Bug 469131

Summary: System not bootable after installation when using encrypted root filesystem
Product: Red Hat Enterprise Linux 5 Reporter: Stephen Gardner <stephen-rhel>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.3CC: dlehman
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-30 14:02:06 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 Stephen Gardner 2008-10-30 02:56:57 UTC
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

After performing a simple "next-next-next" installation on a server  *with* the Encrypt system option checked the machine completed a successful installation but fails to prompt for the password and then fails to locate the root device.

[ I should note that I had a very similar experience to this with ]
[ Fedora 9 (x86_64), Fedora 10 Alpha / Beta and Beta Snap 2 ]
[ reported in BZ #431778 ]

Reproducible: Always

Steps to Reproduce:
PXE booted, no command-line parameters passed
Language: English, UK Keyboard
Install Method: NFS, DHCP (IPv4 only), GUI install commenced
Key skips, disk initialization requested (as the disk has been zeroed before testing)
"Remove linux partitions on selected drives and create default layout"  chosen
Encrypt system  checked, password    12345678   (given, for testing)
Location set to Europe/London
Software selection unchanged from default
Install completed successfully and system rebooted

Actual Results:  
The system boots grub, the kernel, loads the initrd but then fails to locate the VolGroup00 volume group as it has not been through a cryptsetup luksOpen phase and then booting process halts as it fails to mount the root filesystem (and swap) and panics.

Expected Results:  
Prompt for root volume password and then proceed to a clean system startup

Installation was: RHEL5-U3 Beta (x86_64)

Hardware used:
System Hardware: HP ProLiant DL380-G4 (2x 3.8Ghz Xeon, 6GB RAM)
BIOS date: 07/19/2007
SmartArray 6i firmware revision: v2.84 (with 192MB BBWC)
1x logical 146GB drive, comprised of 2x 146GB disks mirrored which is presented to the OS as /dev/cciss/c0d0

Upon restart the system boots but then hits a fatal error with

  Reading all physical volumes.  This may take a while...
  Volume group "VolGroup00" not found
Unable to access resume device (/dev/VolGroup00/LogVol01)
mount: could not find filesystem '/dev/root'
setuproot: moving /dev failed: No such file or directory
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
switchroot: mount failed: No such file or directory
Kernel panic - not syncing: Attempted to kill init!

--

On booting the system in (u3beta) rescue mode the disks, PV, VG and LVs were all correctly detected, I was prompted for the LUKS password and the filesystems were mounted correctly under /mnt/sysimage. I extracted the initrd which contained the cciss driver but unlike a Fedora 9 (x86_64) desktop system I've had for a while it does not contain and of the encryption, hashing or dm-crypt modules or cryptsetup. Neither those modules nor cryptsetup is mentioned in the init file. On the main root filesystem from inside rescue mode I could see that

/etc/modprobe.conf does included
alias scsi_hostadapter cciss

and /etc/crypttab included an entry with a UUID which I presume is for the root device.

Based on the last entry in BZ #431778 this may well now be fixed in (Fedora) rawhide but there are only so many hours i can spend on this issue.

For completeness I ran exactly the same installation in parallel on a DL380-G5 server (with a similar but upgraded spec) and got exactly the same result.

I believe based on testing that this is not a problem with the cciss driver or encrypted root filesystem support but only occurs when the two elements are combined.

Comment 1 David Lehman 2008-10-30 14:02:06 UTC
This was recently found in testing and fixed in mkinitrd-5.1.19.6-39.

You are correct that it is triggered by the use of encrypted cciss devices.

*** This bug has been marked as a duplicate of bug 467839 ***