What Is LILO (Linux Loader)? Architecture, Configuration, and Comparison with GRUB

LILO (Linux Loader) is a legacy bootloader for Linux and Unix-like operating systems that loads the kernel directly from a disk address stored at install time, without requiring filesystem driver support during the boot sequence. It operates at the pre-OS stage — either from the Master Boot Record (MBR) or a partition boot sector — and passes CPU control to the Linux kernel after loading it into memory.

For most production systems today, LILO has been superseded by GRUB2. However, understanding its internals remains essential for engineers maintaining legacy infrastructure, embedded systems, or air-gapped servers where a minimal, deterministic bootloader is a deliberate architectural choice.

How the LILO Boot Process Works at a Low Level

When a machine powers on, the BIOS executes POST (Power-On Self-Test), then reads the first 512 bytes of the bootable disk — the MBR. If LILO is installed there, those 512 bytes contain LILO's first-stage loader. The sequence unfolds as follows:

1. Stage 1 (MBR code): The BIOS loads 512 bytes from the MBR into memory at address `0x7C00` and transfers execution to it. This tiny stub knows only one job: locate and load Stage 2.
2. Stage 2 (map file): LILO reads its map file (`/boot/map`), which was written at install time by the `lilo` command. This map contains the absolute disk block addresses of every kernel image and chain-loader entry. No filesystem parsing occurs here — LILO uses raw LBA/CHS sector addresses.
3. Boot menu presentation: If `prompt` is set in `lilo.conf`, LILO displays a text menu. The `timeout` directive controls how long it waits before defaulting.
4. Kernel load: LILO reads the kernel image from the precomputed disk addresses into low memory, then decompresses and relocates it.
5. Control handoff: LILO passes the kernel command-line parameters and initial RAM disk (`initrd`) location to the kernel, which takes over hardware initialization.

Critical architectural implication: Because LILO encodes absolute disk block addresses at install time, any change to the kernel file, partition layout, or `lilo.conf` requires re-running `/sbin/lilo` to regenerate the map. Forgetting this step after a kernel update is the single most common cause of LILO boot failures.

LILO Configuration: A Deep Dive into `/etc/lilo.conf`

LILO is configured entirely through `/etc/lilo.conf`. Below is a production-representative example with annotations covering options the original documentation frequently omits:

“`ini

Global section

boot=/dev/sda # Install LILO to the MBR of /dev/sda

map=/boot/map # Path to the map file (must be on a non-LVM, non-RAID partition)

install=/boot/boot.b # Second-stage boot loader binary

prompt # Always show the boot menu

timeout=100 # Wait 10 seconds (units are 1/10th of a second)

default=linux-stable # Default entry label

lba32 # Enable LBA32 addressing — critical for disks > 8 GB

compact # Merge adjacent read requests; speeds up boot on HDD

Linux kernel entry

image=/boot/vmlinuz-5.4.0

label=linux-stable

initrd=/boot/initrd.img-5.4.0

root=/dev/sda1

read-only # Mount root read-only initially; fsck runs before remount rw

append="quiet splash"

Fallback kernel entry

image=/boot/vmlinuz-4.19.0

label=linux-fallback

initrd=/boot/initrd.img-4.19.0

root=/dev/sda1

read-only

Chain-load Windows from a second partition

other=/dev/sda2

label=windows

table=/dev/sda # Partition table to pass to the Windows bootloader

“`

After every edit, apply changes with:

“`bash

sudo /sbin/lilo -v

“`

The `-v` flag enables verbose output, showing each kernel and chain-loader entry being mapped. Always verify the exit code — a non-zero return means the map was not written successfully.

Frequently Missed Configuration Parameters

• `lba32`: Without this directive on disks larger than 8 GB, LILO falls back to CHS addressing and will fail to locate kernels beyond the 8 GB boundary. This is a silent failure mode that has caused countless production outages on legacy hardware.
• `compact`: Reduces boot time on spinning disks by coalescing adjacent sector reads. Incompatible with some floppy-boot scenarios.
• `vga=`: Passes a video mode parameter to the kernel. Useful for headless servers where you want a specific framebuffer resolution in the console.
• `append=`: Passes arbitrary kernel command-line parameters. Equivalent to GRUB's `linux` line arguments.
• `password=`: Restricts booting a specific entry with a password. Note that this password is stored in plaintext in `lilo.conf`, so file permissions (`chmod 600`) are mandatory.

LILO Installation Scenarios

Installing to the MBR

“`bash

Verify the target device

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

Install LILO to MBR of /dev/sda

sudo /sbin/lilo -b /dev/sda

“`

Installing to a Partition Boot Sector

When using a boot manager like System Commander, you may want LILO on a partition's boot sector rather than the MBR:

“`ini

boot=/dev/sda1 # Install to partition boot sector, not MBR

“`

This is also the correct approach when LILO is being chain-loaded by another bootloader.

Removing LILO

To restore the original MBR (e.g., before replacing with GRUB):

“`bash

Overwrite MBR with a generic boot sector, preserving the partition table

sudo dd if=/usr/lib/syslinux/mbr/mbr.bin of=/dev/sda bs=440 count=1

“`

Never use `dd if=/dev/zero` on the full MBR — it will destroy the partition table.

LILO vs. GRUB: Technical Comparison

The following table covers the dimensions that matter most to a systems administrator choosing between the two, including several nuances absent from most comparisons:

Verdict for production systems: GRUB2 is the correct choice for any system running a kernel newer than approximately 3.x, using GPT, UEFI, LVM, or software RAID. LILO's value proposition today is limited to embedded or legacy environments where its deterministic, filesystem-agnostic loading model is an asset rather than a liability.

When LILO Is Still the Right Tool

Despite its age, LILO remains appropriate in specific scenarios:

• Embedded Linux systems where the bootloader footprint must be under 32 KB and the kernel location never changes.
• Legacy hardware (pre-2000) where GRUB2 modules exceed available memory or the BIOS has compatibility issues with GRUB's stage loading.
• Forensic and recovery environments where a known-good, minimal bootloader is preferable to a complex one with scripting capabilities.
• Air-gapped systems where the simplicity and auditability of LILO's flat configuration model reduces the attack surface.
• Educational purposes — LILO's source code and boot sequence are significantly simpler than GRUB2, making it an excellent subject for OS internals courses.

For any modern deployment — whether you are provisioning a VPS Hosting environment, configuring a Dedicated Server, or setting up a development stack on Shared Web Hosting — GRUB2 is the default and correct bootloader choice.

Common LILO Failure Modes and Diagnostics

Understanding LILO's error codes is critical for recovery. LILO prints a partial string of `LILO` during boot to indicate progress:

Recovery Procedure

If LILO fails to boot after a kernel update:

1. Boot from a live CD or rescue environment.
2. Mount the root partition: `mount /dev/sda1 /mnt`
3. Chroot: `chroot /mnt`
4. Verify `/etc/lilo.conf` points to the correct kernel path.
5. Re-run: `/sbin/lilo -v`
6. Reboot.

If the map file itself is corrupt, you may need to reinstall the `lilo` package to restore `/boot/boot.b` before re-running the command.

Security Considerations

LILO predates modern firmware security models and has several important limitations:

• No Secure Boot support: LILO cannot participate in the UEFI Secure Boot chain of trust. On systems where firmware integrity verification is required, GRUB2 with a signed shim is mandatory.
• Password protection weaknesses: The `password=` directive in `lilo.conf` stores credentials in plaintext. Restrict file permissions strictly (`chmod 600 /etc/lilo.conf`, owned by root).
• Physical access vulnerability: Without a BIOS/UEFI password, an attacker with physical access can boot from external media and bypass LILO entirely.
• No TPM integration: LILO cannot perform measured boot or interact with a TPM for attestation, unlike GRUB2 with appropriate modules.

For servers where disk encryption, measured boot, or remote attestation is part of the security architecture — such as a VPS with cPanel or a hardened Dedicated Server — these limitations make LILO unsuitable.

Migrating from LILO to GRUB2

If you are maintaining a legacy system still running LILO and need to migrate:

“`bash

1. Install GRUB2

sudo apt-get install grub2 # Debian/Ubuntu

sudo yum install grub2-tools # RHEL/CentOS

2. Install GRUB2 to MBR

sudo grub-install /dev/sda

3. Generate GRUB configuration

sudo update-grub # Debian/Ubuntu

sudo grub2-mkconfig -o /boot/grub2/grub.cfg # RHEL/CentOS

4. Verify the new configuration

sudo grep -i menuentry /boot/grub/grub.cfg

5. Reboot and confirm GRUB2 loads

sudo reboot

“`

Do not remove the `lilo` package until you have confirmed GRUB2 boots successfully. Keep a live rescue USB available during the migration.

If your server uses VPS Control Panels that interact with the bootloader (e.g., for kernel switching or rescue mode), verify panel compatibility with GRUB2 before migrating.

Key Technical Takeaways: Decision Matrix

Use this checklist to determine whether LILO is appropriate for your environment:

Use LILO if:

• The system uses a BIOS (not UEFI) firmware
• The disk uses MBR partition table (not GPT)
• The kernel and partition layout are static and rarely change
• Bootloader footprint must be minimized (embedded systems)
• You are studying boot sequence internals for educational purposes

Do not use LILO if:

• The system uses UEFI firmware (LILO is incompatible)
• The disk uses GPT partitioning
• Kernels are updated regularly via package manager
• You require Secure Boot, TPM attestation, or measured boot
• The system uses LVM, software RAID, or Btrfs for the root filesystem
• You need interactive boot parameter editing for troubleshooting
• The system is internet-facing or subject to security compliance requirements

Operational rule: Any time you edit `/etc/lilo.conf` or update a kernel on a LILO-managed system, running `/sbin/lilo -v` is not optional — it is as mandatory as the edit itself. Automate this with a post-install kernel hook if your package manager supports it.

Frequently Asked Questions

What happens if I update the Linux kernel on a LILO system without running `/sbin/lilo`?

LILO's map file still points to the old kernel's disk block addresses. The system will boot the previous kernel as if the update never happened — or, if the old kernel image was overwritten in place, it will load corrupted data and panic. Always run `/sbin/lilo -v` immediately after any kernel update.

Can LILO boot from a GPT-partitioned disk?

Not reliably. LILO was designed for MBR partition tables. GPT disks use a protective MBR that technically allows LILO installation, but LILO has no awareness of GPT partition entries and cannot reliably locate partitions beyond the first four. Use GRUB2 for any GPT disk.

Is LILO compatible with UEFI systems?

No. LILO is a BIOS-era bootloader with no EFI application support. On UEFI systems, the firmware expects a PE-format `.efi` binary in the EFI System Partition. LILO cannot provide this. GRUB2, systemd-boot, or rEFInd are the correct choices for UEFI.

What is the difference between LILO's `timeout` value and actual seconds?

The `timeout` directive is measured in tenths of a second. A value of `50` equals 5 seconds, `100` equals 10 seconds. This is a common misconfiguration — administrators expecting a 50-second timeout who set `timeout=50` will get a 5-second window instead.

Can LILO boot from LVM or software RAID volumes?

No. Because LILO resolves kernel locations to absolute disk block addresses at install time, it cannot handle the abstraction layers introduced by LVM or MD RAID. The `/boot` partition must reside on a plain partition directly accessible by the BIOS. This is one of the primary architectural reasons GRUB2 replaced LILO in modern Linux distributions.