LILO vs. GRUB
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:
- GRUB has a more powerful, interactive command line interface. LILO,
on the other hand, only allows one command with arguments.
- LILO stores information about the location of the kernel or other
operating system on the Master Boot Record (MBR). Every time a new
operating system or kernel is added to the system, the Stage 1 LILO
bootloader has to be manually overwritten, otherwise there is no way to
boot the new OS or kernel. This method is more risky than the method
used by GRUB because a mis-configured LILO configuration file may leave
the system unbootable (a popular way to fix this problem is to boot
from Knoppix or another live CD, chroot into the partition with
mis-configured lilo.conf and correct the problem). On the other hand,
correcting a mis-configured GRUB is comparatively simple as GRUB will
default to its command line interface where the user can boot the
system manually. This flexibility is probably the main reason why many
users nowadays prefer GRUB over LILO.
- 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.
- With more than a decade of development behind it, LILO is one of the
most widely-used, well-tested and dependable Linux applications ever
written. Most experienced system administrators are well-versed in
configuring the LILO and skilled enough to deal with any emergency
situation.
- The Red Hat Linux Reference Guide claims that GRUB may have
difficulties booting certain hardware. It does not provide any further
details, though.
- GRUB is, according to its developers, alpha-quality software. Use at your own risk.
Some distributors - and their users - may continue to disagree for
some time, however.
| Index entries for this article | |
|---|---|
| GuestArticles | Bodnar, Ladislav |
Posted Jun 17, 2004 2:03 UTC (Thu)
by lutchann (subscriber, #8872)
[Link]
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.
Posted Jun 17, 2004 3:43 UTC (Thu)
by jreiser (subscriber, #11027)
[Link] (3 responses)
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.]
Posted Jun 17, 2004 14:01 UTC (Thu)
by lutchann (subscriber, #8872)
[Link]
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.)
Posted Jun 24, 2004 15:23 UTC (Thu)
by ranmachan (guest, #21283)
[Link] (1 responses)
Posted Jun 28, 2004 1:54 UTC (Mon)
by Sergio1704 (guest, #19452)
[Link]
Posted Jun 17, 2004 8:33 UTC (Thu)
by sbakira (subscriber, #5571)
[Link] (6 responses)
Posted Jun 17, 2004 17:28 UTC (Thu)
by thoffman (guest, #3063)
[Link] (5 responses)
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.
Posted Jun 17, 2004 22:56 UTC (Thu)
by maney (subscriber, #12630)
[Link]
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>
Posted Jun 18, 2004 14:32 UTC (Fri)
by southey (guest, #9466)
[Link]
Posted Jun 18, 2004 14:33 UTC (Fri)
by jzbiciak (guest, #5246)
[Link]
I mean, really, what's the issue w/ a 10MB /boot on a 100GB drive? You won't even notice it.
Posted Jun 18, 2004 22:50 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
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.
Posted Jun 21, 2004 18:52 UTC (Mon)
by mongre26 (guest, #4224)
[Link]
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.
Posted Jun 17, 2004 8:52 UTC (Thu)
by Klavs (guest, #10563)
[Link] (6 responses)
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 :)
Posted Jun 17, 2004 9:56 UTC (Thu)
by grmd (guest, #4391)
[Link] (3 responses)
Posted Jun 17, 2004 10:30 UTC (Thu)
by seyman (subscriber, #1172)
[Link] (2 responses)
"- add patch from GRUB mailing list from Keir Fraser to add a --once flag to
Posted Jun 17, 2004 14:32 UTC (Thu)
by plars (guest, #7736)
[Link] (1 responses)
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. :)
Posted Jun 17, 2004 15:33 UTC (Thu)
by nstraz (guest, #1592)
[Link]
Posted Jun 17, 2004 14:12 UTC (Thu)
by lutchann (subscriber, #8872)
[Link] (1 responses)
Posted Jun 17, 2004 18:02 UTC (Thu)
by plars (guest, #7736)
[Link]
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.
Posted Jun 17, 2004 14:57 UTC (Thu)
by nix (subscriber, #2304)
[Link]
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.
Posted Jun 17, 2004 17:32 UTC (Thu)
by bjn (guest, #2179)
[Link]
Posted Jun 17, 2004 20:45 UTC (Thu)
by HenryHartley (guest, #5630)
[Link]
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: --
Posted Jun 17, 2004 22:39 UTC (Thu)
by ballombe (subscriber, #9523)
[Link]
Posted Jun 17, 2004 23:54 UTC (Thu)
by potiere (guest, #9747)
[Link]
From Almesberger page (the author of Lilo), he started it in 1992.
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. LILO vs. GRUB
LILO stores information about the location of the kernel or other operating system on the Master Boot Record (MBR).
LILO vs. GRUB
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.LILO vs. GRUB
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
I couldn't agree more. LILO vs. GRUB
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.
I did use both utilities for booting my "numerous" distributions.LILO vs. GRUB
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.
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.LILO vs. GRUB
2. Linux software RAID 1
3. Linux LVM and Device Mapper drive setups
4. Reiserfs 4, for those of us on the bleeding edge :-)
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 vs. GRUB
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
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.LILO vs. GRUB
Of course, the best solution would be to teach GRUB to understand: ...
GRUB understanding more file storage systems
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. LILO vs. GRUB
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:LILO vs. GRUB
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
There's a patch out there somewhere that allows to do this with grub. From the changelog of the Fedora Core 2 rpm:dual boot
savedefault function so that you can have the equivalent of lilo -R
functionality (use 'savedefault --default=N --once' from the grub shell)"
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.dual boot
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.
dual boot
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
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.LILO vs. GRUB
LILO vs. GRUB
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. :( )
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
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:LILO vs. GRUB
--------------------------------------------------------
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
boot loader called LILO ("LInux LOader") is on banjo.concert.net,
/pub/Linux/Incoming/lilo.0.tar.Z
to date gcc and as86/ld86 to use it.
--------------------------------------------------------
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=1992Jun28.233320.16842%40bernina.ethz.ch
Henry
"LILO stores information about the location of the kernel or other operating system on LILO vs. GRUB
the 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 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)"LILO vs. GRUB
http://www.almesberger.net/cv/projects.html