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