From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Tue, 20 Oct 2009 15:29:53 +0200 (CEST) Message-ID: <4ADDBB37.4050203@redhat.com> Date: Tue, 20 Oct 2009 15:29:27 +0200 From: Peter Rajnoha MIME-Version: 1.0 References: <4ADD7639.6060904@archlinux.org> <4ADD7B1F.9060704@redhat.com> <4ADD9876.8000006@redhat.com> <4ADDA96F.2080109@archlinux.org> <4ADDB2DE.9020401@redhat.com> <4ADDB59D.7050202@archlinux.org> In-Reply-To: <4ADDB59D.7050202@archlinux.org> Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable 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: =?ISO-8859-15?Q?Thomas_B=E4chler?= Cc: dm-crypt@saout.de, Milan Broz On 10/20/2009 03:05 PM, Thomas B=E4chler wrote: > Peter Rajnoha schrieb: >> If I got him right, I think he meant direct listeners of the "KERNEL" >> udev >> events like udevd does. Yes, we can't do much here - if anybody >> listens to >> the events this way, he is on his own (if we listen to UDEV udev events, >> then these ones will have those env vars set, so one can check them). >=20 > Okay - which program would do that? >=20 Actually, I can't think of anyone listening to the events this way right no= w... If there's anybody, they really need to have a reason to do that. >> Yes, ignore_device is another way how to suppress the events somehow. But >> this one will ignore all the rules irrespective of the sequence when >> it's called. >> When I tried this one first, I had a rule that sets the nodes and >> symlinks >> in /dev/mapper and just after that I called ignore_device, but it ignored >> everything. So this one can't be used either. >=20 > Does it matter? If I remember correctly, libdevmapper creates the > /dev/mapper/* nodes itself even if udev isn't there. So cryptsetup would > create the temporary-cryptsetup-* node, access it and destroy it and > udev would ignore everything else - sounds like a good solution to me. Yes, it does create the nodes itself if udev fails to do so. But I don't th= ink this would be a clean solution. Either we create the nodes by udev or by libdevmapper itself (when the rules are not installed). The thing we kept t= he node/symlink creation code in libdevmapper even with udev support turned on= - that's just a fallback action. And it would always give you a warning messa= ge like " not set up by udev. Falling back to direct node creation.". So I wouldn't go this way... >=20 > I will deploy the rule mentioned in earlier posts as a workaroud for now > and then see what is happening upstream - once the upstream rules are in > a good state, I am more than willing to use those rather than > distro-specific ones. >=20 Yes, sure. We have to do this until we have all the changes propagated. Peter