Weekly Edition
Return to the Distributions page
| |||||||||||||
LILO vs. GRUB
Up until a few years ago there was no arguing about a Linux
distribution's bootloader. With LILO (LInux LOader) as
the dominant software for this purpose, many seasoned Linux system
administrators had mastered the art of creating a lilo.conf file out of
thin air, without having to look through any LILO documentation.
Unfortunately for them, the release
notes of Red Hat 7.2, released in October 2001, informed us that
"we now use GRUB as the default bootloader."
Back in those days, only Caldera OpenLinux was supplying GNU's GRUB (GRand Unified Bootloader) as its preferred bootloader, but this sudden push by Red Hat was about to give GRUB a major boost. Indeed, many distributions soon followed Red Hat's example and started providing GRUB as an option, although few of them displaced LILO altogether. Then in March 2003, the just-released Red Hat Linux 9 re-emphasized Red Hat's commitment to GRUB by placing LILO on a list of deprecated packages that may be removed from a future Red Hat release. Although this has yet to happen, the fact is that Red Hat (as well as Fedora) have not updated their LILO version since August 2000. Does this mean that LILO is dead? Well, not quite. Firstly, LILO has been around for so many years (I was unable to find out exactly how many, but LILO version 15 was released in October 1994), that it is firmly entrenched in many a sysadmin's arsenal of tools. Secondly, GRUB is still considered alpha software - even its most recent release, version 0.95, is only available from alpha.gnu.org, rather than from GNU's stable directory. As for the Linux distributions, most of the major ones seem to be slowly moving towards GRUB as their preferred bootloader, although this has not happened across the board. While SUSE's installation program does default to GRUB, Mandrake's still defaults to LILO. The Debian installer that came with Woody did not provide GRUB at all, but the recent Sarge beta installers now use GRUB by default. Gentoo used to demonstrate a clear preference for GRUB, but its most recent installation documentation gives equal exposure to both bootloaders. This leaves Slackware as the only major distribution that does not provide GRUB, but this is hardly surprising given its target market and its reputation for staying with well-established UNIX/Linux tools. The LILO versus GRUB argument is one of those never-ending and passionate discussions that resurface from time to time on various public forums, not too different from the notorious vi vs. emacs or KDE vs. GNOME verbal battles. Although we all know that these debates are pointless and that the choice of software is a simple matter of personal taste, few of us are able to control the urge to reply as soon as we read a derogatory comment ridiculing our preferred piece of software. So what exactly makes GRUB better than LILO? Here is a list of some of GRUB's frequently cited advantages:
Some people like to acknowledge both the operating
system and kernel when they talk about their computers, so they might
say they use 'GNU/Linux' or 'GNU/Hurd'. Other people seem to think that
the kernel is the most important part of the system, so they like to
call their GNU operating systems 'Linux systems'. I, personally,
believe that [both are] a grave injustice, because the boot loader is
the most important software of all. I used to refer to the above
systems as either 'LILO' or 'GRUB' systems. Unfortunately, nobody ever
understood what I was talking about; now I just use the word 'GNU' as a
pseudonym for GRUB. So, if you ever hear people talking about their
alleged 'GNU' systems, remember that they are actually paying homage to
the best boot loader around: GRUB!
Some distributors - and their users - may continue to disagree for some time, however. (Log in to post comments)
LILO vs. GRUB Posted Jun 17, 2004 2:03 UTC (Thu) by lutchann (subscriber, #8872) [Link] We switched from LILO to GRUB because LILO is too dumb for its own good. Sometimes when moving hard drives from one machine to another, we'd find that LILO would no longer boot (it would get as far as "LI" or sometimes just "L"). It most often happened when Ghosting images onto new machines.Because LILO locates the data it requires (in particular, your kernel) through a static list of sectors and offsets, any changes in the drive geometry, even switching CHS translation techniques, can cause LILO to break and necessitate a boot from a rescue disk. Most of our systems are in custom industrial enclosures with no removable media drives, so booting from a rescue disk isn't always easy. GRUB, on the other hand, actually understands drive geometry and even knows how to read your filesystems. We've yet to have GRUB die on a drive/image transfer. On rare occasions when the MBR gets fragged, booting GRUB over the network and re-running the GRUB installer will fix the problem in much less time than booting all the way into Linux to re-run LILO. So, personal preference aside, GRUB has saved us a lot of time that we previously wasted trying to coax LILO onto new systems.
LILO vs. GRUB Posted Jun 17, 2004 3:43 UTC (Thu) by jreiser (subscriber, #11027) [Link] LILO stores information about the location of the kernel or other operating system on the Master Boot Record (MBR).GRUB often stores its own program in "no mans's land": the remaining sectors of the first track. Usually this is LBA sectors 1 through 63 (31.5KB). This is exactly the place to get clobbered by Cedilla or other dreck associated with MS Wind*ws, and there were more than a few multi-booting users in the US whose Linux became disabled when they installed Intuit's TurboTax 2002. Some storage media have many fewer sectors on the first track, and any disk can have a partition table that puts those sectors inside a partition; GRUB will have a hard time on such a device. It is possible to write an MBR+ext2 bootloader for x86 that boots a kernel and initrd by name lookup in the root filesystem, and resides entirely in the (512-64-n) bytes of the MBR plus the 1KB boot block of a minimal ext2/ext3 filesystem. See http://www.BitWagon.com/ftp/mbr03.tgz and http://www.BitWagon.com/ftp/e2boot4c.tgz. [Note that e2boot4c is for 1KB blocks, and requires modification for 4KB blocks. Also, this work was done in 1998 and does not observe the Extended BIOS Data Area below 0xA0000.]
LILO vs. GRUB Posted Jun 17, 2004 14:01 UTC (Thu) by lutchann (subscriber, #8872) [Link] I assume you're referring to the stage1.5 component, which by default gets installed into the sectors following the MBR. It can also be installed into the boot area of your Linux boot partition for filesystems that support it, and Windows stuff had better not be touching that.Heck, stage1.5 is optional, so if you want you can have GRUB read the stage2 file directly off the hard drive sector-by-sector in the same technique LILO uses. I believe this is how RedHat's installer usually installs GRUB to be immune to apps that trash the spare sectors. (Of course, then you might be susceptible to geometry changes, just like when using LILO.)
LILO vs. GRUB Posted Jun 24, 2004 15:23 UTC (Thu) by ranmachan (subscriber, #21283) [Link] I think it is bad practice to put the Linux loader (whether it be GRUB, LILO or any other) into the MBR, since that is not the purpose of the MBR and a rather fragile place (e.g. reinstalling the Redmond OS on a dual boot system usually overwrites the MBR). Putting it into the first sector of the boot partition is much better.
LILO vs. GRUB Posted Jun 28, 2004 1:54 UTC (Mon) by Sergio1704 (guest, #19452) [Link] I couldn't agree more.This is the point that both users and especially developers ought to understand. There is a particular distro that offers no choice, only GRUB into the MBR. Since I bought my new desktop it refuses to install. And besides, in order to get a clean MBR I need to run fixmbr every time I try to install said distribution.
LILO vs. GRUB Posted Jun 17, 2004 8:33 UTC (Thu) by sbakira (subscriber, #5571) [Link] I did use both utilities for booting my "numerous" distributions.At this time, Grub is not able, and I did'nt see any particular will from the dev team, to boot from a full lvm partition as lilo is able to. Add to this point that grub needs to understand : 1- The disks layout 2- the metadata - as in LVM or RAID 0,1,4,5,6 3- the filesystem where the kernel and other files are placed This whole thing makes GRUB irrelevent if you want to boot your machine from a LVM parition formated in exotic format for instance. So, I'm sticking to lilo.
LILO vs. GRUB Posted Jun 17, 2004 17:28 UTC (Thu) by thoffman (subscriber, #3063) [Link] I also prefer to use GRUB... being able to edit kernel command line parameters and even hunt around the filesystem for other kernels to boot is a very cool feature.Unfortunately, my main machine is set up with dual 10,000 RPM Raptor SATA drives using a combination of mirrored and striped RAID partitions. It's very fast :-) But GRUB can't handle Linux software RAID. So, after installing Fedora Core 2 (apparently successfully) I had a non-bootable system -- easily recovered if you know what to do - boot the Fedora rescue disk, chroot to the RAID partition and install LILO. At least the fedora core 2 installer did correctly set up my lilo.conf file for me. But it would be nice if the installer recognized it's own limitations, and just used LILO automatically when GRUB can't do the job. Of course, the best solution would be to teach GRUB to understand: 1. Linux software RAID 0 I'm not sure if GRUB understands XFS, JFS, and the other advanced filesystems Linux uses either... but LILO does (or has patches at least). So LILO isn't dead yet.
LILO vs. GRUB Posted Jun 17, 2004 22:56 UTC (Thu) by maney (subscriber, #12630) [Link] GRUB may not understand software RAID, but it works just fine with Linux's md using RAID1 for me. I can't see how it would cope with any of the other RAID flavors, since they all stripe the data across multiple physical devices, but I don't believe LILO would work in that situation either. So I'm a little puzzled about what else might have been going on that wasn't described here. Maybe it was an installation issue.LILO may work in a few settings where Grub doesn't, but I would expect them to be rather fragile. LVM, yes, LILO works there... as long as you don't actually use LVM's wonderful capabilities and invalidate LILO's block list. Besides, who needs LVM to manage a /boot partition that's oversized at a few tens of MBs? As for RAID, for real performance you want hardware in there, and then it magically works with Grub again. <grin>
LILO vs. GRUB Posted Jun 18, 2004 14:32 UTC (Fri) by southey (subscriber, #9466) [Link] SUSE 9.1 does warn you with and will change it from GRUB to LILO - except for the fact that the message don't make it clear that you have changed you boot loader!
LILO vs. GRUB Posted Jun 18, 2004 14:33 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] I guess the way I'd solve that particular problem would be to have a separate boot filesystem that's only mirrored, not striped. I don't see the point of striping the boot partition anyway. I do see the point of mirroring, though.I mean, really, what's the issue w/ a 10MB /boot on a 100GB drive? You won't even notice it.
GRUB understanding more file storage systems Posted Jun 18, 2004 22:50 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Of course, the best solution would be to teach GRUB to understand: ...Oh Lord, no. We don't want two parallel sets of software for all these things. And if you make Grub that complex, it will be large enough, buggy enough, and volatile enough, that you'll want a boot loader for Grub. The Linux kernel itself used to be the "boot loader" (you'd put the kernel image on the disk, starting at sector 0). There's a reason we added a tiny boot loader stage to the mix. It seems to me we need to separate the storage for the boot information (including the boot images) from the storage for all the files we use after a full system is running. The running system is too complex for the boot loader to keep up with it. But the boot loader's filesystem requirements are extremely simple. So neither Grub nor LILO have it figured out.
LILO vs. GRUB Posted Jun 21, 2004 18:52 UTC (Mon) by mongre26 (guest, #4224) [Link] I run grub on all of my RAID systems, software or otherwise. There is no problem with grub on software RAID1 or RAID0. Software root RAID5 does not work, but that is not the bootloaders fault.Not sure why you claim otherwise but I know grub works fine. In addition grub offers a better approach IMO for ensuring that the boot loader is installed on both of the disks in a RAID1 mirror to ensure failure of the boot sector device does not create an unbootable system. This is despite claims that it cannot be done by some adherents to Lilo on the mailing lists. grub works just fine in all of the situations and odd disk tricks I have tried.
LILO vs. GRUB Posted Jun 17, 2004 8:52 UTC (Thu) by Klavs (subscriber, #10563) [Link] While Grub is a very nice bootloader - I really like that I have it on my RIP bootcd - so I can boot discs, that some old bios can't handle - because the discs were suddenly moved (or new controllers were added to the mix) - I prefer LILO for servers - simply because of two things:1) it forces you to verify the config - before the change is implemented. (GRUB just reads the config on boot - and if its buggy - you're out of luck on a remote system). 2) LILO supports the -R option - which I use to test kernels, of which I'm not a 100% will boot - this way all I have to do - is to repower the server (which you can get even a monkey to do - and on IBM systems, can be done by "dialing up" to the ASMA processor :)
dual boot Posted Jun 17, 2004 9:56 UTC (Thu) by grmd (subscriber, #4391) [Link] The -R command line option is also very useful when you have a dual boot system, for quick shutdown from one system (e.g. Linux) to reboot into another (e.g. Windows) without the timed out delay waiting for the user to select which system to boot.
dual boot Posted Jun 17, 2004 10:30 UTC (Thu) by seyman (subscriber, #1172) [Link] There's a patch out there somewhere that allows to do this with grub. From the changelog of the Fedora Core 2 rpm:"- add patch from GRUB mailing list from Keir Fraser to add a --once flag to
dual boot Posted Jun 17, 2004 14:32 UTC (Thu) by plars (subscriber, #7736) [Link] That's great to hear that someone is actually thinking about doing this... but a patch out there doesn't help me. Until that patch is in mainline grub code and present in all major distros, grub is completely useless to me.I do a lot of automated testing, sometimes on machines that take a long time to boot. Without the -R (or equivilent option) all of my time would be used by standing around waiting on a LOT of individual machines to get to a boot loader prompt so that I could select the right kernel. Not all of us boot a kernel expecting or hoping for it to work. :)
dual boot Posted Jun 17, 2004 15:33 UTC (Thu) by nstraz (guest, #1592) [Link] I do a lot of automated testing too and I find that LILO is better in that environment. Being able to add another kernel image easily to the config file and setting LILO to boot it is invaluable. As far as I've seen, doing that with GRUB is tricky. If I could specify the default kernel to boot by name instead of by number, I'd probably start using GRUB.
LILO vs. GRUB Posted Jun 17, 2004 14:12 UTC (Thu) by lutchann (subscriber, #8872) [Link] Unattended kernel upgrades make me very nervous, but with some extra hardware on the server, GRUB makes the process bearable. My remote server is connected to a terminal server on the serial port, and GRUB is configured to talk to the serial port rather than the console. With the addition of a network-controlled power switch, I can easily reboot the system and change the boot configuration any way I need to. Were I to use LILO, my only recourse for a bootloader screw-up would be to boot from a rescue disk, which is difficult to do without physical access to the machine...
LILO vs. GRUB Posted Jun 17, 2004 18:02 UTC (Thu) by plars (subscriber, #7736) [Link] Additional hardware is a nuisance when there's a solution (lilo) that doesn't require it. However, when you multiply that by hundreds, possibly thousands of diverse test machines, some of which do not even have a serial port in the traditional sense, it becomes downright impossible to do what you are describing.As for screwing up your boot configuration, I really like lilo better hear too. It's a lot easier to shoot yourself in the foot with grub since (as has already been pointed out) there's nothing that runs after a modification to validate you didn't put a typo in your kernel image name. The other nice thing is that lilo shows you what you selected as the default when you run lilo, so if you screwed up and forgot to change your default when you intended to, you know it before you reboot. Recovery with a boot cd has never been a problem for me in the past, whereas remembering which drive has my kernel on it with so many different machines can be problematic. Grub has a long way to go before I would consider using it, though I like the concept of grub and hope that they can implement these simple features before long.
LILO vs. GRUB Posted Jun 17, 2004 14:57 UTC (Thu) by nix (subscriber, #2304) [Link] LILO stores information about the location of the kernel or other operating system on the Master Boot Record (MBR).No. LILO stores information about the location of its own map file in the MBR; GRUB can optionally do this too, and the only way it can avoid it is the horribly fragile stick-stage-1.5-in-unallocated-sectors kludge. Unlike LILO, GRUB has a web site. It also has a manual, FAQ, a bug tracker, a developer mailing list and a logo. LILO has none of those.Er, actually LILO has a sizeable manpage and a huge LaTeX manual. (It would be nice if the current maintainer kept the latter up to date. :( ) Really, I wish it worked the way SILO did, with none of the uglinesses of LILO or GRUB -- but that might be hard until we get decent OpenBoot-compliant BIOSes.
LILO vs. GRUB Posted Jun 17, 2004 17:32 UTC (Thu) by bjn (guest, #2179) [Link] I also like that one grub.conf file can chain to another one. On systems that have more than one distro (or version of a distro) installed, you can have the first GRUB on /dev/hda, and that one's grub.conf can have a menu option to chain to the second GRUB on (say) /dev/hda2, which has its own grub.conf. This way, as you upgrade the kernel on the second one, you keep the second grub.conf up-to-date; you don't have to try to merge multiple grub.conf's together. With LILO it's update distro #2, boot into distro #1, update the LILO config. to match (now WHAT was that filename again? mount the other root read-only, look it up...), boot back to distro #2... gets old.
LILO vs. GRUB Posted Jun 17, 2004 20:45 UTC (Thu) by HenryHartley (guest, #5630) [Link] With reference to the statement, "Firstly, LILO has been around for so many years (I was unable to find out exactly how many, but LILO version 15 was released in October 1994)..." I found this on groups.google.com dated June 29, 1992:-------------------------------------------------------- From: Werner Almesberger (almesber@nessie.cs.id.ethz.ch) Subject: LILO - Generic boot loader (ALPHA TEST RELEASE) Newsgroups: comp.os.linux Date: 1992-06-28 10:31:20 PST A preliminary alpha test version of a generic (e.g. file-system-independent) You need a 0.96 kernel (patches are relative to 0.96b), any reasonably up I've appended the advertising section of the README to this posting. - Werner The full article is here: --
LILO vs. GRUB Posted Jun 17, 2004 22:39 UTC (Thu) by ballombe (subscriber, #9523) [Link] "LILO stores information about the location of the kernel or other operating system onthe Master Boot Record (MBR)" If you do a default Debian woody install, lilo will not be installed in the mbr, but in the boot partition. The "mbr" package will be installed in the MBR and will chain-load lilo. This arrangement is more robust and "mbr" provide some keystroke for emergency situation (you can try to boot any partitions, a floppy, etc.).
LILO vs. GRUB Posted Jun 17, 2004 23:54 UTC (Thu) by potiere (subscriber, #9747) [Link] "LILO has been around for so many years (I was unable to find out exactly how many, but LILO version 15 was released in October 1994)"From Almesberger page (the author of Lilo), he started it in 1992.
|
|||||||||||||