I installed F11-Preview, using a passphrase in Anaconda. When I came to boot the machine, the passphrase wasn't accepted by the initrd. Initially I thought I had typo'd the passphrase in Anaconda, and so I went back to do a fresh install. However, Anaconda accepts the original/correct passphrase (to unlock the disk so it can tell whether to install or upgrade). Additionally, I started a shell in the installer and typed: sh-4.0# cryptsetup luksOpen /dev/sdb2 lukstest Enter LUKS passphrase for /dev/sdb2: <<here I typed the passphrase>> key slot 0 unlocked. Command successful. and I verified that vgscan, etc can see the unlocked disk. So: I don't think this is an anaconda problem. I think the initrd isn't accepting my passphrase for some reason. Note: I typed the passphrase very carefully, and have tried this several times, with no success. Note also: passphrase is very long (20+ chars) and contains only lowercase characters and spaces. Therefore I don't think this is a keyboard encoding issue (I have a UK keyboard). But it might be truncating long passphrases?
Reassigning this to component plymouth. I examined the initrd and have seen that plymouth is the command used to ask for the password.
Additional: Using 'cryptsetup luks*' commands I changed the passphrase on the device to 123456 Anaconda still accepts this passphrase, but plymouth still can't boot with it. Seems it's not the length or the particular characters within the passphrase which are the problem.
Ah ha, found the problem! I booted Anaconda from a USB device. In Anaconda, the mapping of devices is: /dev/sda - USB memory stick /dev/sdb - Hard disk Unfortunately at boot time the mapping is the other way around: /dev/sda - Hard disk /dev/sdb - USB memory stick The initrd contains hard references to /dev/sdb2, eg: ./init:echo Setting up disk encryption: /dev/sdb2 ./init:plymouth ask-for-password --command "cryptsetup luksOpen /dev/sdb2 luks-e9db38bd-f184-461d-9a42-c6c232e69653" which is why it failed - Plymouth was trying to open the wrong device. I manually rebuilt the initrd to change sdb2 -> sda2, and the machine boots correctly. Anyhow, this is definitely a bug, but I have no idea which component it should go into. Perhaps back to mkinitrd? anaconda?
mkinitrd is the right place for this. Peter is looking at some ways to fix And putting on the blocker list as we have lots of people that install from the live image on a USB key and they may choose to use encryption.
Should be fixed in 6.0.84-1 .
I tested Peter Jones's updated mkinitrd package and I can report that it works.
*** Bug 475748 has been marked as a duplicate of this bug. ***
That's tagged, closing this.
And I did installs today off of a live image running off of a USB stick that included the new mkinitrd and the system booted afterwards (... conveniently, this was the problem that I had hit and started looking at Wednesday afternoon and then Peter pointed me to this Thursday morning :)