Table of Contents
Historical context and roles in the boot process
BIOS and UEFI are firmware interfaces that run before your operating system. In the overall boot sequence, they handle:
- Hardware initialization (CPU, memory, basic chipset)
- Finding a bootable device (disk, USB, network)
- Loading the first-stage OS loader (e.g., GRUB, Windows Boot Manager)
- Passing control to that loader
BIOS (Basic Input/Output System) is the older, legacy standard dating back to the early PC era. UEFI (Unified Extensible Firmware Interface) is its modern replacement, designed to overcome BIOS limitations.
On most modern hardware, you will see “UEFI firmware” rather than true legacy BIOS, although many UEFI systems can emulate BIOS for compatibility (“Legacy boot” / “CSM”).
Core architectural differences
Firmware location and structure
- BIOS:
- Stored in ROM/flash on the motherboard.
- Uses 16‑bit real mode at startup, with strong compatibility constraints.
- Very limited extensibility; OEM-specific options, but not a clean modular standard.
- UEFI:
- Also stored in flash, but:
- Uses 32‑bit or 64‑bit mode from the start.
- Organized into drivers and applications that follow a standardized interface.
- Supports “EFI applications” (like
grubx64.efi), which are normal executables by UEFI standards.
Boot device handling and boot path
- BIOS:
- Looks for a boot device according to the configured order (disk, CD, USB, etc.).
- Reads the first 512 bytes of the boot disk: the Master Boot Record (MBR).
- Executes boot code in the MBR, which typically:
- Loads a second-stage bootloader from fixed disk locations or a specific partition.
- No understanding of filesystems; only knows about sectors.
- UEFI:
- Understands partitions and some filesystems (FAT32 is mandatory).
- Looks for an EFI System Partition (ESP):
- A small FAT32 partition containing
.efifiles (bootloaders, drivers, tools). - Loads an EFI application (e.g.,
\EFI\GRUB\grubx64.efi) based on NVRAM boot entries. - Can also offer interactive selection of EFI boot applications.
This fundamental change—from “execute code at fixed disk offsets” to “load a file from a filesystem”—is one of the key distinctions.
Partitioning schemes: MBR vs GPT
BIOS and UEFI are closely tied to different partition table formats, though there is overlap.
- BIOS + MBR (traditional):
- Common on older PCs.
- MBR:
- Stored in the first sector of the disk (sector 0).
- Holds both:
- Bootloader stub (small piece of executable code).
- Partition table (up to 4 primary partitions).
- Limitations:
- Maximum 2 TiB disk size for standard setups.
- Only 4 primary partitions (extended/logical partitions used as a workaround).
- UEFI + GPT (modern):
- GPT (GUID Partition Table) is part of the UEFI spec, but can be used with BIOS in some setups.
- Advantages:
- Supports disks larger than 2 TiB.
- Many more partitions (often up to 128 by default).
- Redundant partition table copies and checksums for better robustness.
- Requires an EFI System Partition (ESP):
- Usually around 100–550 MB.
- FAT32.
- Contains bootloaders and EFI tools.
- Mixed setups:
- BIOS booting from GPT:
- Possible, but requires special handling (e.g., a small “BIOS boot partition” for GRUB’s second stage).
- UEFI booting from MBR:
- Technically allowed in the spec, but poorly supported and not recommended.
For modern Linux installations on contemporary hardware, the standard approach is: UEFI + GPT + ESP.
How GRUB and other bootloaders differ between BIOS and UEFI
Linux distributions usually use GRUB (or sometimes systemd-boot, rEFInd, etc.). Their behavior changes depending on firmware mode.
GRUB on BIOS
- Installed into:
- The MBR (first sector), plus:
- Additional sectors just after the MBR or a dedicated BIOS boot partition (on GPT disks).
- GRUB stages:
- Stage 1: very small, in MBR, jumps to:
- Stage 1.5/2: larger part of GRUB, knows how to read filesystems.
- Configuration:
- Typically in
/boot/grub/grub.cfg. - Firmware’s role:
- Only loads and jumps to the MBR code; all filesystem navigation etc. is done by GRUB.
GRUB on UEFI
- Installed as an EFI application:
- Example path on the ESP:
\EFI\ubuntu\grubx64.efi\EFI\fedora\shimx64.efi,\EFI\fedora\grubx64.efi, etc.- Firmware:
- Reads NVRAM boot entries (like “ubuntu”, “debian”, “fedora”).
- Loads the chosen
.efifile from the ESP. - GRUB’s configuration:
- Still in
/boot/grub/grub.cfg, but: - GRUB itself is an EFI program loaded from the ESP, not sector-based MBR code.
- No need for MBR boot code or BIOS boot partitions (in a pure UEFI/GPT setup).
Other UEFI-aware loaders and tools:
- systemd-boot:
- Simple UEFI boot manager that reads configuration from the ESP.
- rEFInd:
- GUI boot manager that can scan and chainload other EFI userspace bootloaders and kernels.
Secure Boot and firmware-level security
Secure Boot is a feature of UEFI, not BIOS. It affects how Linux boots in UEFI systems.
- Concept:
- Firmware validates the digital signature of EFI executables before running them.
- Only code signed with trusted keys (in firmware’s key database) can be loaded.
- On typical Linux installations:
- Distributions ship:
- A Microsoft-signed “shim” loader (
shimx64.efi) that is trusted by firmware. - Shim then verifies GRUB and the kernel using distribution-managed keys.
- Implications:
- Custom kernels or unsigned bootloaders will not boot unless:
- Secure Boot is disabled in firmware, or
- You enroll your own keys and sign your binaries.
- With BIOS:
- There is no Secure Boot; firmware simply jumps to MBR code.
- Any bootloader or OS that can be loaded from the MBR can run; security must be enforced at later stages (bootloader, OS).
Practical Linux installation differences
When installing Linux on modern hardware, you’ll often choose between BIOS/legacy and UEFI modes (sometimes implicitly, based on how you boot the installer).
Detecting firmware mode from a running Linux system
- UEFI:
- The directory
/sys/firmware/efiexists and is populated. - The command
efibootmgrworks and shows entries.
[ -d /sys/firmware/efi ] && echo "UEFI mode" || echo "Legacy BIOS mode"- BIOS (legacy):
/sys/firmware/efidoes not exist.efibootmgrtypically fails with “EFI variables are not supported on this system”.
Installation layout differences
- BIOS-style install (on MBR or GPT):
- No ESP required by BIOS itself.
- Typical partitions:
/(and optionally/home,swap).- If using GPT with BIOS:
- GRUB may require a small
bios_grubpartition (~1–2 MiB, unformatted), flagged appropriately. - UEFI-style install (usually on GPT):
- Requires an EFI System Partition (ESP), usually:
- 100–550 MB.
- FAT32, with the “EFI System Partition” flag.
- OS installer:
- Mounts ESP at
/boot/efi. - Installs bootloader under
/boot/efi/EFI/<distro>/. - Rest of partitions as usual (
/,/home,swap, etc.).
Dual-boot considerations (Linux + Windows)
- Mode consistency is crucial:
- Both systems must boot in the same mode (both UEFI or both BIOS) to avoid complex manual setup.
- On modern machines:
- Windows preinstalled systems use UEFI + GPT.
- You should install Linux in UEFI mode and reuse the existing ESP.
- Mixing:
- BIOS-booted Linux on a UEFI Windows disk (or vice versa) introduces complications:
- Different partitioning assumptions.
- Boot manager confusion.
- Hard to manage with single unified boot menu.
Configuration and troubleshooting aspects
Accessing firmware setup
On both firmware types you typically press a key at power-on (e.g., F2, Del, Esc, F10, F12). However, differences exist:
- BIOS:
- Simple text-based menus.
- Options mostly about boot order, basic hardware settings.
- UEFI:
- Often graphical menus, mouse support.
- Options include:
- Selecting boot entries by name (e.g., “ubuntu”, “Windows Boot Manager”).
- Enabling/disabling Secure Boot.
- Managing NVRAM boot order.
- Clearing or managing keys (for Secure Boot).
In some OS setups, you can also reboot directly into UEFI setup from within the OS (e.g., on Windows 8+; on Linux, some vendors provide utilities).
NVRAM boot entries and `efibootmgr` (UEFI only)
In UEFI, boot entries are stored in NVRAM. Linux uses efibootmgr to manage them:
- Show entries:
sudo efibootmgr- Add, delete, or reorder entries (details depend on your distribution and configuration; use with care).
These entries define:
- Which
.efifile to load. - In what order to try them.
If an entry is missing or points to a non-existent file, the system may fall back to default paths like \EFI\BOOT\BOOTX64.EFI on the ESP.
Typical boot problems related to BIOS/UEFI choice
Some common patterns (details of diagnosing/fixing belong in other chapters, but it helps to recognize that the firmware mode is involved):
- Installed in UEFI mode, but firmware set to legacy-only:
- System might not see the UEFI boot entry.
- Installed in legacy mode to an MBR disk, but firmware prefers UEFI:
- Disk may not appear as bootable when in pure UEFI-only mode.
- ESP deleted or corrupted:
- UEFI cannot find the bootloader; you might need to:
- Recreate the ESP.
- Reinstall the bootloader (e.g., via a live Linux USB).
- Converted disk from MBR to GPT without reinstalling bootloader correctly:
- Legacy BIOS boot may fail unless a BIOS boot partition is present and GRUB is reinstalled appropriately.
When and why to choose BIOS vs UEFI
On modern Linux systems:
- Prefer UEFI when:
- Your hardware supports it (almost all modern systems).
- You use large disks (> 2 TiB) or want many partitions.
- You dual-boot with Windows installed in UEFI mode.
- You want Secure Boot (even if just to keep OEM defaults).
- Stick with legacy BIOS mode only when:
- You have very old hardware without UEFI, or
- You need compatibility with an old OS/boot setup that can’t easily be migrated.
For new installations on contemporary machines, UEFI with GPT and an ESP is the default choice and integrates best with modern Linux boot setups and tools.