Setup hibernation on Silverblue / Kionite?

Have you been able to successfully script these steps (bash script?) for Silverblue?

On Silverblue 38, my output from step 11-15 (excluding 13):

 sudo systemctl hibernate
[sudo] password for asterix: 
Call to Hibernate failed: Not enough swap space for hibernation
[asterix@fedora ~]$ sudo audit2allow -b


#============= systemd_logind_t ==============
allow systemd_logind_t swapfile_t:dir search;
[asterix@fedora ~]$ cd /tmp
[asterix@fedora tmp]$ sudo audit2allow -b -M systemd_hibernate
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i systemd_hibernate.pp

[asterix@fedora tmp]$ sudo semodule -i systemd_hibernate.pp
[asterix@fedora tmp]$ sudo systemctl hibernate
Call to Hibernate failed: Not enough swap space for hibernation
[asterix@fedora tmp]$ 

Keep getting the nagging not enough swap space for hibernation.
I have 8GB RAM, created a 12g swapfile. I do not think the swap filesize is the real issue. I had the same thing on Manjaro Gnome before I switched to Fedora SB. But last year (Manjaro, but with older kernel) it worked just fine. Stopped working earlier this year.

free -h
               total        used        free      shared  buff/cache   available
Mem:           7,4Gi       1,6Gi       2,9Gi       599Mi       3,0Gi       5,0Gi
Swap:           19Gi          0B        19Gi

System is a HP Spectre x360 with Intel 11th Gen CPU.

EDIT:
Good news, got rid of that nagging check by doing this:
sudo mkdir -pv /etc/systemd/system/{systemd-logind.service.d,systemd-hibernate.service.d}
echo -e "[Service]\nEnvironment=SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1" | sudo tee /etc/systemd/system/systemd-logind.service.d/override.conf
echo -e "[Service]\nEnvironment=SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1" | sudo tee /etc/systemd/system/systemd-hibernate.service.d/override.conf

  • reboot.

Hibernate immediately shows up as an option in Gnome power menu + sudo system-ctl reboot gives me black screen for a second, then login screen… unfortunately…

1 Like

Your EDIT result is actually the exact thing the SELinux module was trying to avoid. You completly disabled one of the hibernation error checks to force it to try anyway.
The point of my walk thru was to get it all setup without needing to disable any of the checks, since they’re there for a good reason.

That said, if it works for you and you’re happy with it, then that’s fine. There’s actually directions linked at the top of this thread from Fedora Magazine that just tell you to disable all error checks rather than setting up even SELinux.


For your particular failure, you should probably enable the debugging and see more details about what “not enough space” means. In my experience that usually means there really isn’t enough non-zram space.
It would also be helpful to see your swap settings to verify how much space you really allocated to non-zram swap.

1 Like

Yes I thought that was indeed what I was doing :slight_smile: Just as a test.

I enabled debugging, but there is soo much logging in those seconds, also, I cannot figure out how to read full lines. I tried copying to text editor. Anyway, I could not find any clear warnings or errors.

I will remove the swapfile are re-follow the steps, this time creating a much larger swapfile.
I am a bit confused as to why free -h shows 19G swapfile. I would expect my 12GB file + 4GB zram.

Which settings? How?
Sorry I am no expert…

If you followed the Troubleshooting section of my walk thru post, you should see more detailed info a little before the error saying there wasn’t enough space.
jounalctl should give you scrollable output like if you were in a less command, which includes left-right scrolling.

I thought I listed it in my walk thru but apparently not. You can run swapon with no arguments to get it to list all your swap devices and their sizes.

Yes I know how to scroll but it was just a lot of mumbo jumbo…

But this was smart:

I only have 8GB physical RAM, yet this is the output:

$ swapon
NAME               TYPE      SIZE USED PRIO
/dev/zram0         partition 7,4G   0B  100
/var/swap/swapfile file       12G   0B    0

No idea why zram0 is not 50% of my RAM. It’s much bigger! So swapfile will need to be 16GB.
I will go for 20GB instead just to test.

Edit:
I did swapoff /var/swap/swapfile and
sudo rm /var/swap/swapfile
then followed the steps to create a 20g swapfile, (steps 3 to 6) and rebooted. Unfortunately the behaviour did not change.

1 Like

Not yet, I also thought there was some problem with it, LUKS encryption or TPM or something

So I removed /etc/systemd/system/systemd-logind.service.d/override.conf and /etc/systemd/system/systemd-hibernate.service.d/override.conf, rebooted, cleaned up journalctl, ran sudo systemctl hibernate. There was no warning about swap size :smiley:
But it didn’t work: screen went black for 1 sec, then login screen. I notice the following messages in the log:

Sleep mode "disk" is supported by the kernel.
Disk sleep mode "platform" is supported by the kernel.
/dev/zram0: ignoring zram swap
/var/swap/swapfile: detection of swap file offset on Btrfs is not supported
/var/swap/swapfile: device matches configured resume settings.
Hibernation will attempt to use swap entry with path: /var/swap/swapfile, device: 259:3, offset: 8332544, priority: 0
Enough swap for hibernation, Active(anon)=1632748 kB, size=20971516 kB, used=0 kB, threshold=98%

But also lots of these (with different destinations), not sure if related?
Got message type=signal sender=:1.16 destination=n/a path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=UnitRemoved cookie=2662 reply_cookie=0 signature=so error-name=n/a error-message=n/a

This is the full output of sudo journalctl -u systemd-logind.service from the moment I run the hibernation command, with debug enabled:

This is readable if you hit download and open in a text editor with word wrap disabled.

I can’t find anything specific in there, any moment when it fails to hibernate.

FYI: In my bios (HP Spectre x360, i5-1135G7), TPM STATE is enabled, TPM DEVICE is available.
Should I disable TPM STATE? Or would that require me to re-install Silverblue?
I barely use my laptop outside of my own house so I am not sure if TPM is really important for security in my case.

1 Like

This may be the issue. The swapfile used for hibernation should not be on btrfs since that would require loading the kernel and drivers for btrfs before that file could be read.

Place the swapfile on an ext4 file system or use a separate swap partition and it should work.

Please read back. The whole purpose of this thread and the guide written in this thread is to get hibernation to work via a swapfile in a separate btrfs subvolume.

It worked just fine for me last year.

1 Like

There is a bug in Linux kernel 6.2 and later that causes TPMs on most laptops to be unusable (because most TPM hardware in laptops is actually bad and not TPM 2.0 compliant), but I’d expect a different error.

What that suggests though is that you still have Secure Boot enabled. Unfortunately the kernel Lockdown driver only supoorts “encrypted hibernate swap”, but has no implementation to support any actually encrypted swap configurations. So it’s currently not possible on Linux to use Secure Boot and the Lockdown module (which Fedora always includes) with Hibernate.

Turning off your TPM or just Secure Boot realistically has almost no actual security impact though. It mitigates only an attacker-physically-present (Evil Maid), and can be bypassed if the attacker has either the hardcoded Microsoft signing key (let’s not talk about MS’s security record, but this isn’t super likely even still), your motherboard vendor’s signing key (already leaked for MSI and a few other major vendors), Fedora’s signing key (very unlikely), or a custom signing key you manually enrolled (do you have any ekms/akmod drivers?). The threat model is very unlikely and has lots of wholes init, so most researchers agree it’s largely theater for th vast majority of users.

Not quite. The actual file system you put the swapfile on is irrelevant. The file itself is in swap format and is basically a bag of bits. You calculate/read the file offset during setup and add it to your kargs because it gets read from the raw disk using the disk bytes offset and not by interpreting the file system to reach the file.

The guidance about BTRFS specifically is actually outdated as well. BTRFS used to have lots of problems calculating and preserving the fixed file offset necessary for the resume to read the raw file without the file system, but then they added support for calculating it with an actual BTRFS command, and ensured that as long as you put the swapfile in its own subvolume marked as non-COW it will work.

See your own post:

You are actually using the btrfs command, not some outdated stuff, to calculate the offset.
I simply followed your steps using those commands.

1 Like

Exactly, to calculate the offset. Which is then added as a byte value to the kernel command line arguments.

At boot time the kernel just goes to the fixed offset on the storage device, without ever trying to interpret any file system it might contain, and reads in the bag of bits that is the swap file.

The difficulties with file systems come in when you need to ensure the swap contents are written without changing the hardcoded offset, and when trying to figure out what the absolute disk offset is of the swapfile so you know what to hardcoded. Both have been fixed by BTRFS, which is why my instructions tell you to use a BTRFS command to get the absolute offset.

1 Like

You don’t make any sense to me, recommending me to use ext4.

Check your own first 2 steps please.

Also, I switched from Manjaro to Fedora SB a few weeks ago. Manjaro Setup includes hibernation options. If you choose hibernation during setup, it automatically creates a BTRFS swap partition and hibernation just works out of the box without tinkering. On the same laptop, it worked just fine.
And following these instructions (pretty much identical to yours) a manually configured btrfs subvolume instead of partition worked on Manjaro. Again, same hardware.

I’m curious to understand why it doesn’t work on Fedora and why it doesn’t give any clear errors in the log.

2 Likes

When I’m trying to follow this guide, on step 11 I’m getting an error Call to Hibernate failed: Not enough swap space for hibernation.

I have 32 GiB of RAM and 8GiB of ZRAM, which requires somewhere around 48GiB of swap. I am creating a /var/swap/swapfile with size of 56GiB.

System: Fedora Silverblue 39.

Root is encrypted with LUKS, but that shouldn’t be the issue.

Secure Boot is disabled.

1 Like

Is there any news for Fedora 40 being able to hibernate?

1 Like

news of hibernate

Unfortunately, I didn’t hear any yet.

I am thinking of making my own UBlue config when I’ve got time for that.

Which is not soon, I’m afraid.

Didn’t find anything that will simplify this process too. Seems like on Fedora side nobody really wants hibernation. But how do people manage pausing complex tasks then?

1 Like

KDE has sessionrestore now, but for sure not the same.

When creating a ublue config, dont create your own edition but fork config and add those here. Even without desktop-specific GUI integration (GNOME has an extension, KDE may automatically show it) this will be VERY valuable.

Check in the ublue discourse group or create an issue to discuss this first.

I feel you a lot, Fedora moves very slowly, you need to do the stuff you want implemented yourself often, and then wait for it to be merged.

Ublue is more pain tolerant than Fedora I think, would you agree @castrojo ? Something too experimental for Fedora could maybe be tested there and then implemented upstream.

1 Like

I guess hibernation should work without issue if you simply use a separate partition… I don’t think that’s healthy for your SSD plus it takes up some space (a subvol could be created on the fly each time you hibernate). But for end user it’s the same experience… I’ll probably just do that.

2 Likes