Hide Forgot
Fisher does not seem to see a SCSI CD-ROM with SCSI ID 0. Specifically, I have an IDE CD-ROM drive and a SCSI CD-ROM drive. When the SCSI CD-ROM drive had ID 0, it was not found at installation. I installed using my (slower) IDE CD-ROM drive without a problem. When the system came up, it didn't find my SCSI CD-ROM drive at all. Kudzu didn't detect it, explicitly loading modules didn't find it, etc. After loading the ide-scsi module, I could see my IDE CD-ROM drive as a SCSI device. After I changed the SCSI ID of my SCSI CD-ROM drive to 2 and rebooted, Kudzu detected the drive and I could access both drives from the running system. I tried going into installation again and that was able to find the drive as well. I don't know whether this is bug or a feature. There's no problem with my having my CD-ROM drive on something other than SCSI ID 0, but it seems like an odd problem.
What SCSI controller do you have (brand and if possible name)?
We (Red Hat) should really try to fix this before next release.
My SCSI controller is an on-board AIC 7890. I have an ASUS P2B-LS motherboard with this chip on-board. The board's BIOS revision is 1012. From /etc/sysconfig/hwconf: class: SCSI bus: PCI detached: 0 driver: aic7xxx desc: "Adaptec|AHA-2940U2/W / 7890" vendorId: 9005 deviceId: 001f subVendorId: 9005 subDeviceId: 000f pciType: 1 Hmm. cat /proc/scsi/aic7xxx/0 gives a segmentation fault. How strange. Should I send in a separate bug report for that?
This almost always means you have the SCSI ID of the controller set to 0 (devices and the controller itself can not share the same SCSI ID or else the devices won't get found). Until I hear otherwise, I'm assuming that's what the problem is and closing this bug out. Re-open it if the latest kernel builds don't work for you or if your SCSI ID on your controller is not set to 0.
My SCSI controller ID is 7. RedHat 6.2, 7.0 and the other systems that boot with 2.x kernels such as debian 2.2 and the linuxcare rescue CD all see the CD-ROM with no problem.
This still shouldn't be an issue with later kernel builds that have reverted to the original aic7xxx driver. However, I've also contacted the author of the Adaptec aic7xxx driver so that he may correct the situation.
Can you provide dmesg output from a successful and unsuccessful boot?
The only difference between dmesg output of a successful and unsuccessful boot is the detection of the CDROM: Vendor: TOSHIBA Model: CD-ROM XM-6201TA Rev: 1037 Type: CD-ROM ANSI SCSI revision: 02 However, it is definitely worth pointing out that this problem is not present with the 2.4.0.99-23 kernel from rawhide. That kernel detects the drive on either ID 0 or ID 2 as does a 2.4.1 kernel compiled using make oldconfig starting from the config used to build the i686 single processor kernel. I'm attaching a tarfile of the dmesg output from booting into single user mode using 2.4.0.99-11 (from Fisher), 2.4.0.99-23 (from Rawhide) and 2.4.1 as compiled above with the CDROM with ID 0 and ID 2. The only case that fails is Fisher, ID 0. So upgrading the kernel to the rawhide version is sufficient....
Created attachment 9683 [details] dmesg output from various boot scenarios
6.1.0 (actually 6.0.9BETA) corrected an issue where a check condition could be returned as an underflow error even if sense was returned. My guess is that this was what causing your CDROM drive to not appear. This bug should be closed.
As 2.4.0.99-23 fixes this for you, I'll close this bug as fixed in rawhide.