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): How reproducible: 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 re-inserted. 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 bus errors. 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 of questions: * 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 this output: 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 /media. 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?? Thanks
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.