Bug 183996 - UDEV fails to create /dev/hdX4 node for internal IOMEGA ZIP drive
UDEV fails to create /dev/hdX4 node for internal IOMEGA ZIP drive
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Depends On:
  Show dependency treegraph
Reported: 2006-03-04 15:09 EST by John DeDourek
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-20 06:30:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John DeDourek 2006-03-04 15:09:07 EST
Description of problem:
udev fails to create the partition node /dev/hdd4 for my internal
ZIP drive at /dev/hdd, making it difficult to mount

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  boot
2.  ls /dev/hdd*
3.  note that only /dev/hdd exists; in particular /dev/hdd4 is missing
Actual results:
As described above

Expected results:
Expect both /dev/hdd and /dev/hdd4 will exist

Additional info:

I believe that I have udentified two problems in 

First, there is a special section that should avoid creating
a /dev/floppyX symlink for IOMEGA ZIP drives, namely

BUS=="ide", KERNEL=="hd[a-z]", SYSFS{removable}=="1", \
        ENV{ID_MODEL}=="IOMEGA_ZIP*", \
        NAME{ignore_remove, all_partitions}="%k", \

I believe this section is not being executed because
it depends on "ENV{ID_MODEL}=="IOMEGA_ZIP*"
However, the rule that actually imports this environment
variable into the udev environment, namely

KERNEL=="hd*[!0-9]", IMPORT{program}="/sbin/ata_id --export $tempnode"

occurs much later in the rules.

Further, examining the source code for udev in udev_rules_parse.c,
if I read this code correctly, after parsing NAME, it calls 
get_key_attribute only once.  If my interpretation is correct, then
the part of the IOMEGA rule that reads

NAME{ignore_remove, all_partitions}="%k"

will have only the "ignore_remove" part, at best, will be processed.
In the worst case, the entire string "ignore_remove, all_partitions"
might be interpretted as one attribute and not recognized as a
valid attribute at all.  The result would be that the "all_partitions"
part will not be recognized, and possibly the ignore_remove would not
be recognized as well.

Note that a "NAME" with two attributes occurs at two places in
50-udev.rules, once in the IOMEGA section, and once in the section that
should handle "other" IDE floppies (but is apparently handling the ZIP
as well due to the ENV bug mentioned above).

Unfortunately, I will not have access to the machine with the ZIP drive
again until next week sometime, at the earliest.  However, I will attempt
to make some tests to attempt a validation of the above analysis.

I also note that this bug would appear to be related to the portions
of the following two bugs that also report partition nodes not being
bug 152208 filed against the kernel
bug 163417 filed against hal
Comment 1 Kay Sievers 2006-03-17 05:43:45 EST
Regarding the "multiple attribute to one key":
  attr = get_key_attribute(key + sizeof("NAME")-1);
  if (strstr(attr, "all_partitions") != NULL)
  if (strstr(attr, "ignore_remove") != NULL)

should work just fine, cause both matches use the whole attribute string
and search for a matching part in the string that contains both values at
the same time.
Comment 2 John DeDourek 2006-03-29 12:37:15 EST
A fresh install of FC5 on a machine with a similar zip drive shows "all"
partitions (including hdd4) to be present.  In gnome, right clicking on the zip
drive in the "computer" window in the file browser and selecting the zip drive
did create the /media/zip directory and mount the drive.

On a negative, the traditional way of doing things, "mount /media/zip" from a
command window (or a script) isn't going to work because there is no
"/media/zip" directory (dynamically created and removed by the Gnome stuff),
there is no entry in /etc/fstab (feature removed from FC5).  The supposed
replacement "gnome-mount" has totally different syntax, no man page (use
gnome-mount --help), and in particular, the "--help" text seems either
inaacurate or hard to understand. In particular, it would presume that 
  gnome-umount -t -v -p /media/zip
should have unmounted the disk, the "mount point" being a "pseudonum" for
the device.
  gnome-mount -t -v -d /dev/hdd4
did work, though I note in the debug messages that "mount point" was " ";
which is probably why /media/zip didn't work as a pseudonym.
But now I have the system seriously confused.  There is an empty /media/zip
directory and the thing is mounted under /media/zip-1.

Script writing just became significantly more difficult.
Comment 3 Christian Iseli 2007-01-22 06:50:00 EST
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 ?


Note You need to log in before you can comment on or make changes to this bug.