Red Hat Bugzilla – Bug 462492
luks on LV for home broken by initscripts-8.82-1
Last modified: 2014-03-16 23:15:47 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): initscripts-8.81-1.x86_64 plymouth-0.6.0-0.2008.09.10.1.fc10.x86_64 mkinitrd-6.0.63-2.fc10.x86_64 kernel-libre-2.6.27-0.329.rc6.git2.fc10.x86_64 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
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.
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. Thanks!