Bug 458763 - Plymouth fails to unlock encrypted root filesystem after upgrade from F9 to F10-alpha
Summary: Plymouth fails to unlock encrypted root filesystem after upgrade from F9 to F...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: plymouth
Version: rawhide
Hardware: powerpc
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F10Blocker, F10FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2008-08-12 04:34 UTC by W. Michael Petullo
Modified: 2013-01-10 04:46 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-08-30 04:59:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description W. Michael Petullo 2008-08-12 04:34:28 UTC
Description of problem:
I have an encrypted root filesystem. I recently used yum to upgrade Fedora 9 to 10 Alpha. 

Version-Release number of selected component (if applicable):
mkinitrd-6.0.61-1.fc10.ppc
plymouth-0.5.0-14.2008.08.08.fc10.ppc
kernel-2.6.27-0.244.rc2.git1.fc10.ppc

How reproducible:
Everytime

Steps to Reproduce:
1. Install Fedora 9 using an encrypted root filesystem
2. "yum update" to Fedora 10 Alpha
3. Reboot the Fedora 10 Alpha kernel / mkinitrd
  
Actual results:
My system boots using Plymouth. When I tried to boot the Fedora 10 Alpha kernel, I received the following errors after I entered my passphrase:

...
Loading keymap.
Loading /lib/kbd/keymaps/i386/qwerty/us.map
Setting up disk encryption: /dev/hda4
Command failed: No key available with this passphrase
Setting up disk encryption: /dev/hda5
Command failed: No key available with this passphrase
device-mapper: table ioctl failed: No such device or address
...

Expected results:
System should boot.

Additional info:
Booting the Fedora 9 kernel / initrd still works fine.

Comment 1 Ray Strode [halfline] 2008-08-26 13:42:41 UTC
Oh this was an installer bug I think.

Jesse you saw this too, right?  Do you remember the details?

Note there was a bug in the way the size of the password was getting sent over the wire (between client and daemon) that big endian machines would have seen.  That could have caused this, too.

Comment 2 Jesse Keating 2008-08-26 16:56:52 UTC
I did see this, but I don't recall what I eventually did to make it work.  I /think/ I reverted back to the alpha and started from there, but I'm not sure.

Comment 3 Ray Strode [halfline] 2008-08-26 17:29:07 UTC
So I talked to someone on the installer team about this a bit and he helpfully pointed out that comment 0 mentions doing a yum upgrade, not an anaconda upgrade.

This has nothing to do with the installer then.

If the old initrd works, that suggests the disk is still encrypted with the right password, so I think we can safely say this issue is distinct from the issue Jesse was seeing.

It may be the aforemented endianess issue I alluded to earlier.

Michael, would you mind trying the latest plymouth in rawhide and reporting whether the problem is still present?

Comment 4 W. Michael Petullo 2008-08-26 21:01:27 UTC
The version I am using is the most current out of Rawhide. I will try a new version as soon as it is available.

Comment 5 Ray Strode [halfline] 2008-08-27 14:01:51 UTC
Sorry for the confusion, I don't think we've had a rawhide since we were shut down.

Comment 6 W. Michael Petullo 2008-08-29 00:35:49 UTC
I just tried plymouth-0.6.0-0.2008.08.27.2.fc10.ppc and there is no change to my original report.

Comment 7 W. Michael Petullo 2008-08-30 04:59:43 UTC
Okay, the latest update seems to have fixed this. I enter my password and my system continues to boot. No change to plymouth's version since comment #6. Maybe the latest kernel/initrd update did it?

Comment 8 Ray Strode [halfline] 2008-09-02 13:40:57 UTC
yea, unfortunately plymouth daemon updates don't take affect until the next kernel update

(unless you run 

/sbin/mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r)

to force an update)


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