Description of problem: System hibernates just fine: # journalctl -b-1 | tail -20 bře 06 18:46:29 localhost.localdomain /usr/libexec/gdm-x-session[2595]: (**) Microsoft Mouse: (accel) selected scheme none/0 bře 06 18:46:29 localhost.localdomain /usr/libexec/gdm-x-session[2595]: (**) Microsoft Mouse: (accel) acceleration factor: 2.000 bře 06 18:46:29 localhost.localdomain /usr/libexec/gdm-x-session[2595]: (**) Microsoft Mouse: (accel) acceleration threshold: 4 bře 06 18:46:29 localhost.localdomain /usr/libexec/gdm-x-session[2595]: (II) input device 'Microsoft Mouse', /dev/input/event19 is tagged by udev as: Mouse bře 06 18:46:29 localhost.localdomain /usr/libexec/gdm-x-session[2595]: (II) input device 'Microsoft Mouse', /dev/input/event19 is a pointer caps bře 06 18:48:35 localhost.localdomain systemd-logind[767]: Hibernate key pressed. bře 06 18:48:35 localhost.localdomain NetworkManager[895]: <info> sleep requested (sleeping: no enabled: yes) bře 06 18:48:35 localhost.localdomain NetworkManager[895]: <info> sleeping... bře 06 18:48:35 localhost.localdomain NetworkManager[895]: <info> (wlp3s0): device state change: unavailable -> unmanaged (reason 'sleeping') [20 10 37] bře 06 18:48:35 localhost.localdomain NetworkManager[895]: <info> (00:18:13:AB:D3:C1): device state change: disconnected -> unmanaged (reason 'sleeping') [30 10 37] bře 06 18:48:35 localhost.localdomain NetworkManager[895]: <info> NetworkManager state is now ASLEEP bře 06 18:48:36 localhost.localdomain gnome-session[1598]: Window manager warning: Failed to set power save mode for output HDMIA32: Operace zamítnuta bře 06 18:48:37 localhost.localdomain gnome-session[1598]: Window manager warning: Failed to set power save mode for output LVDS15: Operace zamítnuta bře 06 18:48:40 localhost.localdomain systemd-logind[767]: Delay lock is active (UID 42/gdm, PID 1605/gnome-shell) but inhibitor timeout is reached. bře 06 18:48:41 localhost.localdomain systemd[1]: Reached target Sleep. bře 06 18:48:41 localhost.localdomain systemd[1]: Starting Sleep. bře 06 18:48:41 localhost.localdomain systemd[1]: Starting Hibernate... bře 06 18:48:41 localhost.localdomain kernel: PM: Hibernation mode set to 'platform' bře 06 18:48:41 localhost.localdomain systemd-sleep[27230]: Suspending system... bře 06 18:48:41 localhost.localdomain org.freedesktop.Telepathy.ConnectionManager.haze[2693]: tp-glib-Message: Exiting But unfortunately, it never wakes up again. The only relevant information I can find in journal after boot is: # journalctl -b | grep ibernat bře 07 09:49:51 localhost.localdomain kernel: PM: Hibernation image not present or could not be loaded. Version-Release number of selected component (if applicable): $ rpm -q kernel kernel-3.18.1-1.fc22.x86_64 kernel-3.18.1-2.fc22.x86_64 kernel-3.19.0-1.fc22.x86_64 $ uname -a Linux localhost.localdomain 3.19.0-1.fc22.x86_64 #1 SMP Mon Feb 9 08:42:43 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: System hibernates, but newer wakes up. Expected results: System can wake up after hibernation. Additional info:
The system was successfully put into hibernation with 'systemctl hibernate' and systemd thinks hibernation is possible. [ 30.489423] f22m.localdomain systemd-logind[747]: Hibernation is possible, Active(anon)=202204 kB, size=8388604 kB, used=0 kB, threshold=98% Later, when I press the power button, it boot like normal - there's no resume from hibernation. There's the same seemingly bogus message as this report "kernel: PM: Hibernation image not present or could not be loaded." Is the kernel supposed to find the image or systemd though?
kernel-4.0.0-1.fc22.x86_64 systemd-219-11.fc22.x86_64 This is not a regression, as far as I'm aware, it's never worked. Fails on both Apple EFI hardware, as well as a Dell XPS UEFI system.
Created attachment 1015968 [details] journalctl, systemctl hibernate, debug
Created attachment 1015969 [details] journalctl, resume from hibernate, debug
I've seen this bug in a number of previous Fedora releases. I'm currently experiencing it in Fedora 20, with kernel 3.19.5-100.fc20.x86_64, and systemd-208-30.fc20.x86_64. journalctl -b | grep ibernate gives the following: May 04 00:17:47 sparky kernel: PM: Hibernation image not present or could not be loaded. May 04 00:17:47 sparky kernel: PM: Hibernation image partition 8:51 present May 04 00:17:47 sparky kernel: PM: Looking for hibernation image. May 04 00:17:47 sparky kernel: PM: Hibernation image not present or could not be loaded. In previous versions, the bug has gone away or been fixed at some point.
On 3.19.8-100.fc20.x86_64 #1 SMP with Gnome 3.10.2 on HP Z800 (5.8GBRAM, 12 cores) with NVidia Quadro FX 4800 Graphics (Driver 340.76) (Power Switch hibernate worked on previous kernels with restart bypassing BIOS) Now it fails apparently not writing the image file, judging from lack of significant disk activity. Subsequent power-on yields blank screen with <ctrl><alt><F2> giving only blinking active cursor. pm-suspend does work, but power-on goes through BIOS and grub before state is restored. systemctl hibernate fails as with power switch method
(In reply to Chris Murphy from comment #1) > The system was successfully put into hibernation with 'systemctl hibernate' > and systemd thinks hibernation is possible. > > [ 30.489423] f22m.localdomain systemd-logind[747]: Hibernation is > possible, Active(anon)=202204 kB, size=8388604 kB, used=0 kB, threshold=98% > > Later, when I press the power button, it boot like normal - there's no > resume from hibernation. There's the same seemingly bogus message as this > report "kernel: PM: Hibernation image not present or could not be loaded." > > Is the kernel supposed to find the image or systemd though? probably this bug may help https://bugzilla.redhat.com/show_bug.cgi?id=1213131
(In reply to sohny thomas from comment #7) This might be workaround, but not solution. I don't have such parameter on other systems and they work just fine. Moreover, I believe that it should depend on kernel parameter in initram, which looks pretty reasonable: # dracut --print-cmdline rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap resume=/dev/mapper/fedora-swap root=/dev/mapper/fedora-root rootfstype=ext4 rootflags=rw,relatime,seclabel,data=ordered
*** This bug has been marked as a duplicate of bug 1206912 ***