Description of problem: systemctl hibernate no longer works as of 233-6 Version-Release number of selected component (if applicable): 233-6 How reproducible: systemctl hibernate Steps to Reproduce: 1. systemctl hibernate 2. 3. Actual results: not hibernating Expected results: hibernate Additional info:
I also see this. Worked for me in early F26 alphas, but stopped working and still no longer works. I am also running systemd 233-6. Unfortunately, hibernate is the only sleep method that works on my laptop!
Working fine running systemd 233-6 here, I have a bit of a weird setup though with a swapfile on an encrypted root partition. Did you add the dracut resume module to your initramfs?
Did you do a clean install of Fedora 26 Release? It seems both of use updated from 26-Alpha to Release. So it may be related to the upgrade path? Nonetheless "sleep verb not supported by systemd-logind" seems unrelated to dracut and initramfs to me.
So the screen doesn't even turn off after systemctl hibernate for you? I also used it since the Alpha-Release and hibernate is working on both my desktop pc and laptop. You might want to try another kernel though. With 4.11 my laptop refuses to boot after hibernating and I can't test with 4.11 on my desktop.
Screen does not turn off, systemctl hibernate just returns. Ive migrated to rawhide in the meanwhile and there it works again. (Linux 4.13RC0 + systemd v234) So can't really easily test it on Fedora 26 anymore
I can test, I'm still on F26. All I get when I run systemctl hibernate is: Failed to hibernate system via logind: Sleep verb not supported I also have my swap on an encrypted root. How do I add the dracut resume module to my initramfs?
I assume this means resume is in my initramfs: dracut --list-modules | grep resume resume
No, this means that it's available (--help says: --list-modules List all available dracut modules.) Add this to /etc/dracut.conf: add_dracutmodules+="resume" Then rebuild your current initramfs with dracut --force as root. But if hibernating worked before I don't think this will help. And if you're using a swapfile you will also need the resume_offset kernel parameter. Maybe check if hibernating manually with echo disk > /sys/power/state does work?
Oh shoot, sorry, I'm giving wrong information: I have a swap partition. /dev/mapper/fedora-swap swap swap defaults,x-systemd.device-timeout=0 0 0 I'm trying the dracut module now. Thanks!
I tried updating dracut, still get verb not supported. Trying to hibernate manually I get: [root@]# echo disk > /sys/power/state bash: echo: write error: Operation not permitted
Seems like /sys/power/disk also plays a role here, maybe this can help: https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt
And since kernel-4.11.10 is available by now you might want to test this one.
I can't write /sys/power/disk: [root@]# echo reboot > /sys/power/disk bash: echo: write error: Operation not permitted [root@]# cat /sys/power/disk [disabled] I'll try updating to 4.11.10 to see if it changes.
4.11.10 doesn't change the behavior.
After some googling, I saw folks reporting their /sys/power/disk were disabled if they had secure boot enabled, and that they were able to hibernate if they disabled secure boot. I also tried disabling secure boot, and now can hibernate. Yay! Except, this used to work with secure boot enabled. Any idea what changed? I'd really like to re-enable secure boot.
Yeah I also saw this before, I just thought it's not worth noticing since you didn't change anything. No idea, probably some changes in the kernel. If you have some time and want to help, get the kernel sources and use git bisect to find the bad commit, then file a kernel bug and let the kernel devs fix it. Well, but since the reporter already wrote that updating to a newer kernel or systemd version fixes the bug I assume somebody already fixed it and you can just update to a newer kernel, for example from the kernel vanilla repo: https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories
Its not that simple Rawhide doesnt have the grub update that enables secure boot that 26 has. What I am saying is that secure boot is not enabled here on rawhide and this might explain why hibernate works here
Oh, you're right I didn't think of that. Then someone should really check for kernel bugs and if there are none bisect it, I'll check if I can get secure-boot working on my laptop.
The kernel is reported as 4.11.11-300.fc26.i686+PAE. The shutdown in the hibernate state seems to be without errors. The last entries as noted by journalctl: Aug 07 16:00:03 defi systemd[1]: Reached target Sleep. -- Subject: Unit sleep.target has finished start-up -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit sleep.target has finished starting up. -- -- The start-up result is done. Aug 07 16:00:03 defi systemd[1]: Starting Hibernate... -- Subject: Unit systemd-hibernate.service has begun start-up -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-hibernate.service has begun starting up. Aug 07 16:00:03 defi kernel: PM: Hibernation mode set to 'platform' Aug 07 16:00:03 defi kernel: PM: Syncing filesystems ... Aug 07 16:00:03 defi systemd-sleep[13638]: Suspending system... -- Subject: System sleep state hibernate entered -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- The system has now entered the hibernate sleep state. ...skipping... Aug 07 16:00:03 defi systemd-logind[677]: Delay lock is active (UID 0/root, PID 2373/upowerd) but inhibitor timeout is reached. Aug 07 16:00:03 defi systemd[1]: Reached target Sleep. -- Subject: Unit sleep.target has finished start-up -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit sleep.target has finished starting up. -- -- The start-up result is done. Aug 07 16:00:03 defi systemd[1]: Starting Hibernate... -- Subject: Unit systemd-hibernate.service has begun start-up -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-hibernate.service has begun starting up. Aug 07 16:00:03 defi kernel: PM: Hibernation mode set to 'platform' Aug 07 16:00:03 defi kernel: PM: Syncing filesystems ... Aug 07 16:00:03 defi systemd-sleep[13638]: Suspending system... -- Subject: System sleep state hibernate entered -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- The system has now entered the hibernate sleep state. After that, the system restarts and it shows the grub2 menu window.
systemd 233-6.fc26 Fedora 26 (upgraded from F24 where this worked) This is an 2010 Dell with BIOS - secure boot not appicable (no UEFI) Cinnamon 'user applet' PowerOff does not provide option "hibernate" option in F26. # systemctl hibernate Failed to hibernate system via logind: Sleep verb not supported Kernel booted with "resume=/dev/mapper/vg-swap" [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.11.11-300.fc26.x86_64 root=/dev/mapper/vg/LogVol_root ro rd.lvm.lv=vg/LogVol_root rd.lvm.lv=vg/swap rd.lvm.lv=vg/LogVol_usr resume=/dev/mapper/vg-swap LANG=en_GB.UTF-8 rd.driver.blacklist=nouveau vga=837 where /dev/mapper/vg-swap is symlink to /dev/dm-1 $ swapon -s Filename Type Size Used Priority /dev/dm-1 partition 1048572 0 -1
contents of: $ cat /sys/power/disk [platform] shutdown reboot suspend test_resume BIOS PC / no secure boot or UEFI
compared my F24 laptop which can succesfully hibernate via "systemctl hiberante" contents on /etc/systemd/logind.conf and /sys/power/diks are identical yet F26 does not hibernate
upon further testing, it appears that the F26 system can hibernate! The machine has 12GB of RAM and only 1GB swap - when the machine is rebooted, it can be sent to hibernate. After using the system, where the memory used >1.5GB, the hibernate option is no longer available on the GUI or via systemctl. It appears that criteria for allowing hibernate/system memory usage in F26 differs from F24. But for my case (BIOS based F26 x64), I will say this is expected behaviour since used RAM exceeds swap.
I've added resume=<whatever /etc/fstab says is my swap> to my kernel command line and I've added the dracut module and my swap partition is twice the size of my RAM, and I still can't suspend with a fresh installation of F26. Kernel is 4.12.9-300.fc26.x86_64 and secure boot is on.
I'm affected by this as well (Fedora 26 x86_64). After enabling hibernate (adding resume= to GRUB_CMDLINE_LINUX and GRUB_DISABLE_RECOVERY=false to /etc/default/grub, I am only able to hibernate if and only if secure boot is disabled.
@Alan: > The machine has 12GB of RAM and only 1GB swap - when the machine is rebooted, it can be sent to hibernate. > After using the system, where the memory used >1.5GB, the hibernate option is no longer available on the GUI or via systemctl. If you have only 1GB of swap, it is very likely that after some use, the resident memory is higher than the amount of free swap space. When this happens, hibernation is disabled. For reliable hibernation, you needs an amount of swap space at least equal to RAM. This is unrelated to the issue here, which seems to be Secure-Boot related.
*** Bug 1549844 has been marked as a duplicate of this bug. ***
This is outside of the scope of systemd, which just ask the kernel to do the hard work for us ;) tl;dr version: see comment #c13: [root@]# echo reboot > /sys/power/disk bash: echo: write error: Operation not permitted [root@]# cat /sys/power/disk [disabled]
Hi, Unfortunately, hibernation is disabled by the lockdown patch set[0] since there is currently no way to verify the resume image when returning from hibernate. [0] https://src.fedoraproject.org/rpms/kernel/blob/dcd325ca9e08f74233acb6578d46138bfb4c30aa/f/efi-lockdown.patch#_1088
+1 Failed to hibernate system via logind: Sleep verb not supported fresh installed nor changing grub
(In reply to Jeremy Cline from comment #29) > Hi, > > Unfortunately, hibernation is disabled by the lockdown patch set[0] since > there is currently no way to verify the resume image when returning from > hibernate. > > [0] > https://src.fedoraproject.org/rpms/kernel/blob/ > dcd325ca9e08f74233acb6578d46138bfb4c30aa/f/efi-lockdown.patch#_1088 no way to sign the image?
I'm not the authority on this, but my understanding is that yes, there's not currently a way to sign and then verify the image when it's started again so it could be tampered with, thus evading the whole purpose of secure boot.
Why has this bug been closed, can't fix? This is an important feature, imho. At the moment, those people who want hibernation are disabling secure boot in order to get it. This, to me, seems far worse that allowing secure boot with insecure recovery from hibernation. Can't the hibernation problem be brought to the attention of more people, one or more of whom might see a way of fixing it? I understand that Microsoft Windows 10 uses hibernation in its fast boot - if Windows 10 uses hibernation, why can't Linux?
(In reply to Daibhidh from comment #33) > Why has this bug been closed, can't fix? This is an important feature, imho. I closed it because it's an intentional limitation of the secure boot lockdown patches rather than a bug. Upstream is aware of it, and I'm not sure that this is the best place to track enhancements for the patch set. > At the moment, those people who want hibernation are disabling secure boot > in order to get it. This, to me, seems far worse that allowing secure boot > with insecure recovery from hibernation. If we were to drop that patch, it would be a security concern for all users of secure boot which, I believe, is worse than breaking hibernation for the users who require it. If users wish to allow hibernation and keep secure boot enabled, they are free to build a custom kernel that allows that. They should be aware that they undermining the entire purpose of secure boot, though, since they cannot trust that the image they boot hasn't been tampered with. > Can't the hibernation problem be brought to the attention of more people, > one or more of whom might see a way of fixing it? I understand that > Microsoft Windows 10 uses hibernation in its fast boot - if Windows 10 uses > hibernation, why can't Linux? When the patch set (which is not in Linus' tree yet) was submitted for 4.17, the topic of hibernation was briefly discussed: https://marc.info/?l=linux-kernel&m=152414891115530&w=2. Hopefully, it'll eventually be possible to hibernate with secure boot enabled, but for the moment that problem hasn't been solved.
(In reply to Jeremy Cline from comment #34) Thank you very much for the rapid and informative response, I now feel less in the dark about this. > (In reply to Daibhidh from comment #33) > > Why has this bug been closed, can't fix? This is an important feature, imho. > > I closed it because it's an intentional limitation of the secure boot > lockdown patches rather than a bug. Upstream is aware of it, and I'm not > sure that this is the best place to track enhancements for the patch set. As long as a closed problem doesn't become a forgotten problem. Although it is not a bug, from a user's point of view, it is affecting functionality in the same way as a bug, and, on Google search, for example, it still looks like it is considered to be a bug. So should there be a problemzilla forum as well as a bugzilla forum, so that problems outside the bug class continue to be tracked? > > At the moment, those people who want hibernation are disabling secure boot > > in order to get it. This, to me, seems far worse that allowing secure boot > > with insecure recovery from hibernation. > > If we were to drop that patch, it would be a security concern for all users > of secure boot which, I believe, is worse than breaking hibernation for the > users who require it. > > If users wish to allow hibernation and keep secure boot enabled, they are > free to build a custom kernel that allows that. They should be aware that > they undermining the entire purpose of secure boot, though, since they > cannot trust that the image they boot hasn't been tampered with. I would still be concerned about the number of people who are turning off secure boot in order to get hibernate to work: they are not able to spend the time customising the kernel in order to make secure boot work with hibernate, so they turn off secure boot altogether. > > Can't the hibernation problem be brought to the attention of more people, > > one or more of whom might see a way of fixing it? I understand that > > Microsoft Windows 10 uses hibernation in its fast boot - if Windows 10 uses > > hibernation, why can't Linux? > > When the patch set (which is not in Linus' tree yet) was submitted for 4.17, > the topic of hibernation was briefly discussed: > https://marc.info/?l=linux-kernel&m=152414891115530&w=2. Hopefully, it'll > eventually be possible to hibernate with secure boot enabled, but for the > moment that problem hasn't been solved.
(In reply to Daibhidh from comment #35) > (In reply to Jeremy Cline from comment #34) > > Thank you very much for the rapid and informative response, I now feel less > in the dark about this. > > > (In reply to Daibhidh from comment #33) > > > Why has this bug been closed, can't fix? This is an important feature, imho. > > > > I closed it because it's an intentional limitation of the secure boot > > lockdown patches rather than a bug. Upstream is aware of it, and I'm not > > sure that this is the best place to track enhancements for the patch set. > > As long as a closed problem doesn't become a forgotten problem. > > Although it is not a bug, from a user's point of view, it is affecting > functionality in the same way as a bug, and, on Google search, for example, > it still looks like it is considered to be a bug. > > So should there be a problemzilla forum as well as a bugzilla forum, so that > problems outside the bug class continue to be tracked? I'm in the middle of writing some secure boot documentation for https://docs.fedoraproject.org/quick-docs/en-US/kernel/overview.html which should cover hibernation, among other things. Hopefully that will solve this particular issue. > > > > At the moment, those people who want hibernation are disabling secure boot > > > in order to get it. This, to me, seems far worse that allowing secure boot > > > with insecure recovery from hibernation. > > > > If we were to drop that patch, it would be a security concern for all users > > of secure boot which, I believe, is worse than breaking hibernation for the > > users who require it. > > > > If users wish to allow hibernation and keep secure boot enabled, they are > > free to build a custom kernel that allows that. They should be aware that > > they undermining the entire purpose of secure boot, though, since they > > cannot trust that the image they boot hasn't been tampered with. > > I would still be concerned about the number of people who are turning off > secure boot in order to get hibernate to work: they are not able to spend > the time customising the kernel in order to make secure boot work with > hibernate, so they turn off secure boot altogether. It's unfortunate, but it's a trade-off between convenience and security, and it's a choice everyone has to make. If you allow hibernation in the current state of the patch set, you've opened yourself up to the attack secure boot was meant to guard against. I think it's safe to say we all want this to both work "out of the box" for everyone and be secure, but work remains to be done. All that said, there's tools out there like Copr to make it easy for people to build and maintain custom kernels for the community.
For systems with firmware-encrypted OPAL disks, hibernate should be enabled.