Bug 809188 - luks will not un-mount
Summary: luks will not un-mount
Keywords:
Status: CLOSED DUPLICATE of bug 808795
Alias: None
Product: Fedora
Classification: Fedora
Component: cryptsetup-luks
Version: 16
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Milan Broz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 811163 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-02 17:25 UTC by Peter Gückel
Modified: 2013-03-01 04:11 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-12 19:59:52 UTC


Attachments (Terms of Use)
lsof (97.95 KB, text/plain)
2012-04-05 00:08 UTC, Peter Gückel
no flags Details
ps ax (5.46 KB, text/plain)
2012-04-05 00:09 UTC, Peter Gückel
no flags Details
lsblk -f (530 bytes, text/plain)
2012-04-05 00:09 UTC, Peter Gückel
no flags Details

Description Peter Gückel 2012-04-02 17:25:19 UTC
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.

Comment 1 Milan Broz 2012-04-02 17:44:04 UTC
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.

Comment 2 Peter Gückel 2012-04-02 20:38:37 UTC
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?

Comment 3 Peter Gückel 2012-04-02 20:44:55 UTC
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.

Comment 4 Milan Broz 2012-04-02 21:06:24 UTC
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?

Comment 5 Peter Gückel 2012-04-03 01:16:31 UTC
(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.

Comment 6 Peter Gückel 2012-04-03 01:55:43 UTC
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.

Comment 7 Milan Broz 2012-04-03 07:44:43 UTC
(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.)

Comment 8 Milan Broz 2012-04-03 13:03:38 UTC
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>

Comment 9 Peter Gückel 2012-04-03 16:06:40 UTC
(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?

Comment 10 Milan Broz 2012-04-03 16:15:03 UTC
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.

Comment 11 Peter Gückel 2012-04-03 16:26:03 UTC
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.

Comment 12 Peter Gückel 2012-04-03 17:17:12 UTC
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.

Comment 13 Milan Broz 2012-04-03 17:30:46 UTC
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.

Comment 14 Milan Broz 2012-04-03 17:32:18 UTC
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?

Comment 15 Peter Gückel 2012-04-03 18:53:14 UTC
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?

Comment 16 Peter Gückel 2012-04-03 19:15:57 UTC
(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

Comment 17 Peter Gückel 2012-04-04 19:45:29 UTC
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.

Comment 18 Milan Broz 2012-04-04 20:08:29 UTC
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?

Comment 19 Peter Gückel 2012-04-05 00:07:41 UTC
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).

Comment 20 Peter Gückel 2012-04-05 00:08:38 UTC
Created attachment 575240 [details]
lsof

Comment 21 Peter Gückel 2012-04-05 00:09:09 UTC
Created attachment 575241 [details]
ps ax

Comment 22 Peter Gückel 2012-04-05 00:09:39 UTC
Created attachment 575242 [details]
lsblk -f

Comment 23 Peter Gückel 2012-04-05 00:10:58 UTC
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.

Comment 24 Stepan Lendak 2012-04-05 11:34:45 UTC
(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

Comment 25 Lukas Middendorf 2012-04-05 15:44:59 UTC
I'm seeing the same on F16 64bit with an encrypted total hard disc (no encrypted image file).

Comment 26 Milan Broz 2012-04-06 11:08:25 UTC
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)

Comment 27 Milan Broz 2012-04-06 17:27:32 UTC
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)

Comment 28 Peter Gückel 2012-04-06 23:00:39 UTC
I just reinstalled my operating system to f17ßrc3. The problem is gone! I don't have gnome installed.

Comment 29 Christian Jann 2012-04-07 09:43:37 UTC
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 ~]$

Comment 30 Dariusz Garbowski 2012-04-09 00:50:28 UTC
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?

Comment 31 Milan Broz 2012-04-09 08:10:06 UTC
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.

Comment 32 Peter Gückel 2012-04-09 17:19:25 UTC
(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?

Comment 33 Milan Broz 2012-04-10 10:41:48 UTC
*** Bug 811163 has been marked as a duplicate of this bug. ***

Comment 34 Milan Broz 2012-04-12 13:04:57 UTC
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.)

Comment 35 Dariusz Garbowski 2012-04-12 13:22:01 UTC
No colord and colord-sane running here (I am running KDE).

Comment 36 Milan Broz 2012-04-12 14:10:27 UTC
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 ... :-)

Comment 37 Milan Broz 2012-04-12 18:22:51 UTC
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)

Comment 38 Milan Broz 2012-04-12 19:59:52 UTC

*** This bug has been marked as a duplicate of bug 808795 ***

Comment 39 Veit Wahlich 2012-07-17 07:28:24 UTC
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.

Comment 40 David Radice 2013-01-11 15:37:00 UTC
I have the same problem on Fedora 17 x64.


Note You need to log in before you can comment on or make changes to this bug.