Setup hibernation on Silverblue / Kinoite?

Ask Fedora
,
47

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
49

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.

1 Like
50

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.

51

Thanks so much for this. It worked flawlessly on F39, but after upgrading to F40, hibernate was back to failing with

Failed to find location to hibernate to: Operation not permitted

After walking through this guide again, I found one additional SELinux module in the audit2allow list

#============= systemd_sleep_t ==============
allow systemd_sleep_t self:capability sys_admin;

After adding running that policy in as well, hibernation is back working.

I hope someone else finds this useful.

2 Likes
52

Thanks for finding this! Can you report this upstream in GitHub - fedora-selinux/selinux-policy: selinux-policy for Fedora is a large patch off the mainline ? Thanks

1 Like
53

Happy to do that if its going to go anywhere. I’d have assumed that with hibernation officially unsupported, that reporting bugs related to it wouldn’t be well received.

Any advice on how to capture the relevant info that “this is a change from F39 to F40, atomic desktop, labels required for hibernation”?

1 Like
54

The bug you found actually seems to be related to sleep, not necessarily deep sleep/hibernate, so it might be worth reporting. If they decide to close it without fixing it though, so be it.

The other SELinux policy changes in the guide above are about granting the permissions to your custom-created swapfile, which will be unique to each implementation, and applies an existing SELinux label to the file. This however is an error in the permissions granted to the tools/user roles.

55

It appears the upstream SELinux policy already has a fix for what you’re reporting:

1 Like
58

On Silverblue 40 I tried this guide again… unfortunately, the screen turns back on immediately.

This is a HP Spectre from 2019, 8GB RAM. I created a 16GB swap following the instructions:

NAME               TYPE      SIZE USED PRIO
/dev/zram0         partition 7.4G 768K  100
/var/swap/swapfile file       16G   0B    0

When I check the journal, the log between the 2 hibernation messages contains a lot of mumbo jumbo but no actual errors:
Logpasta - simple, secure log paste service

So I have no clue how to debug this further. Any advice?

1 Like
59

This is an extremely old thread, from Dec 2022.
closing

62

As requested by others, reopened.

1 Like
63

I got it working too!
Just like others have reported, step 12 needs to be repeated. May I suggest updating the guide with the following changes?
@aaravchen not sure if you are still around, here are the additions to the guide:

6. Add the kernel parameters for the swapfile
Grubby needs to be installed. rpm-ostree install --apply-live --assumeyes grubby

15 Try to Hibernate (again)
This will fail. Now, add the same SELinux policy again, with a different name:

cd /tmp
sudo audit2allow -b -M systemd_hiber

Load the new policy

sudo semodule -i systemd_hiber.pp

16 Hibernation should now work
try it: systemctl hibernate
After a reboot you should also have hibernation and hybrid sleep options in Gnome menus.

Minor issue:
Grub menu is shown after waking from hibernation. There is a solution via systemd: unset recordfail (which exists to show grubmenu after failed boot) but not sure if it would work for Fedora Silverblue?

64

@zilexa I am still here, but the post is old enough I can’t edit it anymore.

Did they switch away from grubby in the F40 update? I haven’t installed it fresh, but grubby was required before I thought. Maybe I’m mistaken and I just installed it almost immediately to deal with other kernel options.

If you read down a handful more posts after my big one, I believe either I or someone else says this. I couldn’t edit the original by that point either, so it’s separate.

Maybe I’ll just copy my original and repost it with the fixes? I don’t have a great solution for making it visible and obvious.

Ah, I’m on KDE is probably why I didn’t notice this.
What you’re describing sounds like you’re actually getting an error when trying to hibernate, and that’s causing recovery/warning behavior to wake the system back up. Try to track down what’s actually reporting the error and fix that. Your logs before didn’t have any actual error in them, but they may have been from before you enabled hibernate in the Gnome settings.

65

I moved all posts I found informative to a new thread

1 Like
66

The link to the new thread only shows up as an event notification post for logged in users who were already participating in the thread as far as I can tell, so here’s the link for everyone else: Setup hibernation on Fedora Atomic Desktops - #2 by aaravchen

1 Like
67

Done.

68

I think your merge actually pulled the original posts out of this thread.

I was scrolling back to find my original big post in the context here and it’s missing above, but present in the other thread. There are at least a few things from this thread that could be moved over still, and this thread is nonsensical without the posts you moved. Is there a way to change it to a copy into a new thread instead of a move?

69

Some things to add to make the other thread a coherent picture.

This moved post actually needs the reply, the problem wasn’t with using BTRFS (which works fine). This reply addresses that misunderstanding.

This and this also absolutely needs to be moved over. I would have added it to my original post if I could have still edited it. Extra rounds of SELinux are needed, or you just need to create a custom SELinux module that adds the correct label to your swapfile, and the policy to allow hibernate processes to access that file.

Probably this as well. I would have added that to my original too, it includes basics of how to debug “swap too small” problems.

I’m going to re-post a cleaned up version of my description about Secure Boot and the TPM over there since moving the post would really be helpful