Hello,
I have recently installed Tumbleweed on an empty disk, using the suggested settings in the graphical installer for full disk encryption and swap with hibernation support (LUKS+BTRFS with a separate LUKS swap, Password only). Yet I have been unable to perform suspend to disk and restore successfully.
After hibernating the first time (either via GUI or systemctl hibernation), it errors out with “kernel: PM: hibernation: Not enough free memory,” the screen blanks for a while before returning to the lock screen. This made me suspect that the installer might have generated too small of a swap partition, so I readjusted the partitions manually using Live CD Gparted. This made no difference to the reported swap size, even if the swap partition itself is now bigger. See the following output:
When I attempted hibernation the second time in a row, the machine finally turns off with the logs ending at “kernel: PM: hibernation: hibernation entry.” Upon starting the machine and selecting the regular boot entry, it boots as if nothing happened, with the RAM contents getting lost. I have consulted with https://en.opensuse.org/SDB:Encrypted_root_file_system and added a resume=/dev/mapper/cr_swap kernel parameter to no avail.
I have additional logs and specs but they seem too long for this post, can I share pastes on external sites here?
swap space simply needs to be big enough to fit the entire hibernation image but that depends how much is used in your RAM during the hibernation process. To be safe you want your swap size at least match the size of your ram (worked always for me).
From what I can tell the OS can access 20 GB of RAM, so the installer understandably created a 20 GB swap partition. After my modifications, the swap partition has 24 GB (out of which it only uses 20 for swap) which should be more than enough, especially as the post reveals I only had 5 GB allocated (0 GB swap) at the time of testing.
To be safe you want your swap size at least match the size of your ram (worked always for me).
and try whether your system hibernates. Otherwise, normally you should have under the “kernel: PM: hibernation: Not enough free memory,” the amount which was expected to hibernate. Could be possible that swap space is still too low.
Here is a systemd log of the previous behaviour (leaving out an AMDGPU warning with a trace that occurs after the hibernation fails):
pc kernel: PM: hibernation: Basic memory bitmaps freed
pc kernel: PM: hibernation: Marking nosave pages: [mem 0x09f00000-0x09f3bfff]
pc kernel: PM: hibernation: Marking nosave pages: [mem 0x582b9000-0x583c7fff]
pc kernel: PM: hibernation: Marking nosave pages: [mem 0x5b21c000-0x5b21cfff]
pc kernel: PM: hibernation: Marking nosave pages: [mem 0x6a2fe000-0x75bfdfff]
pc kernel: PM: hibernation: Marking nosave pages: [mem 0x77574000-0x775a2fff]
pc kernel: PM: hibernation: Marking nosave pages: [mem 0x77ff7000-0x77ffcfff]
pc kernel: PM: hibernation: Marking nosave pages: [mem 0x77fff000-0xffffffff]
pc kernel: PM: hibernation: Basic memory bitmaps created
pc kernel: PM: hibernation: Preallocating image memory
pc kernel: PM: hibernation: Allocated 1967247 pages for snapshot
pc kernel: PM: hibernation: Allocated 7868988 kbytes in 3.45 seconds (2280.86 MB/s)
pc kernel: PM: hibernation: Creating image:
pc kernel: PM: hibernation: Need to copy 3104317 pages
pc kernel: PM: hibernation: Normal pages needed: 3104317 + 1024, available pages: 2049071
pc kernel: PM: hibernation: Not enough free memory
pc kernel: PM: hibernation: Error -12 creating image
...
pc kernel: PM: hibernation: Basic memory bitmaps freed
pc kernel: PM: hibernation: hibernation exit
pc systemd-sleep[55505]: Faijan to put system to sleep. System resumed again: Cannot allocate memory
Which seems to suggest that PM has ~8 GiB available and wants ~12GiB, which the partition should accommodate easily (one page is 4kB). Image size is currently set to 8211791872. Additionally, /sys/power/pm_trace returns zero, so there is no crash to be seen. Setting the image size to 0 did nothing, the system shuts down with a noticeable delay when I ask KDE to hibernate but doesn’t restore.
When hibernation works you don’t select any entry at all but the system simply restores the previous state and you are presented with a lock screen.
So there is something basically wrong in your setup; the hibernation image is likely sitting in your swap but a “normal boot menu” tells that the system is not trying to retrieve it.
What bootloader are you using? I’m not sure, but maybe the now default grub_BLS does not support resume from hibernation the way the old grub_efi did.
As stated, I left it all at default (so GRUB2_BLS with Secure Boot support, I have SB currently disabled for diagnostics), I only added the kernel option. I just tried modifying the launch options to point to the raw partition directly, to no change in behaviour.
I have not used grub_BLS yet, so cannot help here; you need to wait for a bootloader expert to chime in and confirm if / how grub_BLS can manage hibernation and resume. My feeling is that if you are seeing a boot menu you are not going to resume.
And I feel that at this point your problem has nothing to do with swap size or kernel boot options (but I cannot tell for sure…)
Check that the .conf file(s) in /boot/efi/loader/entries/ contain the relevant resume= parameter on the options line.
If you do make an edit, don’t forget to regenerate the initramfs with sudo dracut -f
This ensures the kernel can find the hibernation image at boot. With LUKS swap, the resume hook in initramfs is essential; otherwise encrypted swap cannot be read at boot.
Broadcast message from user@(Sat 2026-01-17 18:30:59 CST):
The system will suspend now!
Jan 17 18:30:59 kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Jan 17 18:30:59 kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
Jan 17 18:30:59 systemd-logind[825]: The system will suspend now!
Jan 17 18:30:59 ModemManager[910]: <msg> [sleep-monitor-systemd] system is about to suspend
Jan 17 18:30:59 NetworkManager[915]: <info> [1768696259.9704] manager: sleep: sleep requested (sleeping: no enabled: yes)
Jan 17 18:30:59 ModemManager[910]: <msg> [sleep-monitor-systemd] ready to sleep; dropping inhibitor
Jan 17 18:30:59 NetworkManager[915]: <info> [1768696259.9709] manager: NetworkManager state is now DISABLED (ASLEEP)
Jan 17 18:30:59 systemd[1]: Reached target Sleep.
Jan 17 18:30:59 systemd[1]: Starting System Suspend...
....
....
Jan 17 18:31:57 systemd-sleep[2880]: Successfully thawed unit 'user.slice'.
Jan 17 18:31:57 systemd[1]: systemd-suspend.service: Deactivated successfully.
Jan 17 18:31:57 systemd[1]: Finished System Suspend.
Jan 17 18:31:57 systemd[1]: Stopped target Sleep.
Jan 17 18:31:57 systemd[1]: Reached target Suspend.
Jan 17 18:31:57 systemd[1]: Stopped target Suspend.
Jan 17 18:31:57 systemd-logind[825]: Operation 'suspend' finished.
Jan 17 18:31:57 NetworkManager[915]: <info> [1768696317.7098] manager: sleep: wake requested (sleeping: yes enabled: yes)
@deano_ferrari Secure boot must be off/disabled then, doesn’t work when kernel lockdown was introduced in 6.18 kernel. Suspend only AFAIK as can be seen in my output.
Check that the .conf file(s) in /boot/efi/loader/entries/ contain the relevant resume= parameter on the options line.
Verified that my boot entry contains the expected entry and that it matches my fstab configuration.
Don’t forget to regerenate initramfs
I believe I did that after every parameter change, ran it just in case, with no change in behaviour.
@malcolmlewis
My use for hibernation is to be able to return to my work overnight / after a weekend and to force disk encryption after suspend. The machine’s default S3 suspend-to-idle or even suspend-to-ram would eat power constantly, thus draining the device’s battery before I get back to it. I wish not to derail this thread by discussing the why’s.
One of the present-at-installation files, 10-persistent-policy.conf, sets persistent_policy="by_uuid". Does this mean that I have to address the swap partition by UUID?
AFAIK it should be resume=UUID=....... then update via update-bootloader commands. Also can you confirm which efi loader is used, shim or grub with showing the output fromefibootmgr.
