From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.1 (X11; Linux i686; U;) Gecko/20020417
Description of problem:
I installed an old 20 gig drive I had laying around.
/dev/hdb1 * 1 10 80293+ 83 Linux
/dev/hdb2 11 137 1020127+ 83 Linux
/dev/hdb3 138 647 4096575 83 Linux
/dev/hdb4 648 2434 14354077+ 5 Extended
/dev/hdb5 648 902 2048256 83 Linux
/dev/hdb6 903 953 409626 83 Linux
/dev/hdb7 954 1001 385528+ 83 Linux
/dev/hdb8 1002 1030 232911 82 Linux swap
/dev/hdb9 1031 2434 11277598+ 83 Linux
I mounted all the partitons that were mountable as /mnt/hdb1,2 etc.
I am unable to unmount /dev/hdb9, all the other partitions unmounted no problem.
fuser -u /mnt/hdb9
No process references; use -v for the complete list
fuser -v /mnt/hdb9
USER PID ACCESS COMMAND
/mnt/hdb9 root kernel mount /mnt/hdb9
The box also has an 18gig scsi, 89 gig ide and two ide cdroms.
The cdroms are not presently mounted.
/dev/sda7 1004024 324236 628784 35% /
/dev/sda1 46636 15323 28905 35% /boot
/dev/sda3 2016044 817884 1095748 43% /home
none 257212 0 257212 0% /dev/shm
/dev/sda8 774040 17628 717056 3% /tmp
/dev/sda2 11551080 3113368 7850940 29% /usr
/dev/sda5 1209572 358128 790000 32% /var
/dev/hda1 4031656 118468 3708392 4% /mnt/hda1
/dev/hda2 3780056 450360 3137672 13% /mnt/hda2
/dev/hda3 70973608 37052028 30316244 55% /mnt/hda3
/dev/hdb9 11100384 9112516 1423992 87% /mnt/hdb9
Version-Release number of selected component (if applicable):
I will try to reproduce, trying to figure out a workaround for know. More to follw.
With MHarris tip of using lsof, I found a .Trash file that was their. I removed
it and was still unable to umount the parttion. Went to init 1 and was able to
umount it. Mounted all the partitions again, and a different partiton that had a
.trash is doing the same thing.
I will delete that .trash go to init 1 and run the same test again.
I am using nautilus-1.0.6-15, think this has nothing to do with the kernel :-).
Strange, I reproduced the device busy on a different partiton. Again I found a
.Trash with lsof. But this time after removing the directory I was able to
umount the partiton. I will try the same test again. Mount all the partitions
If I create the .Trash on /dev/hbd9 which is mounted as /mnt/hdb9 and create the
.Tash with Nautilus I then can't unmount it. I created a .Trash in /mnt/hdb3 and
did an rm -r on the dir and am again not able to umount the partiton.
Hope this will be useful to someone.
Yes this looks like nautilus...
However it would be interesting to find out why not everybody+dog sees this...
We also need to be sure right-clicking a removable media icon on the desktop and
choosing unmount works.
This could potentially be fixed in nautilus 2.0.5-4, which would mean this is a
dup of bug 70667.
Ted, can you try the fam and nautlius RPMS that shipped in 8.0 to see if that
fixes the problem?
Newer nautilus seems to have resolved this issue, when testing gnome2 from ximian
this problem has never shown up with them. Nautilus 2.0.X and up. Also have 8.0
running and not seen it as well.
Thanks for staying on top of this, would seem to make sense to close as upstream :-)
Yes, seems to be fixed in latest (RHL 9 and upstream)
This issue can be reproduced in RHEL3 gold by mounting a USB floppy,
deleting a file from it using nautilus, emptying the trash, and then
attempting to umount the usb floppy. At this point it is still
saying that the device is busy.
An `lsof /mnt/floppy` implicates fam as holding onto
a /mnt/floppy/.Trash directory and if you kill the pid, you can then
unmount the drive. Perhaps there is a USB edge case which was not
resolved when this was closed or perhaps this is a separate bug?
This seems to have reappeared in FC2 as well, it is espescially touchy
with samba mounts, killing fam does fix it.
I've been reproducing this on RHEL3-U2 with a regular floppy disk.
Once there is a .Trash-root directory on the floppy's fs it gets
picked up automatically on mount by nautilus/gnome-vfs/fam for
monitoring, and so can only be unmounted using nautilus, since
/bin/mount doesn't know to cancel the monitor on
/mnt/floppy/.Trash-root. This is especially aggravating if you mount
it from the commandline and then cannot unmount from the commandline.
It has something to do with the virtual trash URI in gnome-vfs/eel2 as
used by nautilus. I'm having a hard time tracking down the source of
the problem, but it's got something todo with the virtual trash folder
and use of dnotify by fam for monitors.
As a (probably annoying) note, the problem disappears for me if I
rebuild fam without dnotify.
dnotify kernel API requires to open() the file to monitor. This is
a very bad kernel API side-effect. This can be worked around at the
eel/gnome-vfs level by not using the FAM API, or could be fixed by
using a better kernel API like inotify and the gamin library replacing
fam. Getting the right kernel API is the ultimate fix, this is a
work in progress at this point.
gamin now obsolete fam in Rawhide and the upcoming Fedora Core 3.
I believe that the current fixes at the gamin level and nautilus
fixes bugs of this kind.
Is this resolved in RHEL4? Please reclose issue if it is.
This should be closed in RHEL4 for the same reason, you should
double-check the RHEL4 betas and reopen this bug if for some
reason it doesn't work. But this should work.
I just replicated this on FC2. Is there a way this wouldn't be fixed
in fc2 but still somehow be fixed in RHEL4? Perhaps we should re-
FC2 does not have gamin. FC3 will, Rawhide does. That's normal.