I just asked ChatGPT for a solution for hibernation on Silverblue

There were discussions about it, but no solution forever. Some people dealing with it but stopping, while hibernation is such an essential and nice feature for Desktop Linux, especially as Intel S3 sleep drivers are missing!

I guess the solution is pretty good, while not working for me currently. These are the commands nessecary (slightly modified to automate, I hate this “open nano and add this”):

# 1. create swapfile
fallocate -l $(( $(grep MemTotal /proc/meminfo | awk '{print $2}') * 2 )) /swapfile
chmod 600 /swapfile
mkswap /swapfile

# edit fstab

echo "/swapfile swap swap defaults 0 0" | sudo tee -a /etc/fstab

# edit Grub, replace UUID and offset

uuidnum = ls -l /dev/disk/by-uuid/ | grep swapfile

# offset
offsetnum = sudo filefrag -v /swapfile | awk '/swapfile:/ {print $4}'

echo "GRUB_CMDLINE_LINUX="resume=UUID=$uuidnum resume_offset=$offsetnum" | sudo tee -a /etc/default/grub

# update GRUB
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

# Test Hibernation
systemctl hibernate

Is this solution working? Then I pledge to add it to Fedora Silverblue and Kinoite by default.

There is another post on this where people accomplish this, but not complete with the needed Commands.

Hibernation must be integrated by default, but if not already, a solution to get it working would be really helpful!

These answers dont work fully, but I dont see the error. Its better than nothing I guess

There’s a very simple reason why we don’t offer hibernation for Fedora desktop variants by default: there’s no support for secure boot systems right now.

The Chrome OS team at Google has a patch set to fix it, but it hasn’t landed in the kernel. Once it has landed, we can integrate this functionality into all Fedora desktop variants.


It’s also really, really dependant on the hardware (well, firmware) cooperating well. So it’s very vendor, model, and even revision-sensitive. It’s very likely that a large number of systems won’t resume reliably for reasons beyond our control. So it might need to remain an “enable at your own risk” option. (Or something we have an enable-list for known-good systems.)

S4 suspend (suspend-to-disk) doesn’t require that much hardware/firmware cooperation. You might be thinking of S3 suspend (suspend-to-ram), where this is true. It’s so true that it’s being replaced with S0/S0ix suspend (also known as Windows Modern Standby), which requires the operating system to fully manage the system suspend mode instead of having the firmware do it.

1 Like

Maybe! I remember a lot of problems with reliably waking up displays, etc. But it has been a few years. Oh, also: we’ll have to figure out something with swap partitions, right?

Yup. I think the idea would be to dynamically create a btrfs subvolume to instantiate a swapfile for hibernation (similar to the Windows hiberfile.sys trick). But there’s been no real need to do that work until we get S4 suspend working with secure boot enabled.


Thank you! So there is a way, I dont have secureboot anyways yet. Good to hear there is a valid reason.