Bug 69932 - SAN disks detected before SCSI disks
Summary: SAN disks detected before SCSI disks
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: i686 Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2002-07-26 15:51 UTC by Paul Witting
Modified: 2014-01-21 22:48 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 15:39:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Paul Witting 2002-07-26 15:51:02 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; H010818; .NET 
CLR 1.0.3705)

Description of problem:
Boot behavior changed between RH 7.2 and RH 7.3, under 7.3 SAN disks attached 
to a QLogic 2200 are detected BEFORE localally attached disks (at least those 
connected to either an aacraid or aic7xxx controller). The 7.2 behavior 
seems "right", since it would be a rare situation where a SAN boot is 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Install RH while SAN is attached - SAN disk is listed as sda
    -- or --
1.Install RH while SAN disconnected
2.Attach SAN
3.Boot fails when SAN disk is detected first and is assigned sda

Actual Results:  SAN disk is assigned /dev/sda, SCSI disks are 
assigned /dev/sdb+, causing a failure when disk detection routines complete

Expected Results:  Local disks should be mounted first in almost all cases. The 
error reported and the suggested solution (try passing init= to the kernel) 
would likely confuse a new user

Additional info:

I solved the problem by re-ordering /etc/modules.conf and building a new initrd 
while the SAN was unplugged.

Problem experienced with a Dell 2450/Perc3/si and a VaLinux 2200; The RH 7.2 
system was a Dell 4300/Perc2 (Quad Channel), which worked as expected (at least 
in regards to the boot process, see other reports)

Comment 1 Arjan van de Ven 2002-07-26 16:19:34 UTC
the order is determined by /etc/modules.conf actually
it lists the order of scsi host drivers there

Comment 2 Bill Nottingham 2002-07-26 16:28:31 UTC
You can change the order by installing with 'expert noprobe' and choosing your
drivers in whatever order prefer. After install, you can change the order by
reordering the "scsi_hostadapter" lines in /etc/modules.conf.

Aside from that, the order is determined by the PCI bus scan order, which comes
from the kernel.

Comment 3 Paul Witting 2002-07-26 17:24:21 UTC
My experience was that re-ordering the drivers in /etc/modules.conf was not 
sufficient. Once /etc/modules.conf was re-ordered, I had to generate a new 
initrd via mkinitrd /boot/initrd-24.18-3san.img 2.4.18-3smp; then 
modify /etc/lilo.conf to boot from this new ramdisk image (and run lilo, of 
course). Once this was done, devices were detected in the order I wished, and I 
could move back and forth from the two detect orders based on wether I selected 
the original RH configuration or my modified configuration.

As for PCI detect order, the VaLinux boxes seemed to detect the QLogic adapter 
first, which would support the theory that the "installer" saw this item first, 
but the Dell 2450's detect the PERC card first, yet still "loaded" the qla2200 
driver first.

As for installing with the "expert noprobe" option, If I get a chance I'll play 
with this, (these two systems are in production now) but if the order can be 
corrected without such a workaround it ought to be. (I'm a pretty experienced 
Linux user now, and entering that mode made ME nervous, what about the typical 

Comment 4 Seth Vidal 2002-08-06 05:05:52 UTC
I saw the same behavior on a dell PE2650 with internal disks attached to
internal controller and external disks attached to additional adaptec 39160 in
one of the pci slots. I'll try the suggested expert noprobe tomorrow and see if
I can work around it.

Comment 5 Bugzilla owner 2004-09-30 15:39:47 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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