From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Tue, 20 Oct 2009 11:07:10 +0200 (CEST) MIME-version: 1.0 Received: from ironport-out-2.rz.rwth-aachen.de ([134.130.5.41]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KRT00HID2NY5280@mta-1.ms.rz.RWTH-Aachen.de> for dm-crypt@saout.de; Tue, 20 Oct 2009 11:07:10 +0200 (CEST) Received: from [134.61.47.76] ([unknown] [134.61.47.76]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KRT005WE2NYDH70@relay-auth-2.ms.rz.rwth-aachen.de> for dm-crypt@saout.de; Tue, 20 Oct 2009 11:07:10 +0200 (CEST) Message-id: <4ADD7DBD.8000204@archlinux.org> Date: Tue, 20 Oct 2009 11:07:09 +0200 From: =?ISO-8859-15?Q?Thomas_B=E4chler?= References: <4ADD7639.6060904@archlinux.org> <4ADD7B1F.9060704@redhat.com> In-reply-to: <4ADD7B1F.9060704@redhat.com> Content-type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary=------------enig0A95B5D3008128AF74696C5E Subject: Re: [dm-crypt] 1.1.0rc2: device-mapper: remove ioctl failed: Device or resource busy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Milan Broz Cc: dm-crypt@saout.de, Peter Rajnoha This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0A95B5D3008128AF74696C5E Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Milan Broz schrieb: > Hi Thomas, >=20 > 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.) >=20 > 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=3D=3D"add|change", SUBSYSTEM=3D=3D"block", KERNEL=3D=3D"dm-[0-9= ]*", >> PROGRAM=3D"/sbin/dmsetup info -c --noopencount --noheadings -o name -j= %M >> -m %m", RESULT=3D=3D"temporary-cryptsetup-*", OPTIONS=3D"last_rule" >> >> (btw, is there a better way than calling dmsetup to get the name here?= ). >=20 > BTW for recent kernel, name and UUID is in sysfs directly. We have alre= ady > 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=20 forcing me to support ancient kernels (like 2.6.27), while personally=20 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. >=20 > 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=20 that will do anything to the device - but yes, we need to debug it. I=20 have to see if I can set up a test case on the weekend so I can debug=20 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 n= ot > want to hide it by some workaround, it must be fixed. >=20 > (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=20 working computers again :) --------------enig0A95B5D3008128AF74696C5E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkrdfb0ACgkQEda5KzHP/VBrRACgvCDuhz+yqGzJRiJ2h+xNH98o jo8AniXZYHD7I6XpkOmUp7jWJfBMZK+t =TYTk -----END PGP SIGNATURE----- --------------enig0A95B5D3008128AF74696C5E--