Bug 462492 - luks on LV for home broken by initscripts-8.82-1
luks on LV for home broken by initscripts-8.82-1
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-09-16 14:14 EDT by Alexandre Oliva
Modified: 2014-03-16 23:15 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-09-16 17:47:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2008-09-16 14:14:53 EDT
As mentioned in bug 461797 comment 7, before upgrading to initscripts-8.82-1, I got prompted for a password for my "home" filesystem at boot-up a single time, and the filesystem was mounted properly.

After the upgrade, it asks for the password twice, and then drops me to an interactive repair shell.

I have a volume group built out of RAID 1 devices.  In this volume group, I have root, swap, and a "home" logical volumes, all mounted during boot.  The "home" partition is actually a luks-encrypted chunk of disk.

Booting up without rhgb *prints* the password I enter (bad!), after prompting for it, and fails in just the same way.  I couldn't get any additional useful information with this exercise.

The repair shell shows that the 3 devices for the logical volumes are present in /dev/mapper, but the luks device isn't, even though IIRC it appeared to be active.

Running luksOpen in the interactive repair shell created the device and enabled me to mount the filesystem, but leaving that shell reboots the system, so it's no use.

The kernel was installed last thing before the reboot, so its initrd contained the last plymouth binaries.  Re-creating initrd (just in case) didn't make any difference.

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Additional info:
[root@livre ~]# pvs
  PV         VG   Fmt  Attr PSize  PFree
  /dev/md5   all  lvm2 a-   40.42G 2.42G
  /dev/md6   all  lvm2 a-   15.00G 3.58G
[root@livre ~]# lvs
  LV   VG   Attr   LSize  Origin Snap%  Move Log Copy%  Convert
  l    all  -wi-ao 36.00G                                      
  swap all  -wi-ao  2.00G                                      
  test all  -wi-ao 11.41G          
[root@livre ~]# cat /etc/crypttab 
luks-all-l              /dev/mapper/all-l none
[root@livre ~]# grep '/dev/\(all\|mapper\)' /etc/fstab
/dev/all/test           /                       ext3    noatime         1 1
/dev/mapper/luks-all-l  /l                      ext3    noatime         1 2
/dev/all/swap           swap                    swap    defaults        0 0
Comment 1 Ray Strode [halfline] 2008-09-16 17:13:53 EDT
Do either /bin/plymouth or /bin/plymouthd exist? They shouldn't, but might because of an early mkinitrd bug.

If they do exist, then that would explain this behavior.  Since rc.sysinit would be calling an old, stale /bin/plymouth binary instead of the new /usr/bin/plymouth binary.
Comment 2 Alexandre Oliva 2008-09-16 17:47:54 EDT
Aha!  Good catch!

Yes, they did exist (I had them for at least one month), and removing them and then rebuilding mkinitrd did fix the problem.


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