Bug 458763 - Plymouth fails to unlock encrypted root filesystem after upgrade from F9 to F10-alpha
Plymouth fails to unlock encrypted root filesystem after upgrade from F9 to F...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: plymouth (Show other bugs)
rawhide
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F10Blocker/F10FinalBlocker
  Show dependency treegraph
 
Reported: 2008-08-12 00:34 EDT by W. Michael Petullo
Modified: 2013-01-09 23:46 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-30 00:59:43 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 W. Michael Petullo 2008-08-12 00:34:28 EDT
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 09:42:41 EDT
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 12:56:52 EDT
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 13:29:07 EDT
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 17:01:27 EDT
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 10:01:51 EDT
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-28 20:35:49 EDT
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 00:59:43 EDT
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 09:40:57 EDT
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.