Bug 469131 - System not bootable after installation when using encrypted root filesystem
Summary: System not bootable after installation when using encrypted root filesystem
Keywords:
Status: CLOSED DUPLICATE of bug 467839
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda
Version: 5.3
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-30 02:56 UTC by Stephen Gardner
Modified: 2008-10-30 14:02 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-30 14:02:06 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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 ***


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