How can I determine the sleep mechanism the system uses?

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.

How do you define sleep?

The state where the system is completely switched off requires a swap partition and a resume statement in the command line.

Anything else is a system which - to varying degree - is still powered in a mode referred to as standby or suspended.

Modern systems is capable of being in a suspended state for days and weeks.

On a Lenovo system your red dot over the i will pulse if it is in standby or suspend to ram mode.

1 Like

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.

That will be configured in your power settings.

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.

1 Like

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.


Well, actually ask a question instead of treating a support forum like a search engine. :wink:

You dropped this:


Topic title edited.

How To’s belong in the Tutorials section.

Not sure if I understand what you mean.

But the question was in the title.

How to determine the sleep mechanism in use?

@linux-aarhus and @Teo Many thanks for all the background information.

Executing cat /sys/power/mem_sleep returns [s2idle].

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”:

udev.log_priority=3 amd_pstate.shared_mem=1 amd_pstate=passive splash

Oh, and I do not dual boot, just Linux.

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

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.

1 Like

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.

In /etc/mkinitcpio.conf I have:

HOOKS="base udev autodetect modconf block keyboard keymap consolefont encrypt openswap resume filesystems fsck plymouth"

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:

cryptdevice=UUID=0547c112-bbd6-43c9-8e23-ad3207afedf1:luks-0547c112-bbd6-43c9-8e23-ad3207afedf1 root=/dev/mapper/luks-0547c112-bbd6-43c9-8e23-ad3207afedf1 resume=/dev/mapper/luks-b3063d16-3277-4725-89a2-14f079d36d79 udev.log_priority=3 amd_pstate.shared_mem=1 amd_pstate=passive splash

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.

1 Like

I double checked all the values in /etc/openswap.conf:

## cryptsetup open $swap_device $crypt_swap_name
## get uuid using e.g. lsblk -f

## one can optionally provide a keyfile device and path on this device
## to the keyfile

## additional arguments are given to mount for keyfile_device
## has to start with --options (if so desired)

## 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:

NAME                                          FSTYPE      FSVER LABEL    UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
├─nvme0n1p1                                   vfat        FAT32 NO_LABEL FEEC-51B2                             251.6M    16% /boot/efi
├─nvme0n1p2                                   crypto_LUKS 1              0547c112-bbd6-43c9-8e23-ad3207afedf1                
│ └─luks-0547c112-bbd6-43c9-8e23-ad3207afedf1 ext4        1.0            2b7072e2-76a6-42f5-83c2-2ab80366d449    357G    56% /
└─nvme0n1p3                                   crypto_LUKS 1              b3063d16-3277-4725-89a2-14f079d36d79                
  └─luks-b3063d16-3277-4725-89a2-14f079d36d79 swap        1     swap     f204fe9e-1387-44d5-b256-f0e540591fd7                [SWAP]

What should cryptsetup status cryptswap return? Because, on my system it says: /dev/mapper/cryptswap is inactive.

Theres lots going on in this thread.

I admit I skipped just about everything … but only to mention

Generally speaking suspend is the default.

Unless you configured something else … that is generally what will be used.

You can look for such options especially in your Desktop Environment or Screen Locker or Power settings.

Some options or configurations can also apply a scenario of ‘sleep - then - hibernate’.

All of this is to say that unless you configured hibernation … the system is likely suspending (to ram) by default.

I will also include the general archwiki on the subject
(which should also include configuration avenues)

1 Like

Thanks for your reply and the link.

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. :wink: