[pkg-cryptsetup-devel] UUID in fstab for device mapper devices?

[Guido Günther]

On Sat, Aug 08, 2009 at 11:12:37PM +0200, Ferenc Wagner wrote:
> Guido Günther <agx at sigxcpu.org> writes:
> 
> > On Fri, Aug 07, 2009 at 04:28:46PM +0200, Max Vozeler wrote:
> > 
> >> we recently changed d-i (partman-target, to be precise) to use 
> >> UUIDs in fstab in order to get stable device naming. [...]
> >> Since then, we concluded that it is preferable to go back to plain
> >> /dev/mapper/ paths for LVM LVs because those already provide stable 
> >> device naming (and are more descriptive).
> 
> And filesystem UUIDs are pretty useless as soon as you start using LVM
> snapshots, dd backups or multipath for example.
> 
> > ENV{DM_UUID}=="mpath-*", \
> > 	SYMLINK+="disk/by-id/$env{DM_TYPE}-$env{DM_NAME}"
> > [...]
> >
> > This is what should idealy be used in d-i for multipath device naming.
> > We could then start to remove the hacks that use /dev/mapper/mpath* to
> > reference multipath devices then.
> 
> My limited experience shows that multipath uses unique /dev/mapper/<WWID>
> device names by default, or the configured name, as Bastian mentioned.
> Is that because I'm lucky, and other types of multipaths don't behave
> so nice?  Also, I haven't seen mpath-names apart from an obscure
> multipath.conf option...
It uses the WWID, the configured name (via multipath.conf) or mpathX if
you set user_friendly_names=yes - which we currently use in d-i to have
an easy way to identify multipath devices.

> Anyway, an unfortunate multipath/LVM interaction should also be
> considered: without special configuration in lvm.conf, the PV scan
> finds the LVM metadata on the individual paths as well as on the
> multipath device, then tries to create mappings straight onto the
> first path, skipping the multipath layer.  Of course it fails, because
> that device isn't available any more, but the error is rather hard to
> diagnose from the initramfs prompt.
This can be fixed by preferring /dev/mapper/mpathX names.
Cheers,
 -- Guido