Bug 500830

Summary:	11-Preview: boot passphrase not accepted
Product:	[Fedora] Fedora	Reporter:	Richard W.M. Jones <rjones>
Component:	mkinitrd	Assignee:	Peter Jones <pjones>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	dcantrell, fedora, hdegoede, katzj, krh, pjones, rstrode, tomek, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-05-18 20:48:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	446452

Description Richard W.M. Jones 2009-05-14 12:49:48 UTC

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?

Comment 1 Richard W.M. Jones 2009-05-14 13:55:06 UTC

Reassigning this to component plymouth.  I examined
the initrd and have seen that plymouth is the command
used to ask for the password.

Comment 2 Richard W.M. Jones 2009-05-14 13:57:06 UTC

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.

Comment 3 Richard W.M. Jones 2009-05-14 14:05:14 UTC

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?

Comment 4 Jeremy Katz 2009-05-14 16:05:50 UTC

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.

Comment 5 Peter Jones 2009-05-14 18:56:37 UTC

Should be fixed in 6.0.84-1 .

Comment 6 Richard W.M. Jones 2009-05-14 22:02:06 UTC

I tested Peter Jones's updated mkinitrd package and
I can report that it works.

Comment 7 Tomasz Torcz 2009-05-15 13:58:27 UTC

*** Bug 475748 has been marked as a duplicate of this bug. ***

Comment 8 Jesse Keating 2009-05-18 20:48:00 UTC

That's tagged, closing this.

Comment 9 Jeremy Katz 2009-05-18 20:55:17 UTC

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 :)