On Mon, 23 Aug 1999, Tim Walberg wrote:
> One method I've seen on another platform (Solaris/Veritas)
> is as follows:
>
> 1) boot loader knows about a list of the various components
> of the boot RAID device (accomplished via eeprom on SPARC)
> and will attempt to boot from the first of these it can
> talk to
> 2) first component is accessed in read-only mode (thus not
> invalidating any RAID data) in order to load the kernel
> far enough to go through the device detection/configuration
> stages
> 3) after RAID devices have been detected and configured,
> boot/root file systems can be re-mounted read/write
Yes - this is pretty much what we're doing using either grub or lilo. The
bootloader (grub or lilo) reads the kernel from one of the RAID 1 mirrors,
and then the latest version of the RAID kernel code auto-detects RAID
partitions by their partition type (0xFD) and assembles them. After that,
as long as the "root=" argument to the kernel is correct, booting proceeds
normally.
The primary difference between the grub and lilo approaches is how they
handle steps 1 & 2 above.
Lilo stores info about the kernel and it's location (I believe the blocks it
occupies?). At boot time it goes straight to the stored location and reads
the kernel. That's why lilo needs to be re-installed after any kernel
change. Lilo's advantage is that, when things go well, everything can be
done from the running linux system (while the initial - and only - grub
install is done from a bootable floppy).
Grub stores info about the device and filesystem path for the grub config.
At boot time it reads the filesystem on that device to find the grub config
(text file) and does whatever it says to, still reading the filesystem to
find whatever files it's told to. Grub's advantage, as I see it, is that
once it's installed once, it just works. I've had lilo re-installs go
haywire, leaving me with a system that wouldn't boot (yielding "LI" or
somesuch).
> The only major problem I've gotten into with this is when
> the root filesystem gets corrupted enough that the kernel
> can't be found on the booted component, but hopefully that's
> a **very** rare occurrence.
And probably deadly regardless of your boot method...
-Andy
