Table of Contents
Legacy BIOS and Modern UEFI
In a Linux context, understanding the difference between BIOS and UEFI is essential because it directly affects how your system starts, how disks are partitioned, how bootloaders such as GRUB are installed, and how you troubleshoot boot problems. This chapter focuses only on the firmware layer that runs before the operating system, not on GRUB or the kernel loading details, which are covered elsewhere.
What Firmware Does Before Linux Starts
Every PC has low level firmware that powers on the hardware, performs basic checks, and then finds something bootable on a disk or other device. That firmware is either traditional BIOS, also called legacy BIOS, or UEFI, which is its modern successor.
The firmware runs from non volatile memory on the motherboard. When you power on the machine, it initializes the CPU, memory and essential devices, then looks at a boot order configuration and hands control to a bootloader on one of the selected devices. That handoff point, and where the bootloader is stored, are where BIOS and UEFI differ most.
Legacy BIOS: Characteristics and Limitations
Legacy BIOS is the older firmware model originating from the early IBM PC era. It follows a very simple boot process that assumes a disk with an MBR partition table and a specific structure in the first sectors of the disk.
Under BIOS, the firmware looks at the selected boot device, reads the very first sector of the disk, the Master Boot Record, and executes the small boot program located there. This program then continues the boot chain by loading more code from the disk, such as the rest of GRUB. BIOS does not understand filesystems. It only reads a fixed sector and jumps into whatever instructions are found there.
Because of its age, BIOS comes with several important limitations that affect Linux installations. The traditional MBR scheme supports only four primary partitions. To create more partitions, you must use extended and logical partitions. More importantly, BIOS plus MBR has a practical disk size limit of 2 TiB. Disks larger than this cannot be fully addressed by MBR. On very new hardware this restriction is unacceptable.
BIOS configuration interfaces are very basic. Many older systems only provide text based configuration screens with minimal options: boot order, basic SATA settings, some security and power management options. Secure boot, per device boot entries, and detailed graphical menus are normally not available in pure BIOS systems.
Linux still supports BIOS booting very well. On a BIOS system, installers will usually default to creating an MBR partition table on the boot disk and will install GRUB in the MBR. The default partitioning tools and bootloader options offered during installation differ when the firmware is BIOS instead of UEFI, and that is one of the most visible effects of this distinction for a Linux user.
UEFI: Design and Features
UEFI, the Unified Extensible Firmware Interface, is a modern firmware specification that replaces legacy BIOS with a more flexible and powerful environment. Instead of a single fixed boot sector, UEFI can read files on a special filesystem and execute them directly as programs.
The most important concept for Linux users is the EFI System Partition, commonly abbreviated as ESP. This is a small partition on the disk that contains bootloader binaries, typically using the FAT32 filesystem. UEFI knows how to read FAT formatted ESPs, can locate .efi programs within them, and can execute those programs as its boot targets. Unlike BIOS, UEFI does not depend on the MBR code; instead it stores boot entries in its own non volatile variables, each entry pointing to a specific .efi file on a specific ESP.
UEFI systems are normally used together with GPT partition tables. GPT removes the limitations of MBR and supports very large disks and many partitions. On a Linux UEFI system, it is standard to have at least one GPT partition of type EFI System Partition that is mounted inside Linux, usually at /boot/efi.
UEFI also standardizes a richer pre boot environment. Many UEFI implementations provide a graphical setup interface, a built in boot menu that shows all detected bootloaders, configurable per device boot entries, and additional options such as secure boot control and firmware update mechanisms. Some vendors even allow firmware updates directly from within the UEFI interface using files stored on a USB drive, which is separate from Linux level update mechanisms.
From a Linux perspective, bootloaders on UEFI systems are regular .efi binaries stored as files on the ESP. GRUB, systemd boot and other loaders all place their binaries on the ESP. This design makes multi boot scenarios more flexible since multiple operating systems can each have their own bootloader file on the same ESP and individual entries in the UEFI boot menu.
BIOS vs UEFI: Practical Differences for Linux
For a Linux user installing or managing systems, BIOS and UEFI differ in several practical ways: how you partition disks, where the bootloader lives, and how the firmware chooses what to start.
On a BIOS system, the primary boot target is always the code in the MBR of the boot disk. The bootloader is installed into the beginning of the disk, and the partitioning scheme is often MBR. Tools like fdisk will show an MBR style layout and there is no requirement for an EFI System Partition. During a Linux installation, if the firmware is detected as BIOS, installers will suggest creating typical BIOS style partitions such as a root partition and optionally a separate /home, with no ESP.
On a UEFI system, a GPT layout is common and an ESP is mandatory if you want to boot via UEFI. Installers will detect UEFI mode and either reuse an existing ESP or create a new one, frequently around 100 to 550 MiB in size, formatted as FAT32 and mounted at /boot/efi. The bootloader is then installed as a .efi file under a directory such as /EFI/grub or /EFI/<distribution>. The UEFI firmware retains a boot entry that points to this file, and the firmware boot menu will list it by name.
UEFI also provides a standardized variable store that Linux tools can access. On a running Linux system in UEFI mode, commands like efibootmgr let you inspect and modify UEFI boot entries. This is not available on pure BIOS systems. If you run efibootmgr and receive an error that EFI variables are not supported, the system is either in BIOS mode or the necessary EFI variables filesystem is not available.
Another important difference is how external media boot. On a BIOS system, a bootable USB stick simply needs a proper MBR with boot code and a bootable partition containing whatever bootloader you want. On a UEFI system, the USB must contain an ESP or similar FAT partition with a proper .efi bootloader placed under /EFI/BOOT/ with a standardized name such as BOOTX64.EFI. Most Linux live images accommodate both BIOS and UEFI on the same media, but knowing which firmware path is actually being used is crucial when troubleshooting.
In day to day use, a running Linux system behaves similarly regardless of whether it started under BIOS or UEFI. However, disk layout, bootloader location, and how boot entries are managed are different. When you perform actions such as reinstalling GRUB, migrating to a new disk, or creating a dual boot configuration with another operating system, you must take into account whether the system is using BIOS or UEFI.
Secure Boot and UEFI
One of the most visible features associated with UEFI is secure boot. Secure boot is a UEFI specification feature that allows the firmware to verify the digital signatures of bootloaders and certain other pre boot components before executing them. In theory, this prevents unauthorized or tampered code from running during early boot.
On many consumer systems, secure boot is enabled by default. Linux distributions that support secure boot provide signed bootloaders and, sometimes, signed kernel images. During installation, if secure boot is enabled, the installer will choose an arrangement that keeps the boot chain valid under secure boot. Some distributions also provide small shim loaders, which are signed by keys accepted by the firmware and which then verify and load the real bootloader.
For users who want full control or for some custom setups, secure boot can complicate matters, because unsigned or self built bootloaders will not run unless appropriate keys are enrolled or secure boot is disabled through the firmware setup interface. Understanding that secure boot is a UEFI only feature and that it operates before Linux begins helps in recognizing why certain custom kernels or bootloaders may fail to start on UEFI systems with secure boot turned on.
Secure boot enforcement depends on UEFI. If secure boot is enabled, only bootloaders and kernels signed with keys trusted by the firmware will execute. Unsigned or improperly signed Linux boot components will fail to start until secure boot is disabled or the correct keys are enrolled.
Compatibility Support Module (CSM) and Mixed Modes
Many motherboards that support UEFI also include a Compatibility Support Module, often labeled CSM, that emulates legacy BIOS behavior. When CSM is enabled, the firmware can boot in a BIOS like mode from devices that expect an MBR and a traditional boot sector.
This leads to mixed configurations where a system with UEFI capable firmware actually boots Linux through the BIOS compatibility layer. In such a scenario, there may be a GPT disk but the bootloader is installed as if the system were BIOS, or an MBR disk is used even though UEFI and GPT would be more appropriate. Dual boot setups with older operating systems can prompt users to enable CSM, which then changes how Linux must be installed.
For Linux administrators, it is critical to know whether the current boot used native UEFI or CSM. A common symptom of confusion is that a disk with an ESP and UEFI configured bootloader will not appear in the firmware boot menu when CSM only booting is enabled, or that tools like efibootmgr fail because the system is running in legacy mode. Inspecting the firmware setup screens and testing efibootmgr from Linux are standard ways to verify this mode.
A consistent configuration uses either pure UEFI with GPT and an ESP, or pure BIOS with MBR style boot and a BIOS aware bootloader. Mixed and hybrid setups often work, but they are prone to boot issues when disks are moved between machines, when firmware settings are changed, or when additional operating systems are installed.
How to Tell Which One You Are Using
On a running Linux system, you can usually determine whether the system booted via BIOS or UEFI by checking for specific filesystems and tools. UEFI systems expose firmware variables through a special filesystem, usually mounted at /sys/firmware/efi. If this directory exists and contains entries, the machine is almost certainly running in UEFI mode. If the directory is missing or empty, the system is usually in BIOS mode.
Another approach is to run lsblk or fdisk -l and check the partition table type and the presence of an EFI System Partition. A disk labeled as GPT with a small FAT32 partition of type EFI System Partition is a strong indication of UEFI usage, although you must still confirm the actual boot mode. The efibootmgr command provides a direct view into UEFI boot entries. If it runs successfully and lists a boot order and multiple Boot#### entries, the system is using UEFI. If it fails due to missing EFI variables, the system is operating in BIOS mode.
From the firmware side, entering the pre boot configuration screen at startup and looking at the interface often gives clues. Systems that show graphical interfaces, explicit UEFI labels, and per entry boot selections often use UEFI. Options such as secure boot toggle, per drive UEFI or legacy selection, and configurable boot entries are characteristic of UEFI. Very old hardware with only text based BIOS setup and no mention of UEFI is almost always legacy only.
Recognizing which firmware mode is in use is an essential first step when planning Linux installations, troubleshooting boot failures, or migrating disks. It determines whether you work with MBR based boot sectors and BIOS oriented GRUB installations, or with GPT, an ESP, and UEFI boot entries managed by tools such as efibootmgr.