Understanding boot sequences in BIOS and UEFI

Understanding UEFI and BIOS: A Practical Guide for Linux Users

BIOS and UEFI do the same job in different ways, and most boot problems come from mixing those ways up. If a Linux install will not boot, the firmware mode is one of the first things to check.

The evolution of BIOS and UEFI

Historical context of BIOS

BIOS is old by computing standards. It boots machines using a simple sequence. The firmware runs a POST, initialises basic hardware, then reads the Master Boot Record on disk. The MBR hands control to a tiny bootloader. That model worked for decades. It also carries limits: 16-bit code, disk geometry assumptions, and the 2 TB barrier tied to MBR partitioning. Those quirks explain many legacy boot problems still seen today.

Introduction of UEFI

UEFI replaced BIOS as the modern firmware standard. It boots from a dedicated EFI System Partition formatted as FAT32. Firmware runs executable .efi files, not raw MBR code. UEFI supports GPT partitioning, larger disks, modular drivers in firmware, and a clearer mechanism for selecting boot entries. Secure Boot is part of the UEFI toolset. It checks signatures for boot components and aims to prevent unauthorised boot code.

Key differences between BIOS and UEFI

BIOS is procedural and limited. UEFI is modular and file-based. BIOS looks at MBR; UEFI reads the EFI partition and executes .efi binaries. Secure Boot is normally a UEFI feature. UEFI exposes variables you can change from the running system with tools like efibootmgr. For Linux installers, the main point is simple: match the installer mode to the firmware mode. Boot the installer in UEFI mode if you want an EFI install. Boot it in legacy mode if you want an MBR install. Mixing modes causes boot problems.

Boot sequence mechanics

How BIOS initializes hardware

BIOS does hardware initialisation with POST routines. It runs firmware-level checks and sets up minimal CPU and chipset state. It enumerates devices using legacy interrupt services and then looks for a bootable MBR on attached disks or removable media. Boot order is stored in firmware settings. If the bootloader in MBR is corrupt, BIOS has nothing else to run and the system stops at a boot error.

UEFI’s approach to hardware initialization

UEFI runs hardware setup in a more modular way. Drivers can be part of the firmware or loaded from the EFI partition. The firmware hands control to an .efi binary, such as a boot manager or direct loader. UEFI keeps a list of boot entries in NVRAM. That list points at file paths on the EFI System Partition. You can reorder entries from firmware menus or from Linux with efibootmgr. UEFI also supports network boot via EFI drivers in a cleaner way than legacy PXE on BIOS.

The role of bootloaders in the sequence

Bootloaders remain the bridge between firmware and kernel. In UEFI systems you usually install a bootloader into /boot/efi/EFI/<distro>/ like GRUB or systemd-boot. For Secure Boot, the bootloader often needs a signed shim. In legacy BIOS, GRUB writes to the MBR and expects to chainload its stage files from a filesystem. The practical rule is to know where the bootloader lives. If a system boots Windows Boot Manager instead of GRUB, the firmware is still following its boot order. Fix the order or reinstall the bootloader to the EFI partition.

Troubleshooting boot issues in BIOS and UEFI

Start with the firmware settings. Check boot order, secure boot state, and whether the firmware is in UEFI or legacy mode. Common fixes I use:

Reboot into firmware and confirm the USB appears as a UEFI device when installing an EFI system.
Disable Fast Boot and Fast Startup in Windows. They lock disks and confuse installers.
If using Secure Boot, either disable it for the install or use a signed shim. Linux Mint ships a signed shim that usually works, but older ISOs or custom kernels may not be signed.
Use a known-good tool to make the USB: Etcher for a straight write, or Ventoy if you want multiple ISOs on one stick. Pick GPT/FAT32 when making a UEFI-capable USB.
Boot a live USB and run efibootmgr to inspect NVRAM boot entries. Use it to reorder or create entries.
If GRUB fails to show, chroot from a live ISO and reinstall the bootloader to the correct target (EFI or MBR). For EFI installs, mount the EFI partition at /boot/efi and run grub-install --target=x86_64-efi.

Those steps clear most boot issues I run into.

Practical insights on Linux Mint installation

Linux Mint is friendly, but firmware settings still trip people up. I follow these rules for Mint installs:

Match installer mode to target mode. Boot the Mint USB in UEFI mode for an EFI install.
Create a 512 MB EFI System Partition, FAT32. Mount it at /boot/efi.
If Windows is present, avoid rewriting the Windows EFI entry. Use the installer to add Mint alongside Windows and let it register a new EFI entry. If Windows vanishes from the firmware list, use efibootmgr or the firmware menu to restore the order.
If the installer fails to boot after install, check Secure Boot and the presence of shimx64.efi in the EFI path. Mint usually installs shim, then grub, then the kernel.
For stubborn installs, use a live ISO, chroot into the installed system and run grub-install and update-grub.

If you created the USB with Ventoy and the firmware sees only a “partition 2” device, check the firmware’s USB boot menu. Some firmware exposes each partition separately. Select the UEFI entry that points to the Mint ISO.

User experiences and common challenges

I have seen the same pattern again and again. Someone makes a bootable USB, puts it first in boot order, hits a failure screen, and ends up back in Windows Boot Manager. That usually means the installer boot mode did not match the firmware mode, or Secure Boot blocked unsigned code. It also happens when the USB was made with the wrong partitioning scheme or the ISO was not written correctly.

People often decide Linux is too hard after one failed attempt. That is fair, but the fixes are mechanical. Confirm the USB boots in the mode you expect. Check Secure Boot. Confirm the installer can see the EFI System Partition. If you hit a failure screen, boot a live environment and inspect the disk layout before changing anything.

Takeaways

Match installer mode to firmware mode. Boot Mint in UEFI if you want an EFI install.
Use a proper EFI System Partition (512 MB, FAT32) and mount it at /boot/efi during install.
Check Secure Boot if components fail to load; use signed shims or disable Secure Boot temporarily.
Use efibootmgr and a live ISO to inspect and repair EFI entries rather than random changes in the firmware UI.

Fix the firmware, fix the boot. That gets rid of most of the usual Linux Mint install failures and boot issues.