Bug 18719 - RH7.0 fails to install on Perc 3/DC if Perc 2/DC is present
Summary: RH7.0 fails to install on Perc 3/DC if Perc 2/DC is present
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.0
Hardware: i386
OS: Linux
high
high
Target Milestone: ---
Assignee: Michael Fulbright
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-10-09 15:22 UTC by Tesfamariam Michael
Modified: 2005-10-31 22:00 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2000-10-27 17:01:41 UTC
Embargoed:


Attachments (Terms of Use)

Description Tesfamariam Michael 2000-10-09 15:22:30 UTC
When Perc3/DC and Perc2/DC are present on a system, RH installs on 
Perc2/DC. If the Perc2/DC was added with some logical volumes after 
installing on Perc3/DC, RH tries to boot of the Perc2/DC and the system 
hangs with the following message "VFS: Cannot open root device 08:06
Kernel panic: VFS: Unable to mount root fs on 08:06". The megaraid (v1.09) 
always insmod to Perc2/DC first. Slot assignment and cards BIOS 
Enabling/Disabling doesn't have any effect.

Comment 1 Matt Domsch 2000-10-09 20:39:17 UTC
This isn't really an installer issue, but a kernel issue, and fairly generic at 
that.  The question is, in what order should a device driver detect cards that 
it supports?  If you have disks on SCSI controllers such that you violate this 
order, your root and /boot file systems wind up in the wrong place, and you 
can't boot.

There needs to be a generic way to indicate to the kernel and various device 
drivers which controller the BIOS thinks is your boot device, and make sure 
that the right driver is loaded first, and that the right controller is 
detected first by that driver.  Volume labels help a lot, but don't handle the 
cases of root, /boot, and swap properly, /boot necessary for lilo.


Comment 2 Alan Cox 2000-10-27 17:01:38 UTC
I2O controllers actually let you ask them if they were the boot device (the
controller firmware  obviously knows this). We put the boot device first then
scan the others in PCI order.


Comment 3 Dale Kaisner 2001-07-20 21:39:21 UTC
Resolved in RH7.1


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