Is GRUB the best bootloading solution? Is there an easier alternative?

I have had some rather bad experiences with GRUB2. I could say (and have said) some nasty things about its design and development process. I especially dislike its means of update: for whatever reason it must semi-automatically update several scripts – one indirectly via another in a chain – for every kernel update – or many other minor (and seemingly unrelated) configuration alterations.

This is directly contrasted by previous experiences I had with LILO – to which I am seriously considering reverting – as I never had any problems with it, and its configuration was pretty simple. For one thing, as I remember it, I had only to update (or, rather, it only ever updated) a single, simply-managed configuration text-file per kernel-update.

So how does LILO work on modern hardware with today’s kernels? How does GRUB? How do other bootloaders? Do I have to fulfill any preconditions, or is it just about writing the configuration file and running lilo command as I fondly remember it in the old days? Does the kernel package update (Debian/Ubuntu) update LILO as it does with GRUB2?

Asked By: user77422


I use LILO instead of GRUB2. To be honest, it was not my choice – GRUB2 installation failed in Debian Live CD installer, but then was option to install LILO which succeed. I have 2 years old laptop running Debian Stable. LILO works flawlessly for me.

Answered By: Larsoden


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


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.


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.

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

Answered By: mikeserv

LILO still is usable, even with UEFI BIOSes. UEFI can load the Linux kernel directly, usually. This depends on the UEFI itself, though.

However if you do need a boot selection screen, for instance if you’re booting into several OSes on one machine, then a small bootloader might be handy.

I’d consider using EXTLINUX instead, though. It’s a variant of SYSLINUX, but it resides in ext-type partitions.

The beauty of EXTLINUX is, that while it is more expandable and has many more options than LILO, it can be just as simple, and is actively maintained.

Answered By: polemon

I don’t remember any equivalent of update-grub. However there’s an older system which is still supported in Debian. (It’s used for uboot on my ARM server).

The most recent kernel is symlinked to /boot/vmlinuz and initrd to /boot/initrd.img. It’s updated by the kernel package. The boot loader is pointed at those & dereferences the symlink on each boot.

So you may well not get a recovery option. In any case this isn’t going to be the most widely tested option, so it’s even more advisable to keep a working boot disk around :-).

Update: If your goal is anything other than literally running LILO on a modern computer, there are probably better alternatives, as described by the other answer(s) here :).

The above only makes sense for the original BIOS-based version of LILO. Modern hardware does provide BIOS compatibility on top of EFI, if you don’t want secure boot or booting Windows 8 from the same menu. You could theoretically get ELILO working but it doesn’t support secure boot or loading Windows 8. ELILO no longer makes sense in general so my guess is there’s not much of a community behind it.

Answered By: sourcejedi

I coded grub-smart, which makes GRUB to automatically figure out its optimal configuration.

Categories: Answers Tags: ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.