Hibernate doesn't wake-up properly

Hi there,
After reinstall from scratch Leap 15.2 MATE, after hibernate from the MATE panel, it goes to sleep but I can’t get wake-up working fine. The desktop starts, the SSD LED lights, I can see some text (no time to read it) then, black screen. After few seconds, 2 LED in the keyboard blink. I have to long press the power button to switch off and reboot.

 cat /proc/version
Linux version 5.3.18-lp152.57-default (geeko@buildhost) (gcc version 7.5.0 (SUSE Linux)) #1 SMP Fri Dec 4 07:27:58 UTC 2020 (7be5551)

cat /sys/power/state
freeze mem disk

cat /sys/power/mem_sleep
s2idle [deep]

                        total        used        free      shared  buff/cache   available
Mem:        8098388     1641312     5515180      203364      941896     5996768
Swap:       8398844           0     8398844

BTW, how I could check if the sleeping state is really S4 Hibernation/Suspend to Disk?

If I need to provide more info or set up parameters, please write the exact command, I am not very skilled.

This means kernel panic (crash). Try to reproduce it when booted into text mode, then there is chance you can capture kernel output on screen with camera. Boot into run level 3, hibernate using “systemctl hibernate”.

It will fail if swap is not larger than ram.

It looks like you may be ok - see if swap is the resume device in /etc/default/grub - I have seen it point to the uuid of the install media instead of the real swap.

It should be the uuid of swap.

 cat /etc/default/grub
# If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update
# /boot/grub2/grub.cfg.

# Uncomment to set your own custom distributor. If you leave it unset or empty, the default
# policy is to determine the value from /etc/os-release
GRUB_CMDLINE_LINUX_DEFAULT="splash=silent resume=/dev/disk/by-id/ata-Samsung_SSD_850_EVO_250GB_S2R6NX0JA50129K-part3 mitigations=auto quiet"

# Uncomment to automatically save last booted menu entry in GRUB2 environment

# variable `saved_entry'
#Uncomment to enable BadRAM filtering, modify to suit your needs

# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
# GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
#Uncomment to disable graphical terminal (grub-pc only)

# The resolution used on graphical terminal
#note that you can use only modes which your graphic card supports via VBE

# you can see them in real GRUB with the command `vbeinfo'
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#Uncomment to disable generation of recovery mode menu entries

#Uncomment to get a beep at grub start

# GRUB_INIT_TUNE="480 440 1"

Will this help?
“ata-Samsung_SSD_850_EVO_250GB” is the system SSD but I can’t see UUID, only “by-id”. sda3 is the swap

 df -h
Filesystem            Size  Used Avail Use% Mounted on
devtmpfs              3.9G     0  3.9G   0% /dev
tmpfs                 3.9G   86M  3.8G   3% /dev/shm
tmpfs                 3.9G  9.8M  3.9G   1% /run
tmpfs                 3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/sda2              45G  7.4G   35G  18% /
tmpfs                 3.9G  4.0K  3.9G   1% /tmp
/dev/sda4             176G   33G  134G  20% /home
/dev/sda1             500M  7.5M  493M   2% /boot/efi
/dev/sdb1             3.6T  3.1T  385G  89% /store1
tmpfs                 791M   28K  791M   1% /run/user/1000

I rebooted with level 3 target in GRUB. Log in and run “systemctl hibernate”
I noticed that when I hibernate from MATE menu, one LED in my keyboard labelled “1” stay steady on unlike from run level 3 this LED is off.
This is why my first question:

BTW, how I could check if the sleeping state is really S4 Hibernation/Suspend to Disk?

When I start again from hibernate (run level 3) I get the text from GRUB with the kernel version but no error message then a short cursor blink persistently.
I have to key Ctl-Alt-Delete to shutdown.

Why 2 different hibernate? Strange for a new install.
Any idea to fix?


Please note the following Linux Kernel comment:

There is currently no way to verify the resume image when returning from hibernate. This might compromise the signed modules trust model, so until we can work with signed hibernate images we disable it when the kernel is locked down.

openSUSE Release Notes – Bug Report #1178830.

Sorry for my ignorance, I just learned about Kernel Lockdown feature. Few idiot questions:

  • How can I check my kernel is locked down?
  • I understand the hibernate image can be changed by an attacker. But is the hibernation process still working or not (hibernation and resume)?
  • If the hibernation process is not fully working, why there is not advert?
  • Is your post directly related to my issue?

Within the systemd Journal, search for “Kernel is locked down”:

 # journalctl --this-boot | grep -i 'Kernel is locked down' --before-context=2 --after-context=2
Dez 10 09:10:58 eck001 kernel: efi:  ACPI 2.0=0x514ca000  ACPI=0x514ca000  SMBIOS=0x5b649000  SMBIOS 3.0=0x5b648000  ESRT=0x57cb4a18  MEMATTR=0x57d34018 
Dez 10 09:10:58 eck001 kernel: secureboot: Secure boot enabled
Dez 10 09:10:58 eck001 kernel: Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7
Dez 10 09:10:58 eck001 kernel: SMBIOS 3.1.1 present.
Dez 10 09:10:58 eck001 kernel: DMI: System manufacturer System Product Name/PRIME B450-PLUS, BIOS 2202 07/14/2020

AFAICS, the current situation is:

  • If the Kernel is locked down, a hibernation image will be written to the Swap partition.
  • But, because hibernation image is not encrypted, it can not be read when the system wakes up.
  • Yes, there is no warning.
  • And yes, there ain’t anything in the Leap 15.2 Release Notes regarding this behaviour – yet …

The “kernel_lockdown.7” man page is not installed by default on Leap 15.2 – the URL is: <https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html&gt;

Thanks, I understand now

 sudo journalctl --this-boot | grep -i 'Kernel is locked down' --before-context=2 --after-context=2
  sudo journalctl --this-boot | grep -i 'lockdown' --before-context=2 --after-context=2

both return nothing, so kernel is NOT locked down … and hibernate can’t wake up correctly.
My thoughts:

  • Kernel locked down is NOT the default state, I didn’t change anything like that in the new install
  • My issue is NOT linked to the kernel locked down issue

Is it important to run without Kernel locked down, in a home environment?

Anyway I’ll not use hibernate, it’s a pity I like it.

That’s for you to decide, depending on your assessment of security risks.

I don’t normally use hibernate, so I have never tested this. Yes, kernel is locked down here. But swap is encrypted, so I think it should work. Maybe I’ll test when I next reboot.

I did some experiments with hibernation. These experiments were all done in KVM virtual machines. I used KDE in each case.

Experiment 1: This virtual machine uses an encrypted LVM, with root, home and swap as part of the encrypted LVM. There is a separate “/boot”, and the root file system uses “ext4”. Booting is with UEFI, but secure-boot is not enabled. However, I am using 32-bit UEFI, so that is possibly an issue.

I used the “Leave” menu entry from right-click on the KDE desktop, and chose hibernate. On reboot, it seemed to be restoring from hibernate. The request for the encryption key was later than with normal booting. And, shortly thereafter, I saw it doing “fsck” on a drive – should not happen on recovery from hibernate. And, sure enough, I got a normal login screen instead of a restored session.

Experiment 2: This virtual machine does not use crypto, and does not use secure-boot. It is UEFI (with 64-bit UEFI).

I hibernated. On reboot, it did restore from hibernation. I got the “unlock screen” and, after unlocking, a restored session.

Experiment 3: This virtual mached does not use crypto. It does use secure-boot (64-bit UEFI). After a normal boot, I do see “kernel lockdown” messages in the “dmesg” output.

I hibernated. On reboot, it did restore from hibernation. The kernel_lockdown does not seem to prevent that.

I guess I should try one more, with 64-bit UEFI and an encrypted LVM.

Some more experiments (continuing from my previous post in this thread):

Experimetn 4: I have Leap 15.2 installed to an external drive (USB external drive). It does use an encrypted LVM.

I booted this external drive using the same virtual machine as in experiment 3. This is with secure-boot, 64-bit UEFI, etc. And, after hibernation, it restored just fine.

I then booted it using the same virtual machine as in experiment 1. So this time, 32-bit UEFI and no secure-boot. Again, it resumed from hibernation without a problem.

So what went wrong in experiment 1 above: That was probably user error. On checking, I notice that I have “noresume” as one of the boot parameters, so I guess I cannot complain that it failed to resume.

Kernel locked down or, not?

I can’t comment your experiments, I am not skilled enough.

I try to understand why I don’t have kernel lockdown and I had a look on the UEFI setup utility. My motherboard is ASRock 970 Extreme4, almost 10 year old. I didn’t have a look for very long time.
In this UEFI setup I have to choose in

Boot options priorities, 4 priorities to set:

  • UEFI Built-in EFI
  • Opensuse
  • Opensuse-secureboot
  • AHCI PO: Samsung SSD
  • Disabled

then in another page I have to choose in

Secure Boot:

  • Enabled
  • Disabled

I don’t really understand the difference between the 2 secure boot.

I’d guess you could help me to choose the best choice in these parameters. Thanks

  1. The “openSUSE-Secure-Boot
    ” should be at the top of the boot priorities list. 1. There may well be another setting for “Windows-UEFI
    ” or “Other/Legacy” – choose “Windows” – the openSUSE EFI is “Redmond compliant” – meaning, the openSUSE EFI has been “accepted” by the powers in Redmond … 1. Enable “Secure Boot

I set up in order:

  • Opensuse-secureboot
  • Opensuse
  • AHCI PO: Samsung SSD
  • UEFI Built-in EFI

and set Secure Boot: - Enabled
There is just after that a button

Install default secure boot keys: Do you really wish to install factory default secure variables (PK, KEK, db, dbx)?

I didn’t set that.

However still no output at

sudo journalctl --this-boot | grep -i 'Kernel is locked down' --before-context=2 --after-context=2
sudo journalctl --this-boot | grep -i 'lockdown' --before-context=2 --after-context=2

So I just read

But as Linus said, kernel lockdown has nothing to do with secure boot. Both are separate things.

As hibernate doesn’t work, how to enable/disable kernel lockdown to try again hibernate?

As far as I know, the kernel is always locked down when you boot with UEFI and secure-boot is enabled.

I found this thread. See comment 5-7 and 11

I tied Alt-SysRq-x in Opensuse/MATE, it open “Save Screenshot”
Any other shortcut?

From this Security thread

To enable kernel lockdown on boot, use the kernel parameter lockdown=mode.

I don’t have this command in my GRUB parameters.
Is there another place it could be?