It seems that Bluefin uses a zram based swap drive. I would like to use a swap partition to enable hibernation. I believe it is possible, but as I’m still unfamiliar to the particulars of a imutable linux distro, and the non-standard system paths, I wanted to check the collective wisdom here.
Hibernation is an important feature to me, and as I am on a Framework 13, I know it works. Just curious if there are any special hitches getting it working on Bluefin?
Edit: as this has been solved, let’s keep this as a running tab for hibernation on Bluefin with a Framework 13 laptop.
I successfully set up hibernation on my Framework 13 in Bluefin/Aurora, but with a swap file rather than a swap partition. Here are my rough notes on what I did:
In step 6, to add kernel parameters for the swapfile, use sudo rpm-ostree kargs --editor instead of sudo grubby --args='...' --update-kernel=ALL (this different way to modify kernel arguments is one of the differences between Fedora Atomic desktops and the non-Atomic Fedora desktops)
One thing I noticed around one or two months after I set up hibernation is that my laptop started to exhibit an undesirable behavior where the Wi-Fi module stops being able to connect to Wi-Fi networks after waking up from hibernation. I’m not sure why this would happen (but I suspect a problem in the kernel), and I’m curious if you (or anyone else) can reproduce this behavior.
I have it wanting to work. However when I run
sudo systemctl hibernate
the screen goes black for a second and then the login screen comes up. Looking through the journalctl log doesn’t reveal anything to me, as I have no idea what I am looking for.
I did have to manually edited the policy as it had a troubleshoot require in there.
@ethanjli did you have this issue? What did you have to do? It feels like the system wants to hibernate, but the lid switch or something like is triggering it to immediately wake again.
Oh, actually I did experience something like that when I was setting up hibernation, when I still hadn’t fully reconfigured my SELinux policies correctly. You may need to go through another iteration of the SELinux-related troubleshooting steps in both the first link I posted and the second link I posted. I really don’t understand SELinux, so I was basically fumbling around in the dark with that.
It turns out that a second policy seems to be required. I basically redid step 12 like post 20 suggests and named the policy systemd_hiber instead. However, the contents of that policy and the previous systemd_hibernation policy are identical. Only without creating the second policy it didn’t seem to have any affect on hibernation.
Very curious thing. It is now working.
Do you reset this issue by rebooting? Or is this something that happens everytime you resume? Have you tried more than one wifi connection? I’m wondering if the connection authorization is getting bugged due to the state of the system’s up time, compared to the system time. I wonder if you were to disconnect from the wifi connection BEFORE hibernating if this would be a work around?
Yes, after I reboot then the Wi-Fi module works normally until the next hibernation.
I’ve tried plugging in a USB Wi-Fi dongle after resuming from hibernation, and unfortunately it suffers the same problem (KDE says it’s stuck trying to configure the network interface but it fails with an “Authorization supplicant timed out” error message).
I’ve just now tried disconnecting from Wi-Fi networks before hibernating, and (to my great surprise) I am able to connect to networks after resuming! So this is a viable workaround. In fact, this appears to be a viable alternative to rebooting, for making my Wi-Fi module work after I hibernate without disconnecting first. Thanks for the suggestion!
This behavior makes it very plausible to me that maybe hibernation causes the state of past and future wireless network interfaces to be stored and reloaded in some undesirable way that doesn’t happen with sleep mode.
I read up on it a few months ago. Basically, because a lot of devices won’t be able to hibernate out of the box, they disabled and removed it for everybody. Makes no sense to me to risk data loss on low battery, by default.
It should be easy to allow the user to run a test and if it works, then enable it.
Were you able to find a solution for this? I have the same problem. Also, I noticed that, even after manually editing and recompiling the policy, it still shows the troubleshooting stuff if I run audit2allow again.
