I’ve never had an issue once its set up. Just a 16GB LUKS partition alongside my normal LUKS partition, a small edit to /etc/crontab so I only have to enter the password once, set the RESUME variable, add to fstab, and rebuild init. This method even works with suspend-then-hibernate on every laptop I’ve used it with.
This would take 5 seconds at install time, but instead you have to install, reboot to the live USB, shrink LV, shrink PV, shrink LUKS, shrink partition, repartition, grow LUKS, grow PV, grow LV, and finally set up the swap partition as above.
Am I the only one? Does anyone else use encrypted drives and hibernate?
Suspend and hibernation are both cursed features due to weird nonstandard ACPI fuckery and hardware devices that don’t cleanly know how to bring itself back up.
The last time I successfully enable hibernation, it took more tike (to save and boot from hibernate) than booting fresh and restore session.
I had 32GB of RAM and XFCE as DE.
Odd, not my experience at all.
It’s one of those things that work perfectly on all mainstream operating systems but becomes a hassle of different guides on Linux.
For the longest time there were complications using hibernation and some kernel security features together. I believe most of them have been fixed at this point, but I don’t think Ubuntu 22.04 is running a kernel with those patches. Maybe the next LTS will.
Hibernation and encryption can be a real pain depending how your system is set up. I never got it to work reliably myself, but maybe I should give it another go.
The obvious downside of hibernation is that there’s reserved disk space equal to or greater than your RAM size that you just can’t use for anything else, which can be quite substantial (only 32GB for me but many devs will run with more RAM). Still, I’d like a toggle during the setup process to just enable hibernation…
The method that I use moves memory to the encrypted drive space, so there’s no chance of a data leak. Perhaps I should post a guide…
The attack described in the post I linked assumes a privileged attacker wants to gain deeper access to the kernel, with the ability to rewrite the encrypted swap header already. It’s an attack that’s not very important to general users, but it’s a real issue for kernel developers.
With secure boot configured correctly I don’t think there’s any risk in using encrypted swap partitions for hibernation, but the kernel itself had some issues with it for a while.
What do you mean by «support»? In my Debian install I created an encrypted partition + LVM and I can hibernate without issue. I believe Ubuntu has an install option for encryption, so I think it should also work.
Full hibernate? Hybrid with power might work, but if the battery dies the default way doesn’t work.
I use swapfiles, which makes hibernation slightly more difficult than a partition. Depending on the filesystem there are even different steps (btrfs).
