(Not)Hibernating Ubuntu 16.04 with full disk encryption22 Oct 2017
To maximize the usage of my new laptop battery, I wanted to have it hibernate when I close the lid. I could see I had an "Hibernate" option in the settings, but it always stayed always greyed out and I could not select it.
One morning I sat at the table decided to fix this issue. First thing I tried
sudo pm-hibernate to see if I could actually hibernate. The
command did nothing except returning and error code 1.
After some Googling, I understood it had to do with my BIOS configuration. I have Secure Boot enabled in my BIOS, which seems to prevent hibernating.
One reboot later, after having disabled this option from the BIOS, I ran
pm-hibernate again, and this time I had much better results. My screen turned
off for 2 seconds, then back again for 2 more seconds, then the laptop went to
Great! I'm making progress. So I'm pressing the switch button to turn it back on, but instead of coming back to my session, it initiated a whole reboot, going through the Lenovo splash screen and Ubuntu cryptsetup prompt.
More Googling told me that I need to configure GRUB to define what swap partition it should attempt to resume from. When you hibernate, the whole RAM memory is flushed to swap. GRUB needs to know the UUID of the swap disk holding that info.
To get the UUID, I typed
sudo blkid | grep swap to get a list of all swap
devices. In my case, I had two of them:
/dev/mapper/ubuntu--vg-swap_1: UUID="b0d3688c-e44a-4972-b18a-43e79ca3777c" TYPE="swap" /dev/mapper/cryptswap1: UUID="78df939a-d7a9-46dc-9082-d46415cd6e0a" TYPE="swap"
Ok, so which one is it? Because I'm using Ubuntu full disk encryption, one of those two disks is actually the encrypted swap disk and the other is the "live" decrypted swap. But which is which?
swapon -s told me the name of the active swap:
/dev/dm-3. Ok, that's a good
sudo dmsetup info /dev/dm-3 yield the final answer: it's
cryptswap1 is the active swap; it means it's the decrypted swap, so
ubuntu--vg-swap_1 is the actual encrypted swap. It actually makes sense, as
vg in the name stands for "Volume Group", a term used in LVM terminology.
My issue with that setup is that I cannot tell GRUB to resume on the decrypted swap, because the UUID of this swap will be randomly assigned at each boot and more importantly it won't be decrypted yet when resuming.
But I cannot tell GRUB to boot on the encrypted swap disk either as it will be random garbage from its point of view.
I was stuck. Other solutions online suggest that I could flush my RAM to a disk that was not encrypted so I could resume from it, but that defeats the purpose of encrypting my disks if I dump everything that is in RAM to a readable disk.
After hours and hours of Googling and trying, I was about to give up. That's when I decided to ask one of my coworker that I know has a similar setup: Linux on a Lenovo laptop, using encrypted disks.
His answer was all I needed:
over the years I just made my mind over the fact that hibernate was broken and I never even try to see if it's fixed, I just consider it as broken forever
That's not just me then. Hibernating and having an encrypted drive are mutually exclusive. Too bad, I'd rather keep the encrypted drive.
Tags : #ubuntu
Want to add something ? Feel free to get in touch on Twitter : @pixelastic