Hibernation resume fail on linux kernel 4.9.0, Debian 9

Question

I recently upgraded my kernel from 3.16.4 (Debian jessie) to 4.9.0 (Debian stretch). Everything was fine, until I tried to "Hibernate" (suspend to disk).

When I use Hibernate option in LXDE, it appears to hibernate. I can hear the disk spindle ticking and writing data. But the problems appears when resuming from hibernation. The kernel successfully restores the image from swap, but then freezes and reboots, with all that work lost. I could not find answer anywhere on internet. The people are just solving some mistakes around not setting /etc/initramfs-tools/conf.d/resume or have set kernel paramters, or have wrong entry in /etc/fstab. I have these correct. Correct UUID in /etc/initramfs-tools/conf.d/resume, correct fstab and not set resume kernel paramter.

• I moved the swap partition outside of the extended partition to primary. The UUID was saved and applied to the new swap.

• The system reaches "Restoring image 100%" and then "Suspending consoles", and then it powers off and boots normally, with all work lost.

• Tried clean install, but without luck.

• Happens only on i386 (32-bit x86), amd64 (64-bit x86) does not suffer.

Disk partition table layout:

NAME   FSTYPE LABEL    UUID                                 MOUNTPOINT
sda                                                         
├─sda1 ext4   HDD      <ROOT-UUID> /
└─sda2 swap   HDD-SWAP <SW-UUID> [SWAP]
sr0

The sda2 was logical(resides-inside-extended) before the upgrade.

Fstab:

UUID=<ROOT-UUID> / ext4 errors=remount-ro 0 1
UUID=<SW-UUID> none swap sw 0 0

/etc/initramfs-tools/conf.d/resume

RESUME=UUID=<SW-UUID>

Kernel cmdline

BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-686-pae root=UUID=<ROOT-UUID> ro quiet

System information:

Computer: Compaq CQ60-120ec
Swap Size: 3.5GiB
Processor: AMD Athlon X2 64 QL-66
GPU: Nvidia Geforce 8200M G
Memory: 2G DDR2 667MHz
Desktop Environment: LXDE
Debian Version: 9 (stretch)
Kernel version: 4.9.0-3
Graphics Driver: nvidia legacy 304xxx

(I know the processor is 64bit but it came with 32bit os originally, so I thought it was 32bit until I examined /proc/cpuinfo)

Answer 1

The issue is due to a conflict between hibernate and kASLR on x86-32. This can be solved by disabling kASLR with the nokaslr kernel boot option. x86-64 is not affected.

For Grub this can be done by editing /etc/default/grub and adding nokaslr to the boot options, e.g.: GRUB_CMDLINE_LINUX_DEFAULT="quiet nokaslr"

Then run update-grub to update the configuration and reboot to give it a try.

I had exactly the same issue and it seems that only the PAE kernel is affected by that issue. The same kernel without PAE works without issues.

The workaround for me was to install linux-image-686 and uninstall linux-image-686-pae and linux-image-4.9.0-4-686-pae. The exact kernel version may change over time due to upgrades, but basically the currently running PAE kernel need to be replaced with a kernel without PAE.

It has actually nothing to do with PAE support of the CPU, as my CPU supports PAE according to /proc/cpuinfo. But PAE is anyway not of much use on old notebooks.

It has also nothing to do with kernel 4.9 PAE as the same issue happens with kernel 4.13 PAE from Debian backports.

Answer 2

Probably /etc/uswsusp.conf wants a changed entry for the 'resume device', if this is not used, myabe just try to grep your old UUID in all files in /etc to find a place wher change is needed. Also an update-initramfs would be necessary, I would say.

Answer 3

I was getting the same error. Reinstalling with the latest netinst iso, i.e. debian-9.1.0-amd64-netinst.iso sorted it out. Bug appears to have been fixed (at least for this architecture).

Answer 4

I removed uswsusp and hibernation works again like a charm. BTW I think that it was already the case before Jessie when I was using nvidia driver, I tested using uswsusp and had to remove it to get hibernation working.

Answer 5

If you have a swap partition (with correct size) and if you edit "/etc/initramfs-tools/conf.d/resume" with what "#blkid" result and i386 will not hibernate correct than it's a bug on Debians i386 4.9 kernel ! Update kernel to a version greater than 4.9 or roll back to 3.16 kernel.

Answer 6

Please excuse the generic nature of this reply. I have seen similar questions all over the Web and decided to write one answer for all. I encountered the same problem as you upgrading Debian-Jessie on an Hp2510. I switched to Ubuntu-desktop and found it there too. I subsequently did my testing on Ubuntu and the Hp2510 so it may not completely apply to your situation.

Some older computers updated with new Linux systems experience boot problems. They may not boot at all or they may take as long as three minutes to boot. Coincidentally, they either fail to hibernate or take so long to hibernate and dehibernate that the capability is useless. Often this is not because old computers are simply slow but because of a change introduced in the 4.8 Linux kernel, causing a problem with a very common Intel chipset, which includes svideo output. Beginning with this kernel, any computer with this chipset will experience boot problems unless the Linux command line argument "video=SVIDEO-1:d" is included in GRUB_CMDLINE_LINUX. This will significantly shorten both 64-bit and 32-bit boot times but fixes hibernate problems only for 64-bit. No 32-bit system supports hibernate after this point. Further, the boot times for all 4.8 and 4.9 kernel versions are bad (except 4.8.rc1-7). This is finally resolved in 4.10. Kernels 4.8 and 4.9 should just be avoided (they are obsolete anyway).

If you want the fastest boot times, use a pre-4.8 kernel. I would use Ubuntu-desktop 15.04 with kernel updated to 4.7.10. This is the only way to get hibernation in a 32-system. The 64-bit system boots 7% slower than the 32-bit but it is still faster than any later version. If you want a currently supported 32-bit system and are willing to forego hibernation, use any that either are released or updated to a 4.10 or later kernel. Any 64-bit version works after 4.8 with the video fix but for best performance avoid 4.8 and 4.9.

To add the video fix do sudo nano /etc/default/grub. After closing nano do sudo update-grub. Unless GRUB_CMDLINE_LINUX_DEFAULT, which is inserted after GRUB_CMDLINE_LINUX, is blank, "video=SVIDEO-1:d" will not be the last Linux command line argument, which some people say is necessary. It actually can be anywhere.

You can always invoke hibernate with the pm-hibernate command in a terminal (or tty) but to have it an available GUI option you need to create or add to the policy file /etc/polkit-1/localauthority/50-local.d/ com.ubuntu.enable-hibernate.pkla (obviously distro-specific) the following text:

[Re-enable hibernate by default for login1]
    Identity=unix-user:*
    Action=org.freedesktop.login1.hibernate
    ResultActive=yes
[Re-enable hibernate for multiple users by default in logind]
    Identity=unix-user:*
    Action=org.freedesktop.login1.hibernate-multiple-sessions
    ResultActive=yes

Answer 7

At times the problem is not in the grub or UUID. This also happens when you are out of storage space. There will be no write space left thus resuming from hibernation will freeze.

When you get to that error, you can click on alt+ f2/f3/f7 or ctrl+alt+ f2/f3/f7 to open terminal. Login to your account or root using terminal.

Then run the command sudo df -h to check on storage space. In my case I had no space on my /dev/sda1 so check on free space on the drives in the list.

If you are out of space, please try deleting some files to get some considerable amount of space.

After that you can click on alt+f1 or ctrl+alt+f1 and wait for the login gui to appear or type reboot in the terminal to reboot