Re: [dm-crypt] 1.1.0rc2: device-mapper: remove ioctl failed: Device or resource busy

["Thomas Bächler" <thomas@archlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]

Milan Broz schrieb:
> Hi Thomas,
> 
> currently there is discussion between dm/lvm developers and
> some maintainers how to unify DM udev rules so these problems are
> fixed definitely. (Final state should be that applications using
> libdevmapper will use udev to create nodes and unified udev rules are
> part of libdevmapper package.)
> 
> CCing Peter - I am sure he can explain your questions better than me.

I would be very interested in this, I'll look up the discussion.

>> Then I suggested adding the following udev rule (which I will probably
>> make the default):
>>
>> ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="dm-[0-9]*",
>> PROGRAM="/sbin/dmsetup info -c --noopencount --noheadings -o name -j %M
>> -m %m", RESULT=="temporary-cryptsetup-*", OPTIONS="last_rule"
>>
>> (btw, is there a better way than calling dmsetup to get the name here?).
> 
> BTW for recent kernel, name and UUID is in sysfs directly. We have already
> some rule in dm package.

$ cat /sys/block/dm-0/dm/name
lvm_pv
$ cat /sys/block/dm-0/dm/suspended
0
$ cat /sys/block/dm-0/dm/uuid
CRYPT-4e80f75b-77d2-465c-ba8c-9480493dd717

This is awesome. How new does the kernel have to be? Some people are 
forcing me to support ancient kernels (like 2.6.27), while personally 
I'd rather only support latest stable.

>> Now, this fixes the problem with 1.0.7, as it prevents devicekit from
>> blocking access to the device, but the above error message isn't gone in
>> 1.1.0: http://bugs.archlinux.org/task/16735#comment51536
>>
>> What is this remove error caused by, if not by some application being
>> called from udev blocking access? Note that there are no
>> temporary-cryptsetup-* volumes left after luksOpen.
> 
> No idea - but always I debubugged it, it was initiated from udev event
> through udev rule.

The rule above should effectively keep udev from spawning any process 
that will do anything to the device - but yes, we need to debug it. I 
have to see if I can set up a test case on the weekend so I can debug 
this - until now, I have not seen this problem myself.

> I'll add better debug message to next cryptsetup rc (including process
> + parent process name, I hope I can get it from /proc in debugging mode)
> into debug output to allow more easy debugging of that problem - I do not
> want to hide it by some workaround, it must be fixed.
> 
> (Surely nobody want an application randomly reading opened, decrypted
> internal keyslot device.)

That would be great. For now I am happy that the affected users have 
working computers again :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]