The difference between LILO and GRUB

bootgrub2lilo

I am running a web server under Debian and I currently have GRUB installed.

Should I consider using LILO instead of GRUB? And what are the advantages of each?

Best Answer

LILO has a simpler interface and is easier to wrap your head around.

GRUB is more featured and handles odd configurations better.

The LILO bootstrap process involves locating the kernel by in essence (it's more complicated than this) pointing to the first logical-sector of the Kernel file. The GRUB bootstrap process is more filesystem aware and can locate a kernel file in a filesystem without having to specify a logical-sector.

There is a reason nearly everyone is using GRUB these days, and that's because it's less fragile and handles edge-cases better.

ELILO

Managing EFI Boot Loaders for Linux: Using ELILO

It's really difficult for me to decide which part of that to copy+paste because it's all really good, so I'll just ask you please to read it.

Rod Smith

Authored and maintains both `gdisk` and `rEFInd`.

But before you do I'd like to comment a little on it. The ELILO link above is to one of the many pages on UEFI booting you'll find on rodsbooks.com written by Rod Smith. He's an accomplished technical writer, and if you've ever googled the topic of UEFI booting and wound up not reading something of his, it was likely because you skipped the top several results.

Linux UEFI boot

Basically, the Linux kernel can be directly executed by the firmware.

In the link above he mentions the Linux kernel's EFI stub loader - this is what you should be using, in my opinion, as it allows the linux kernel to be called directly by the firmware itself. Regardless of what you're doing something is being executed by the firmware - and it sounds like that something is grub. If the firmware can directly load your os kernel, what good is a bootloader? UEFI firmware mounts a FAT formatted GPT partition flagged esp by the partition table and executes a path there it has saved as a UEFI boot variable in an onboard flash memory module. So one thing you might do is put the linux kernel on that FAT partition and store its path in that boot variable. Suddenly the kernel is its own bootloader.

Bootloaders

On UEFI systems, bootloaders are redundant - ELILO included.

The problem bootloaders were designed to solve was that BIOS systems only read in the first sector of the boot flagged partition and execute it. It's a little difficult to do anything meaningful with a 512 byte kernel, so the common thing to do was write a tiny utility that could mount a filesystem where you kept the actual kernel and chainload it.

In fact, the 512 bytes was often not enough even for the bootloaders. grub, for instance, actually chainloads itself before ever chainloading your kernel, because it wedges its second stage in the empty space between the boot sector and the first sector of your filesystem. It's kind of a dirty hack - but it worked.

Bootmanagers

For the sake of easy configuration though, some go-between can be useful.

What Rod Smith's rEFInd does is launch as an EFI application - this is a relatively new concept. It is a program that is executed from disk by - and that returns to - the firmware. What rEFInd does is allow you to manage boot menus and then returns your boot selection to the firmware to execute. It comes with UEFI filesystem drivers - so, for instance, you can use the kernel's EFI-stub loader on a non-FAT partition (such as your current /boot). It is dead simple to manage - if such a thing is necessary at all - and it adds the simplicity of an executable system kernel to the convenience of a configurable bootmanager.

Atomic Indirection

The kernel doesn't need symlinks - it can `mount --bind`.

If there's any path on your / where you should disallow symlinking, it is /boot. An orphaned symlink in /boot is not the kind of problem you should ever have to troubleshoot. Still, it is a common enough practice to setup elaborate indirections in /boot by several distributions - even if it is a horrible idea - in order to handle in-place kernel updates and/or multiple kernel configurations.

This is a problem for EFI systems not configured to load filesystem drivers (such as are provided with the rEFInd package) because FAT is a fairly stupid filesystem overall, and it does not understand them.

I don't personally use the UEFI filesystem drivers provided with rEFInd, though most distributions include a rEFInd package that can be installed via package manager and forgotten about just using their own awful symlinked /boot config and rEFInd's packaged UEFI filesystem drivers.

My Config

I once wrote a set of instructions on it and posted it here, but it looks like:

% grep esp /etc/fstab && 
> ls /esp/EFI

LABEL=ESP          /esp  vfat defaults      0 1
/esp/EFI/arch_root /boot none bind,defaults 0 0 

arch_root/  arch_sqsh/  arch_xbmc/  BOOT/  ipxe/

So I just put those two lines in my /etc/fstab pointing to a folder that I intend to contain the new linux installation's /boot and I'm almost done worrying about the whole thing. I also have to do:

cat /boot/refind_linux.conf 

"Arch" "root=LABEL=data rootflags=subvol=arch_root,rw,ssd,compress-force=lzo,space_cache,relatime"

Apart from installing the refind-efi package via pacman for the first one, that is all that is required to setup as many separate installations/configurations as I desire. Note that the majority of that string above consists of btrfs-specific mount-options specified as kernel parameters. A more typical /boot/refind_linux.conf would probably look like:

"Menu Entry" "root=/dev/sda2"

And that's all it takes.

rodsbooks.com

If you still want ELILO then you can find installation instructions at the link above. If you want rEFInd you'll find links to it in the first paragraph there. Basically if you want to do any UEFI boot configuration, read rodsbooks.com first.