Bug 500830 - 11-Preview: boot passphrase not accepted
11-Preview: boot passphrase not accepted
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
: 475748 (view as bug list)
Depends On:
Blocks: F11Blocker/F11FinalBlocker
  Show dependency treegraph
 
Reported: 2009-05-14 08:49 EDT by Richard W.M. Jones
Modified: 2013-01-10 00:13 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-18 16:48:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2009-05-14 08:49:48 EDT
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 09:55:06 EDT
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 09:57:06 EDT
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 10:05:14 EDT
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 12:05:50 EDT
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 14:56:37 EDT
Should be fixed in 6.0.84-1 .
Comment 6 Richard W.M. Jones 2009-05-14 18:02:06 EDT
I tested Peter Jones's updated mkinitrd package and
I can report that it works.
Comment 7 Tomasz Torcz 2009-05-15 09:58:27 EDT
*** Bug 475748 has been marked as a duplicate of this bug. ***
Comment 8 Jesse Keating 2009-05-18 16:48:00 EDT
That's tagged, closing this.
Comment 9 Jeremy Katz 2009-05-18 16:55:17 EDT
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 :)

Note You need to log in before you can comment on or make changes to this bug.