Description of problem: I believe this is a Nautilus problem.
This problem has been tested on two different machines, both running
Core 3, and fully updated (yum) as of 11/26/2004. This is a USB device
issue. I have tested with a 160 GB USB drive, plus 2 different "pen"
drives, one a 256 Meg and the other a 512 Meg. The problem is that if
I unmount the drive a couple of times and then physically remove the
device, the "system" stops "seeing" the drive when inserted into a USB
slot after this "cycle" has been done a couple of times. The "fix" is
a machine reboot.
Version-Release number of selected component (if applicable):
I can consistently reproduce this problem on two different machines.
Steps to Reproduce:
1. Insert a USB disk drive a USB slot. My experience is that if I then
click on the "Computer" Icon on my desktop, it will "see" the device.
Also, it shows up on my desktop as a new device. I can access the
drive and a "df -k" command will show a mounted device.
2. Unmount the device. Remove from the Usb slot and then re-insert.
3. It may take two or three attempts, but after the 2nd or 3rd time
Nautilus does not "see" the device. It does NOT show up as a device
when I click on the "Computer" icon, and no icon appears on my
desktop. I simply have no access at all to the USB device.
At this point, even if I insert a *different* USB disk drive, it does
NOT see that one either. Don't know if I would also have problems
with another USB device, e.g., a printer.
Actual results: See above
Expected results: I would expect to be able to consistenly "see" the
USB device when it's been properly unmounted, removed, and then
Additional info: One time when I began a shutdown (which does fix the
problem) I saw some SCSI bus errors. On the assumption that a USB
device is handled like a SCSI device, perhaps this is related. That
is, could be some type of bus error?? I do not consistently see the
Note: Although larger drives would not be routinely be plugged into a
USB slot and unplugged, this is fairly common for the little "pen"
drives now available. I routinely carry such a device with me, and may
want to plug into a machine a couple of different times per day.
I can confirm that on my fully updated FC3 box, if I insert and remove
the compact flash from my usb reader several times, the icon will
eventually refuse to appear and a reboot is required to get it
"working" again. If I watch /var/log/messages, I see kernel: messages
indicating that the device is being recognized.
# service restart haldaemon
# service restart messagebus
has no effect.
This sounds like a gnome-volume-manager issue to me.
Nautilus only shows the icon if the volume was mounted.
This sounds like a kernel issue with the usbstorage drivers. A couple
* Can you do an 'lshal' after this happens or does it just hang?
* Does the fstab (and /media) entry show up for the device and just
not show up in Nautilus?
* Can you mount the device manualy?
After a reboot (when things work properly), an "lshal" yield about
1258 lines of output. (lshal | wc -l).
It took about 5 tries (unmount, remove device, re-insert in USB port)
before I again had the problem. At that point, the lshal command gave
lshal version 0.4.0
libhal.c 767 : org.freedesktop.DBus.Error.NoReply raised
"Message did not receive a reply"
*** [DIE] lshal.c:dump_devices():71 : Couldn't obtain list of devices
After the "failure", *only* my cd drive shows up under /media. (Which
is NOT a usb device). The usb "pen drive" no longer shows up under
And NO, I cannot mount the device manually.
As a follow-up to Comment #4, let me note that when the device is in
the USB drive, it is mounted on /dev/sda1. However, after I experience
a failure, if I *try* to mount the device manually: "mount /dev/sda1
/media/usbdrive" I receive an error message stating that "/dev/sda1"
does not exist.
Sounds like a dup of 136255. There is a timing issue with pulling out
the device when HAL is doing an open() which causes the open to not
return. Since the open call is in the kernel you get a deadlock that
HAL can not exit out of (kernel will not let processes exit on IO)
which then requires the reboot to get things working again. This
needs to be fixed in the kernel.
*** This bug has been marked as a duplicate of 136255 ***
Assuming this is a kernel fix, any time estimate as to when we would
get a fix. Also, what would be considered a work-around in the mean time??
I assume the new ub drivers which don't use scsi emulation will fix
this though they currently crash for other reasons. It is hard to say
when this will be fixed by the kernel guys. Best bet is to ask the
maintainer of usb-storage and to test out the ub drivers and filing
bugs on it upstream. Workaround is to try and not to unmount too
often. I know that sucks. Also this bug only happens on certant
hardware setups or I would be getting a lot more bugs filed against
this so you might want to see if you can reproduce this on other
computers or setups (for instance hubs or certant USB controlers might
cause the timing issue).
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.