Bug 60797 - Driver Load Order different on Install and Reboot
Driver Load Order different on Install and Reboot
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.2
noarch Linux
medium Severity medium
: ---
: ---
Assigned To: Michael Fulbright
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-06 16:25 EST by pdelaney
Modified: 2007-04-18 12:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-03-08 09:02:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description pdelaney 2002-03-06 16:25:20 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt)

Description of problem:
Driver load order during install can differ than load order on reboot if a 
driver update disk is used. Can leave system unable to reboot.

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


How reproducible:
Sometimes  (configuration dependent)

Steps to Reproduce:
1. Set up a system with two SCSI cards on the same PCI bus. Cards must be 
controlled by different drivers. Place one disk on each controller. In my test 
system, I used two adapters - one controlled by the sym53c8xx driver and the 
other by the mptbase/mptscsih driver.
2. Use a driver update disk to update the driver for the second controller 
found.  You may have to re-order cards in the system to reproduce the failure. 
In my setup, the mptbase/mptscsih driver was updated.
3. Install to the disk on the second controller (/dev/sdb)
	

Actual Results:  The module load order during installation and during reboot 
differ. This results in disk order changing and leaving the system unable to 
reboot successfully.


Expected Results:  Expect that the module load order during installation will 
be the same on reboot.

Expect that driver disk modules would load before any other modules.




Additional info:

The sym53c8xx (/dev/sda) driver loaded then the mptbase/mptscsih drivers were 
loaded from the driver disk (/dev/sdb).
Installation to /dev/sdb completely successfully with boot loader on /dev/sda.

However, /etc/modules.conf specifies that the mptbase/mptscsih modules load 
first and the sym53c8xx second. Unzipping and mounting the ramdisk images and 
viewing linuxrc, showed that the mptbase/mptscsih modules would load prior to 
the sym53c8xx module.  Thus /dev/sdb during install now became /dev/sda... 
and /dev/sda during install became /dev/sdb on a reboot.  

A similar problem was reported to regarding scsi and the megaraid driver. In 
this case, the (updated) scsi driver loaded first, the megaraid second during 
installation.  On reboot, the megaraid loaded first and the scsi driver second. 
Again the device ordering was altered preventing boot.

I can provide an update disk if required.
Comment 1 Jeremy Katz 2002-03-06 17:05:11 EST
This should be fixed with the updated boot disks released last month.  Can you
confirm that it occurs with these updated images?
Comment 2 pdelaney 2002-03-08 08:39:06 EST
Sorry about missing the updated boot image.  This image does correct the re-
ordering issue - thank you.  

The new boot image does not correct bug # 55037 and # 55832.  In my tests,the 
ramdisk images written to /boot contained obsolete driver object files 
(preventing reboot). The ramdisk image created on /dev/fd0 was correct.

I was able to work around this problem by using 3 disks during install:
(1) new boot.img (2) driver disk (3) updates diskette from RH created for the 
original boot image.

Can you verify #55037 / #55832 are alive again?


Comment 3 pdelaney 2002-03-08 09:02:42 EST
Searched some more... it appears that the RH intended the updates disk to be 
used even with the updated boot image. Not a problem will consider this 
closed.  Thank You.
Comment 4 Jeremy Katz 2002-03-13 17:00:59 EST
Yep, the three are meant to be used in concert unfortunately

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