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):
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
We've changed this significantly since this was filed; I think it should be
better now. Does it work for you?
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.