Description of problem: When I want to unmount a luks loopback device: sudo /sbin/cryptsetup luksClose /dev/mapper/myloopdevice I get the message: "Device /dev/mapper/myloopdevice is busy." Version-Release number of selected component (if applicable): cryptsetup-luks-1.3.1-3.fc16.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: I have no files from the loopback device open in kwrite, nor am I displaying the directory of the loopback device in dolphin. I am not using any file in any way, but I cannot un-mount the device.
And did you unmouned filesystem first? Please paste output of "lsblk -f" luksClose is just crypto layer unmapping, you need to umount fs if you want do this manually.
NAME FSTYPE LABEL MOUNTPOINT loop1 └─myloopdevice (dm-0) The need for umount fs must be new. I have been using luks for years and have never had to umount the fs before. I have a script that I wrote that I run whenever I want to mount/umount the loopback device. It always worked fine until a while back. This is always how I did it in the past: sudo /bin/umount ~/mntmyloopdevice sudo /sbin/cryptsetup luksClose /dev/mapper/myloopdevice It always worked. Since a while now, I get the device busy message. So, how do I umount the fs?
I just tried: sudo umount -t ext4 /dev/mapper/myloopdevice And I got: umount: /dev/mapper/myloopdevice: not mounted The, I ran: sudo /sbin/cryptsetup luksClose /dev/mapper/myloopdevice And I got: Device /dev/mapper/myloopdevice is busy. Something is weird and it wasn't before.
Ah, so it is unmounted. Nothing changed, your steps are perfectly fine. Is it Gnome shell? I just saw bug #808795 ... Can you try it from console?
(In reply to comment #4) > Ah, so it is unmounted. Nothing changed, your steps are perfectly fine. So, if it's unmounted, why do I get the message that the device is busy? > Is it Gnome shell? I just saw bug #808795 ... I don't use gnome. I use the Kool desktop Environment ;-) But, I do have gnome installed. > Can you try it from console? I ran those commands from konsole. I will do it again, this time both mounting and umounting (actually, I always do it from the konsole, since I run my script to open/close the loopback device). I will reboot, so as to get rid of the old stuff that won't umount. Then, I will be back.
I rebooted to start from a clean session. I entered the command from my script manually into konsole (my device is really called safe1, not myloopdevice, as in the dialogue above): mkdir -p ~/Safe1 sudo /sbin/modprobe cryptoloop && /sbin/lsmod | /bin/grep cryptoloop sudo /sbin/losetup /dev/loop1 ~/Documents/safe1.img sudo /sbin/cryptsetup luksOpen /dev/loop1 safe1 Here it asks: Enter passphrase for /dev/loop1: and I enter my passphrase, then enter more commands: sudo /bin/mount -t ext4 /dev/mapper/safe1 ~/Safe1 So, now I have the loop device opened and mounted. Now, I will umount and close it: sudo /bin/umount ~/Safe1 sudo /sbin/cryptsetup luksClose /dev/mapper/safe1 And I get the message: Device /dev/mapper/safe1 is busy. See! I doesn't work and it used to. The rest of my script goes: sudo /sbin/losetup -d /dev/loop1 And I get the message: loop: can't delete device /dev/loop1: Device or resource busy And the final command in my script (entered in konsole, of course, for the purposes of this demonstration): rmdir ~/Safe1 It used to work, for years, just like this, but now I can't unmount the device nor remove /dev/loop1, because the device hasn't been umounted.
(In reply to comment #6) > sudo /sbin/modprobe cryptoloop && /sbin/lsmod | /bin/grep cryptoloop btw cryptoloop is deprecated, it uses dm-crypt module. > Now, I will umount and close it: > > sudo /bin/umount ~/Safe1 > sudo /sbin/cryptsetup luksClose /dev/mapper/safe1 > > And I get the message: Device /dev/mapper/safe1 is busy. See! I doesn't work > and it used to. Can you try "sudo /sbin/cryptsetup luksClose safe1 --debug" ? (and paste output) I need to reproduce it because this seems quite strange, it should work without change. What's the exact versions? rpm -q lvm2 cryptsetup-luks kernel udisks udisks2 ? Can you also paste "grep watch /lib/udev/rules.d/*" ? Btw if you upgrade to F17 cryptsetup (1.4.x) you do not need to use losetup. cryptsetup can handle loop mapping itself, just use img file as parameter, unmapping is automatic when last reference disapears. (Unfortunatelly I think it will not allow to update without other packages affected, there was library version bump in F17 - but you can try.)
I am not able to reproduce this on F16... Btw you can use loop device directly even in F16 cryptsetup, just try to cryptsetup luksOpen <file with luks image> <name>
(In reply to comment #8) > Btw you can use loop device directly even in F16 cryptsetup, just try to > cryptsetup luksOpen <file with luks image> <name> I don't understand what you mean. Am I using it indirectly? What would I change?
You can remove losetup from your script, cryptsetup can allocate loop device itself. IOW: sudo /sbin/losetup /dev/loop1 ~/Documents/safe1.img sudo /sbin/cryptsetup luksOpen /dev/loop1 safe1 can be just sudo /sbin/cryptsetup luksOpen ~/Documents/safe1.img safe1 Anyway, it was just suggestion, not related to bug report.
a) rpm -q lvm2 cryptsetup-luks kernel udisks udisks2 lvm2-2.02.86-6.fc16.x86_64 cryptsetup-luks-1.3.1-3.fc16.x86_64 kernel-3.3.0-2.fc16.x86_64 kernel-3.3.0-4.fc16.x86_64 kernel-3.3.0-8.fc16.x86_64 (this one is running) udisks-1.0.4-3.fc16.x86_64 package udisks2 is not installed (doesn't exist in f16) b) I modified my script and now I load dm_crypt, not cryptoloop (deprecated), like you said. It mounts fine, like before, but I still can't unmount, like before. c) sudo /sbin/cryptsetup luksClose safe1 --debug # cryptsetup 1.3.1 processing "/sbin/cryptsetup luksClose safe1 --debug" # Running command luksClose. # Locking memory. # Allocating crypt device context by device safe1. # Initialising device-mapper backend, UDEV is enabled. # Detected dm-crypt version 1.11.0, dm-ioctl version 4.22.0. # dm status safe1 OF [16384] # Releasing device-mapper backend. # Allocating crypt device /dev/loop1 context. # Trying to open and read device /dev/loop1. # Initialising device-mapper backend, UDEV is enabled. # Trying to load LUKS1 crypt type from device /dev/loop1. # Initialising gcrypt crypto backend. # Reading LUKS header of size 1024 from device /dev/loop1 # Deactivating volume safe1. # dm status safe1 OF [16384] Device safe1 is busy. # Releasing crypt device /dev/loop1 context. # Releasing device-mapper backend. # Unlocking memory. Command failed with code 16: Device safe1 is busy. d) grep watch /lib/udev/rules.d/* /lib/udev/rules.d/10-dm.rules:OPTIONS:="nowatch" /lib/udev/rules.d/11-dm-lvm.rules:OPTIONS:="nowatch" /lib/udev/rules.d/60-persistent-storage.rules:# watch metadata changes by tools closing the device after writing /lib/udev/rules.d/60-persistent-storage.rules:KERNEL!="sr*", OPTIONS+="watch" /lib/udev/rules.d/64-md-raid.rules:OPTIONS+="watch" /lib/udev/rules.d/80-udisks.rules:KERNEL=="dm-*", OPTIONS+="watch" e) Thanks for info on cryptsetup/losetup in f17. I always do a clean install and will wait until at least f17ß or f17 pre-release comes out before I upgrade my computer(s). f) > can be just > sudo /sbin/cryptsetup luksOpen ~/Documents/safe1.img safe1 Suggestions are good! :-) Thanks for helping me make my script better. I don't need useless lines.
Aside: Could you explain why I have to modprobe dm_crypt when the module is actually called dm-crypt? I tried modprobe dm-crypt and nothing happened.
It works for me (both dm-crypt/dm_crypt) on rawhide with kmod-5-7.fc17.x86_64, so that's perhaps separate bug for modutils/kmod in fc16... But it should be loaded automatically by device-mapper core, no need to run modprobe.
Can you try to comment out this line: /lib/udev/rules.d/80-udisks.rules:KERNEL=="dm-*", OPTIONS+="watch" and retry - is the problem still there?
a) I edited the rules file and rebooted, to make sure that the new rules are active. b) I ran these commands manually, the same as they are in my script: sudo /bin/umount ~/Safe1 sudo /sbin/cryptsetup luksClose /dev/mapper/safe1 Output was same as before: Device /dev/mapper/safe1 is busy. sudo /sbin/losetup -d /dev/loop1 The output was: loop: can't delete device /dev/loop1: No such device or address Note that something has now changed, since it used to say, loop: can't delete device /dev/loop1: Device or resource busy ! ...But recall that the /dev/mapper/safe1 is still busy from the previous command. c) Should I restore the rules file to how it was originally?
(In reply to comment #15) > sudo /sbin/losetup -d /dev/loop1 > > The output was: loop: can't delete device /dev/loop1: No such device or address > > Note that something has now changed, since it used to say, loop: can't delete > device /dev/loop1: Device or resource > busy ! > > ...But recall that the /dev/mapper/safe1 is still busy from the previous > command. Disregard this! I must have done something wrong. I just tried it again and the response it the same as before the udev change: loop: can't delete device /dev/loop1: Device or resource busy
I just had an idea. I thought perhaps some feature of the destop environment might be 'using' /dev/mapper/safe1, so I logged out of KDE and changed to a virtual terminal. I ran the luksClose command there, but there was no change.
I am afraid we need full "lsof", "ps ax" and "lsblk -f" output to move somewhere... Can you provide these? There must be something which has device open. Even if you add "sleep 5" or something after unmout (before luksClose) it still doesn't help?
sleep 5 did not help. The results were exactly the same (I ran the commands from the command line in a virtual terminal, not using my script).
Created attachment 575240 [details] lsof
Created attachment 575241 [details] ps ax
Created attachment 575242 [details] lsblk -f
I never thought to run the 3 commands as root. Should I have? Also, I have not reverted the udev rules file to the default, ie., the rule change you asked for is still in effect.
(In reply to comment #18) > I am afraid we need full "lsof", "ps ax" and "lsblk -f" output to move > somewhere... Can you provide these? > > There must be something which has device open. Even if you add "sleep 5" or > something after unmout (before luksClose) it still doesn't help? I have same trouble, F16 64bit
I'm seeing the same on F16 64bit with an encrypted total hard disc (no encrypted image file).
In process output is this: 2075 ? S 0:00 [jbd2/dm-0-8] 2076 ? S< 0:00 [ext4-dio-unwrit] And you do not have other DM devices except this crypt. Seems to me like there is problem with lazy umount or so... (jbd/ext4 should not be active anymore IMHO) I am able to reproduce it this way: - luksOpen, mount - keep some reference to fs (stay in mounted dir is enough) - umount -l now, even if last reference disappears, device is still busy. Seems like lazy umount is not working here. Not sure if it is your problem though - please can paste lsof running under root? (from your list it cannot read other processes)
It is not only LUKS, there seems to be something broken when operation in session. losetup /dev/loop0 /aaa mount /dev/loop0 /mnt/tst (in another terminal: cd /mnt/tst ; cd /) umount /mnt/tst losetup -d /dev/loop0 - device busy! nothing is mounted, loop is still in use... Cannot reproduce this without login into session (simple twm with two xterms works fine). We will need someone from desktop to check what's going here. (All above is with udisk and gvfs uninstalled)
I just reinstalled my operating system to f17ßrc3. The problem is gone! I don't have gnome installed.
Same problem here, Fedora 16 KDE. I've noticed it for about 3 weeks, since some update, but ignored it. Sorry but I can't remember which update caused it, I've thought it goes away with the next kernel update. I've also found this thread: http://forums.fedoraforum.org/showthread.php?t=278193 [chris@thinkpad ~]$ uname -r 3.3.0-8.fc16.x86_64 [chris@thinkpad ~]$ sudo cryptsetup luksOpen /dev/disk/by-uuid/907*** wddata Swipe your right index finger on UPEK Eikon 2 Enter passphrase for /dev/disk/by-uuid/907***: [chris@thinkpad ~]$ sudo cryptsetup luksClose /dev/mapper/wddata [chris@thinkpad ~]$ sudo cryptsetup luksOpen /dev/disk/by-uuid/907*** wddata Enter passphrase for /dev/disk/by-uuid/907***: [chris@thinkpad ~]$ sudo mount /dev/mapper/wddata /mnt/wddata # I haven't opened any directory/file on that device. [chris@thinkpad ~]$ lsof |grep /mnt/wd [chris@thinkpad ~]$ [chris@thinkpad ~]$ sudo umount /mnt/wddata [chris@thinkpad ~]$ sudo cryptsetup luksClose /dev/mapper/wddata Device /dev/mapper/wddata is busy. [chris@thinkpad ~]$
I see the same in F16. For me it seemed to be connected to update when kernel 3.3.0 was introduced. I will test this with kernel 3.2.x. Can you guys try it with kernel 3.2.x too?
The problem is not limited to KDE, and and it appears to be present in 3.2.x kernel as well. But I was not able to isolate it yet except it only happens after you login into GUI (and it is not caused by udisk/gvfs). Using just plain losetup has the same problem, so it is not cryptsetup/DM problem. And, yes, it seems like kernel block device reference problem, I would not be surprised if this is related to some namespace/session/cgroup problem.
(In reply to comment #31) > …it seems like kernel block device reference problem, I would not be > surprised if this is related to some namespace/session/cgroup problem. You might be onto something. I had a related problem. Now that I am using fedora 17ßrc3, I was surprised to have the problem reappear, albeit in a slightly different form. I had a straight ext4 data partition mounted to ~/Store and I decided that I liked the name Storage better, so I made a ~/Storage mount point and umounted ~/Store and mounted ~/Storage. when I tried to rmdir Store, I was told that it was busy! I had to reboot the system in order to rmdir Store. Isn't this kind of the same problem?
*** Bug 811163 has been marked as a duplicate of this bug. ***
Please can you try kill "colord" and "colord-sane" processes in system and retry? (With clear reboot, no busy devices) Seems this process is doing something very strange leading to increasing atomic use counted for mounted fs. (At least on my system.)
No colord and colord-sane running here (I am running KDE).
Ok, thanks. so it is just trigger for some other action in this system. (And colord-kde is on its way, just not yet in F16 ... :-)
Which version of systemd do you have installed? Can you try to downgrade to systemd-37-3.fc16 a try to reproduce it again? (this one http://koji.fedoraproject.org/koji/buildinfo?buildID=271914)
*** This bug has been marked as a duplicate of bug 808795 ***
I am still experiencing this bug on F16 x86_64 (all available updates installed) with a LUKS-encrypted USB partition (no LVM) with ext3 FS I had umounted through Nautilus before suspend and detach. Killing colord (and colord-sane before) filled my kernel log with lots of journal commit I/O and buffer I/O errors on the busy devicemapper block device and I was able to cryptsetup luksClose it afterwards. As several essential packages depend on colord but color management is not required for me, I will chmod a-x /usr/libexec/colord /usr/libexec/colord-sane until an update to colord hopefully resolves this problem.
I have the same problem on Fedora 17 x64.