Bug 180769

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: