From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830 Description of problem: This report are three RFEs (apart from the man page correction below... :-). I hope that this report will help you improve updfstab (a nice program!) in some way. BTW, these errors also happen on Red Hat Linux 7.3. ------------------------------------------------------------ (1) DiskOnKey might be partition 0 The DiskOnKey devices sold OEM by IO Data in Japan (called "Easy Disk") come as (in updfstab.conf parlance) partition 0. This is true for two DiskOnKey devices that I use. This information can also be found, for instance, in: http://homepage2.nifty.com/naripyon/linux/diskonkey.html (even if you cannot read Japanese, you can see that the mount point is /dev/sda, not /dev/sda1). The consequence of that is that the default setup for Red Hat does not work with these partition 0 devices. The simplest workaround is to add the following lines to the end of /etc/updfstab.conf: device diskonkey { partition 0 } ------------------------------------------------------------ (2) Updfstab can't scan /proc/partitions since modules are not loaded The updfstab manual says that "updfstab always scans /proc/partitions for the proper partition number before relying on this value". However, when I insert a USB mass storage device (say, a DiskOnKey) on (say) a freshly booted machine, the sd_mod module is not loaded, so when updfstab runs, the device's partitions are not available on /proc/partitions. A simple (but perhaps not easy :-) correction for that would be for updfstab (or hotplug?) to install the module corresponding to the device before scanning /proc/partitions. (Talk about the updfstab manual, please make the following corrections. On the first lines of the "CONFIGURATION" section of the updfstab manual page: "it's" -> "its", and also the underlining is wrong. On the "partition num" item: boldface is wrong). ------------------------------------------------------------ (3) Updfstab scan of /proc/partitions fails to find the proper partition My two DiskOnKey devices have the following partition tables (from /proc/partitions): 8 0 31824 sda 1 3 8 23 0 0 0 0 0 23 23 8 1 84344761 sda1 0 0 0 0 0 0 0 0 0 0 0 8 2 934940732 sda2 0 0 0 0 0 0 0 0 0 0 0 8 4 1717556736 sda4 0 0 0 0 0 0 0 0 0 0 0 and 8 16 128176 sdb 290 105 507 1853 0 0 0 0 0 1853 1853 8 17 84344761 sdb1 0 0 0 0 0 0 0 0 0 0 0 8 18 934940732 sdb2 0 0 0 0 0 0 0 0 0 0 0 8 20 1717556736 sdb4 0 0 0 0 0 0 0 0 0 0 0 Despite that, if I don't do the workaround above, updfstab uses "partition 1" (/dev/sda1, etc). So it is failing to notice that the first partition is invalid. Updfstab should see (on, say, sda above) that the number of blocks of sda1 is bigger than the one of sda, come to the conclusion that sda1 is not "proper" (i.e., invalid), and use sda instead. Ideally, updfstab should analyze the partition table itself and automatically find the right partitions to use (the information in /proc/partitions is not enough). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Plug IO Data's Easy Disk in an USB slot 2. Try to mount it Actual Results: Mount fails Expected Results: Should mount correctly /mnt/diskonkey Additional info:
By the way, one more detail. It seems that all DiskOnKey devices can be mounted as /dev/sda4 (i.e., partition 4). My two devices work like this, and a search for "diskonkey linux sda4" on Google returns some pages on people using sda4. One of the pages above ("Unofficial DiskOnKey Mini-HOWTO", available only on the Google cache) explains that it is for legacy Apple Macintosh compatibility. I hope this additional information helps somehow.
As of 0.99.96, it uses partition 0 by default for diskOnKey. Man page is also cleaned up.
Wait! The I/O Data "Easy Disk" (DiskonKey OEM) devices are "partition 0", but I'm not sure that this applies to *all* DiskonKey devices, especially the ones sold in the U.S.. Until Kudzu can find in a safe way the correct partition, please choose the option that will work with the highest number of devices (which might be "partition 4" or "partition 1", the only way to be sure is to contact the manufacturer). (Sorry for not making the above more explicit in the bug report, and also sorry for the dealy in replying).
The last comment is right! The new default actually broke our DiskOnKey's. I had to edit the /etc/updfstab.conf.default file and change partition to 1 for our diskonkeys to work again. Only 1 works with ours (M-Systems 64 Mb DiskOnKey, Hawking Technology model MD128U, ). I tried partition 4, but no dice...
*** Bug 119897 has been marked as a duplicate of this bug. ***
*** Bug 126018 has been marked as a duplicate of this bug. ***
In Fedora Core 3 and later, handling of mounting of devices is done via the 'hal' component. As such, changes to updfstab are very unlikely to be made in the future (in fact, it is no longer shipped in the kudzu tarball.)