Bug 1467045 - 233-6: systemctl hibernate no longer works: sleep verb not supported by logind
233-6: systemctl hibernate no longer works: sleep verb not supported by logind
Status: NEW
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
26
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-02 04:57 EDT by dac.override
Modified: 2017-08-12 10:09 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description dac.override 2017-07-02 04:57:51 EDT
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:
Comment 1 Matthew Gilbert 2017-07-17 11:44:18 EDT
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!
Comment 2 fedora 2017-07-17 13:31:39 EDT
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?
Comment 3 dac.override 2017-07-17 13:36:19 EDT
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.
Comment 4 fedora 2017-07-17 14:14:35 EDT
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.
Comment 5 dac.override 2017-07-17 14:17:17 EDT
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
Comment 6 Matthew Gilbert 2017-07-17 14:57:20 EDT
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?
Comment 7 Matthew Gilbert 2017-07-17 14:59:44 EDT
I assume this means resume is in my initramfs:

dracut --list-modules | grep resume                                                                                                    
resume
Comment 8 fedora 2017-07-17 15:30:01 EDT
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?
Comment 9 Matthew Gilbert 2017-07-17 15:44:25 EDT
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!
Comment 10 Matthew Gilbert 2017-07-17 15:48:55 EDT
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
Comment 11 fedora 2017-07-17 15:52:01 EDT
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
Comment 12 fedora 2017-07-17 15:58:13 EDT
And since kernel-4.11.10 is available by now you might want to test this one.
Comment 13 Matthew Gilbert 2017-07-17 16:02:51 EDT
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.
Comment 14 Matthew Gilbert 2017-07-17 16:12:37 EDT
4.11.10 doesn't change the behavior.
Comment 15 Matthew Gilbert 2017-07-17 16:22:44 EDT
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.
Comment 16 fedora 2017-07-17 16:38:06 EDT
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
Comment 17 dac.override 2017-07-17 16:40:23 EDT
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
Comment 18 fedora 2017-07-17 16:43:29 EDT
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.
Comment 19 Claude Frantz 2017-08-07 12:45:51 EDT
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.
Comment 20 Alan 2017-08-11 06:37:00 EDT
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
Comment 21 Alan 2017-08-11 06:44:07 EDT
contents of:

$ cat /sys/power/disk
[platform] shutdown reboot suspend test_resume

BIOS PC / no secure boot or UEFI
Comment 22 Alan 2017-08-11 10:05:16 EDT
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
Comment 23 Alan 2017-08-12 10:09:06 EDT
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.

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