Even though I'm no Ubuntu Dev, I can confirm that it is impossible to resume from a hibernated session with encrypted swap when the key isn't stored anywhere (read: wenn you use /dev/urandom as a keyfile) if you hibernate to the swap partition. (there would be other possibilities, for example hibernating to a specially created swap file on the root fs or something) Just using a keyfile instead of /dev/urandom doesn't seem to solve the problem completly. I just fiddled around a bit with the initrd-Code (in /usr/share/initramfs-tools) and it seems to me as if this code supports encrypted swap partitions, but only if they have either a keyscript or a passphrase. This of course has the adventage that the key won't be stored in the initrd which would result in insecurity and thus pointlessness of encrypted swap but causes the disadventage that you won't be able to resume a hibernated session from a keyfile-encrypted swap. (please correct me if I'm wrong.) I hacked something together which would generate a keyfile on boot from /dev/urandom, stores it in /boot and encrypts the swap with this file. The file is then deleted on shutdown or reboot. It really is a hack and not even worth explaining here, but maybe that would be a possible solution. It makes the encrypted swap a bit more insecure but still offers the possibility of resuming from it without using a passphrase.
Anyway, I consider it a good idea to warn the user in advance if hibernate is damned to fail. Or maybe to dynamically change the according variable in /etc/default/acpi-support so the option won't even occur on logout screen. -- encrypted swap partition causes data loss upon hibernation https://bugs.launchpad.net/bugs/98680 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
