This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 183996

Summary: UDEV fails to create /dev/hdX4 node for internal IOMEGA ZIP drive
Product: [Fedora] Fedora Reporter: John DeDourek <dedourek>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: kay.sievers
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-09-20 06:30:35 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

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):
udev-071-0.FC4.3
kernel-2.6.15-1.1833_FC4smp

How reproducible:
always

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 
/etc/udev/rules.d/50-udev.rules

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", \
        GOTO="check_media_end"

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
created:
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 ?

Thanks.