Bug 1206912 - After upgrade hibernate no longer works
Summary: After upgrade hibernate no longer works
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1199708 1357886 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-29 14:19 UTC by Stefan Becker
Modified: 2017-08-08 11:56 UTC (History)
33 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1357886 (view as bug list)
Environment:
Last Closed: 2017-08-08 11:56:05 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1206936 None CLOSED Laptop does not resume from hibernate, boots instead, due to missing resume= kernel argument 2019-08-13 21:28:44 UTC
Red Hat Bugzilla 1396407 None CLOSED [RFE] Add support for Intel Rapid Start (IRS) 2019-08-13 21:28:44 UTC

Internal Links: 1206936 1396407

Description Stefan Becker 2015-03-29 14:19:32 UTC
Description of problem:

After updating to latest F21 stable updates, hibernate stops working, because the information about the resume device is no longer processed correctly.

Version-Release number of selected component (if applicable):

systemd-216-21.fc21.x86_64
dracut-038-33.git20141216.fc21.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Put machine to hibernate
2. power up machine
3.

Actual results:
machine does not hibernate, it boots normally

Expected results:
machine should detect valid hibernation on swap device and resume from that

Additional info:

The latest dracut update takes a new feature of systemd into use:

/usr/lib/dracut/modules.d/95resume/module-setup.sh:

    if [[ $hostonly_cmdline == "yes" ]]; then
        cmdline  >> "${initdir}/etc/cmdline.d/95resume.conf"
        echo  >> "${initdir}/etc/cmdline.d/95resume.conf"
    fi

    # if systemd is included and has the hibernate-resume tool, use it and nothing else
    if dracut_module_included "systemd" && [[ -x $systemdutildir/systemd-hibernate-resume ]]; then
        inst_multiple -o \
                      $systemdutildir/system-generators/systemd-hibernate-resume-generator \
                      $systemdsystemunitdir/systemd-hibernate-resume@.service \
                      $systemdutildir/systemd-hibernate-resume
        return 0
    fi

On my system that generates this information into the initrd:

# lsinitrd | fgrep resume
resume
-rw-r--r--   1 root     root           40 Mar 29 16:17 etc/cmdline.d/95resume.conf
-rwxr-xr-x   1 root     root        28704 Mar 29 16:17 usr/lib/systemd/systemd-hibernate-resume
-rwxr-xr-x   1 root     root        37048 Mar 29 16:17 usr/lib/systemd/system-generators/systemd-hibernate-resume-generator
-rw-r--r--   1 root     root          635 Mar 13 10:44 usr/lib/systemd/system/systemd-hibernate-resume@.service

# lsinitrd -f etc/cmdline.d/95resume.conf
 resume=/dev/mapper/VolGroup00-LogVol02

But unfortunately systemd-hibernate-resume-generator(?) ignores the contents of etc/cmdline.d/95resume.conf and *ONLY* looks for "resume=" on the kernel command line. By adding "resume=/dev/mapper/VolGroup00-LogVol02" to /boot/grub2/grub.cfg I got hibernation working again.

Unfortunately I do not know if this needs to be fixed in dracut (add resume= to the kernel command line?) or systemd (check for etc/cmdline.d/ contents?), so I file this bug to dracut first.

Comment 1 Jonathan S 2015-03-31 15:50:48 UTC
Yes, I have this some problem too.

Stefan's analysis of the problem seems to be correct and the adding of 'resume=....' to the kernel command line seems to be a valid workaround.

Comment 2 Roy Rankin 2015-04-08 22:14:14 UTC
I also have this problem on the 3.19 kernels. By adding the output of lsinitrd -f etc/cmdline.d/95resume.conf which for me was " resume=UUID=88974181-39f3-44f6-af13-dab8e5b6d4fc" as above restored hibernate function with 3.19.3 kernel.
Note that without the workaround hibernate is still working with the 3.18.9 kernel.

Comment 3 Stefan Becker 2015-04-09 02:08:02 UTC
(In reply to Roy Rankin from comment #2)
> Note that without the workaround hibernate is still working with the 3.18.9
> kernel.

I assume that you have not regenerated the initrd for the 3.18.9 kernel with latest dracut. Updating to a new kernel does not modify older initrds on /boot.

Comment 4 Adam Pribyl 2015-04-09 18:39:43 UTC
After update of dracut from -32 to -33 I can not resume from hibernation anymore - system restarts ignoring the hibernation image. Downgrading the dracut and regenerating the initramfs solves the problem.

Comment 5 Harald Hoyer 2015-04-23 12:52:45 UTC
(In reply to Adam Pribyl from comment #4)
> After update of dracut from -32 to -33 I can not resume from hibernation
> anymore - system restarts ignoring the hibernation image. Downgrading the
> dracut and regenerating the initramfs solves the problem.

even with "resume=..." on the kernel command line?

Comment 6 Adam Pribyl 2015-04-24 07:50:33 UTC
I've added the resume to /etc/default/grub2 and upgraded the dracut and kernel to latest version. After reboot I was dropped to dracut rescue shell, the root file system had many corruptions (this could be just an accident), the newly generated entry in grub2.conf had no resume at kernel command line. After fixing the filesystem I regenerated grub2.conf manually, regenerated the initramfs and now I can again hibernate and resume again... but is this really way it _should_ work?!

Comment 7 Harald Hoyer 2015-04-24 09:19:21 UTC
(In reply to Adam Pribyl from comment #6)
> I've added the resume to /etc/default/grub2 and upgraded the dracut and
> kernel to latest version. After reboot I was dropped to dracut rescue shell,
> the root file system had many corruptions (this could be just an accident),
> the newly generated entry in grub2.conf had no resume at kernel command
> line. After fixing the filesystem I regenerated grub2.conf manually,
> regenerated the initramfs and now I can again hibernate and resume again...
> but is this really way it _should_ work?!

"resume=<swapdev>" really should be added by anaconda on installation and corrected, if you change your swap device.

hibernation only works reliably, if you specify the device.

dracut can help you with the kernel command line:

On my machine:
$ dracut --print-cmdline 
 resume=UUID=03ea4b3f-94fd-40c8-81e8-802734082be8 root=UUID=d5e53483-30bc-4119-8c0c-841d47a2f76b rootfstype=btrfs rootflags=rw,noatime,compress=lzo,ssd,discard,space_cache,autodefrag,inode_cache,subvol=root:foo:hoyer.harald.OS:x86_64

Comment 8 Adam Pribyl 2015-04-24 12:18:55 UTC
Up to -32 version of dracut I never used "resume=anything" intentionaly anywhere. It was "magicaly" present in initramfs:etc/cmdline.d/95resume.conf, thats all. I luckily did not used anaconda for many years... I do not know where the "resume" should be added by anaconda.


The dracut changelog says
* Fri Mar 06 2015 Till Maas <opensource@till.name> - 038-33.git20141216
- Do not fsck on resum from hibernate
Resolves: rhbz#1174945

* Tue Dec 16 2014 Harald Hoyer <harald@redhat.com> 038-32.git20141216
- fixed systemd journal in the initramfs
Resolves: rhbz#1174733

I did not checked exact changes in the source but I do not understand how the above change is related to this behavior change of dracut.

Now dracut prints for me:
dracut --print-cmdline 
 resume=UUID=2b46147e-18f0-4366-ac99-172e7de7e502 root=UUID=6789faaa-68e7-40cf-8d19-fa55c1b49531 rootflags=rw,relatime,data=ordered rootfstype=ext4
but this is probably irrelevant as it works now with "resume=" in grub2.conf.

Comment 9 Stefan Becker 2015-04-24 12:33:38 UTC
(In reply to Adam Pribyl from comment #8)
> The dracut changelog says
> * Fri Mar 06 2015 Till Maas <opensource@till.name> - 038-33.git20141216
> - Do not fsck on resum from hibernate
> Resolves: rhbz#1174945

Corresponding git change:

 http://pkgs.fedoraproject.org/cgit/dracut.git/diff/0032-do-not-fsck-on-resume-from-hibernation.patch?h=f21&id=0716a8025f162faafd0b4b716a4f393c9786ed6c


> I did not checked exact changes in the source but I do not understand how
> the above change is related to this behavior change of dracut.

I do not see anything about "fsck" in the above change. It only takes "systemd-hibernate-resume" into use, so IMHO the changelog is mis-leading.

systemd-hibernate-resume & friends *IGNORE* the contents of etc/cmdline.d/95resume.conf and only use "resume=" from the kernel command line, i.e. what is in grub.cfg. *THAT* is the issue here.

If you roll back to -32 and run dracut, systemd-hibernate-resume will no longer be used, and hibernate will magically starts working again.

Can please someone who knows the dracut internals explain how the information in etc/cmdline.d/95resume.conf is supposed to be used?

(a) Do the dracut scripts have to read that information manually or
(b) does dracut automagically append this information to /proc/cmdline? (is that even possible????)

If it is (a) then the bug is in systemd-hibernate-resume.

If it is (b) then the bug is in dracut, i.e. it doesn't feed this information early enough into /proc/cmdline for systemd-hibernate-resume to pick up.

Comment 10 Lorenzo Pistone 2015-05-02 10:37:42 UTC
Any update on this? I suppose it would affect Fedora 22 as well, and I would guess it's a blocker there.

Comment 11 Till Maas 2015-05-04 09:55:32 UTC
IMHO it is a bug/missing feature of systemd unless there is a way to modify /proc/cmdline.

The patch should fix the fsck bug, because without it there seemed to be a race condition causing the root filesystem to be checked before a resume was attempted, the details are in the referenced bug 1174945.

Comment 12 A. Folger 2015-05-05 10:07:37 UTC
I am suffering from the same problem since some recent updates. Is a fix in the works? (The upside is that I am now checking what dracut does, but really, we shouldn't expect every user to learn this ;-))

Comment 13 Adam Pribyl 2015-05-05 19:39:22 UTC
I do not think so. The reason is, this IMHO happens only to the systems, that were upgraded, and most probably not via Anaconda. As I understood, Anaconda should place the required resume= option to the kernel command line. 

The other thing is why systemd ignores the etc/cmdline.d/95resume.conf in initramfs... to my knowledge, nobody posted a bug against systemd.

Comment 14 Lorenzo Pistone 2015-05-05 19:52:03 UTC
No, my installation was fresh, not an upgrade.

Comment 15 A. Folger 2015-07-28 11:24:27 UTC
Just want to report that after a fresh install of Fedora 22, the problem persists. Can we make headway? This is really annoying.

Comment 16 Adam Pribyl 2015-07-28 11:33:27 UTC
Lets switch that bug to systemd...

In the meantime we have to use workaround.

Comment 17 Vít Ondruch 2015-08-18 17:38:12 UTC
There are similar bugs:

bug 1199708
bug 1207425
bug 1213131
bug 1206936

It would be nice if this issue get more attention ...

Comment 18 Vít Ondruch 2015-08-18 17:38:47 UTC
*** Bug 1199708 has been marked as a duplicate of this bug. ***

Comment 19 Lorenzo Pistone 2015-10-04 14:03:18 UTC
With the recent kernels 4.1.7-200 and 4.1.8-200 the method of appending manually the "resume=" argument to the kernel command line doesn't work anymore. Or maybe it's a systemd upgrade that broke it? I don't know, it is time already to fix this bug.

Comment 20 Lorenzo Pistone 2015-10-04 14:12:37 UTC
I noticed that using the partition name (/dev/sdxy) instead of the partition UUID works. Needless to say, I double-checked that the partition UUID that I use is correct and so it is.

Comment 21 Chris Murphy 2015-10-04 16:11:24 UTC
(In reply to Lorenzo Pistone from comment #20)
> I noticed that using the partition name (/dev/sdxy) instead of the partition
> UUID works. Needless to say, I double-checked that the partition UUID that I
> use is correct and so it is.

I don't expect it to work with partition UUID, which is a GPT concept. It needs to be set to the swap fs UUID as reported by blkid.

Comment 22 Lorenzo Pistone 2015-10-04 16:13:26 UTC
Sorry, I meant the fs UUID, not PARTUUID.

Comment 23 Adam Pribyl 2015-10-06 17:55:26 UTC
I do not understand how this bug could be ignored for such a long time, when it has to hit anybody using hibernation. I can confirm that with kernel-4.1.8-100.fc21.x86_64 the resume does not work.


dracut --print-cmdline 
resume=UUID=2b42147e-18f0-4366-ac99-172e7de7e602 root=UUID=4389fa2a-68e7-40cf-8d19-fa55c1b49531 rootflags=rw,relatime,data=ordered rootfstype=ext4

it is on the dracut commandline, but the resume terribly fails with various letters from systemd startup reamining on the screen. 

Does anybody know the workaround if the systemd-maint does not care?

Comment 24 Chris Murphy 2015-10-06 18:45:22 UTC
As far as I'm aware, kernel maintainers have given up on hibernation (suspend to disk). It appears to all be very hardware specific. And while systemd has a hook in for the support still in the kernel, it ultimately depends on the kernel.

These days on both Macs and PCs hibernation is managed by firmware. I think about the best case is if we can have some hybrid sleep where the battery gets low enough and it causes the system to wake and poweroff instead of just dying in sleep or trying to hibernate, either of which can result in data loss or corruption.

Comment 25 Adam Pribyl 2015-10-06 19:56:56 UTC
Chris, this is the first time I read this... would welcome any reference. 

I do use the hibernation on normal desktop PCs without batteries because it saves me whole desktop work and waits for me even when power is lost in meantime. Of course, this also saves more power and stops various LED blinking "effects".

Comment 26 Chris Murphy 2015-10-06 20:25:59 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=781749
https://bugzilla.redhat.com/show_bug.cgi?id=781749#c12

The basic gist there is that it's fundamentally dangerous and inherently broken, is unlikely to get fixed, and is being removed as much as possible from user space.

Comment 27 Till Maas 2015-10-06 20:33:49 UTC
(In reply to Chris Murphy from comment #26)

> The basic gist there is that it's fundamentally dangerous and inherently
> broken, is unlikely to get fixed, and is being removed as much as possible
> from user space.

afaics, the only thing that is broken here (reported in this bug) is that systemd/dracut does not properly check whether there is a hibernate image on swap before continuing to boot regularly. The support in the kernel is fine.

Comment 28 Lorenzo Pistone 2015-10-07 12:18:43 UTC
Imo that comment doesn't mean that it is actively being killed off, it's just stating the fact that there's not enough manpower to maintain it at consistent quality. Also it's a discussion from March 2012 so most probably irrelevant today.

I agree with Till Maas, the problem here is just poor cooperation between dracut/anaconda/systemd in adding a "resume=..." argument to the kernel command line, *and* (I believe) a recent regression in passing a UUID in such argument, rather than a partition name. If someone can direct me in debugging this second bug on my system I'll be happy to do it.

Comment 29 Fedora End Of Life 2015-11-04 10:17:11 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 30 Stefan Becker 2015-11-04 11:32:04 UTC
Moving to F22 as the problem still exists

Comment 31 Lorenzo Pistone 2015-11-04 11:34:05 UTC
On a fresh installation?

Comment 32 Stefan Becker 2015-11-04 11:36:08 UTC
A fresh installation adds "resume=" to grub configuration in F22? I doubt that.

Comment 33 Lorenzo Pistone 2015-11-04 12:15:37 UTC
My bad. I meant in rawhide/23. It's the only explanation left to understand why this appears to be ignored.

Comment 34 long 2016-05-12 22:34:16 UTC
I can go ahead and confirm resume= is still missing in a fresh install of F23.

Comment 35 Benjamin Xiao 2016-06-01 16:40:42 UTC
(In reply to Lorenzo Pistone from comment #20)
> I noticed that using the partition name (/dev/sdxy) instead of the partition
> UUID works. Needless to say, I double-checked that the partition UUID that I
> use is correct and so it is.

I can confirm this. Using FS UUID makes the hibernation fail randomly but specifying the swap partition by /dev works every time.

Not sure why this is taking such a long time to fix. We really just need the installer to specify a grub parameter for the swap partition. The lack of a resume parameter is really dangerous, especially for situations where laptops run out of batteries. Gnome attempts to hibernate when laptops run out of power, but if the resume parameter isn't there, you might as well just hard power off...

Comment 36 Chris Murphy 2016-06-01 17:23:44 UTC
What's taking a long time is there's a disagreement whether resume= should be handled in dracut or by the installer. An additional problem, in my opinion, is there is a rather significant lack of interest in power management in Fedora, from the Workstation WG, the kernel and installer teams. So until that changes, it's unlikely to get significant investment in making this work out of the box and maintaining it.

In the meantime, bug 1332266 is accepted as freeze exception, that change will cause systemd to understand resume= is missing, and therefore it won't mislead upower into thinking suspend to disk is supported, and therefore you shouldn't get a message in the DE indicating the system will hibernate. Instead, in critical power situations, you should get a notification the system will shut down.

Comment 37 Chris Murphy 2016-06-01 17:31:33 UTC
As described, this bug is probably not a bug, but a duplicate of bug 1206936.

Also, it's unreliable to support this with resume=/dev/ designation because on any system with two or more drives, that designation can flip between boots and there is no way around that. So it needs to work reliably with UUID or with a label, and if a label that means anaconda needs to give swap a label at creation time.

An additional problem is that by default Anaconda puts swap on LVM. The dracut maintainer says the hibernation image being located on LVM isn't supportable.
http://systemd-devel.freedesktop.narkive.com/yDJDcA9o/systemd-hibernator-generator-does-not-function-on-default-fedora-install#post9

Comment 38 Stefan Becker 2016-06-01 17:55:20 UTC
(In reply to Chris Murphy from comment #37)
> An additional problem is that by default Anaconda puts swap on LVM. The
> dracut maintainer says the hibernation image being located on LVM isn't
> supportable.

Funny, swap on LVM and hibernation has worked flawlessly in Fedora for well over 10 years now. Swap on encrypted LVM is also the easiest way for whole disk encryption from usability PoV.

I can only urge dracut and/or systemd maintainers that they are not going to break this.

Comment 39 Stefan Becker 2016-06-01 18:08:18 UTC
(In reply to Chris Murphy from comment #37)
> Also, it's unreliable to support this with resume=/dev/ designation because
> on any system with two or more drives, that designation can flip between
> boots and there is no way around that.

That statement doesn't apply to LVM: resume=/dev/mapper/<VG name>-<LV name> is a name that is always the same at each boot.

Comment 40 Fedora End Of Life 2016-07-19 13:15:48 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 41 Chris Murphy 2016-07-20 17:50:55 UTC
*** Bug 1357886 has been marked as a duplicate of this bug. ***

Comment 42 Stefan Becker 2016-07-20 17:57:30 UTC
Re-open and assigning to F24 as this problem still hasn't been fixed.

Still using the resume= workaround on F24.

Comment 43 Chris Murphy 2016-07-20 18:18:13 UTC
To fix it requires acknowledgment of whose bug it is: systemd, or the installer. On other distros, the installer includes the resume= boot parameter hint in the bootloader configuration file. But on Fedora, Anaconda doesn't do this, and there is disagreement between systemd and installer developers where it belongs.

Comment 44 gjs 2016-12-26 12:12:28 UTC
Maybe this helps too:
After upgrading from Fedora 24 to 25 suspend and hibernate did not work any longer.
Acer Aspire TimelineX 3830TG wth dual graphics card (Intel and Nvida)
Because switchable with Wayland has a better support I set both video-cards at work in the bios prior to update.
After upgrade no suspend or hibernate albeit it was possible from the command-line.
Probably there is a problem in using switchable and both graphics cards with Wayland in FC25?

Make sure you use the Intel one:
Reboot and set bios to "integrated" (so no more nvidia just Intel)
Solution: edit GRUB: GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rhgb quiet acpi=on acpi_osi=Linux"

This seems to work.

Comment 45 Fedora End Of Life 2017-07-25 18:52:10 UTC
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 46 Fedora End Of Life 2017-08-08 11:56:05 UTC
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.