OK maybe this isn't rocket science, but I've seen it asked plenty of times,
and the only solutions I've seen presented required seperate /boot
partitions and/or ramdisks. Yech (IMHO). I don't want a 12-step boot
process involving a bunch of different partitions... I just want it to work.
The premise I based my work upon is that I have the recent RAID code in the
kernel with autostarting enabled, and a RAID 1 member partition looks
*exactly* like a normal partition, and can be read just like any other
partition... so you should be able to boot the kernel from it just like a
normal partition.
Note that my premise does _not_ apply to RAID 0, 4 or 5. Well maybe 0, but
I don't know, and I wouldn't want a RAID 0 root anyway.
LILO
LILO is probably the most utilized bootloader for Linux systems, so I started
by investigating whether I can make it grok RAID 1 root.
I messed around for a while with the latest version of LILO. No dice.
Maybe I'm not bright enough, but I couldn't get LILO to grok that the md*
devices are its friend, and no amount of quickie hacking on my part was
gonna change that.
LILO is just not going to let me boot my RAID 1 root.
This is not a slam on LILO. Heck, I've happily used it for years to boot my
Linux systems, and probably will continue to on my non-root-raid systems
just because it works out of the box.
GRUB
I've seen GRUB mentioned a few times as an alternative bootloader. I decided
to look into it...
Ah-hah! Here we have a boot loader that is both more sophisticated than
LILO in its user interface (menu-driven), and that also reads the filesystem
on its own (no System.map or any of that jazz, and no need to re-install
GRUB every time you recompile your kernel). Let me say that again, in case
it didn't sink in. GRUB understands ext2 filesystems, and it will read the
kernel file from the filesystem on the fly at boot time - it doesn't need to
store any special knowledge in advance to be able to boot any particular
kernel. Even better it reads a config file from the filesystem *at boot
time* to determine it's behavior - no need to re-install it for config
changes either.
Unfortunately the ducomentation is not for the faint of heart, and a
cookbook recipe specific to Linux seems to be lacking. Several false starts
over the course of months where I ran out of momentum (and kept booting from
a kernel floppy)... and then I finally made some sort of personal
break-through :-) this morning and now I (sort of) understand GRUB.
I changed two lines in the GRUB code, and it's willing to believe that a
partition of type 0xfd is a Linux ext2 filesystem. Whammo! It's perfectly
happy to boot *any* kernel I tell it to, from either of the members of my
RAID 1 root.
I have now installed GRUB on both of my RAID 1 root disks, and configured it
to boot the first disk, and fall back to the second disk if it encounters a
problem with the first disk. My system boots. No floppies, no loopback
mounts and ramdisk shenanigans. It just works.
I've verified that it's able to boot a kernel off of either of my disks.
I have not yet gone so far as to yank the first disk and see what it will
do... I'll try that later.
I'm willing to put together a cookbook description, of sorts, to patch and set
up GRUB to boot RAID 1, and post it to the list. I guess my question is
whether there's any interest in such a thing. It's entirely possible that
most people are smarter than me, and won't have as much trouble figuring out
how GRUB works. :-)
If you want to check out GRUB, you can find it at:
http://www.uruk.org/grub/
-Andy
PS - I'll give you a tip. If you're not using lilo, chmod 000 /sbin/lilo or
you're likely to over-write grub in your MBR with lilo the next time you
build a kernel with "make install" out of habit. Ask me how I know... :-)
