Lenny boot fails with /root in MD on LVM; patch included

[martin f krafft]

also sprach Alexis Rosen <debian at alexis.users.panix.com> [2009.05.04.1952 +0200]:
> A1 and B1 are mirrored together by md, making "md0" for use as /boot.
> A2 and B2 EACH and SEPARATELY become an LVM2 PV ("PV1" and "PV2").
> PV1 and PV2 EACH and SEPARATELY become an LVM2 LVG ("LVG1" and "LVG2").
> LVG1 and LVG2 are carved up into a bunch of LVs each.
> /root, /usr, /tmp, and /var are each formed by mirroring together 2 LVs, 1 
> each from LVG1 and LVG2, becoming "md1" through "md4".

So you are running RAID on LVM. This is backwards in my world. I am
not sure we should even support that use case, but I'll leave it up
to the LVM people to decide about your patch; if they agree, I'll
include the mdadm change you propose.

Anyway...

> /home is formed by striping together 2 LVs, 1 each from LVG1 and
> LVG2, to become "md5".

[...]

> Why am I not simply using md to mirror the whole disk and then
> making LVM volumes on top of that? Because I don't want the whole
> thing mirrored. /home needs to be striped.

Why don't you then put the main system on LVM-over-RAID on
partitions 2 and use partitions 3 as a /home strip set? You might
argue that you want full flexibility to move space between the
different filesystems, but realistically speaking, /, /usr, and
/boot are mostly fixed in size. Put those on LVM-over-RAID (or just
pure RAID) and then use the rest for stripe sets or whatever else
you might need to accomodate /home and /var.

> The heart of the problem, I think, is that there's no easy way to
> figure out which /dev/mdNs need to be up before which LVs, and
> vice-versa. You could have mdN inside an LV inside another mdN
> (and so on).

Exact analysis, this is in fact the heart of the problem. But as
you say yourself, without a dependency graph, we cannot properly
cater to the situation. I am not sure whether this complexity would
be justified, given that I would never suggest anyone to run RAID
off non-physical devices, unless you are doing testing and/or are
prepared to deal with the pain.

But as I said above, if the LVM folks think your patch is sensible,
I won't object. If I feel belligerent, I might throw in a pinch of
cryptsetup though. "My LVM on RAID on encrypted LVM doesn't work!"

> Do I need to send this patch somewhere else to have it considered?

File a bug against LVM and put me on X-Debbugs-Cc. If they fix it,
I'll add the prerequisite to mdadm.

Thanks,

-- 
 .''`.   martin f. krafft <madduck at d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"we should have a volleyballocracy.
 we elect a six-pack of presidents.
 each one serves until they screw up,
 at which point they rotate."
                                                      -- dennis miller
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20090504/0267c95a/attachment.pgp>