HAL and LUKS II: revenge of cryptsetup

[Sam Morris]

On Sun, 20 Apr 2008 00:51:50 +0000, Sam Morris wrote:

> I'm trying to track down the reason why I haven't been able to mount
> encrypted volumes on my Debian system for a couple of months. I
> eventually found "HAL + LUKS" at <http://lists.freedesktop.org/archives/
> hal/2007-October/009716.html>, which seemed to describe what I was
> seeing.
> 
> I eagerly applied the attached patch, only to find that it had already
> been committed a few weeks ago... so why is the workaround not working?
> Adding some more debugging code, I got:
> 
> Apr 20 01:26:51 xerces hald[28904]: 01:26:51.013 [I] osspec.c:238: Not
> doing workaround; hotplug_event->sysfs.device_file == '/dev/dm-2'
> 
> So I guess it never really worked, or maybe the DEVNAME in the hotplug
> event that HAL recives used to start with "/dev/mapper/temporary-
> cryptsetup-" but does no longer.
> 
> So, another workaround is needed. The HAL commit mentions that the
> workaround is only a temporary one, and that the real fix needs to be
> made to udev. It also says that such a fix has been committed--can
> anyone point me to it so that I can get it included in Debian's udev
> packages? I tried to dig it out of the udev git repository, but the
> commit messages are... terse. :)

Today I tried modifying HAL to make it find out the 'true' device name 
for events where hotplug_event->sysfs.sysfs_path starts with "/sys/block/
dm-". The theory is that it can test to see whether the name starts with 
"temporary-cryptsetup" and ignore the device if this is the case.

First I tried using libdevmapper. The code to get a list of current 
mappings along with their device number and name is straightforward, 
however since hal does not run as root, it is unable to open /dev/mapper/
control to do the query in the first place.

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?

-- 
Sam Morris
http://robots.org.uk/
 
PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078