24

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?

  • Depending on whether or not you have an EFI firmware type you could do without either if you liked and load the linux kernel from firmware. But you can still use LILO with EFI (eLILO anyway) or BIOS. It's in the kernel source tree and is maintained. If you want to know how to do the EFI thing I can answer that, but I don't have personal experience with LILO, just know that it is kept and works. – mikeserv Jul 26 '14 at 23:36
  • I remember using LILO around 2010 or 2011 on a then-current Core 2 Duo. I guess it should still work (disconsidering UEFI etc..), the PC architecture has not changed that much. – Renan Jul 27 '14 at 0:14
  • @mikeserv, please write everything you know about LILO-EFI duet. Any informations regarding this topic are welcome. – user77422 Jul 27 '14 at 1:58
  • I actually wrote something you might find useful earlier here that deals shortly with the differences between uefi/bios. The point is uefi includes a bootloader so grub/lilo/anything is redundant. What it often doesnt include is a boot manager - for menus and stuff - so i recommend you go to rodsbooks.com/refind – mikeserv Jul 27 '14 at 2:25
  • 3
    It's still what ships with Slackware. That's hardly a tiny community. – Bandrami Jul 27 '14 at 15:33
26

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.

3

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.

1

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.

  • -1 The (deb/ubuntu) kernel package will not update EFI. (EFI won't read fs that support symlinks, so you can't just use my answer). +1 for EXTLINUX as a newer alternative to LILO. Your link shows it supports several other filesystems which is a good sign. EFI support looks a bit new though, where that's necessary. – sourcejedi Jul 27 '14 at 13:35
  • @sourcejedi - you're wrong. An EFI system on which the proper EFI filesystem drivers are loaded can handle symlinks easily. – mikeserv Jul 27 '14 at 15:39
  • For some reason, linking directly to syslinux.com seems to be forbidden. – polemon Jul 27 '14 at 18:39
  • @mikeserv I know, but loading a filesystem driver struck me as somewhat obscure for most cases. You'd even need to install some sort of EFI script (terminology?) to load the driver & then the kernel. Oh, & I bet no-one has MS secure boot signatures for these drivers so that's another wormcan :p. – sourcejedi Jul 27 '14 at 21:25
  • @sourcejedi - will you please read the answer I wrote here? And yes - you would need some means of loading the driver. – mikeserv Jul 27 '14 at 22:20
1

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.

  • ugh. symlinks in/from /boot are a filthy solution to any problem. – mikeserv Jul 27 '14 at 15:37
  • welp lilo is dead (and uboot deprecated) so yeah. What's the problem you had in mind? People aren't using FAT for /boot yet... BootLoaderSpec is a good project but not really there yet... and there's good reason for that (evil patents, FLOSS compatible license granted only for EFI interop). – sourcejedi Jul 27 '14 at 21:47
  • That was a good edit. – mikeserv Jul 29 '14 at 3:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy