Bug 458763

Summary: Plymouth fails to unlock encrypted root filesystem after upgrade from F9 to F10-alpha
Product: [Fedora] Fedora Reporter: W. Michael Petullo <mike>
Component: plymouthAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: atodorov, dcantrell, krh, poelstra, rstrode
Target Milestone: ---   
Target Release: ---   
Hardware: powerpc   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-08-30 04:59:43 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: 438943    

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)