Setup hibernation on Silverblue / Kionite?

Hibernate always requires a fixed on disk location to function and always has. The kernel is loading the swap content as a binary blob from the physical disk before file system drivers are loaded when it resumes from hibernation.

SSDs certainly prefer to move content around and distribute writes across a range of internal physical hardware bits (like eMMC in an SD Card), and modern file system drivers try to assist with that by distributing churn across a dynamic range of disk interface addresses. But SSDs aren’t anywhere near as brittle as they were 15 years ago when they first started getting popular. If you’re not using it your SSD for high churn server content 24 hours a day for year on end, you’re unlikely to run into these types of issues anymore. They are still kit as robust as platter disks, but for an average consumer it’s basically an invisible difference now.

As an example Optane disks for are specifically designed to have a high speed SSD as a semi-hidden hibernation and sleep cache, exactly like this swapfile, attached to an HDD. The drivers for them are largely Windows-only, and hit have some extra logic, but still.

2 Likes

I don’t know the purpose of your message.
I have been able to use a btrfs subvol for hibernation with Manjaro for a while. Until after an update that stopped working. Same for Fedora.

Weirdly, btrfs has had official support for creating the hibernation file for a year now. Since around that time it actually stopped working.

On Manjaro, hibernation still works if you simply use a dedicated partition.

I suspect that is also the case for Fedora?

How does the Fedora team otherwise use Fedora on a laptop ??

Most likely when you install Fedora for the first time you even get the option to add a partition for hibernation? I don’t remember.

1 Like

Sadly, there is none of that at the time, AFAIK. There wasn’t when I was installing my Fedora 39 Silverblue system on my laptop at least.

While I have never installed silverblue, it is a fact that when installing most spins of fedora if the user selects to do a custom partitioning during the installation they are able to add a swap partition of equal to or larger than the installed RAM size that then would be used for hibernation.

With most modern laptops, it appears suspend has replaced hibernation and a full startup from SSD is actually faster than hibernation restart from an HDD or earlier sata SSDs.

my default zram is 8GB, on 16GB RAM. This should be enough to fit RAM contents afaik

Suspend doesnt use RAM

ZRAM is actually part of RAM and is powered off with hibernation: So hibernation would require at least 16GB of drive space (file or partition) to enable hibernation. Suspend does not power off the RAM.

2 Likes

TL;DR

  • SSDs wearing out isn’t actually a factor for anything less than commercial servers now.
  • The file system isn’t used for restoring from hibernate, so it has to support some way of having the bag of bits that is a swap space in a fixed location for writing during hibernation.

It’s been possible for a number of years if you setup some of the btrfs details properly, but the btrfs development team didn’t guarantee the behaviors until a couple years ago. I believe the required setup is a dedicated subvolume with compression disabled, COW disabled, and backup disabled, holding nothing but the swapfile. That ensures the necessary fixed physical disk location of the swapfile is retained so it can be hard coded into the kernel command-line arguments and used by the kernel during resume from hibernation.

It has continued working fine for me on Fedora, and worked fine to setup a new laptop not that long ago as well. Figuring out the necessary contiguous-on-disk size for the file is a bit haphazard because you need to estimate in-kernel values, but if you’re able to get it set right it’s very stable.

They don’t. The Fedora team is pretty clear that they don’t support hibernation in Fedora, and setting it up and maintaining it is completely up to you. Their claim is that it’s “unstable, hard to setup, hard to debug, and insecure”. Most of the claims seem to be based on historical kernel issues that are no longer true, but it’s their choice of what to support regardless.

You don’t directly, at least not like other installers. You can always create custom partitions during installation, but that’s as far as it goes, and there’s no indication of any relationship to swap or hibernation.

1 Like

That seems to be the intended path, but it’s not at all close to ready.

Sleep but not hibernate requires the newer deep sleep modes of the processors to get you much in the way of extended battery life. Deep sleep modes on Intel chips however are heavily obscured by Intel themselves, all but preventing their use in Linux for years after the chips are released and extensive reverse engineering has occurred. That deep sleep mode is the hibernation pseudo-replacement Windows has.
In regular sleep mode, most laptop batteries will still wear out in less than 3x the normal idle+screen off time (so ~1.5 days from full charge would be usual). That’s suitable for taking your laptop to the coffee shop or to class and back, assuming it’s plugged in both there and at home, but isn’t a suitable replacement for a laptop used less than daily or that needs to be used intermittently from battery while traveling.

The SSD faster reboot is only an option if you have a way to restore state, which becomes heavily dependent on your Desktop environment and specific programs to provide the logic for retaining and restoring state. It requires applications themselves to retain state when restarted, which almost none do, and requires your DE to retain what windows were open and where they were positioned, something DEs have struggled with for a long time.

1 Like

All very true, and the part about not supporting hibernation is a key factor.

Short term suspension is the norm. Long term suspension except when attached to external power has been out for some time. There are many threads here about problems with sleep/suspension and power draw. Most seem related to hardware changes and what modes are supported (or no longer supported) by the cpu.

If a user has to keep state of an app then nothing related to suspension is ideal with the current state of hardware/kernels. Particularly since there are often issues with restoring the display state when resuming from suspension. Saving and restoring the content of gRAM seems difficult at best.

I will test that for Silverblue, thanks. Maybe I’ve missed it first time. And I guess users can still boot from liveUSB and adjust partitions manually if necessary.

Does the device still stop to use power in that case? Because it’s the main reason to use hibernation - to save state but stop power consumption.

Oh, you’ve already answered, thank you.