Hi Martin,
You're right -- that was a lot of text :-). I haven't done an
2.4/LVM1-2.6/LVM2 conversion yet, but am going to have to at some point
in the not too distant future. I _have_ however, set up a 2.6/LVM2
root-on-LVM-on-MD setup. Here's some comments for ya (and anyone else
looking at this), roughly corresponding to your questions:
10) You might want to have a look at the lvm2create_initrd script that's
been bandied about here. (I have a fairly recent copy at:
http://poochiereds.net/svn/lvm2create_initrd). It has a number of
features that are helpful -- in particular a lvm2rescue mode, which
brings up a shell prior to the pivot_root. Also the old lvmcreate_initrd
script uses the deprecated change_root function.
8) yes, the DM control device numbers can (and do) change.
7) You're quite correct about the problems with major/minor numbers on
dm devices. In fact its even worse than you know, since a kernel upgrade
or rebuild can now cause your DM major/minor numbers to change
(depending on how drivers get loaded).
The best way to handle it (as far as I can see) is to use udev (the
replacement for devfs). Under Debian (probably other distribs too), it
mounts a ramdisk over /dev early in rcS.d. This means you need a startup
script that happens after /dev getting mounted and before root gets
fsck'ed that runs a vgscan --mknodes.
We considered trying to make the initrd image fix the device entries on
the root filesystem, but that's dangerous since you're mucking with the
rootfs before it's been fscked. So at this point using udev is _highly_
recommended for root-on-LVM2 setups (prob. for root on EVMS setups etc
too), as it gets around the whole problem of invalid devices on the
rootfs.
There are prob. a lot of things I'm forgetting too, but I'm glad you got
your setup transitioned without data loss!!!
Cheers,
Jeff