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.
Yes I thought that was indeed what I was doing 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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
Just as a test.