Continuing my adventure from bug #438954 and bug #438955... Now anaconda detects my pre-existing LV LUKS partitions and asks me for a password. I entered it and selected "global password" and voila it showed me all 4 partitions (/, swap, /home, /newroot) with the correct type (ext3/swap). So I told it to format swap and /newroot (as / for F9) and the installation went through. After reboot I was asked for the password and the encrypted swap partition was correctly activated. But then the mount of / failed :-( When I checked the "init" script in the generated initrd I noticed there was no cryptsetup command for the root partition! I updated the script to read: ... cryptsetup luksOpen /dev/mapper/VolGroup00-LogVol01 luks-VolGroup00-LogVol01 resume mapper/luks-VolGroup00-LogVol01 echo Creating root device. + cryptsetup luksOpen /dev/mapper/VolGroup00-LogVol03 luks-VolGroup00-LogVol03 mkrootdev -t ext3 -o defaults,ro /dev/mapper/luks-VolGroup00-LogVol03 echo Mounting root filesystem. mount /sysroot After that the system boots up fine, asking for 4 passwords for the 4 partitions (2 during initrd [swap & /], 2 during init scripts [/home & /oldroot]). I think the culprit is mkinitrd but maybe anaconda doesn't provide the correct information that root has been encrypted? Version-Release number of selected component (if applicable): anaconda-11.4.0.65-1.i386 mkinitrd-6.0.41-1.fc9.i386 kernel-2.6.25-0.195.rc8.git1.fc9.i686
This is a known bug. It will be fixed in mkinitrd-6.0.42, which will hopefully be built this weekend. The bug was basically that only the first LV would get luksOpen called. Since you also have swap on LV you hit it.
Retried with mkinitrd-6.0.43-1.fc9.i386 It now writes cryptsetup commands for both LVs into the init script. So booting works OK now. Sorry to nitpick: The order of the cryptsetup commands is not really nice for resuming from hibernation: you first have to enter the password for the root partition, but that isn't required. I.e. init now has: echo Setting up disk encryption: /dev/mapper/VolGroup00-LogVol03 cryptsetup luksOpen /dev/mapper/VolGroup00-LogVol03 luks-VolGroup00-LogVol03 echo Setting up disk encryption: /dev/mapper/VolGroup00-LogVol01 cryptsetup luksOpen /dev/mapper/VolGroup00-LogVol01 luks-VolGroup00-LogVol01 resume /dev/mapper/luks-VolGroup00-LogVol01 echo Creating root device. mkrootdev -t ext3 -o defaults,ro /dev/mapper/luks-VolGroup00-LogVol03 but it should read instead: echo Setting up disk encryption: /dev/mapper/VolGroup00-LogVol01 cryptsetup luksOpen /dev/mapper/VolGroup00-LogVol01 luks-VolGroup00-LogVol01 resume /dev/mapper/luks-VolGroup00-LogVol01 echo Setting up disk encryption: /dev/mapper/VolGroup00-LogVol03 cryptsetup luksOpen /dev/mapper/VolGroup00-LogVol03 luks-VolGroup00-LogVol03 echo Creating root device. mkrootdev -t ext3 -o defaults,ro /dev/mapper/luks-VolGroup00-LogVol03 So mkinitrd should first dump the cryptsetup for swap, then the resume command and then the rest of the cryptsetup commands.
While browsing the mkinitrd code for a possible solution I noticed a variable name typo: # fgrep -n cryptopart /sbin/mkinitrd 72:ncryptoparts=0 718: eval cryptoparts${ncryptoparts}='"'/dev/$slavedev $dmname'"' 719: let ncryptoparts++ 1791:for cryptdev in ${!cryptopart@} ; do The variable name in line 718 must be "cryptopart", i.e. without the trailing "s".
Created attachment 301770 [details] unlock & resume from encrypted swap before anything else The attached patch is my implementation proposal. I have verified it on my laptop.
Created attachment 302226 [details] unlock & resume from encrypted swap before anything else Updated patch against mkinitrd 6.0.45
As the original issue is solved I'm closing this one. Opened bug #443082 for the order of unlocking & resuming.