I think hibernation is a great and am thinking about setting it up on my framework when I get it, planning on using ubuntu 21.04. The only concern I have is the extra writing to the drive causing the drive to fail ealier than it normally would. Please let me know if the effect would be negligble on the drive.
Besides improvements in the tech behind SSDs I would also consider that you aren’t, or at least I’m not, hibernating every single time you use the computer. Something you’ll just use standby.
In my case, my hibernation partition is on a 250gb ssd module. As it is not using the full size of the drive, I imagine I will not see the thing wear out before the controller on the module dies. Which is to say, not for a long time. I’m not really concerned about it. If it does wear out, I’ve got the perfect laptop for that situation.
I am waffling about whether I want to try to resize my encrypted drives in order to use hibernation. I tested it out previously, and it tries to work, but fails since the 4G of swap space is too small. The partition order on the drive is efi, recovery, encrypted swap, then encrypted fs with two volumes and timeshift set up. I was able to follow a nice guide here: Pop!_OS 21.04: installation guide with btrfs-LVM-luks and auto-apt snapshots with Timeshift | Willi Mutschler to set things up, modified slightly to add a volume with nocow to house VM images. Looking at this page: ResizeEncryptedPartitions - Community Help Wiki leads me to believe that if I need to add more swap I will need to create a new encrypted partition with encrypted swap at the end of the drives, as there is a note about making sure that the resized partition starts at its original sector. I can follow this to a certain extent but the details get beyond me. My best solution if I really want to make use of hibernation likely is to pull any info off of the drive that I want to save, and start over, this time making the swap space sufficiently large. If I go that route I’ll likely set it to RAM + 2gb, in order to avoid any need to go through this again down the line.
Everyone seems to be focused on hibernation on Linux, but for anyone using Windows here’s something interesting I found. The default hibernation setting on my Framework laptop is to wait 596,523 1/3 hours before hibernating. I changed mine to 30 minutes.
This a setting conducive with S0 standby which the framework laptop and windows supports. In this mode the computer goes into low power when suspended, until 5% of the battery has been used sleeping, and then hibernation is activated. For this reason, your hibernation timer doesn’t really need to be altered.
Thanks for the thread/everyone, this has been on my checklist for a while. Gonna knock this one out in Fedora. Does anyone know to get similar Windows suspend-then-hibernate behavior in Linux?
Ideally both:
S0 suspend/sleep, then after X used percentage (e.g. 5%), hibernate
During S0 suspend/sleep, hibernate upon reaching some low battery percentage, e.g. 5%. If suspended at 7%, hibernate when laptop reaches 5%, not at 2% (7% minus the used 5% = 2%).
The former “suspends the system both to RAM and disk, so a complete power loss does not result in lost data. This mode is also called suspend to both.”
The latter “initially suspends the system to RAM and if it is not interrupted within the delay specified by HibernateDelaySec in systemd-sleep.conf(5), then the system will be woken using an RTC alarm and hibernated.”
I had hibernation running on my last laptop because I often was coding from the bus. I don’t use it anymore. Everything boots quick enough and it’s a way to ensure I restart things like Chrome or Slack that are memory hogs.
On Linux I have found this to be VERY true. However on Windows not so much. At any rate restarting the whole system instead of the process is not my preferred method. But this is an important point nonetheless: A fresh system has many other benefits that might not be captured by a system that hasn’t been restarted in months.
Honestly I get enough system restart simply from updating components and then requiring a restart.
The funny thing is in 18.04 they changed the default swap size in the installer to 1 GB because ‘nobody needs more than that with large amounts of RAM’. Oh boy the Launchpad issues around that get spicy. I ended up finding a custom partitioning script to use in my preseed file to make a large enough swap to hibernate.
I honestly didn’t realize that Linux had abandoned hibernation! To be fair, I did a Debian minimal install on my current (non-Framework — I’m batch 5!) with manual partitioning to setup full disk encryption (including encrypted swap), so I’m not exactly a “install using defaults” kind of person.
I fully concur with you that hibernation is wonderful, especially for someone who uses LUKS.
There are no issues with battery drain.
There are no issues with attempting to lock and unlock LUKS devices, since the computer turns off.
The second one is interesting because for the longest time, people sort of wrote off suspend as “less secure” than hibernate, since the LUKS devices wouldn’t be suspended (and so their contents could still be accessed). However, recently, people wrote up integrations with systemd and such to automatically lock LUKS devices before suspend and prompt to unlock them before resuming. However, this was (last I checked) still prone to quite a few bugs, to the point that I stopped using it and just started hibernating.
Hibernation really is a nice sweet spot between suspend and shutdown. It lets you resume your work (like suspend) while preventing any issues should your computer run out of power (like shutdown).
Hibernation is hibernation. Sleep and deep sleep are similar but different. As far as the differences, I imagine deep sleep shuts down more while in standby then traditional sleep. However in any sleep case, whether it is deep or not, you will be loosing battery over time.
With hibernation your computer is off and your work session saved. You are not loosing any power at all, as the computer is off.