[ale] GRUB issue on boot

Thu Apr 13 22:52:57 EDT 2006

LILO will let you change the boot up display, or add "emergency" or
whatever.  GRUB, OTOH, will let you load a backup kernel that you have
stockpiled away somewhere out of the way from anywhere on the filesystem
at any time.  If you have a failsafe/debug kernel that you do not want
people to have access to (say, on a production server, where someone
other then the SA may be booting the kernel), you can edit the boot
parameters to boot THAT kernel instead, on-the-fly.

Moreover, if the kernel is on a different drive, or you're testing an
upgrade before making it permanent and adding it to the menu (or
overwriting the current kernel), you can do that with GRUB.  With LILO,
you cannot.

For example, on my systems, I have:

 /boot/kernel - Gentoo's kernel (the default)
 /boot/kernel.vanilla - A vanilla kernel from kernel.org
 /boot/kernel.lowmem - One that doesn't work > 880 MB RAM, just in case
 /boot/kernel.debug - A Gentoo Kernel with all debugging features
	compiled in.

I also have, in my home directory, every kernel I've ever used.  Now, if
I run into a problem down the line and find that something is no longer
working right, but I know that it worked correctly six or so kernels
ago, I can just type "e", tell GRUB to load that kernel from my home
directory, with all the appropriate parameters, and see if something
did, in fact, break in a newer kernel.

This way, I don't have the bootloader keeping track of every single
kernel that I've ever used, and I can still have them available to me at
boot time if I need to troubleshoot something.  It's quite efficient,
and makes a great deal of sense.  The only really unpretty thing about
it is that /lib/modules tends to get pretty heavy, but that's something
that I can deal with.

> don't even know what that is supposed to mean. I also don't know what
> a "multiboot kernel" is. I have done some searching and can't come up
> with a definition. So there is another thing that really doesn't
> matter in regard to just loading the OS. Doing a search for "multiboot
> lilo" seems to generate results that indicate LILO supports this
> mysterious feature as well.
> 

LILO does not support the MultiBoot standard.  MultiBoot is a standard
that many smaller operating system kernels now follow that has a
specific header, and can work no matter what the native executable
format of the system is (ELF, A.Out, PE, whatever).

Very useful for developers, but as things run forward, MultiBoot should
become more and more used in the world.  It is an excellent boot
protocol mechanism.

> Also, the bootloader having an interactive shell for editing its
> config and rewriting it to the bootsector is useless when the
> bootloader won't load. If I'm not mistaken, that was the problem that
> started this thread - Grub not loading.
> 

This is true.  However, I was responding to what you'd said as far as
its inflexibility.  I was just showing you how it is that the claim can
be made that it is, in fact, more flexible then LILO.

> All of your "features" are pretty, but they don't really mean much for
> a production system that just needs to boot. Chances are, that machine
> won't be booting so much that it needs all the fancy features of Grub
> its bootloader.
> 

The ability to completely change the way the system boots -- down to the
last configuration detail -- can be of extreme use on a production
system, so long as it's done properly.  No matter *what* boot loader
choice you use, if the boot sector takes a crap, or the drive takes a
crap and the boot sector can no longer be read, you're in trouble.
Those are, arguably, the most important 512 bytes that exist on the
device.  However, when that isn't the problem, GRUB is far superior of a
choice for any boot solution, unless you absolutely never upgrade
kernels, rebuild, test, troubleshoot, anything.  In that situation, LILO
is good, because you'll never be changing or updating the configuration.

Hopefully, EFI will be everywhere in a year or two, and the need for a
boot loader program at all will become obsolete, because loaders for
Linux, *BSD, Windows, etc., will be able to be programmed as add-ons or
modules to the EFI environment, for systems that won't natively support
the EFI standard.  AFAIK, Windows 64-bit will, and Linux already does.
I'm not sure about the other freely available Unix systems, though.

	- Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEPw6I0kE/IBnFmjARA04xAJ9oB7rpjh3NCVYvTBmgOaWmPjGJFQCfR/Mk
ZuWKedxDJvsk8/bur+6h8u8=
=vcev
-----END PGP SIGNATURE-----