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.