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
desc: "Adaptec|AHA-2940U2/W / 7890"
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 188.8.131.52-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 184.108.40.206-11 (from Fisher), 220.127.116.11-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 18.104.22.168-23 fixes this for you, I'll close this bug as fixed in rawhide.