LWN: Comments on "LILO vs. GRUB"

LILO vs. GRUB

Sergio1704 — 2004-06-28T01:54:54+00:00

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

ranmachan — 2004-06-24T15:23:49+00:00

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

mongre26 — 2004-06-21T18:52:54+00:00

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.

GRUB understanding more file storage systems

giraffedata — 2004-06-18T22:50:01+00:00

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

jzbiciak — 2004-06-18T14:33:03+00:00

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.

LILO vs. GRUB

southey — 2004-06-18T14:32:03+00:00

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

potiere — 2004-06-17T23:54:42+00:00

"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.
http://www.almesberger.net/cv/projects.html

LILO vs. GRUB

maney — 2004-06-17T22:56:35+00:00

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

ballombe — 2004-06-17T22:39:33+00:00

"LILO stores information about the location of the kernel or other operating system on
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 vs. GRUB

HenryHartley — 2004-06-17T20:45:13+00:00

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)
boot loader called LILO ("LInux LOader") is on banjo.concert.net,
/pub/Linux/Incoming/lilo.0.tar.Z

You need a 0.96 kernel (patches are relative to 0.96b), any reasonably up
to date gcc and as86/ld86 to use it.

I've appended the advertising section of the README to this posting.

- Werner
--------------------------------------------------------

The full article is here:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=1992Jun28.233320.16842%40bernina.ethz.ch

--
Henry

LILO vs. GRUB

plars — 2004-06-17T18:02:24+00:00

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

bjn — 2004-06-17T17:32:32+00:00

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

thoffman — 2004-06-17T17:28:23+00:00

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
2. Linux software RAID 1
3. Linux LVM and Device Mapper drive setups
4. Reiserfs 4, for those of us on the bleeding edge :-)

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.

dual boot

nstraz — 2004-06-17T15:33:54+00:00

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

nix — 2004-06-17T14:57:34+00:00

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.

dual boot

plars — 2004-06-17T14:32:05+00:00

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. :)

LILO vs. GRUB

lutchann — 2004-06-17T14:12:10+00:00

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

lutchann — 2004-06-17T14:01:41+00:00

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.)

dual boot

seyman — 2004-06-17T10:30:19+00:00

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
savedefault function so that you can have the equivalent of lilo -R
functionality (use 'savedefault --default=N --once' from the grub shell)"

dual boot

grmd — 2004-06-17T09:56:21+00:00

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.

LILO vs. GRUB

Klavs — 2004-06-17T08:52:51+00:00

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 :)

LILO vs. GRUB

sbakira — 2004-06-17T08:33:51+00:00

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

jreiser — 2004-06-17T03:43:35+00:00

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

lutchann — 2004-06-17T02:03:58+00:00

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.