This was my first attempt to install Debian, and my first exposure to
Linux's boot sequence. A short patch for the problem reported is
enclosed, but it almost certainly needs improvement for the general
case.
I am prototyping a larger system with an old p3-800 with two 80GB
disks. The disk layout I came up with does not successfully boot
without intervention. Here's what I did:
Both disks ("A" and "B") are partitioned into two partitions each ("1"
and "2").
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".
/home is formed by striping together 2 LVs, 1 each from LVG1 and LVG2,
to become "md5".
swap is formed by mirroring together 2 LVs, 1 each from LVG1 and LVG2,
making "md6".
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.
Anyway, I created this inside the installer, doing manual
partitioning. The installer was able to create this setup, and it
installed Lenny.
Booting failed, dropping me into the initrd sh. This is because the
initrd /scripts/local-top/* are not smart enough to cope with /root on
an md device built on top of LVM LVs. The hand-fix is to bring up the
VGs (lvm vgchange -ay), then the md devices (mdadm -A --scan), then
modprobe the FSes and mount /root. But fixing the scripts, all you
have to do is get the lvm vgchange in at the right time.
After a long slog through the initrd scripts (they are twisty mazes of
little shell scripts, all alike), I came up with the enclosed patch.
It's simple and it works great for me, but despite an initial attempt
to be correctly general I decided I don't know nearly enough about
Debian's initrd design rules to do a proper job. This patch will
probably work for most people, but I can easily imagine it breaking -
I don't know what booting looks like for more complex hardware
environments.
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).
So unless you want to design a config file that lays out a dependancy
tree, and parse/act on it at boot time, you need to... do something.
What, I'm not sure, though my solution might be pretty reasonable.
Someone more experienced than I in this stuff will have to decide.
Do I need to send this patch somewhere else to have it considered?
/a
----------------------------------------->% cut here
%<-------------------------------------------
diff -rN -U3 orig/scripts/local-top/early_lvm2 a/scripts/local-top/
early_lvm2
--- orig/scripts/local-top/early_lvm2 1969-12-31 19:00:00.000000000
-0500
+++ a/scripts/local-top/early_lvm2 2009-05-04 12:53:24.000000000 -0400
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+PREREQ=""
+
+prereqs()
+{
+ echo "$PREREQ"
+}
+
+case $1 in
+# get pre-requisites
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+if [ ! -e /sbin/lvm ]; then
+ exit 0
+fi
+
+modprobe -q dm-mod
+modprobe -q dm-snapshot
+modprobe -q dm-mirror
+
+lvm vgchange -ay
+exit 0
diff -rN -U3 orig/scripts/local-top/mdadm a/scripts/local-top/mdadm
--- orig/scripts/local-top/mdadm 2009-05-04 12:34:31.000000000 -0400
+++ a/scripts/local-top/mdadm 2009-05-04 11:46:07.000000000 -0400
@@ -6,8 +6,16 @@
#
set -eu
+PREREQ="early_lvm2"
+
+prereqs()
+{
+ echo "$PREREQ"
+}
+
case ${1:-} in
- prereqs) exit 0;;
+ prereqs) prereqs
+ exit 0;;
esac
. /scripts/functions
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
