Description of Problem:
Installating Hampton beta3 onto LSI U320 as boot device with other scsi/RAID
cards (Adaptec 39160 and PERC3/DC) as additional cards with storage attached to
them, /etc/modules.conf doesn't order the mptbase and mptscsih in the right
order. After install, Linux loads the mptbase driver but doesn't load mptscsih,
doesn't find the /dev/sda device and fails with can't find root device message.
Version-Release number of selected component (if applicable):
Always when using different scsi controllers with LSI U320 as boot device
Steps to Reproduce:
1. Install Hampton Bet3 onto LSI U320 card (using a driver diskette of course),
with Adaptec 39160 and PERC3/QC as add on cards with storage attached to them.
2. Reboot to the Hampton kernel
3. Fails with can't find root message
Fails with can't find root device message
To install and boot system that has multiple scsi cards.
Ordering the modules in /etc/modules.conf so that mptscsih loads right after
mptbase and remaking the initrds fixes the problem. Anaconda needs to put them
in the right order in /etc/modules.conf
Created attachment 50645 [details]
Okay, let me try to make sure that I've got this straight. The boot controller
is the U320 card and the first disk on the controller is properly being assigned
sda. But, the order that the modules are loading is such that mptscsih is
loaded later than the mptbase module?
The problem with the current order of the modules.conf drivers is that the
subsequent scsi drivers after mptbase, in this case megaraid and aic7xxx, get
loaded before the mptscsih driver. The mptbase driver alone is not able to find
and load its devices correctly, so the boot device on the 22320 scsi card is not
found and placed at /dev/sda. Mptscsih needs to get loaded after mptbase, but
before anything else, and right now this is not happening.
With the 6650 we have here with a fusion card and aic7xxx, I'm getting the
aic7xxx loaded first and then mptbase, then mptscsih. Are you doing noprobe and
then loading them by hand? If so, what order did you choose to load modules in?
Actually we are running into problems getting the drivers of the disk during a
dd install. With a straight dd install (linux dd) we get a message to insert
fusion driver update disk after we've already inserted the driver disk and hit
ok. At this point we are forced to jump over to VC2 and load the drivers
manually from /tmp/drivers. Both drivers load successfully and controllers and
devices are detected but the manual load doesn't prompt entries into
modules.conf until somewhere at the end of the install. Of course, if you have
another scsi device, it will become /dev/sda after rebooting because of the
incorrect order of modules.conf.
Doing an "expert noprobe dd" install gets both drivers listed in the scsi driver
list when it is time to add devices from the menu. Loading the mptbase driver
works fine, but when attempting to load the mptscsih driver you are prompted
with the "insert fusion driver update disk" screen again. You can jump over to
VC2 and load the manually, but this again causes modules.conf to be out of order.
Basically, if the driver disk process for the two fusion drivers (mptbase and
mptscsih) was working correctly. The modules.conf order would take care of
Okay -- I was testing with NFS installs last night, so the drivers were in the
second stage. I'll try some different things this afternoon with our current
trees and see if I can reproduce this.
Booting with 'linux dd' and using the drvblock that we're currently generating
is working fine for me. Could you email me an image of the driver disk you're
Just emailed the driver disk we are using.
Hrmm... this is all working fine here, even with the driver disk you sent. I
booted with 'linux dd', said Yes to having a driver disk, inserted it, and had
the proper drivers loaded and was on my way. Maybe a different pci id or a bios
problem on the fusion card?
Also, just for whatever it's worth -- manually loading the drivers and not
updating the modules.conf will definitely cause drivers to be ordered
differently post-install, so if you manually load drivers, you should also
manually add them to /tmp/modules.conf
Problem is solved now that installer has the drivers and loads them without
driver disk in beta4.