Description of problem: Mounting ZIP 250 drive using the following command: mount -t vfat /mnt/hdb4 /media/zip I get the following result: mount: special device /mnt/hdb4 does not exist I checked the /dev folder and I find that file is not there. I took a look at the udev rules to see if there was something wrong but I found nothing. I had this same problem in FC3 and was fixed after a few updates but I don't know what is wrong in FC4. Version-Release number of selected component (if applicable): udev-058-1 kernel-2.6.12-1.1398_FC4 hal-0.5.2-2 dbus-0.33-3 How reproducible: Always Actual results: /dev/hdb4 is not created. Expected results: /dev/hdb4 is create to mount the ZIP drive. Additional info:
I have the same problem. My zip drive is listed as hdd4 in fstab. mount -t vfat /dev/hdd4 /media/zip does not work "I get "mount: special device /dev/hdd4 does not exist" The only way I can mount is by by using a two step process First Step: issuing the command mount -t vfat /dev/hdd /media/zip This returns: "mount: wrong fs type, bad option, bad superblock on /dev/hdd, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so" Second Step: then the command mount -t /dev/hdd4 /media/zip (which, as noted above, fails on it's own)
I understand this way of accessing the ZIP using this method and it works but the fact is that udev or hal use to create the /dev/hdb4 automatically when I booted up in FC3. When I first installed FC3 it didn't create the hdb4 file but according a bug report I read, it said that this was caused by some debugging code left in think hal and udev had some errors in it's udev.rules file. This problem was quickly fixed in FC3 through some updates and my ZIP drive worked perfectly without performing any extra commands as you mentioned above. Now that I upgrade to FC4, I thought I should not have the same problem since it was fixed in FC3 but I guess it has reappeared again. I have looked through many forums, made posts regarding this, and I have finally come here to see if anybody else had a similar situation and wants this to be resolved once and for all.
I will try to reproduce this when I return to the office on Monday (only got the hardware in the office)
Did you have any success in reproducing this bug?
I just upgraded to kernel-2.6.12-1.1447_FC4 and I get the same thing. A quick look on google seemed to indicate that this was a kernel bug. However, trying to mount /dev/hdd and then mounting /dev/hdd4 did work for me.
I am having the same problem as Davang. I have made some additional interesting observations. If you boot Fedora Core 4 with a disk in the ZIP drive it is possible to mount and unmount sucessfully with varying file formats. If, however you boot without a zip disk in the drive, and then attempt to mount, you get the same error messages that Davang is experiencing. Early on, to rule out a coincident hardware problem, I sucesfully mounted the same hardware with the KNOPPIX 3.7 live CD. I was also sucessful with the SUSE 9.2 live CD. When I installed FC4 I already had FC2 on my hard drive. I selected upgrade as opposed to new install. It would be interesting to see if the other gentlemen also selected that upgrade option as well. I hope this helps. Larry
Although I don't understand the nature of this problem, I do know how to resolve it manually. The following command allows me to successfully mount my internal Zip 100 drive: mount -t vfat -o uid=500 /dev/hdd4 /media/zip I use the uid parameter to give my personal account (with uid of 500) access to the drive. Omit the -o argument to allow only root access to the device. You can also use -o umask=<xyz> to set the umask as desired. My only problem with this is, I have to do this manually. There is a note at the top of my /etc/fstab file saying not to modify it. I am supposed to use some hal component/command to update this. I tried experimenting with that command, and now I cannot mount ntfs partitions, such as my /dev/hda1! mount responds invalid fs type "NTFS" or something similar. (I'm running Win XP right now, so I really can't check the exact msg.)
Hey! Another thought is: If the zip drive is not formatted by IomegaWare tools under Windows or using mzip under linux, it is possible that the correct partition is actually /dev/hd<X>4 where X in the drive from A-D (a&b=primary; c&d=secondary; a&c=master; b&d=slave.) Either fedora automatically assumes hdd4 when it could be hdb or hdc, or you used native windows format command by right-clicking your drive and selecting "format" without having installed IomegaWare. If this is the case for anyone, check either your system's bios to see where your zip drive is installed, or carefully run fdisk/cfdisk/etc. to READ the partition table of the correct drive to discover where the partition is set to be. If you are really adventurous, you can take a blank zip disk and fdisk & format it under linux using the ext2 filesystem - just as a diagnostic step. In fact I think I'll look through my disks and see if one is expendable (read: "contains nothing important.") Gotta go for now.. --Aaron
NTFS isn't supported by our kernels because of pattents. As far as not being able to mount can you attach the output of the command lshal with a disk in the drive, thanks.
I originally had Core 2 installed, and upgraded to core 4. It gave me no end of problems! If I tried to add/remove packages off of the CD, the list of packages listed as being installed when rebooting from the CD post-install did not match the actual packages that were/were not installed. Also, SELinux was not functional for the upgrade. I was quick to re-format and re-install my Fedora from scratch. It is when using a scratch install of Core 4 that mounting the zip disk works manually. I can also say that mount complains of no /dev/hdd4 when I omit the -t argument. In addition, if I specify "-t auto" mount instead complains that it can't auto-detect the fs type. I am going to attach a .zip file that contains the following files: fstab - /etc/fstab mtab - /etc/mtab filesystems - /etc/filesystems * note that ntfs is not listed here. lshal.out - result of running `lshal>lshal.out`
Created attachment 121113 [details] A .zip file containing files applicable to my installation.
Hey! It's Aaron again! The other day, I tried to format a 100M Zip disk using fdisk followed by mke2fs. fdisk worked just fine, but mke2fs aborted with something like "unable to determine fs type while getting size of disk", or something similar. just to be certain, I used 'dd if=/dev/zero of=/dev/hdd' (with the disk unmounted, of course). I then re-ran 'fdisk /dev/hdd', which warned of no partition table, but ran Okay. Once again, when I ran "mke2fs -j /dev/hdd1" I received the same error message. My next step, is to try to to mount under my Knoppix 4.02 CD. I will then try to format it using the same. Regards! Aaron Outhier
OK. I've been bitten by this bug. I had installed Fedora Core 4 on a machine without a Zip drive. I then added an Iovega 100MB IDE Zip drive as hdd (cdrom is hdc). I observe the following: -- udev has created a /dev/hdd node, but has not created the /dev/hdd4 required for the standard iomega formatted zip disks ls -l /dev/hdd* gives brw-rw---- 1 dedourek floppy 22, 64 Jan 16 11:18 /dev/hdd -- /etc/fstab has the required entry for mounting, i.e. /dev/hdd4 /media/zip auto pamconsole,exec,noauto,managed 0 0 This of course causes the following errors when attempting to mount manually command(1) -> mount /media/zip gives error -> mount: you must specify the filesystem type --- command(2) -> mount /dev/hdd gives error -> mount: can't find /dev/hdd in /etc/fstab or /etc/mntab --- command(3) -> mount /dev/hdd4 gives error -> mount: you must specify the filesystem type --- command(4) -> mount -t vfat /dev/hdd4 /media/zip gives error -> mount: special device /dev/hdd4 does not exist --- command(5) -> mount -t vfat /dev/hdd /media/zip gives error -> mount: wrong fs type, bad option, bad superblock ...etc. Of course commands (1) and (3) are attempting to make use of the above mentioned entry in /etc/fstab and are expected to fail without the existence of /dev/hdd4. Command (2) won't work because there is no matching /etc/fstab entry. Command (4) is the correct "manual" mount for the zip but fails because of the missing /dev/hdd4 Command (5) will fail because it does not reference the correct partition on the zip drive and therefore will not find a valid file system. It does access the drive however, supporting the belief that the hardware is operational. HOWEVER, AN IMPORTANT CLUE is that after command(5), the necessary /dev/hdd4 IS CREATED! ls -l /dev/hdd* gives brw-rw---- 1 dedourek floppy 22, 64 Jan 16 12:28 brw-r----- 1 root disk 22, 68 Jan 16 16:38 although perhaps not with appropriate ownership etc. At this point, command(4) will succeed and perform the mount. PECULIARLY, commands(1) and (3) continue to report that /dev/hdd4 doesn't exist, even though it does at this point. error message --> mount: special device /dev/hdd4 does not exist I presume that kudzu/udev/hotplug somehow should create both /dev/nodes. A question: should /dev/hdd4 be created: -- at boot time when /dev/hdd is created -- or at disk insertion time, when the disk is spun up and the partition table is checked -- or at first attempt to access /dev/hdd4 How can I help debug this problem?
Additional information. Applied today's had update. This did not solve the problem. Symptoms are the same as in the privous message. Just to document the environment: Machine is IBM ThinkCentre 8143-4JU with Pentium M51 3.20 GHz with 512Mb RAM, Intel 915G chipset Hard drive is 80 GB serial at sda CDRW/DVD at hdc Iomega 100MB zip at hdd Install is FC4 updated daily via yum. As of today, rpm's possibly relevant to the problem are kernel-2.6.14-1.656_FC4 kudzu-1.1.116.3-1 udev-058-1.0.FC4.1 hal-0.5.2-2.fc4 One additional detail just noticed: The following links have been created in /dev fd -> /proc/self/fd floppy -> hdd floppy1 -> fd0 however, /etc/fstab has /dev/fd0 /media/floppy auto pamconsole,exec,noauto,managed 0 0 /dev/hdd4 /media/zip auto pamconsole,exec,noauto,managed 0 0 The floppy appears to function normally from the desktop.
Ooops, sory, that's today's "hal" update, not today's "had" update.
Updated to kernel-smp-2.6.15-1.1830_FC4 udev-071-0.FC4.2 module-init-tools-3.2-0.pre9.0.FC4.1 still running hal-0.5.2-2.fc4.1 The partition node (/dev/hdd4 in my case) is still not created automatically. The symptoms remain the same as described above.
No change, bug remains, for kernel-2.6.15-1.1831_FC4 as expected.
No change for kernel-2.6.15-1.1833_FC4smp However, I spent some time digging into udev and I have a suspicion about the cause of this bug. In /etc/udev/rules.d/50-udev.rules is a rule of the form: # workaround for devices which do not report media changes BUS=="IDE", KERNEL=="hd[a-z]", SYSFS{removable}=="1", \ ENV{ID_MODEL}=="IOMEGA_ZIP*", \ NAME{ignore_remove, all_partitions}="%k", \ GOTO="check_media_end" This sounds like it should be making the partitions for the ZIP drive. However, this rule occurs well before the following rules # never access removable ide devices, the drivers are causing event loops on open() BUS=="ide", DRIVER!="ide-cdrom", SYSFS{removable}="1", GOTO="persistent_end" # by-id (hardware serial number) KERNEL=="hd*[!0-9]", IMPORT{program}="/sbin/ata_id --export $tempnode" KERNEL=="hd*[!0-9]", ENV{ID_SERIAL}=="?*", \ SYMLINK+="disk/by-id/ata-$env{ID_MODEL}_$env{ID_SERIAL}" etc..... Notice that this latter use of ENV{ID_SERIAL} occurs after the IMPORT{program}="/sbin/ata_id --export $tempnode" I am suspicious about whether the ENV{ID_MODEL} in the "IOMEGA rule" can access the ID_MODEL value from the "environment" before the "/sbin/ata_id" is run to import the value. Unfortunately, blindly inserting an IMPORT{program} as part of the IOMEGA rule is a concern because of the warning "never access removable ide devices, the drivers are causing event loops" The structure of the testing and branching before the "/sbin/ata_id" stuff looks like it might allow "ide-cdrom" to use the /sbin/ata_id. (Someone check me on that; the logic is very convoluted.) The hope would be that a similar test, but substituting "ide-floppy" for "ide-cdrom" would protect the IOMEGA rule (with the import from /sbin/ata-id added) from the dire consequences promised by the comment. Unfortunately, it will be several days before I again have access to the machine with the ZIP drive. At that time I will attempt a "patch" and see what happens. Being a "newbie" at the udev stuff, however, means that the experts may be able to produce a more robust patch, if indeed the above speculation proves to be correct.
For the portion of this bug describing the failure to create the partition node /dev/hdb4 (or /dev/hdd4), please see bug 183996.
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Fedora Core 4 is no longer maintained. Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the current Fedora release, please reopen this bug and assign it to the corresponding Fedora version.