Re: GRUB OR LILO?
On Mon, Jul 4, 2011 at 3:18 PM, Stephen Powell <zlinuxman@wowway.com> wrote:
> On Mon, 04 Jul 2011 11:38:40 -0400 (EDT), Nico Kadel-Garcia wrote:
>> On Mon, Jul 4, 2011 at 2:24 AM, Alex PADOLY <alex.padoly@gmx.fr> wrote:
>>> ...
>>> For a server that works permanently with DEBIAN SQUEEZE,
>>> I used LILO in kernel compilation and with and scsi isa card.
>>> Why many of LINUX distribution choose GRUB?
>>> I don't know that I must choose.
>>> ...
>>
>> There are a big, big stack of reasons. Once grub is installed, you can
>> edit grub.conf and don't have to "re-install" it in the boot loader,
>
> If it's installed in the master boot record, yes. If Grub Version 2
> is installed in a partition boot sector, I believe it reads a list of blocks,
> just as LILO does. I don't believe that this is the case with
> Grub Version 1. However, Grub Version 1 is no longer actively developed.
> And both versions of Grub use unallocated sectors to store extra
> code when they are installed in the master boot record. This can
> lead to conflicts with other programs trying to do the same thing
> or backup / restore issues. So there is a down side to this feature.
If you've got other tools writing to the MBR for boot loading, you've
got other issues. Typically, that's used with "chain loading". Your
default OS is responsible for the MBR updates, and your alternative
OS's used to rely on their own boot loaders (such as a grub or LILO
boot loader on a particular partition or non-standard boot drive, such
as detached storage.)
Chain loading used to be popular, partly because it left a default
Windows OS bootable and compatible with MS recovery tools. (Been
there, done that, helped deal with thousands of dual-boot machines.)
Effective virtualization in the Windows world has eliminated much of
the desire for this, but it's still a potential concern. Most of the
same issues occur for LILO and grub for this approach, though.
>> This is an *enormous* stability advantage: various changes of system
>> configuration and kernel changes can re-arrange your drives, and
>> having to figure out which one gets the boot loader with the new
>> ordering is incredibly painful.
>
> I'm not sure exactly what you mean by the above. With an appropriate
> combination of symbolic links to block special files and direct
> UUID or LABEL specifications, LILO can be made independent of driver
> type (i.e. traditional IDE vs. libata SCSI emulation) and discover
> order (i.e. /dev/sda vs. /dev/sdb).
Changing the kernel, or attaching bootable media, can change the
naming of block devices *unpredictably*. The use of uuid specific
device names is relatively new. I went through the pain when ID drives
suddenly switched from being named "/dev/hda", /dev/hdb", etc. to
suddenly being "/dev/sda", "/dev/sdb", etc. (Don't get me started on
Promise's RAID controllers.) And /dev/sd* device ordering is
sensitive to kernel storage controller modules being statically
loaded, dynamically loaded, and in different booting order in the
BIOS. All the pre-planned symlink setups in the world will break when
/dev is now rebuilt by udev,
This way lies madness, and grub allows you to see and gracefully
manipulate that madness much more effectively and safely than LILO.
>> LILO's old limitations to having your "/boot" partition contained
>> entirely in the first 8 Gig of disk was also a big issue with
>> dual-boot or larger drived systems where a single "/" partition was
>> preferable. Grub does not have this issue.
>
> And LILO doesn't either. Not anymore. As long as the BIOS supports
> EDD packet addressing, the old 8.4G limit is long gone. For more
> up-to-date information on LILO, see
Yup. Been there, done that, had to deal with old server class hardware
less than 2 years ago. While this is commonly available in even
vaguely modern motherboards, it is a serious crap shoot to rely on it
for ancient server systems, or without doing BIOS updates. Ever tried
to do BIOS updates on systems without Windows on them?
> http://users.wowway.com/~zlinuxman/lilo.htm
>
> LILO is not for everyone; but when properly installed and configured,
> it meets my needs quite well; and I have found it very reliable.
It has its uses, much as "su" has uses when "sudo" breaks down. But
it's no longer a good tool to recommend for "newbies".
Reply to: