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

[Peter Rajnoha <prajnoha@redhat.com>]

On 10/20/2009 03:05 PM, Thomas Bächler 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).
> 
> Okay - which program would do that?
> 

Actually, I can't think of anyone listening to the events this way right now...
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.
> 
> 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 think
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 the
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 message
like "<node> not set up by udev. Falling back to direct node creation.".

So I wouldn't go this way...

> 
> 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.
> 

Yes, sure. We have to do this until we have all the changes propagated.

Peter