Description of problem:
After creating an encrypted swap partition during installation of F13 to ensure no sensitive data is being recoverable from swapped-out pages or hibernation data, resuming from hibernate image fails as dracut does not unlock the partition although listed rd_LUKS_UUID= in kernel command line and crypttab with corrent UUID.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot from Fedora 13 installation media.
2. Create a custom harddisk partition layout including a partition for swap and check the "encrypt" box.
3. Boot F13 and install all updates and reboot.
4. Hibernate using GNOME or /usr/sbin/pm-hibernate.
5. Power-on the system again.
Dracut does not unlock the swap partition. The system does not resume and performs an ordinary boot instead. After switching to the system root fs, /etc/rc.d/rc.sysinit asks for the password for the swap partition and unlocks it. When the swap is being activated, a message appears stating that the swap contains suspend data and is being reset to a swap signature.
Dracut should unlock the swap partition and the kernel should resume from software suspend image in swap.
A LVM setup is not reasonable in my case as I need Ext4 discard/TRIM support for SSD hardware and LVM/devicemapper does still not support it.
I believe a related problem is that swap never gets LUKS-opened after regular boot. This problem was present even in pre-dracut mkinitrd.
I always have to do cryptsetup luksOpen + swapon after new boot.
Confirming hibernate also does not resume for me.
does it work, if you add
to the kernel command line?
thanks for your suggestions, it helped.
The following worked well for me:
These both did NOT work:
Using the latter, the device gets also unlocked by the initrd/initramfs, but does not resume. After a while "Could not open root filesystem" or similar appeared and system remains in sleep loop.
I think, anaconda should at least add resume= to the kernel command line if the problem cannot be fixed otherways.
(In reply to comment #3)
> Hi Harald,
> thanks for your suggestions, it helped.
> The following worked well for me:
luks-UUID != filesystem-UUID
$ udevadm info --query=all --name=/dev/mapper/luks-d1b7e28f-bbdf-4e27-a51f-e61c0b56bbc6
So, here UUID is 0a2bd0df-fb5f-4f00-ae87-3ae6287f9ad5 and not d1b7e28f-bbdf-4e27-a51f-e61c0b56bbc6