Bug#466546: cryptroot-system fails booting after multipath-tools install
debian at x.ray.net
debian at x.ray.net
Tue Feb 19 13:42:30 UTC 2008
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).
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 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
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)
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)
More information about the pkg-lvm-maintainers