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.
This should be fixed with the updated boot disks released last month. Can you confirm that it occurs with these updated images?
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?
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.
Yep, the three are meant to be used in concert unfortunately