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. On 10/20/2009 10:35 AM, Thomas Bächler wrote: > Okay, this report has a long story. I had reports of cryptsetup 1.0.7 > failing to work after updates (I later found out that the cause was > installing devicekit). I advised the affected people to try the 1.1.0 > release candidate to get better debug output - but the bug was gone with > 1.1.0. But something else happened with 1.1.0: On every opened LUKS > volume, the message > > device-mapper: remove ioctl failed: Device or resource busy > > would appear (see http://bugs.archlinux.org/task/16735#comment51508). > > 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. > 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. 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.) Milan -- mbroz@xxxxxxxxxx _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
