Boot Loader Proposal

[Bill Rugolsky Jr.]

On Tue, Oct 21, 2003 at 09:11:44AM -0700, Jesse Keating wrote:
> Ok, here is how I feel about this long, tiresome argument.  There are 
> many people that like grub, and for the majority of the userbase, grub 
> does what it needs to do.  Sure there could be some improvement, but 
> from what I'm told by the people who work on grub, it's somewhat 
> trivial, and possibly the community could do it.

That sounds a bit optimistic; I'll believe it when I see Grub grab
my kernel off of a Device-Mapper /boot logical volume over a whole-disk
MD RAID5, without legacy DOS partitions (or EFI garbage).

I basically agree with your proposed solution of putting LILO outside
Fedora Core, but indulge me for a minute while I ruminate on Grub's
shortcomings.

Look a year or two into the future:

The problem that I have with the "Grub model" is that it expects that
Grub be able to interpret volume and filesystem meta-data.  There is
always a fallback to LILO-like behavior, but here I'm talking about the
*model*.

As the performance problems with volume management (i.e., io request
splitting/merging/scheduling, etc.) are solved, and present a thinner
layer between userspace and storage, we should want most users to
benefit from it.  Users also want to boot from a variety of devices:
USB keychains, etc.  But using the Grub model, that means adding code to
the Grub loader for device discovery and walking metadata for MD, LVM2,
EVMS, Reiser4, etc.  This begs the question: if Grub has to load a ton
of code just to find the kernel, why not go back to something trivial
and static, updated when the kernel or config is modified, and just get
on with booting the kernel?

There is much to be said for the LinuxBIOS approach (which I've played with
a bit): do the minimal hardware setup, get the kernel into RAM, and let the
kernel do the rest.

Rather than having a complicated bootloader with a command line and all
that, I'd much rather have the system boot into a "failsafe"  Linux initramfs,
perhaps even using the polling version of drivers that are being worked on
for crash dumps, and use kexec() to (re)launch the desired kernel with the
desired configuration.  Speed is generally not an issue; on a LinuxBIOS box,
it generally takes far longer to retrieve the kernel from a slow boot device
than it takes the kernel to run "init".  Move more slow device probing out
into userland and it will be even faster.

Regards,

	Bill Rugolsky