Red Hat Bugzilla – Bug 27627
can't mount SCSI zip drive if no disk inserted during boot
Last modified: 2007-04-18 12:31:28 EDT
I had earlier reported problems seeing my CDROM drive when it has SCSI ID 0
(see bug 25997). Since then, I've been testing with the Rawhide kernel
(2.4.0-0.99.23) which has been overall working just fine. However, I
noticed that I can no longer mount my SCSI zip drive (/dev/sda4). This is
the only SCSI "hard drive" I have. I also have a tape drive and CD-ROM
drive. I can mount /dev/sda4 fine under the default Fisher kernel and
under RedHat 6.2, but not under 2.4.0-0.99.23. Interestingly,
/proc/scsi/scsi and the boot process both see the zip drive, and fdisk -l
/dev/sda shows the sda4 partition. Attempting to mount says that /dev/sda4
is an invalid block device.
My SCSI controller is an on-board AIC 7890. I have an ASUS P2B-LS
with this chip on-board. The board's BIOS revision is 1012. From
desc: "Adaptec|AHA-2940U2/W / 7890"
I know there are issues with new beta AIC7xxx drivers. Do I need to be
concerned about this? For now, I've gone back to the default Fisher kernel
recompiled with apm changes (from bug 26261) and everything works fine.
(My CD-ROM drive is no longer on ID 0.)
There are no siginificant differences between dmesg output with these two
kernels. (ACPI messages are not present in 0.99.23 since ACPI is turned
off, and the CPU speed differs by a few thousands...)
If I'm reading my logs right, you have the choice of the
aic7xxx and aic7xxx_old drivers. Try the aic7xxx_old
driver and see if it works.
In our current source tree, we have the original aic7xxx
as the aic7xxx driver, the new one as aic7xxx_new, and the
original one has a few bug fixes. So when we come out with
a new kernel package, please do test it and make sure that
it fixes the problem.
We (Red Hat) should really try to resolve this before next release.
I have a little more information. My original report was slightly inaccurate.
The actual situation is that you can't mount the zip drive if no disk was
inserted during the boot process. The same modules are present in both cases
and fdisk -l /dev/sda works in both cases, but if no disk was inserted while the
system booted, you get an error that /dev/sda4 is not a valid block device.
This problem occurs with both the stock Fisher kernel and the Rawhide kernel.
It does not happen with an unpatched 2.4.1 kernel which seems to use a different
aic7xxx driver from RedHat's kernel. Unloading and reloading the aic7xxx and
sd_mod modules didn't help.
OK, please try it with the 2.4.1-0.1.9 or later kernel when it gets
to rawhide -- that should be in sync with the latest -ac releases in
terms of what aic7xxx driver it is using. Thanks.
I'd like to try with that kernel. Is there a way I can know when it is
available other than continually checking rawhide? I'm also waiting for the new
kernel to do some iptables testing.
I'm sorry to say that this bug has NOT been fixed in Wolverine.
Rawhide has a more recent kernel.
Is this a regression relative to the 2.2 kernel?
I know that some people find that the boot hangs if they
do not have a disk inserted, and we're trying to fix that,
but I'm not sure it's related.
You could try
echo "scsi add-single-device C B T U > /proc/scsi/scsi"
where C is controller number, B is bus number, T is target
(your zip disk) SCSI id, and U is your target lun (probably
0) to see if that helps.
Alan reports known regressions regarding removeable devices
fixed in the source code we are building for the next rawhide.
2.4.2-0.1.16 or later will have his known regressions fixed
and be worth testing when it appears in rawhide.
echo "scsi add-single-device 0 0 6 0" > /proc/scsi/scsi
didn't work, but I'm not surprised since /proc/scsi/scsi already showed the zip
drive and fdisk -l /dev/sda already worked. However, this made me think of
something else which actually did work. After running the following C code:
int fd = open("/dev/sda", O_RDWR);
if (fd == -1)
fprintf(stderr, "open device: %s\n", strerror(errno));
if (ioctl(fd, BLKRRPART, 0) == -1)
fprintf(stderr, "ioctl BLKRRPART: %s\n", strerror(errno));
to force the system to reread the partition table (or running fdisk /dev/sda and
hitting "w"), it was possible to mount /dev/sda4. I guess the kernel tries
(unsuccessfully) to read the partion table at boot time and then forgets to
reread it later when things change.
Another piece of evidence that supports this is that if you eject this disk and
insert another with a different partition table, you can't mount partitions on
the new disk that didn't exist on the old disk until after you run the above
It would be unsurprising if the removable device fixes will be in the kernel you
mentioned since it looks from a casual perusal of the ac patches that 2.4.2-ac4
has code that rechecks the partition table of removable disks after it notices
that they have been changed.... Anyway, I'll retest when a new kernel makes it
to rawhide (and I notice it or see something about it here or on the wolverine
Arjan, can you please double-check that those fixes went into
2.4.2-0.1.16? If not, please put them in place for the next
I can't reproduce this using the aic7xxx driver from kernel-2.4.2-0.1.19.
Everything mis seen and works fine on bootup. This is with an 2930U2
Could you retry using the 2.4.2-0.1.19 kernel in rawhide and see if this problem
This problem is fixed in the 2.4.2-0.1.19 kernel.
"This problem is fixed in the 2.4.2-0.1.19 kernel." -> Closing as fixed in