On Mon, Jul 4, 2011 at 3:18 PM, Stephen Powell <zlinux...@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.pad...@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". -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caocn9ry6zewm2emerr_j_0yocffk0rgsbaksf3ok4e7-gch...@mail.gmail.com
