From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.5) 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 are attached. Version-Release number of selected component (if applicable): kernel-2.6.21.3 How reproducible: Always 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) Actual Results: The drive is not recognized correctly. Nothing can be mounted. The drive cannot be used. Expected Results: 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. Additional info: 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 cat /proc/scsi/scsi 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
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage 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. Cheers Chris
Hello Chris, 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 2.6.21.3, 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. -- MM
Just a: yum update kernel and re-test would be great. This will pick up the latest stable kernel. Cheers Chris
Looks like the "latest stable kernel" works! I installed kernel-2.6.22.5-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. -- MM
(In reply to comment #10) > Looks like the "latest stable kernel" works! :) > I installed kernel-2.6.22.5-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. :D > 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... Cheers Chris