Bug 462492

Summary:	luks on LV for home broken by initscripts-8.82-1
Product:	[Fedora] Fedora	Reporter:	Alexandre Oliva <oliva>
Component:	initscripts	Assignee:	Bill Nottingham <notting>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	rstrode, rvokal
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-09-16 21:47:54 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:

Description Alexandre Oliva 2008-09-16 18:14:53 UTC

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

Comment 1 Ray Strode [halfline] 2008-09-16 21:13:53 UTC

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 21:47:54 UTC

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!