Red Hat Bugzilla – Bug 250486
ATAPI ZIP Drive not recognized unless system is booted
Last modified: 2007-11-30 17:12:12 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:22.214.171.124) Gecko/20070727 Fedora/1.1.3-2.fc7 SeaMonkey/1.1.3
Description of problem:
With earlier kernels, 2.6.18 for example, /dev/hda was always created.
Now, kernels create /dev/sde and /dev/sde4, if and only if the drive
has a disk inside and the system is re-booted.
More of the problem is that /dev/sde cannot be read from nor written to,
except by the sfdisk program. And hundreds of error messages are logged
when commands such as mount and fdisk are used to access the device.
Examples of commands and responses, as well as a few of the error messages
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Insert a ZIP disk into the drive
2.Re-boot the system and watch the boot-up messages - many errors are listed
3.After boot-up, login as root and try to issue a mount command, the fdisk command, the sfdisk command.
4.The command, sfdisk -l /dev/sde4, will show how badly the system has
recognized the ZIP drive, indicating charactersitics that match the system's
other Hard Drives(Western Digital SATA drives)
The drive is not recognized correctly. Nothing can be mounted.
The drive cannot be used.
Just one example: The command, mount -t vfat /dev/sde4 /mnt, should have
resulted in the partition /dev/sde4 being mounted at the mount-point /mnt.
Here is the output from the only command (sfdisk) that has any success at all:
[root@estreet ~]# ls -alt /dev/sde*
brw-r----- 1 root disk 8, 64 2007-07-28 14:23 /dev/sde
brw-r----- 1 root disk 8, 68 2007-07-28 14:23 /dev/sde4
[root@estreet ~]# sfdisk -l /dev/sde
Disk /dev/sde: 0 cylinders, 255 heads, 63 sectors/track
Warning: The partition table looks like it was made
for C/H/S=*/64/32 (instead of 0/255/63).
For this listing I'll assume that geometry.
Units = cylinders of 1048576 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
/dev/sde1 0 - 0 0 0 Empty
/dev/sde2 0 - 0 0 0 Empty
/dev/sde3 0 - 0 0 0 Empty
/dev/sde4 * 0+ 95 96- 98288 6 FAT16
[root@estreet ~]# mount /dev/sde4 /mnt
mount: you must specify the filesystem type
[root@estreet ~]# mount -t vfat /dev/sde4 /mnt
mount: /dev/sde4: can't read superblock
Created attachment 160465 [details]
A few of the error messages generated when accessing the ZIP drive
Created attachment 160466 [details]
Output of a script that rescans the SCSI bus
Note the lines containing "scsi1". These are the lines that
should show vendor information about the device (I think).
Similar results are obtained as the output of the command
The device is not recognized properly.
Reassigning to default owner of 'kernel' component.
What exactly do the boot messages say?
Post (as attachments)
1. the contents of /var/log/dmesg after booting with a disk inserted.
2. the contents of /var/log/dmesg after booting without a disk inserted.
Created attachment 168590 [details]
Contents of /var/log/dmesg after booting with a disk inserted
Created attachment 168591 [details]
Contents of /var/log/dmesg after booting without a disk inserted
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.
I am CC'ing myself to this bug and will try and assist you in resolving it if I can.
There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?
If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.
Thanks for your comment offering to assist in resolving this bug.
Are you asking that I install the "latest kernel" and then see if
the problem still exists? I'm not clear on the possible implication
in your question. If so, I would be happy to get a specific version
of the kernel from kernel.org, install it, and then try using the
ZIP drive/disk again.
Since submitting this bug report, I have not upgraded the kernel.
I'm still using 126.96.36.199, built on July 26, 2007. If you have a
specific kernel version in mind, please indicate which one it is.
Otherwise, I'll just pick the "latest stable version".
Thanks again for offering your assistance.
yum update kernel
and re-test would be great. This will pick up the latest stable kernel.
Looks like the "latest stable kernel" works!
I installed kernel-188.8.131.52-76.fc7.x86_64.rpm,
re-booted the machine specifying this kernel,
and then inserted a ZIP disk into the ZIP drive.
Not only were there no error messages during the
boot-up process, but the kernel (I assume) detected
the disk being inserted and entered several messages
The drive was correctly detected (number and size of
sectors) and the correct partition number was given
Thank you, Chris, for pushing me to try a newer kernel.
I was reluctant to upgrade because VMware and NVIDIA
had been running well for a long time, and if it ain't
broke, I usually don't want to fix it.
Please close this bug. I feel a bit guilty for opening it,
seeing now that simply upgrading to a new kernel very probably
would have made the ZIP drive problem go away.
(In reply to comment #10)
> Looks like the "latest stable kernel" works!
> I installed kernel-184.108.40.206-76.fc7.x86_64.rpm,
> re-booted the machine specifying this kernel,
> and then inserted a ZIP disk into the ZIP drive.
> Not only were there no error messages during the
> boot-up process, but the kernel (I assume) detected
> the disk being inserted and entered several messages
> into /var/log/messages.
> The drive was correctly detected (number and size of
> sectors) and the correct partition number was given
> as well.
> Thank you, Chris, for pushing me to try a newer kernel.
> I was reluctant to upgrade because VMware and NVIDIA
> had been running well for a long time, and if it ain't
> broke, I usually don't want to fix it.
> Please close this bug. I feel a bit guilty for opening it,
> seeing now that simply upgrading to a new kernel very probably
> would have made the ZIP drive problem go away.
This solves a good number of bugs. You should not feel bad at all about filing
this bug report as I can now close and indicate what fixed this issue for you to
let others know. Closing then...