Description of problem: If RHEL 3.0 is installed over ***PXE and NFS or Hard drive image***, by using "linux dd askmethod" at the boot prompt, if installing to a mass storage controller such as a scsi/raid controller, for which an older driver is present in the installation cd, and we provide a newer driver disk, the newer driver is used during the install, and it creates, formats partitions correctly, copies files correctly, but ***DOES NOT copy the new updated driver***, that was provided, to the lib/modules/<kernel- version>/kernel/drivers/scsi directory, and the initrd created too has the older driver from the install cd. so in some cases when the older driver is incorrect for the newer hardware/firmware, after installation, on reboot to freshly installed system, the kernel panics. This is because the insmod fails for the older driver that the initrd has, so the kernel cannot find/mount the root partition. ***This does not happen with CDROM based installs, where any new driver provided with driver diskette is copied over to the installed system correctly, and the initrd created is with the newer driver.*** Version-Release number of selected component (if applicable): How reproducible: Every time. Steps to Reproduce: 1.Install RHEL 3.0 by pxe and nfs or hdd image onto adaptec raid controller (2200S or 2410SA) 2.Use new driver on Adaptec website, newer than installation cd driver, in driver diskette during install. 3.Use new firmware for controller from website. Actual results: On reboot after installation is over, you would most probably get a kernel panic, because the older driver on the installation cd that gets copied over, and is in the initrd, does not load correctly, the insmod fails. Expected results: The correct newer driver from the driver diskette provided by user should be copied over, (which does happen with CDROM installs, but does not, with other installs) Additional info: Generally, RHEL 3.0 is not installed with the CDs. so, this should be a problem that shouldn't happen.
The newer driver should end up in /lib/modules/$(uname -r)/updates and not under drivers/scsi -- are you sure it's not ending up there?
Closing due to inactivity. Please reopen this bug if you have further information to add to the report.