From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; it-IT; rv:1.7.2) Gecko/20040803 Description of problem: Hardware: Freecom USB HD 20GB When inserting USB HD, hotplug load modules scsi_mod and usb_storage. If I remove USB disk these modules are remaining loaded, not so bad... But if I plug again USB HD the function load_drivers call updfstab just a second before the modules are binding to device so updfstab can't see new hardware. I've edited just on line in hotplug.functions: ... if echo "$MODULE" | grep -q "usb-storage" > /dev/null 2>&1 ; then [ -x /usr/sbin/updfstab ] && /usr/sbin/updfstab fi ... in ... if echo "$MODULE" | grep -q "usb-storage" > /dev/null 2>&1 ; then sleep 3 && [ -x /usr/sbin/updfstab ] && /usr/sbin/updfstab fi ... so updfstab wait some seconds before update fstab. I don't know if this problem remain with other devices but I think yes. Version-Release number of selected component (if applicable): hotplug-2004_04_01-1 How reproducible: Always Steps to Reproduce: 1.Plug USB storage 2.Unplug USB storage 3.Plug again USB storage Actual Results: The second time I plug the device fstab isn't updated. Expected Results: Every time I plug or unplug a device fstab should be updated. Additional info: I've added in /etc/updfstab an entry to match my device: ... match hd "DK14FA-20" ...
I have two USB flash drives, one from Dell, and one from Lexar. Both exhibit the same behavior. I didn't have to edit /etc/updfstab to get them to work. I didn't realize that updfstab was running before the existing modules could bind to the device, but instead ran 'rmmod usb-storage' and noticed that 'updfstab' worked fine after that. The fix posted here works fine for me.
I'm seeing this problem all across my network and it's really causing problems as users expect to use these things. I know everything used to work so I'm concerned that some more recent update broke something. Updates are mirrored and applied nightly and I don't recall seeing this problem until December, which is odd given the age of this report. On my regular desktop machine, three seconds of sleeping doesn't seem to be sufficient; seven seems to be the minimum. I'll try stepping back through all of the updates to see if I can pinpoint the source of this issue. Any suggestions would be appreciated.
BTW, this is probably a dup of bug 119140, although I know things were working fine for me long after that bug was reported. Perhaps some recent kernel update increased the amount of time it takes to recognize the devices?
*** This bug has been marked as a duplicate of 119140 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.