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]
free
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.
Thanks
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 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.
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_DISTRIBUTOR=
GRUB_DEFAULT=saved
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=8
GRUB_CMDLINE_LINUX_DEFAULT="splash=silent resume=/dev/disk/by-id/ata-Samsung_SSD_850_EVO_250GB_S2R6NX0JA50129K-part3 mitigations=auto quiet"
GRUB_CMDLINE_LINUX=""
# Uncomment to automatically save last booted menu entry in GRUB2 environment
# variable `saved_entry'
# GRUB_SAVEDEFAULT="true"
#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)
GRUB_TERMINAL="gfxterm"
# 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'
GRUB_GFXMODE="auto"
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
# GRUB_DISABLE_LINUX_UUID=true
#Uncomment to disable generation of recovery mode menu entries
# GRUB_DISABLE_RECOVERY="true"
#Uncomment to get a beep at grub start
# GRUB_INIT_TUNE="480 440 1"
GRUB_BACKGROUND=
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
SUSE_BTRFS_SNAPSHOT_BOOTING="true"
GRUB_USE_LINUXEFI="true"
GRUB_DISABLE_OS_PROBER="false"
GRUB_ENABLE_CRYPTODISK="n"
GRUB_CMDLINE_XEN_DEFAULT="vga=gfx-1024x768x16"
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
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?
Thanks
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.
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.
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
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
”.