> - 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 fo

> - 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).