Bug 180769 - Wrong order for cciss module when using LVM
Wrong order for cciss module when using LVM
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: mkinitrd (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-10 02:53 EST by Dag Wieers
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 14:47:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dag Wieers 2006-02-10 02:53:41 EST
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):
mkinitrd-3.5.13.3

How reproducible:
Always

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 10:43:49 EST
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 14:47:38 EDT
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:
http://www.redhat.com/security/updates/errata/
 
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.

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