Bug 79558 - DiskOnKey might be partition 0; scan of /proc/partition not good enough
Summary: DiskOnKey might be partition 0; scan of /proc/partition not good enough
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kudzu
Version: 8.0
Hardware: i686
OS: Linux
medium
low
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
URL:
Whiteboard:
: 119897 126018 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-12-13 11:22 UTC by fred-m
Modified: 2014-03-17 02:32 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-23 19:11:09 UTC
Embargoed:


Attachments (Terms of Use)

Description fred-m 2002-12-13 11:22:20 UTC
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:

Comment 1 fred-m 2002-12-16 10:10:43 UTC
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.

Comment 2 Bill Nottingham 2003-02-13 21:09:38 UTC
As of 0.99.96, it uses partition 0 by default for diskOnKey.
Man page is also cleaned up.

Comment 3 fred-m 2003-03-09 06:45:58 UTC
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).


Comment 4 Jorge 2003-04-29 23:56:54 UTC
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...

Comment 5 Bill Nottingham 2004-04-16 04:46:26 UTC
*** Bug 119897 has been marked as a duplicate of this bug. ***

Comment 6 Bill Nottingham 2004-06-29 04:25:10 UTC
*** Bug 126018 has been marked as a duplicate of this bug. ***

Comment 7 Bill Nottingham 2005-09-22 20:49:56 UTC
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.)


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