- 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).
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).
Incidentally, I've just upgraded my RAM to 64GB and it's in the process of resizing the swap partition right now!
https://help.ubuntu.com/community/EnableHibernateWithEncrypt...
https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryptio...
> 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?