[ale] GRUB issue on boot

Fri Apr 14 00:01:09 EDT 2006

I think all of that is way overkill. If I am building kernels myself I
keep the previous known working one, maybe two, around. Adding an
extra entry to LILO for them, and keeping those entries active, is not
difficult. Judicious use of symlinks help in this situation. Keeping
20 different kernels in some obscure directory just because you might
possibly decide to boot one some day is silly in my opinion.
Seriously, when is the last time you booted a kernel that was older
than your second most recent? The ability to load a random kernel
located in some obscure location is just useless for every day work
and 99% of troubleshooting instances.

So I think we are arguing definitions of flexibility. I think LILO is
plenty flexible. It follows the K.I.S.S. methodology. You don't have
to learn all sorts of weird commands and syntax to load your
kernel(s). Just define the ones you want to use, in various ways, and
go on about your business.

Grub? Yeah, it offers the world in flexibility. At the cost of
complexity. I don't want complexity in something I rarely deal with.

On 4/13/06, Michael B. Trausch <fd0man at gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> James Sumners wrote On 04/13/2006 10:19 PM:
> > I still don't see how any of that matters when all you want to do is
> > boot your machine. Why would I want to do "boot-time alterations"? I
>
> 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-----
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
>

--
James Sumners
http://james.roomfullofmirrors.com/

"All governments suffer a recurring problem: Power attracts
pathological personalities. It is not that power corrupts but that it
is magnetic to the corruptible. Such people have a tendency to become
drunk on violence, a condition to which they are quickly addicted."

Missionaria Protectiva, Text QIV (decto)
CH:D 59