Bug 119140 - plugging in usb flash device sometimes fails to update /etc/fstab
Summary: plugging in usb flash device sometimes fails to update /etc/fstab
Alias: None
Product: Fedora
Classification: Fedora
Component: hotplug
Version: 2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
: 122837 122868 126868 130855 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-25 15:08 UTC by Nils Philippsen
Modified: 2014-03-17 02:43 UTC (History)
13 users (show)

Clone Of:
Last Closed: 2005-02-08 18:13:18 UTC

Attachments (Terms of Use)
Patch to run updfstab until fstab changes or a specified number of attempts has been reached (1.74 KB, text/plain)
2004-03-26 09:43 UTC, Nils Philippsen
no flags Details
another take at fixing this (1.14 KB, patch)
2004-07-30 21:42 UTC, Carlos Rodrigues
no flags Details | Diff
run updfstab from the right place (1.23 KB, patch)
2005-02-07 23:29 UTC, Bill Nottingham
no flags Details | Diff

Description Nils Philippsen 2004-03-25 15:08:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312

Description of problem:
Sometimes, when plugging in the USB flash device (disk on a key,
whatever you may want to call it), neither /etc/fstab gets updated nor
the corresponding entry /mnt/flash gets created. When that happens, a
subsequent run of updfstab works as expected. It seems as if it could
be a timing issue that sometimes manifests in updfstab being run too soon.

It _seems_ like it fails more often when the device was
mounted/umounted in between plugging in/out.

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

How reproducible:

Steps to Reproduce:
1. Plug in USB flash device
2. Watch /etc/fstab, /mnt and/or Nautilus->Computer whether any new
entries get created

Actual Results:  Sometimes, no entry in /etc/fstab, corresponding
directory in /mnt get created.

Expected Results:  Entry in /etc/fstab, corresponding entry in /mnt
get created always.

Additional info:

--- 8< --- /etc/updfstab.conf ---
include /etc/updfstab.conf.default
device flash {
        partition 1
        match   hd "Traveling Disk"
--- >8 --------------------------

Comment 1 Bill Nottingham 2004-03-25 15:10:14 UTC
If you add 'sleep 5' in front of the call to updfstab in
/etc/hotplug/usb.agent, I assume it succeeds?

Comment 2 Nils Philippsen 2004-03-26 09:43:45 UTC
Created attachment 98875 [details]
Patch to run updfstab until fstab changes or a specified number of attempts has been reached

Comment 3 Nils Philippsen 2004-03-26 09:45:29 UTC
I've just attached the patch that works for me -- it basically does this:

- run updfstab
- check whether anything has changed
- wait 1 second and repeat until a specified number of attempts are

Comment 4 Brian Peyton 2004-04-28 17:34:26 UTC
Without the above patch Fedora core 2 test 3 still has the issue 

Comment 5 Bill Nottingham 2004-04-29 03:05:05 UTC
That just seems.... wrong. Repeatedly running it over and over just
seems like a hack.

Comment 6 Bill Nottingham 2004-05-21 19:06:25 UTC
*** Bug 122837 has been marked as a duplicate of this bug. ***

Comment 7 Nils Philippsen 2004-07-12 13:49:30 UTC
Bill you mentioned something about some code that "waits for USB to
settle down" which would be the thing to do here. Where did you say
was it -- kudzu or anaconda? Needless to say I still experience the
problem from time to time...

Comment 8 Bill Nottingham 2004-07-12 20:27:30 UTC
That is code from the loader in anaconda, IIRC.

Comment 9 Carlos Rodrigues 2004-07-16 04:43:43 UTC
I'm seeing a similar thing with my USB camera (for which I had to add
and entry in /etc/updfstab.conf.default, bug #127992) which I think
may be the same thing:

The first time I plug in the camera after boot, the /mnt/camera
directory and the corresponding fstab entry gets created. I then
unplug the camera and they disappear, as they should. But if I then
plug the camera back in, the entries don't get created. Running
updfstab manually does the trick.

After some messing around I found that doing a "rmmod usb_storage",
and then plugging the camera in, fixes it.

So, it seems that while usb_storage is loaded, updfstab is never run.

Comment 10 Carlos Rodrigues 2004-07-30 21:42:51 UTC
Created attachment 102323 [details]
another take at fixing this

This patch fixes this problem for me. It is less hackish although I feel that
there may be another way of doing this.

Comment 11 Bill Nottingham 2004-08-31 14:41:16 UTC
*** Bug 126868 has been marked as a duplicate of this bug. ***

Comment 12 Jason Tibbitts 2005-01-25 15:49:50 UTC
I have recently started seeing problems like those described in this bug. 
However, proposed fixes aren't quite working.  I modified the call to updfstab
in hotplug.functions as follows:

sleep 1 && date >> /tmp/a && tail -1 /etc/fstab >> /tmp/a && ls -l
/sys/bus/usb/drivers/usb-storage >> /tmp/a && [ -x /usr/sbin/updfstab ] && 
/usr/sbin/updfstab && tail -1 /etc/fstab >> /tmp/a

(on one line) and see the following:

Tue Jan 25 09:33:28 CST 2005
/dev/vg0/crap   /export/crap    ext3    defaults        1 3
total 0
lrwxrwxrwx  1 root root 0 Jan 25 09:33 1-1.1:1.0 ->
lrwxrwxrwx  1 root root 0 Jan 25 09:28 module -> ../../../../module/usb_storage
/dev/vg0/crap   /export/crap    ext3    defaults        1 3

So the device is appearing, but /mnt/flash does not appear in fstab.  It works
if I run updfstab manually, or if I sleep for seven seconds instead of one. 
What else is required in order for updfstab to recognize the device?

Comment 13 Jason Tibbitts 2005-01-31 17:22:40 UTC
I have tested various kernel versions and found that the behavior changed with

Under 2.6.9-1.11_FC2 and earlier, I have precisely the problem originally
described in this bug: when the usb-storage module is installed, updfstab is
called a little too early and waiting for the device to appear in
/sys/bus/usb/drivers/usb-storage works.  The device appears in that location and
in /proc/scsi/scsi at essentially the same time.

Under 2.6.10-1.6_FC2 and later, the device appears in /proc/scsi/scsi several
seconds later than it appears in /sys/bus/usb/drivers/usb-storage, and so even
waiting for it to show up in the latter location is not enough because updfstab
still won't find anything.

My current hack is to sleep for seven seconds, which seems to cover the delay on
all of my hardware.

Comment 14 Need Real Name 2005-02-03 18:11:59 UTC
I emailed the kernel mailing list about this issue and Greg KH <greg@kroah.com>,
who maintains the usb code, says that this is a userland bug and not a problem
with the kernel. Fedora needs to be fixed to follow the appearance of the
/dev node and not the usb hotplug event.


Comment 15 Bill Nottingham 2005-02-03 19:44:59 UTC
Greg's comment is only relevant when udev is in use, which is not the case for FC2.

Comment 16 Bill Nottingham 2005-02-04 21:06:01 UTC
*** Bug 122868 has been marked as a duplicate of this bug. ***

Comment 17 Bill Nottingham 2005-02-04 21:08:59 UTC
*** Bug 130855 has been marked as a duplicate of this bug. ***

Comment 18 Bill Nottingham 2005-02-07 22:40:29 UTC
*** Bug 119774 has been marked as a duplicate of this bug. ***

Comment 19 Bill Nottingham 2005-02-07 23:29:10 UTC
Created attachment 110766 [details]
run updfstab from the right place

Try this. You know, if we want to key off the *device*, running from usb.agent
is rather silly.

Comment 20 Need Real Name 2005-02-08 13:41:56 UTC
The patch (id=110766) appears to work here. I am assuming I don't
need to reboot for the hotplug script changes to take effect. If that
is the case then this fix seems okay. I see a delay of about 7 seconds
for my Lexar Secure Key to show up which compares to about 5 seconds
under MacOS X.

Comment 21 Bill Nottingham 2005-02-08 18:13:18 UTC
Fixed in 2004_04_1-1.1.

Comment 22 Leslie Katz 2005-03-29 03:12:19 UTC
(In reply to comment #21)
> Fixed in 2004_04_1-1.1.

I know nothing of technical matters. I only know that I want my USB flash 
drive to work "normally". I can only hotplug my usb flash drive once per 
session. The second time I try, the drive's not recognised. I found this page, 
which deals with my problem. As a result of reading it, I updated my existing 
hotplug to version 2004_04_01-8.1, the latest I could find at the Fedora 
website. However, that's made no difference to my inability to hotplug twice 
in a session. Has something done after the version mentioned above re-created 
the problem? Unfortunately, that's as it appears to me presently.

I am aware of the patch referred to above. However, I have no idea what to do 
with it. If I can figure that out, would it be dangerous to try it, given that 
it was obviously created to deal with an earlier version of hotplug?

Comment 23 Bill Nottingham 2005-03-29 16:56:05 UTC
Leslie: Under FC3, the infrastructure is different; automatic mounting is done
via HAL and its subprograms.

If it's not working for you, please open a new bug against the 'hal' component.

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