Bug 180769

Summary: Wrong order for cciss module when using LVM
Product: Red Hat Enterprise Linux 3 Reporter: Dag Wieers <dag>
Component: mkinitrdAssignee: Peter Jones <pjones>
Status: CLOSED WONTFIX QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-19 18:47:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Dag Wieers 2006-02-10 07:53:41 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060130 Red Hat/1.0.7-1.4.3 Firefox/1.0.7

Description of problem:
I have lost a few hours yesterday figuring out why booting didn't properly work on a restored system with a cciss module and LVM on a ProLiant DL380 G3.

I restored a system by booting into RHEL3 rescue mode, creating an LVM setup, untarring the backup over the new filesystem layout and bringing all the required config-files up to date with the new system. After creating a new initrd, the kernel failed to boot. Either with 'No filesystem with label /' or when using the LV name /dev/rootvg/rootlv 'Error 6: cannot mount filesystem ext3' (or something similar).

Eventually I found that I had to run mkinitrd with the following options to make it work:

  --preload sd_mod --preload cciss --with lvm-mod

(not sure if the lvm-mod was needed explicitly)

Fact is that without preloading the order was more like:

   scsi_mod sd_mod lvm-mod cciss

with preloading cciss it was:

  scsi_mod cciss sd_mod lvm-mod

and with the above options I got:

  scsi_mod sd_mod cciss lvm-mod

Now, I am not sure what influences the order of mkinitrd's module list. But this should somehow be fixed. Apparently when you do a new anaconda install there does not seem to be a problem, but when creating an initrd with mkinitrd on a clean restored system, this fails.

One of the problems determining the cause was that on a 25 lines remote console, you have no clue of what happened when loading the modules. If there was a better interface to see what was failing and what not, the correct order of the modules would have been a piece of cake.

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

How reproducible:

Steps to Reproduce:
1. Boot a system in rescue mode
2. Create a initrd with cciss module and lvm-mod
3. Look at the order

Additional info:

Comment 1 Peter Jones 2006-02-28 15:43:49 UTC
We've changed this significantly since this was filed; I think it should be
better now.  Does it work for you?

Comment 3 RHEL Product and Program Management 2007-10-19 18:47:38 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.