After hibernating with systemctl hibernate, the system boots normally as if it had been shutdown. I have the resume parameter in the kernel line and the resume hook in mkinitcpio.conf

These are the relevant kernel messages:

$ dmesg | grep -i swap
[    0.000000] Command line: initrd=\initramfs-linux.img root=/dev/sda2 rw resume=/dev/sda4
[    0.000000] Kernel command line: initrd=\initramfs-linux.img root=/dev/sda2 rw resume=/dev/sda4
[    0.350295] PM: Checking hibernation image partition /dev/sda4
[    8.776686] Adding 8191996k swap on /dev/sda4.  Priority:-1 extents:1 across:8191996k FS
$ dmesg | grep -i hibern
[    0.350295] PM: Checking hibernation image partition /dev/sda4
[    0.350301] PM: Hibernation image not present or could not be loaded.

So the only remaining possibility is that systemctl didn't write to disk. In fact, when I run the command, the screen first goes blank for a couple of seconds, then I can see my terminal again, and finally it shutdowns itself.

I read that pm-utils do not work very well with systemd, so I wouldn't want to switch to those. Any suggestions?


  • 4
    I had a similar problem. I fixed it by tweaking the resume= kernel option. Find out the UUID of your swap partition and then try to resume=UUID=....... – Adrian Ratnapala Mar 17 '15 at 4:41
  • @AdrianRatnapala: Thanks for the help! I'll try your solution. – rubik Mar 18 '15 at 1:27
  • I have the same problem. Could you please share your solution here? – frogatto May 28 '15 at 16:01
  • @abforce Following Adrian's solution worked for me. Replace normal paths with UUIDs in the kernel options. – rubik May 28 '15 at 19:12

To elaborate @AdrianRatnapala's comment, you have to:

  1. Find uuid of your swap partition. Suppose the partition is sdb3, then

    $ ls -l /dev/disk/by-uuid/ | grep sdb3
    lrwxrwxrwx 1 root root 10 окт.   9 08:59 1dd7e123-1f82-45f0-a202-0ff3ea6f081a -> ../../sdb3
  2. Open /etc/default/grub, and find the line starting with GRUB_CMDLINE_LINUX_DEFAULT=". Add there between the quotes resume=/dev/disk/by-uuid/your-swap-uuid. As an example:

    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/disk/by-uuid/1dd7e123-1f82-45f0-a202-0ff3ea6f081a"
  3. Run as a root update-grub
  4. A reboot is needed to use the new kernel command-line.
  • I don't use Grub but the essence of the procedure is the same! – rubik Oct 9 '15 at 9:47
  • UUID of my swap changes every reboot so this doesn't work :( – Petr Jan 19 '16 at 16:30
  • @Petr this is weird… UUID should only change upon reformatting. I found alike bug-report though, but this is dated by 2008 year. Okay, just for the safe case try sudo mkswap </dev/partition-name>, then check its UUID with sudo blkid </dev/partition-name>. If it still would change upon reboot, I'd suggest you to ask a question at unix.stackexchange.com – Hi-Angel Jan 19 '16 at 17:55
  • @Petr ah, another thing to try before asking — you could manually set UUID of swap with sudo swaplabel -U <NEW-UUID> </dev/partition-name>. You could generate new UUID with uuidgen utility. – Hi-Angel Jan 19 '16 at 18:05
  • 3
    grub-mkconfig -o /boot/grub/grub.cfg in Arch Linux. :) – vmassuchetto Jun 23 '17 at 19:01

I want to share my success here because it might help others with this issue. Bottom line, for those who want to skip the details: After changing the GRUB_CMDLINE_LINUX_DEFAULT line in the /etc/default/grub file and doing update-grub, do a complete Shut Down and Restart of the machine before trying out the hibernation.

The details: I have just successfully implemented hibernation on the Linux installation of my Lenovo ThinkPad T480 (dual boot Debian 9 and Windows) following the above advice to add a resume=UUID= parameter to the GRUB_CMDLINE_LINUX_DEFAULT line in /etc/default/grub. But it did not work the first time. I added the parameter, ran update-grub, and tried to hibernate (systemctl-hibernate). The system seemed to hibernate, but when powered back on the previous screen image would appear and remain for several seconds before the machine went into the login screen that usually presents on initial startup; all work present before hibernation was gone. I finally noticed (grep 'command line' syslog) that the changed GRUB_CMDLINE_LINUX_DEFAULT line had NOT been passed to the kernel. After more effort, I found that a complete shutdown and restart WOULD result in the changed line being passed (grep 'command line' syslog again). After that, systemctl hibernate induced hibernation as before, but at power on the previous state of the machine was restored correctly.

  • This answer provides some additional useful information that could be appended to the accepted answer. In particular, the need to reboot in order to use the new kernel command-line is obvious to experienced Linux users, but might trip up new users. – Gregor Nov 6 '19 at 15:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.