I have read the power management articles in the Manjaro Wiki as well as in the Arch Wiki, but I still don’t understand how to easily and reliably determine which method exactly I have set up on my machine.
I ask because on my Lenovo Z16 AMD Gen 1 sleep only works up to and with kernel 6.5. Anything newer and the machine will wake up after sleep, but the screen would stay black.
So I wanted to see if I was maybe still using a setup that had been replaced by something more modern since I installed my computer more than 3 years ago, or if there was maybe a less problematic setup than the one I was using.
I’m referring to the state my laptop is in when I close it or send it to sleep via the GNOME shell. The red dot above the Lenovo logo then pulsates.
I have a SWAP partition:
/dev/nvme0n1p1 4096 618495 614400 300M EFI System
/dev/nvme0n1p2 618496 1966029281 1965410786 937.2G Linux filesystem
/dev/nvme0n1p3 1966029282 2000397734 34368453 16.4G Linux filesystem
Unfortunately, I can’t remember what I set up during the installation a couple of years ago and would therefore like to understand my configuration better.
What I mean - why I say define sleep - to different people the words may have different meaning - please see the systemctl --help - the system commands section where I have trouble figuring out what they exactly do (that is for another time to look into).
System Commands:
is-system-running Check whether system is fully running
default Enter system default mode
rescue Enter system rescue mode
emergency Enter system emergency mode
halt Shut down and halt the system
poweroff Shut down and power-off the system
reboot Shut down and reboot the system
kexec Shut down and reboot the system with kexec
soft-reboot Shut down and reboot userspace
exit [EXIT_CODE] Request user instance or container exit
switch-root [ROOT [INIT]] Change to a different root file system
suspend Suspend the system
hibernate Hibernate the system
hybrid-sleep Hibernate and suspend the system
suspend-then-hibernate Suspend the system, wake after a period of
time, and hibernate
The commands is executed by the desktop in question
systemctl suspend - the led pulsates
systemctl hibernate contents of RAM is written to SWAP partition and led goes off
I am defaulting my systems to 8GB swap even I have 64G and 32G systems - I usually commit my code to remote git and close my virtual machines before closing the lid - so 8GB is more than enough.
If your system does not work as expected on kernel > 6.5 it is possibly an added kernel argument or the ACPI table contains unexpected values.
I have just got myself a x13 gen4 without Windows - and my system suspends and wakes up as expected.
This is pure thought appearing while writing this: If you are dual-booting Windows then values may have been written to ACPI tables which makes Linux act weird - especially when waking up from suspend or hibernation.
I was looking for a way to enable Quectel EM05-G and found a lot of information on various Lenovo models on Laptop/Lenovo - ArchWiki - While your specific Z-series is not listed - you may find inspiration.
If we are talking about the suspend mode, you can check what the kernel thinks it has with
cat /sys/power/mem_sleep
Unfortunately it is not always what it really is (because the oem uefi is a closed source and a guessing game for the kernel). So it may be worth toggling. Chances are, with a modern laptop with windows 10 or 11 preinstalled, it supports only s2idle (because that is what Microsoft thinks is cool now) so it my be worth switching for a test. Note that s2idle is not much more than a turned off screen under linux so it barely save battery.
systemctl suspend does what it is supposed to do. The laptop goes to sleep and the LED pulsates.
systemctl hibernate also sent the laptop to sleep, but the LED then blinked quickly (as did the power button on the side of the laptop) AND after that the laptop could not be woken up. Interesting side note: After running systemctl hibernate, the LEDs of the F1, F4 and F9 buttons on the keyboard lit up, all others were dark. F1 = mute sound, F4 = mute microphone and F9 = disable camera
In the “GNOME Settings” under “Power” and “Power Button Behavior”, “Suspend” is selected.
The following kernel parameters are set in “/etc/default/grub”:
Thanks for the help once again. I will now read through the two Wiki articles again and either leave the issue until I reinstall my system or hopefully will be able to narrow down and solve the problem.
When putting a thinkpad in hibernation the led and the power led will blink fast until memory has been written to swapspace. When done the system powers off.
Usually it takes longer for the system to resume from hibernation than it takes from a clean shutdown.
If your system fully encrypted then you need to configure the system to be able to read the swap and thus be able to load the hibernated system.
My knowledge on the subject is not up-to-date
Reading
My old knowledge seems to relate to Legacy BIOS systems and is still used with a Manjaro installation with swap and hibernate.
My first thought is - ahh - that is why hibernate does not work - you don’t have the resume=UUID= and you are likely missing the resume HOOK in mkinitcpio.conf
From reading these links new knowledge is that systemd is capable of handling this automagically - to a degree - resume hook must be in HOOKS array of mkinitcpio.conf, initramfs rebuilt and adequate swapspace is available.
I tested again with systemctl hibernate and in fact the Th(i)inkPad LED does eventually stop blinking and the computer shuts down. However, after powering the system back on the machine seems to boot normally without resuming from SWAP, as I am prompted with the GRUB encryption passphrase dialog.
I seem to have the correct resume entry for LUKS in /etc/default/grub (the ID is correct at least), here’s the entire GRUB_CMDLINE_LINUX_DEFAULT= content:
I didn’t mention the LUKS entries in /etc/default/grub at first because I wasn’t sure if I should make the IDs of my partitions public. Sorry about that.
I’m not sure if it’s worth the effort to get this under control, as my knowledge is limited and I don’t want to bother anyone here in the Forum with it.
The reason I wanted to fix it in the first place is because I wantes to be able to use one of the newer kernels. But as said, as soon as I use a kernel above 6.5, my system will not wake up from idling properly. As I now know my system is not hibernating but “normally” sleeping via s2idle. So, I am not sure if the fact that hibernation does not seem to be configured properly has something to do with the issues around waking up from idling.
Maybe I should just reinstall the system soon?
Anyway, thanks for your advice and help. Much appreciated!
This indicates an issue with the hibernation process - possibly the size of the swap - or it is an issue with opening the swap.
When using an encrypted system - swap partition is encrypted as well (insecure if not) and you are expected to unlock the encrypted system before you resume.
For this to happen correctly the init need to know the key to use when unlocking the swap.
That key is usually placed inside the encrypted root - so root must be unlocked - the key provided to init which then unlock the swap partition and resume the system.
You should have a configuration /etc/openswap.conf which provides the instruction necessary for openswap hook to work correctly.
Perhaps that configuration is incorrect or the key is not where it is supposed to be - I have no idea.
I double checked all the values in /etc/openswap.conf:
## cryptsetup open $swap_device $crypt_swap_name
## get uuid using e.g. lsblk -f
swap_device=/dev/disk/by-uuid/b3063d16-3277-4725-89a2-14f079d36d79
crypt_swap_name=luks-b3063d16-3277-4725-89a2-14f079d36d79
## one can optionally provide a keyfile device and path on this device
## to the keyfile
keyfile_device=/dev/mapper/luks-0547c112-bbd6-43c9-8e23-ad3207afedf1
keyfile_filename=crypto_keyfile.bin
## additional arguments are given to mount for keyfile_device
## has to start with --options (if so desired)
#keyfile_device_mount_options="--options=subvol=__active/__"
## additional arguments are given to cryptsetup
## --allow-discards options is desired in case swap is on SSD partition
cryptsetup_options="--type luks"
… and they seem to be correct when comparing them with lsblk -f:
I set up hibernation a while ago according to the Arch wiki, and I always assumed that it worked as expected. However, I recently discovered that my system is actually only suspending and not hibernating.
I noticed this while investigating after trying to install a kernel higher than 6.5 and the computer would not properly wake up after suspending.
When trying to hibernate, the computer seems to do so, e.g. with systemctl hibernate, but then reboots instead of waking up (restoring from swap) afterwards.
I am not sure what could be causing this, as at least to my limited understanding and from following the wiki, everything seems to be set up correctly.
It is probably some really stupid little mistake I made, like most of the time.
