Bug#566965: lvm2 initscript breaks most "advanced" setups (e.g. stacked block devices) or booting via UUID/LABEL

[Christoph Anton Mitterer]

I think reducing the severity is inappropriate, as this clearly breaks
several configurations from booting.


On Sun, 2010-09-26 at 17:34 +0200, Bastian Blank wrote:
> > I've changed the title and increased the severity as this breaks so many
> > setups.
> Please explain.
See what I've written in my previous email, all setups where lvm is used
with stacked block layers.


> > Bastian, could you please _strongly_ reconsider to correct the initramfs
> > boot-script.
> There is no correct one. Please be more specific.
Maybe, but simply scanning for VGs and making them _all_ available is
what guarantees the best results.
That's also how the whole idea behind the scanning/make-available system
of LVM is.


> > This is AFAIU a misconception of it. As $ROOT is the final device
> > containting the root-filesystem.
> > This must not necessarily be an LV, just imagine setups like:
> > physical disk -> MD -> LV -> dm-crypt/LUKS -> ext4-root-fs
> You need more information in this case. Please provide patches to supply
> all the necessary information to the initramfs. However you are not
> allowed to enable everything it gets the hand on.
Why not? As I've said it does not harm, not even performance wise.

I mean I think only stuff should be included in initramfs images, if
necessary (to keep them small), but that's a totally different thing and
not done by many packages (including lvm2, which simply always adds
stuff to the initramfs regardless of whether the root fs or resume
devices are on LVM or not.


I doubt that it's a good idea at the moment to provide patches that find
out which LV and VG are used for the root-fs and resume devices.
This is (see the wiki link I've mentioned before) very complicated, and
I think it would be better to provide once a overall solution, which is
not only for lvm but also for all the other kinds of block layers.

I mean it's rather complex to find out which VG/LV are actually
required, they don't have to be directly below the root-fs. Therefore
it's not just possible to get this via some simple /etc/fstab grep-ing.


Again, I also prefer to do only the least necessary things in the
initrd, but as I've laid out on that wiki page, that's far too
complicated at the moment, especially as long as all other maintainers
(cryptsetup, mdadm, multiplath, etc. etc.) don't participate.

So for now, simply making all VGs/LVs available (of course not yet
mounting them or so) seems the best solution to me.

Anyway, using $ROOT in lvm2 seems to be definitely wrong. Even with some
heuristic that finds out which VG/LVs are needed for root-fs/resume
devices, this would then need to go into some config-file in the inird
(as e.g. cryptsetup does it).


> > 2) As it expects some rather fixed device pathnames.
> > This in addition breaks using things like UUID/LABEL, even if there are
> > no stacked block devices.
> 
> The device name is already unique. More then UUID or LABEL, lvm support
> snapshots.
What do you mean? Of course it's unique, but people nevertheless might
want to use UUID/LABE instead of the dm device name.


Another some harm of the current way seems to be, that lvm2 initramfs
scripts get troubles when e.g. lvm is not used at all (but installed)
and the root-fs uses a LABEL of the style "foo-bar", which is totally
legal.




Best wishes,
Chris.

btw: It seems that 2.02.74 of lvm2 is out,...
There are many many improvements since the current debian version, which
would cure quite a few problems.
Can you perhaps make any forecasts on when we'll see this (at least in
experimental)? :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5677 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20100926/dbc0dd16/attachment.bin>