Red Hat Bugzilla – Bug 183996
UDEV fails to create /dev/hdX4 node for internal IOMEGA ZIP drive
Last modified: 2007-11-30 17:11:26 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
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.
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.
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.