Bug#466546: cryptroot-system fails booting after multipath-tools install

[debian at x.ray.net]

Package: multipath-tools
Version: 0.4.8-7
Severity: important

hi!

i'm not sure where this report fits best, it might primarily concern 
device naming which is a kernel thing, it has to do with initramfs 
installation which belongs to the initramfs-glue, which happens to 
irritate me quite a bit as in this case there seem to be two packages 
(-boot and -initramfs) doing the same thing, but overall it concerns 
multipath - so i chose to put it here (directions welcome).

symptoms:
after installation of multipath-tools, booting is not possible anymore.
the root device isn't multipath but in this case dm-crypt.
the problem occurs when the cryptroot password prompt should appear - it
just doesn't but each cryptsetup try outputs a 'Command failed: Can not
access device' and when the maximum number of tries is exceeded the boot
process fails because no root-fs can be found.

the problem:
the crypted device has a canonical name like in this case /dev/sda5. 
this is configured in initramfs in /conf/conf.d/cryptroot.
when the multipath binary is called, multipath devices are created in
/dev/mapper/ (with names that seem to be created to uniquely and
consistently identify devices).
there's also a multipath device created for /dev/sda5 (with a single path).
from now on, cryptsetup /dev/sda5 fails ('Can not access device' - but
it's there and - funny enough - a cryptsetup luksDump /dev/sda5 works).
this must be because it's mapped by the multipath module.
calling cryptsetup on the respective multipath device works.
as this will probably happen in all cases when multipath is installed to
access a multipath connected device while the root-fs is on a
non-multipath device, i think this should be solved.

thoughts on solutions:
i don't really know why /dev/sda5 can't be accessed by cryptsetup
anymore when multipath is using it, but that's obviously what's 
happening and i tend to assume that it probably makes some technical 
sense. on the other hand, if that can be changed, it's probably a very 
practical solution.
another possible solution is, i guess, to implement an option in the 
multipath binary, to ignore i.e. not create a multipath device for 
devices which are connected only singlepath. but this will break the 
boot process in case of a root-fs multipath device in cases of failure 
of paths so that there's only a single path left.
maybe it were most straightforward to change the devicenames in 
/etc/crypttab on installation before mkinitramfs. but following this 
rationale means the multipath package/installation had to regard each 
and every devicename configuration in the system...
or maybe multipath shouldn't be installed to initramfs on (non-initial) 
installation.
the solution which sounds best to me, but also least realistic (for the 
more or less near future) would be to always map/name all - i.e. also 
non-multipath - devices according to the same naming-scheme (generally, 
unique and consistent names for devices really sounds like a very good 
thing to have to me)

	Chris