Setup hibernation on Silverblue / Kinoite?

There is a tutorial for 36 Workstation. I for now replaced every “/swap” with “/var/swap”, but not sure if that would just work.

Like creating the swap partition in the /var directory and using it the same way.

Do you need to change partitions during setup or something? Is everything included in the setup tutorial?

3 Likes

Yes, you can follow that tutorial and get hibernation to work on Fedora Silverblue.

I have some comments on that guide, however:

  1. dracut is not needed for Silverblue.
  2. You can get the resume offset with sudo btrfs inspect-internal map-swapfile -r /var/swap/swapfile if your btrfs tools are v >= 6.1, which they are on Silverblue 37. There’s no need to download and compile an external program.
  3. The hibernate-preparation.service and hibernate-resume.service configuration is unnecessary and just slows down the hibernation process. Rather, you should just add your swapfile to /etc/fstab.

To elaborate on item 3 above, there’s no harm in automatically mounting your swapfile via /etc/fstab. By default it will get a much lower priority than your zram swap, so it will most likely only ever be used when hibernating. The system will automatically know to use the swapfile for hibernating, because the zram swap is not large enough, as it is configured to be 50% the size of your total RAM.

3 Likes

Hi Eddie, I have done the tutorial along with your comments. Now when I want to run systemctl hibernate for the first time the following error message appears. The swapfile is mounted and the resume parameters are added. Any idea?

Error:
Failed to hibernate system via logind: Not enough swap space for hibernation

Edit:
My failure i forgot this chapter:

$ mkdir -p /etc/systemd/system/systemd-logind.service.d/ $ cat <<-EOF | sudo tee /etc/systemd/system/systemd-logind.service.d/override.conf [Service] Environment=SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1 EOF $ mkdir -p /etc/systemd/system/systemd-hibernate.service.d/ $ cat <<-EOF | sudo tee /etc/systemd/system/systemd-hibernate.service.d/override.conf [Service] Environment=SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1 EOF

Does your system use the swap in addition to the ram? Or just for hibernating?

Just for hibernating.

NAME TYPE SIZE USED PRIO
/dev/zram0 partition 8G 0B 100
/var/swap/swapfile file 40G 0B -2

The exact same thing happened to me :slight_smile:

I’m not sure why it should even be needed though, as my swapfile should be large enough to fit everything. It’s possibly related to this: Failed to hibernate system via logind: Not enough swap space for hibernation · Issue #15354 · systemd/systemd · GitHub

8 posts were merged into an existing topic: Setup hibernation on Fedora Atomic Desktops

Thanks a lot for this! I am currently automating this into a script but have some questions

  1. Is zram always RAM/4 ?

  2. I am also currently getting errors at point 12

The rest worked on Fedora Kinoite!

@siosm is there any issue with OSTree? Can this complete procedure be done here?

1 Like

I don’t think you can assume zram will always be a specific device, no.

As I mentioned, SELinux policy is it’s own while rabbit hole. There’s one system audit.log file that captures all security events (loggable successful ones and attempted violations), and audit2allow will parse out all violations in the file and attempt to generate policy using available macros to allow them. If you have any other security events on the system, they’ll also show up in the log and audit2allow will generate policy to allow them too.
Luckily the policy you need for this is pretty much dependent only on the swapfile name and location. Really all that should be missing is a persistent SELinux label on the file, and a macro call to allow it to be used as a swapfile. If you generate the code for the policy once, you should be able to reuse it on any system with matching file name and location of the swapfile,.and just follow the instructions for compiling the policy from source (explained if you had to hand-edit it).

1 Like

IIRC, Fedora sets zram to 50% of the host system’s RAM, but it caps out at 8GB.

1 Like

Nice guide :+1:

Are you sure it’s not enough to just go with ram_size? My understanding is that zram already resides in RAM; this would mean it’s not possible to exceed the max cap for RAM, and that it’s therefore unnecessary to allocate any additional swap space for zram.

Hibernation just moves RAM to swap – it doesn’t treat compressed zram data any differently from other data.

Oh my mistake, I misunderstood the RAM/4. It’s technically possible to adjust your zram size, so what assumption to make is up to you.
Zram is compressed, and the listed zram size is the size of the compressed content. If you read about it, the recommended best case compression assumption seems to be about 50%, so it’s recommended to assume your worst case uncompressed size is zram_size * 2. The compressed size takes up RAM, so you have to make sure to subtract that space from your overall RAM size when calculating the swapfile size.

At the end, your swapfile just needs to be big enough to hold all your RAM contents. You can make it bigger if you’re unsure or want to be really sure.
With the SELinux policy added, you no longer have to disable pre-checking of the swapfile, so it will always prevent sleeping and report that the swapfile is too small if it isn’t big enough at some point. That check occurs on every sleep/hibernate, and errors are reported to journald.

Ok yes thats what mine seems to be too

Yes, zram is compressed, but I don’t see how that is relevant when it comes to hibernating? To me it seems like it just moves whatever is in RAM to swap. Then, when resuming it just moves whatever is in swap to RAM. Just moving raw data, no compression/decompression being performed.

So a swapfile the exact same size as your RAM seems like it should always be enough, as long as you make sure that the swapfile is only ever used for hibernation.

I’ve configured two laptops like this and haven’t noticed any issues, though maybe I’ve just been lucky.

This is also somewhat dependent upon the way ram is moved to the swap partition AND how the graphics are suspended/hibernated. For a true quick restart without graphics problems the hibernation should also move the content of the GPU ram to swap, and that also requires swap space. Users of nvidia gpus have a specific service to properly suspend and restore the gpu ram.

To me that would mean the swap used for hibernation should be at a minimum the size of RAM + the size of GPU RAM + a little extra for safety sake.

My understanding of zram is that what you write to the /dev/zram device is compressed and stores in a pre-allocated section of RAM. The size listed for the zram is the size pre-allocated in RAM.

The principle of hibernation/suspend-to-disk is that everything in RAM needs to be stored in disk instead. That necessitates the contents of zram being copied out to the swapfile, zram disabled, and then the remaining RAM contents added to the swapfile (effectively). I haven’t heard anyone being capable of writing the compressed zram contents from RAM directly to the swapfile and back.

What may be confusing or misleading is that the default zram and swapfile handling for suspend-to-disk was updated a while ago to transparently handle this zram content copying and disabling (according to something I read somewhere). And if you aren’t using a lot of the zram space, it won’t need that big of a swapfile. However if you don’t make the swapfile big enough for your worst case, you may unexpectedly find hibernate didn’t work or got corrupted (depending on whether you have pre-checking of file size disabled or not).

Maybe I’m mistaken, most of this info is cobbled together and then verified, so it could be there’s no changes for automatic zram disabling and enabling and the swapfile does only need to be the size of RAM. But it would be had to know for sure unless you had a very full zram when trying to hibernate, and the pre-checksnn the swapfile enabled.

I wasn’t aware.of that, though it makes sense. I haven’t encountered anything that mentioned including GPU RAM size in swapfile size calculations before, even when zram isn’t involved.
I don’t have a system with a dGPU, so I don’t have that service. Do you have details on what it’s called that I could look up?

Thanks for the info, I had no idea!

It does sound like it’s unnecessary to include the GPU RAM size in the swapfile calculation though, is already creating it’s own swapfile equivalent just for the GPU.

Awesome tutorial, thanks a lot.

In case this helps anyone, as part of the troubleshooting, I had to do another round of audit2allow to fix systemd sleep not being able to access the swapfile:

#============= systemd_sleep_t ==============
allow systemd_sleep_t swapfile_t:dir search;

I just followed step 12. again with that and used a different module name (systemd_sleep). (Not sure if there’s a way to “amend” the SELinux module created previously, which would be nicer, I guess (?), but it works now, so… :person_shrugging:)

1 Like

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