Bug 1206912
| Summary: | After upgrade hibernate no longer works | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Stefan Becker <chemobejk> | |
| Component: | systemd | Assignee: | systemd-maint | |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 24 | CC: | afolger, andreas.kriegl, aschorr, ben.r.xiao, blaffablaffa, bugzilla_acct_1959, bugzilla, covex, danielsun3164, devin, dimitris.on.linux, dracut-maint-list, gjs0206, greta_watson, harald, johannbg, jonathan, jsynacek, kmoriwak, lnykryn, long, msekleta, opensource, orion, pspacek, rjones, rrankin, sohnythomas, s, stefan.hoelldampf, systemd-maint, vondruch, zbyszek | |
| Target Milestone: | --- | Keywords: | Reopened | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1357886 (view as bug list) | Environment: | ||
| Last Closed: | 2017-08-08 11:56:05 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
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. 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. (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. 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. (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? 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?! (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 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> - 038-33.git20141216 - Do not fsck on resum from hibernate Resolves: rhbz#1174945 * Tue Dec 16 2014 Harald Hoyer <harald> 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. (In reply to Adam Pribyl from comment #8) > The dracut changelog says > * Fri Mar 06 2015 Till Maas <opensource> - 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. Any update on this? I suppose it would affect Fedora 22 as well, and I would guess it's a blocker there. 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. 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 ;-)) 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. No, my installation was fresh, not an upgrade. Just want to report that after a fresh install of Fedora 22, the problem persists. Can we make headway? This is really annoying. Lets switch that bug to systemd... In the meantime we have to use workaround. There are similar bugs: bug 1199708 bug 1207425 bug 1213131 bug 1206936 It would be nice if this issue get more attention ... *** Bug 1199708 has been marked as a duplicate of this bug. *** 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. 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. (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. Sorry, I meant the fs UUID, not PARTUUID. 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? 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. 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". 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. (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. 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. 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. Moving to F22 as the problem still exists On a fresh installation? A fresh installation adds "resume=" to grub configuration in F22? I doubt that. My bad. I meant in rawhide/23. It's the only explanation left to understand why this appears to be ignored. I can go ahead and confirm resume= is still missing in a fresh install of F23. (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... 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. 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 (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. (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. 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. *** Bug 1357886 has been marked as a duplicate of this bug. *** Re-open and assigning to F24 as this problem still hasn't been fixed. Still using the resume= workaround on F24. 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. 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. 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. 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. |
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.