HAL and LUKS II: revenge of cryptsetup

[Sam Morris]

On Mon, 2008-04-21 at 10:36 -0400, David Zeuthen wrote:
> On Sun, 2008-04-20 at 16:32 +0000, Sam Morris wrote:
> > Next I did it the brute-force way: list the contents of /dev/mapper, do a 
> > stat on each block device, look at st_rdev and compare it to the device 
> > number of the event; if they match then look at the name. This doesn't 
> > work either though... the 'temporary-cryptsetup-*' block device does not 
> > appear in /dev/mapper by the time HAL has a change to read the directory. 
> > Probably because cryptsetup removes the mapping too quickly.
> > 
> > Any other ideas?
> 
> The fundamental problem is that device-mapper creates it's own device
> nodes in /dev and that's why it's indeed racy. Instead it should rely on
> udev doing this (udev is supposed to manage /dev) and, FWIW, it's a
> known problem and have been discussed by myself, Alasdair and Kay on
> more than one occasion. For some reason I'm not seeing these races on
> Fedora so it "works" fine here (but probably not under load).

This seems to be what Ubuntu have done. I guess they have patched
libdevmapper not to creat the device nodes itself.

> I think a temporary fix includes a udev rule that checks for temporary-cryptsetup*
> and then avoids propagating such events the HAL. That's still a bit racy
> though.

I gave this a go but couldn't get it to work. The uevents sent by the
kernel don't contain any device-mapper specific information, so that's
why I had to resort to the two workarounds I mentioned, neither of which
would work. But it's possible (probable!) that I just don't know the
correct udev-fu to make udev aware of the mapping name...

Anyway, thanks for the reply, I was starting to think that no-one else
had this problem. :)

> 
>     David
> 
> 
-- 
Sam Morris <sam at robots.org.uk>