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.
Hi @ethanjli I had hibernation working on Silverblue, but I did a clean install of Bluefin and now I am in trouble.
I could actually run the Grubby command twice, after the first time I closed Terminal, opened it and ran the Grubby command. It worked (verified with your command).
But the issue I am facing is step 11, where you have to hibernate for the first time. This is what happens:
sudo systemctl hibernate
Call to Hibernate failed: Access denied
I tried without sudo and I also tried after doing this:
systemctl unmask hibernate.target
Created a /etc/systemd/sleep.conf file in which I added AllowHibernation=yes
But it doesn’t matter, I always get access denied.
I am extremely surprised that you used Grubby, since I had thought that wasn’t supposed to be used on Silverblue or on Bluefin (but apparently I’m wrong)…I never installed Grubby and instead used rpm-ostree kargs to edit kernel arguments (and when you say “verified with your command”, maybe you mean that you used rpm-ostree kargs to confirm that the Grubby command correctly modified the kernel args?). Hopefully that’s unrelated to your problem, but since most of the hibernation setup process is beyond anything I have a clear mental model for, I can only be 99% sure.
It’s been so long since I did hibernation setup that I forget what error message you’re supposed to see when you try to hibernate without SELinux being properly reconfigured - so I can only make guesses here, but the error message you report sounds like a message I would expect to see in such a situation. When I searched for this exact error message, I found a comment and its follow-up which suggest that this error message does indeed occur when you try to hibernate before SELinux is fully correctly reconfigured. So I think we should check whether the cause of your reported error message is related to SELinux policies or is actually something else. If you check your SELinux audit log (I don’t know the proper/correct command to do this, but maaaaaybe sudo audit2allow -b will report equivalent information?), what do you see?
Sorry this is distro-level stuff and Fedora has years of discussions as to why they don’t support it, we’ll likely never support this with our images.
If hibernate is too hard or insecure for {reasons} is there some other best practice for “save what I’m doing” and “agressively save power” ?
One of the things I love most about my Framework 16 when it runs Windows is that hibernate finally “just works”. After years of fighting problematic Dells it’s bliss! I was hoping to find that here with Bluefin too, and have one more reason to stay on this side of the boot divide.
OK so first of all I created confusion. After I got that Access denied message, I simply did not continue to perform any of the other steps.
But then I checked with sudo rpm-ostree kargs --editor and noticed the IDs the editor show are exactly the ones I used with the grubby command.
side question
There is zero documentation how to use the editor. I could not find any option to save, I tried all keyboard combinations. How do I actually save and exit?
But the grubby command gave me an error of the sorts grubenv file not found (something like that). So it may have applied it partially? No clue. I can confirm, even after a reboot, when I check with sudo rpm-ostree kargs --editor the IDs are still there.
Stuck:
However unfortunately, I get the infamous issue when I hibernate, screen goes black for 2 sec then shows login screen.
So something is not OK. But since I had it working on Silverblue-rebased-to-uBlueOS base image (F41 based), using the same steps. I should get it working on Bluefin as well! I have 8GB RAM and may have created a too small swapfile this time (16GB). I will try again with 20GB.
Not sure how to continue, I remember it was near impossible to find a proper error report…
Based on your description, it sounds like maybe rpm-ostree launches vim as the default editor? If so, you can enter edit mode by pressing i, and then you can exit from edit mode back to normal mode by pressing the Escape key. In normal mode, you can save and exit by typing :wq and then pressing the Enter key.
Thanks for the instructions for the editor.
But performing the SELinux steps twice is exactly what I did already.
That’s why I’m unsure what to do next. I would like to undue the SELinux and Grubby actions, remove swapfile and sub volume and start fresh. But I don’t know how to undue the SELinux and Grubby actions