After mounting a loopback filesystem (in this case a floppy image) and then later umounting it, Gnome still shows the device as present on the "Places" menu. Running "losetup -a" doesn't show anything, indicating the device has been correctly unmounted. However, "udisks --enumerate" does produce output, so the device hasn't been correctly unregistered. I found that this bug has been logged for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/554330 Reproducible: Always Steps to Reproduce: 1. Mount loopback filesystem 2. Unmount loopback filesystem 3. udisks --enumerate Actual Results: The loopback device persists in udisks even though it has been unmounted. Expected Results: Remove the unmounted loobback device from the list of registered loopback devices.
Patch here: http://people.freedesktop.org/~david/0001-Generate-change-uevent-for-loop-device.patch Applied to Linux GIT tree if I'm not mistaken here: http://lkml.org/lkml/2010/5/21/327 So.. This is a bug in the kernel, not in udisks itself... reassigning to gentoo-sources maintainers
Created attachment 240647 [details] backported patch to generate "change" uevent for loop device Can you apply this to gentoo-sources-2.6.34-r2 and let me know if it fixes your issue. Let me know if you need help applying it.
I applied the patch, recompiled the kernel and re-tested. The issue has not been resolved by this patch. The test was as follows: 1. $ mkdosfs -C floppy.img 1440 2. $ mkdir flpy 3. $ sudo mount -o loop floppy.img ./flpy/ # Gnome adds the "flpy" device and a "1.5 MB Filesystem" device to "Places" 4. $ sudo umount ./flpy # Gnome removes the "flpy" device, but the "1.5 MB Filesystem" remains. 5. $ sudo losetup -a # No results displayed (with or without sudo) 6. $ udisks --enumerate # The list includes " /org/freedesktop/UDisks/devices/loop0" There seems to be no way to unmount or detach the loop device from udisks, regardless of privileges, as the device isn't mounted... $ udisks --unmount /dev/loop0 Unmount failed: Device is not mounted Let me know if you need any additional info.
Please test with gentoo-sources-2.6.35
Kernel 2.6.35 resolves this issue.
(In reply to comment #5) > Kernel 2.6.35 resolves this issue. > closing as fixed by 2.6.35 then