VMware ESXi and vSphere Cluster Management

Alternative Linux Boot Loaders: ISOLINUX, LILO, ELILO, systemd-boot, rEFIt, and rEFInd

Compare Linux boot loader and boot manager alternatives to GRUB, including BIOS and UEFI compatibility, use cases, configuration models, maintenance status, and safety considerations.

GRUB is a common Linux boot loader and boot manager, but it is not the only option. ISOLINUX, LILO, ELILO, systemd-boot, rEFIt, and rEFInd were designed for different firmware environments and startup tasks. Some load Linux directly, some select between operating systems, and some are mainly associated with live or installation media.

This lesson separates those roles, explains BIOS and UEFI compatibility, and provides selection guidance for older computers, modern UEFI systems, and multiboot installations.

What happens when Linux starts?

Firmware is the software built into a computer or virtual machine that initializes hardware and begins the boot process. Traditional PCs use BIOS, while modern PCs generally use UEFI. EFI is the closely related firmware and executable environment used by UEFI and by some older systems.

A boot loader is software that firmware launches to load a Linux kernel or hand off startup to another boot component. A boot manager presents or chooses boot targets. It may chainload another loader, launch an EFI application, or start a compatible Linux kernel itself.

Chainloading means starting one boot program from another. For example, a boot manager might offer a Windows EFI loader, a Linux loader, and a recovery loader as separate choices.

  1. Firmware initializes the machine and selects a boot path.
  2. BIOS loads boot code from a disk boot sector or compatible disk area. UEFI loads an EFI executable, normally from the EFI System Partition.
  3. A boot manager may display choices such as Linux, Windows, or recovery tools.
  4. A boot loader loads the Linux kernel and supplies its kernel command-line options.
  5. The loader also loads the initramfs, or initial RAM filesystem. This temporary root filesystem contains early userspace tools and drivers needed to find and mount the real root filesystem.
  6. The kernel starts the main operating-system userspace.

BIOS, UEFI, and the EFI System Partition

Legacy BIOS booting and UEFI booting use different disk layouts and boot-entry mechanisms. BIOS normally executes boot code from a disk's boot area and does not use EFI executable files. UEFI searches for EFI executable files and can store selections in firmware variables called NVRAM boot entries.

The EFI System Partition (ESP) is a FAT-formatted partition containing UEFI boot files. It commonly contains directories such as EFI/Linux, EFI/Microsoft, or EFI/Boot, but exact names depend on the operating system and tool.

  • A BIOS installation needs BIOS-compatible boot code and a BIOS-compatible loader.
  • A UEFI installation needs an ESP, suitable EFI executables, and usually a firmware boot entry or a recognized fallback path.
  • Installing a BIOS loader does not automatically create a UEFI boot entry.
  • Booting the installation medium in BIOS mode and installing in UEFI mode, or doing the reverse, can produce a confusing or unusable setup.

Before changing boot software, determine how the installed Linux system was started. On a running Linux system, the presence of the firmware variables interface is a useful indication:

if [ -d /sys/firmware/efi ]; then
    echo "Booted in UEFI mode"
else
    echo "Booted in legacy BIOS mode"
fi

UEFI boot-entry tools generally work only when Linux itself was booted in UEFI mode and the firmware exposes writable variables. To inspect existing entries, use:

sudo efibootmgr -v

The output depends on firmware support and administrator permissions. Do not assume that a successful command means every firmware implementation will display entries identically.

ISOLINUX and the SYSLINUX family

SYSLINUX is a family of lightweight boot loaders for several media and filesystem situations. Related components have been used for hard disks, network booting, and different filesystem or removable-media workflows.

ISOLINUX is the SYSLINUX-family component traditionally associated with booting Linux from ISO 9660 images, optical discs, and bootable installation or live media. It is commonly encountered inside a Linux installer image rather than as the boot loader of an already-installed desktop or server.

This distinction matters. A live ISO needs boot structures that firmware or an optical-drive BIOS path can understand, along with a way to locate the compressed live filesystem and kernel. An installed system has persistent partitions, an installed kernel, and firmware or disk boot entries that must be maintained over time.

ISOLINUX is principally associated with legacy BIOS-style ISO boot paths. A modern image may also contain a separate UEFI boot path, so the presence of ISOLINUX does not by itself tell you that the complete image is BIOS-only.

Example: choosing a live or installer image

If you are creating or examining a traditional Linux installation ISO, ISOLINUX may be the component that presents the initial “Try,” “Install,” or rescue menu for BIOS booting. That is a media-boot decision, not necessarily a recommendation for the boot loader on the installed disk.

LILO

LILO means Linux Loader. It was historically a widespread Linux boot loader and remains important for understanding older Linux installations. LILO targets legacy BIOS systems rather than UEFI systems.

LILO uses a configuration-and-install model. Its configuration describes kernels, root devices, boot options, and other targets. The installer then writes boot code and the required disk-sector mappings. Editing the configuration file alone does not normally update what the boot sector will use.

boot=/dev/sda
prompt
timeout=50

image=/boot/vmlinuz-old
    label=linux-old
    root=/dev/sda2
    read-only
    initrd=/boot/initramfs-old.img

The stanza above is conceptual and is not a universal modern distribution configuration. After validating the configuration and target disk, the historical workflow required rerunning the LILO installation or update command, commonly:

sudo lilo

If a configuration change has no effect, check both whether LILO was rerun and whether the machine is actually booting through LILO. Modern distributions may not package or support LILO, and its BIOS-only design makes it a poor choice for a new UEFI-based installation.

ELILO

ELILO means EFI Linux Loader. It was a conceptual EFI counterpart to LILO: a relatively direct loader for starting Linux in an EFI environment.

ELILO had a historical role in early EFI Linux booting, before newer UEFI boot managers and distribution integration became more common. It is now legacy or limited-maintenance software. Distribution packaging, architecture support, Secure Boot support, and documentation may be incomplete or absent.

Check current distribution support before selecting ELILO. Its historical importance does not make it a generally suitable default for a new UEFI installation.

gummiboot and systemd-boot

gummiboot was a minimal, text-oriented EFI boot manager. It became part of the systemd project and is now known as systemd-boot. Current documentation and packages generally use the systemd-boot name.

systemd-boot is UEFI-only. It reads simple loader entry files, commonly following the Boot Loader Specification style. Entries describe a title, a Linux kernel path, an optional initramfs path, and kernel options. The EFI executable and entry files are normally placed on the ESP or in another arrangement accessible to the firmware and supported by the selected setup.

A conceptual layout might look like this:

ESP/
├── EFI/
│   └── systemd/
│       └── systemd-bootx64.efi
└── loader/
    ├── loader.conf
    └── entries/
        └── linux.conf

Example loader.conf:

default linux.conf
timeout 4

Example entry:

title   Linux
linux   /vmlinuz-linux
initrd  /initramfs-linux.img
options root=UUID=example-root ro quiet

The paths are examples, not a distribution-specific installation recipe. The kernel and initramfs must actually exist at the referenced locations, and the root identifier and options must match the installation.

systemd-boot is a good fit for a straightforward UEFI Linux system that needs a simple menu and direct entries, including setups using unified kernel images. It is less suitable when you need extensive scripting, unusual filesystems, or broad legacy BIOS compatibility.

rEFIt

rEFIt was a graphical EFI boot manager. It presented available EFI boot options and allowed users to launch them from a visual menu, particularly on older EFI-based systems.

rEFIt is no longer actively developed. It is mainly relevant as historical background and as the predecessor to rEFInd. New deployments should not select it without a compelling compatibility reason and a clear recovery plan.

rEFInd

rEFInd is an actively maintained fork and successor of rEFIt. It provides a graphical UEFI boot-selection interface and can automatically discover EFI boot loaders and, in suitable configurations, compatible Linux kernels.

Common rEFInd menus may include Linux, Windows, macOS, recovery tools, and separate EFI loaders. rEFInd is primarily a boot manager. It may chainload another loader, such as a distribution-provided EFI loader, or directly start a compatible Linux kernel.

Its configuration is commonly controlled by a file such as refind.conf. Automatic scanning is convenient, while manual menu stanzas provide deliberate entries when discovery does not produce the desired result.

# Conceptual rEFInd configuration ideas
scanfor internal,external,manual
# A manual stanza can identify a loader or a kernel explicitly.

A direct kernel entry and a chainloaded entry are different. A direct entry names the Linux kernel and usually its initramfs and options; a chainloaded entry starts another EFI loader, which then performs the kernel selection or loading.

Comparison of the alternatives

ISOLINUX
Type: media boot loader
Firmware: traditionally BIOS-oriented ISO boot; a complete image may also provide a separate UEFI path
Interface: text-based live or installer menu
Use case: bootable ISO, optical, live, and installation media
Status: established SYSLINUX-family component with a specialized role
Limitation: not normally the persistent loader for an installed system

LILO
Type: boot loader
Firmware: legacy BIOS only
Interface: text menu or direct selection
Use case: historical installed Linux systems on BIOS machines
Status: historical and limited on modern distributions
Limitation: configuration changes require rerunning the installer; unsuitable for UEFI

ELILO
Type: EFI boot loader
Firmware: EFI/UEFI only
Interface: simple loader selection
Use case: historical EFI Linux booting
Status: legacy or limited maintenance
Limitation: verify current package, architecture, firmware, and Secure Boot support

gummiboot / systemd-boot
Type: UEFI boot manager with direct loader capability
Firmware: UEFI only
Interface: minimal text-oriented menu
Use case: simple UEFI Linux systems and loader-entry or unified-kernel-image workflows
Status: systemd-boot is the current name and maintained successor
Limitation: narrow scope compared with feature-rich boot managers; no BIOS mode

rEFIt
Type: boot manager
Firmware: EFI/UEFI only
Interface: graphical
Use case: historical EFI multiboot selection
Status: discontinued
Limitation: not actively developed; predecessor to rEFInd

rEFInd
Type: graphical boot manager with optional direct kernel launching
Firmware: UEFI only
Interface: graphical discovery and selection menu
Use case: Linux, Windows, macOS, and multiple EFI-loader multiboot systems
Status: actively maintained fork and successor of rEFIt
Limitation: automatic discovery depends on file locations, scan settings, kernel compatibility, and Secure Boot trust

Selection guide by scenario

Live or installation ISO media
Appropriate option: ISOLINUX for a traditional BIOS-oriented ISO path
Why: it is designed for ISO and bootable-media workflows
Caveats: confirm whether the image also supports UEFI; media boot behavior is separate from the installed system's boot loader

Legacy BIOS-only Linux computer
Appropriate option: LILO for a historical or specially maintained system
Why: it is a BIOS-oriented Linux loader
Caveats: configuration edits require reinstalling or updating LILO; current distribution support may be missing

Minimal UEFI Linux installation
Appropriate option: systemd-boot
Why: it offers a small menu and simple entry files for direct UEFI booting
Caveats: an ESP and correct UEFI boot entry are required; it does not provide BIOS compatibility

UEFI multiboot with graphical selection
Appropriate option: rEFInd
Why: it can discover and display Linux, Windows, macOS, and other EFI loaders
Caveats: automatic scanning may need adjustment, and rEFInd may be selecting another loader rather than loading Linux itself

Historical or legacy EFI environment
Appropriate option: ELILO or rEFIt only when existing compatibility requirements demand it
Why: both explain older EFI boot arrangements
Caveats: maintenance, package availability, architecture, and Secure Boot support must be checked before deployment; newer supported alternatives are usually safer

Safety, Secure Boot, and recovery planning

Replacing boot software can make an installed system temporarily unbootable. Common causes include using the wrong firmware mode, placing an EFI executable outside the ESP, selecting the wrong partition, losing a firmware boot entry, or referencing an incorrect kernel path.

  • Confirm whether the installed system currently boots through BIOS or UEFI before changing components.
  • Identify and mount the correct ESP when working with UEFI. Do not assume that every FAT partition is the ESP.
  • Inspect existing UEFI entries before modifying them.
  • Keep recovery or installation media available.
  • Retain at least one known-working EFI boot entry until the replacement has been tested.
  • Verify distribution packaging, project maintenance, CPU architecture, firmware behavior, and Secure Boot requirements.

Secure Boot is a UEFI signature-verification feature. It can prevent an unsigned or untrusted EFI binary, boot manager, chainloaded component, or kernel from launching. A Secure Boot error may mean that the selected program is not signed by a trusted authority or does not match the configured trust policy.

When Secure Boot is enabled, use a trusted signed boot path supported by the distribution, or change firmware policy only after understanding the security consequences. A boot manager that works with Secure Boot disabled may fail immediately when it is enabled.

Troubleshooting common failures

A UEFI boot manager does not appear in firmware options

  • Confirm that the system is currently booted in UEFI mode.
  • Check that an ESP is mounted and contains the expected EFI files.
  • Inspect NVRAM entries with sudo efibootmgr -v when running under UEFI.
  • Check whether firmware expects a fallback path or a particular architecture-specific filename.

The firmware reports a Secure Boot signature error

  • Check the current Secure Boot state.
  • Determine whether the EFI boot manager and kernel are signed and trusted by the firmware.
  • Check whether a chainloaded component has a compatible signature.
  • Use the distribution's supported signed path, or change trust settings only with full awareness of the security implications.

A LILO configuration change has no effect

  • Verify that the machine is actually booting through LILO.
  • Validate the disk and partition targets.
  • Rerun the appropriate LILO installation or update process after editing its configuration.

rEFInd does not show a Linux installation

  • Inspect whether the kernel or another EFI loader is located where rEFInd scans.
  • Check whether automatic scanning is disabled or filtered.
  • Confirm that the boot files are available on the ESP or another accessible filesystem.
  • Add a deliberate manual entry when automatic discovery is unsuitable.

A bootable ISO does not start on a modern machine

  • Check whether the image contains a BIOS path, a UEFI path, or both.
  • Confirm that the firmware boot mode matches the capabilities of the image.
  • Check removable-media boot settings and recreate the image with a current process that preserves its intended boot structures.

Key takeaways

  • ISOLINUX is mainly associated with traditional Linux ISO, live, and installation media.
  • LILO is a historically important BIOS-only loader whose changes require rerunning its installer.
  • ELILO is an older EFI counterpart to LILO and should be considered legacy unless current support is verified.
  • gummiboot became systemd-boot, a minimal UEFI boot manager based on simple loader entries.
  • rEFIt is a discontinued graphical EFI manager; rEFInd is its actively maintained successor.
  • rEFInd is primarily a graphical boot manager and can either chainload another EFI loader or directly start a compatible Linux kernel.
  • Firmware mode, ESP layout, firmware entries, Secure Boot, architecture, and distribution support all affect whether a choice is appropriate.

For broader context, compare these tools with the usual Linux baseline in this alternative boot loader reference.