Hacker News Reader

Comment by Kliment | Hacker News Reader

After setting up a swap partition of sufficient size, hibernate worked with no issues whatsoever on my very recent hardware and kubuntu. The main reason it's disabled by default on ubuntu is that the default partition setup isn't compatible with hibernation for most memory sizes. You need a swap configuration that's large enough to fit your entire RAM and also your current swap. I find it works at least as well as on any other OS. I currently have it configured to auto-hibernate on low battery or after some number of hours of sleep. From my point of view the Linux community is doing absolutely great on that front, and I've never had a machine where hibernate didn't work correctly. The main issue here is the defaults on one distribution (ubuntu) make it a massive pain to enable.

View on HN

And you need to find some buried comment on hacker news to figure out that partitioning is the problem! Thanks!

Use the Arch Linux documentation it's often helpful even if you don't use arch Linux.

Or the Gentoo-one or Debian or even the Kernel docs regarding resume=<partition>. There are a few things to consider:

- it does not work on encrypted partitions since there is no way to unwrap any key at all

- with an active state originating from an encrypted partition gives any attacker the opportunity to manipulate the hibnerated system image

- hardening tools often recommend to turn off hibernation in the kernel completely because of #2 (and the implication that this would load any crafted image into your working memory)

- recent distributions create /tmp as a tmpfs/ RAM disk which makes hibernation impossible due to power loss of RAM in this sleep state, and /tmp could be the default if nothing else is specified

- partition parameters on kernel command lines rise and fall with modules available at boot time/ through the bootloader, e.g. GRUB or Lilo. It might happen that using UUID in the case of hibernation does not work in combination with certain bootloader versions

- hardware does not support the power down sleep state, e.g. Raspberry PI or has no peripherals connected triggering a boot process (BIOS does this upon pressing for example the shutdown-key on a USB-keyboard with this enabled in the BIOS which in turn requires the USB-ports to be monitored/ enumerated and powered which isn't the case for any Raspberry)

I've been using hibernation for more than a decade on different hardware and distributions but only on that drag-around low-fi laptop ingesting ycombinator, running IRC client or Liferea. I always use the swap partition for this and it has always been /dev/sda2 with 4GByte (currently 5.4.* for Arch, Gentoo and Debian). I trust Grub, currently 2.x but also worked back in the days with 1.x since it is a kernel parameter (and the kernel self-compiled with CONFIG_HIBERNATION=y and copied with a steady hand and a magnetized needle).

I have hybernation working fine with root and swap under lvm in a luks encrypted partition. Pretty sure when I set up ubuntu 16.04 or 18.04 it just worked out of the box. Though sound doesn't like to come back properly for the headphone jack and I need to rmmod/modprobe the driver.

> - it does not work on encrypted partitions since there is no way to unwrap any key at all

In Debian, this is handled by initramfs scripts: the script asks for password, unlocks the device and then resumes from it. I think this will be the case with other distributions too. Or at least you can hack it yourself (open the device and run "resume" command on it).

> - with an active state originating from an encrypted partition gives any attacker the opportunity to manipulate the hibnerated system image

This is true, however a) with common encryption modes (XTS) they can only produce garbage, b) it's very difficult to target specific data as the memory allocation is random, c) they can use the same tampering for the system itself (e.g. /bin/bash), d) they can tamper with bootloader or kernel (unless SecureBoot is enabled) anyway.

> - recent distributions create /tmp as a tmpfs/ RAM disk which makes hibernation impossible due to power loss of RAM in this sleep state

I don't see a problem with this. The content of all tmpfs filesystems is saved into the image (there is much more that could break otherwise, for example /run).

> - partition parameters on kernel command lines rise and fall with modules available at boot time/ through the bootloader, e.g. GRUB or Lilo. It might happen that using UUID in the case of hibernation does not work in combination with certain bootloader versions

I have never had problem with this and I can imagine a situation when this happens (you are using the same bootloader and initramdisk for normal boot and for resume).

Same here - the swap partition to match the memory size did the trick. I'm on a Lenovo 480. To hibernate, I just type in "sudo systemctl hibernate" and it works, I'm happy.

Incidentally, I've just upgraded my RAM to 64GB and it's in the process of resizing the swap partition right now!

it usually works out of the box but the swap won't be encrypted. that may or may not be what you want. a proper solution with random generated key to encrypt swap takes some extra steps:

https://help.ubuntu.com/community/EnableHibernateWithEncrypt...

https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryptio...

This was a fascinating comment to read - thanks for the insight.

> You need a swap configuration that's large enough to fit your entire RAM and also your current swap.

I'm struggling to wrap my head around this one - please help me understand?

How can a swap be made large enough to fit your entire RAM as well as your current swap?

In other words, what if your current swap is already being used near capacity?

Or is that not really likely with a really large swap?

Everything in RAM and Swap will be compressed when you want to hibernate.

The memory contents have to go somewhere. They can't stay in RAM as RAM will be powered off. If there's sufficient free swap space they go there. If there isn't, the current swap and memory contents get compressed and it then goes to swap. If there's still not enough space, hibernation will fail. So if your swap is filled with incompressible data to its full capacity, you will not be able to hibernate. This is very unlikely if your swap is enormous, but it can happen.

That's for taking the time to explain - makes perfect sense - cheers.

This seems like a bug because it means system state results in unpredictable behavior. There should be a dedicated swap for hibernation, like the pre-allocated hiberfile used by Windows.

you can set it up that way if you prefer, there is a resume= kernel param you can set to a separate file or device. I keep them combined tho because I hardly ever use much swap, and don't have a ton of disk, and if hibernation ever did fail, I can just close some tabs and be fine

Make the swap partition equal to 1.5 times your RAM. That's always worked for me.

Reply on news.ycombinator.com