Pick the wrong side of UEFI vs Legacy BIOS during an install and nothing warns you. The installer finishes fine, then the box says "no bootable device" the moment the USB stick comes out, or Windows quietly drops off the GRUB menu on a dual boot laptop. It's one firmware setting, and it decides how everything after it boots.
| What actually changes | How the firmware finds and starts your bootloader |
| Usual disk layout | Legacy boot with MBR, UEFI with GPT plus an EFI System Partition (ESP) |
| What to pick in 2026 | UEFI, unless the hardware simply can't do it |
| Two second check | ls /sys/firmware/efi exists = UEFI, missing = Legacy BIOS |
UEFI vs Legacy BIOS: The Short Answer
Both are firmware. They run before Linux is even in memory, and their real job is tiny: find a bootloader, hand over control, get out of the way. Legacy BIOS does it the 1980s way. It reads the first 512 bytes of a disk and runs whatever code sits there. No idea what a file or a filesystem is.
UEFI is closer to a mini operating system. It reads a FAT32 partition, loads the bootloader as an actual file (something like /EFI/ubuntu/shimx64.efi), and keeps a list of boot entries in NVRAM on the motherboard. That list is why Linux and Windows can sit side by side, each with its own loader, instead of fighting over one boot sector.
And on most hardware sold in the last decade, "Legacy" in the setup screen isn't a real BIOS anymore. It's the CSM (Compatibility Support Module), an emulation layer on top of UEFI. On beginner Linux subreddits the UEFI vs Legacy BIOS advice is pretty much unanimous: UEFI if supported, legacy if not. Several commenters point out that distros are slowly dropping legacy install paths, so picking it today is mostly picking future trouble.
Key Takeaway:
How UEFI vs Legacy BIOS Booting Actually Works
Most explanations stop at "UEFI is newer and faster." True-ish, but it won't help you fix a broken boot at 2 AM. What matters in UEFI vs Legacy BIOS on a Linux box is where the boot code physically lives, and who reads it.
What Legacy BIOS Does at Power-On
The BIOS runs POST, walks the boot order, and loads sector 0 of the chosen disk. That sector is the MBR: 446 bytes of boot code, a 64-byte partition table with room for 4 entries, and the 0x55AA signature. 446 bytes is way too small for GRUB, so GRUB tucks its next stage (core.img) into the gap right after the MBR. One disk, one boot sector, one loader. That's the whole design.
What UEFI Does Instead
UEFI reads the partition table, finds the EFI System Partition, mounts it as FAT32, and runs the .efi file named in its NVRAM boot entry. No entry that works? It falls back to /EFI/BOOT/BOOTX64.EFI, which is exactly how a USB installer boots on a machine that's never seen it. The full behaviour is in the UEFI specification if you like that kind of reading.
The Linux Boot Chain, Step by Step
- Firmware (UEFI or BIOS) initialises hardware and picks a boot device.
- On UEFI with Secure Boot on,
shimx64.efiloads first (signed by Microsoft's UEFI CA) and then checks GRUB's signature. - GRUB reads
grub.cfg, shows the menu, loads the kernel and initramfs. - The kernel mounts root and starts systemd as PID 1, which brings the box up to its default target. Our guide on systemd targets and boot modes picks up from right here.
Concept:
Boot mode and partition table are two separate things, and it's the most common UEFI vs Legacy BIOS mix-up out there. One Reddit thread has a commenter claiming UEFI means GPT and legacy means MBR, and getting corrected straight away. UEFI can boot an MBR disk, and legacy boot can boot a GPT disk if there's a tiny BIOS boot partition for GRUB. GPT is just the normal pairing with UEFI, not a hard rule.
How to Check If Linux Is Using UEFI or Legacy BIOS (Ubuntu and Rocky Linux)
These commands answer three questions: which mode the system booted in, what the disk layout looks like, and how to investigate a broken GRUB installation. On a VPS, the hosting provider generally controls the virtual firmware and boot configuration, so you may not have the same choices as you do on a physical PC. If you're planning to deploy your own Linux server, our Best Linux VPS Hosting guide compares hosting options for different workloads.
Check Your Boot Mode on Ubuntu 24.04 / 26.04
The kernel only creates /sys/firmware/efi when the firmware handed over UEFI runtime services. No directory, no UEFI. It's the quickest UEFI vs Legacy BIOS test there is.
LinuxTeck
[ -d /sys/firmware/efi ] && echo "Booted in UEFI mode" || echo "Booted in Legacy BIOS mode"
# 64 = 64-bit UEFI, 32 = 32-bit UEFI (rare, some cheap tablets)
cat /sys/firmware/efi/fw_platform_size
# Install the tools that read firmware boot entries and Secure Boot state
sudo apt update
sudo apt install -y efibootmgr mokutil
# List firmware boot entries and the current boot order
sudo efibootmgr -v
Check Your Boot Mode on Rocky Linux 9 / 10
Same test, dnf instead of apt. On a UEFI install efibootmgr and mokutil are usually already there, minimal images sometimes skip them.
LinuxTeck
[ -d /sys/firmware/efi ] && echo "Booted in UEFI mode" || echo "Booted in Legacy BIOS mode"
# Install the firmware tools if the minimal image skipped them
sudo dnf install -y efibootmgr mokutil
# List firmware boot entries and the current boot order
sudo efibootmgr -v
# Kernel log shows the UEFI version and vendor the firmware reported
sudo dmesg | grep -i "efi: efi v"
Run this before you touch anything else. Firmware varies a lot between vendors, and one Reddit user found out years later that their laptop's legacy mode only ever showed Windows in the boot menu, with the Linux entry hidden behind extra firmware settings. Knowing the mode first saves you from chasing the wrong fix.
Inspect the Partition Table and EFI System Partition
This is where UEFI vs Legacy BIOS actually shows up on disk. Works the same on both distros. Swap /dev/sda for /dev/nvme0n1 on NVMe. A UEFI install should show a small vfat partition (usually 512 MB to 1 GB) mounted on /boot/efi.
LinuxTeck
lsblk -o NAME,SIZE,FSTYPE,PARTTYPENAME,MOUNTPOINTS
# Partition table type: gpt = GPT, dos = MBR
sudo fdisk -l /dev/sda | grep -i "disklabel type"
# Is the EFI System Partition mounted where GRUB expects it?
findmnt /boot/efi
df -h /boot/efi
That small vfat partition is the one people on Reddit ask about after an install, the "why did it make a 100 MB partition I can't delete" question. It's the ESP. Leave it alone. If the df columns look odd, our df command examples walk through them.
Reinstall GRUB on Ubuntu (UEFI and Legacy)
Only run the half that matches your side of UEFI vs Legacy BIOS. On Ubuntu, grub-pc and grub-efi-amd64 conflict with each other, so installing the wrong one pulls out the right one.
LinuxTeck
sudo mount /dev/sda1 /boot/efi
sudo apt install --reinstall -y grub-efi-amd64 shim-signed
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
sudo update-grub
# Legacy BIOS system: write GRUB to the disk, not to a partition
sudo apt install --reinstall -y grub-pc
sudo grub-install --target=i386-pc /dev/sda
sudo update-grub
Reinstall GRUB on Rocky Linux (UEFI and Legacy)
The RHEL family handles UEFI differently. The bootloader ships as signed packages, so on UEFI you reinstall the RPMs instead of running grub2-install.
LinuxTeck
sudo dnf reinstall -y grub2-efi-x64 shim-x64
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
# Legacy BIOS system: write GRUB to the disk, not to a partition
sudo grub2-install /dev/sda
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Compatibility Note:
On Rocky Linux 9 and 10 the real config is /boot/grub2/grub.cfg in both modes. The grub.cfg under /boot/efi/EFI/rocky/ is only a small stub pointing at it, and it shouldn't be regenerated with grub2-mkconfig. Rocky 8 kept the full config on the ESP, so old guides that write there will clobber the stub on newer releases. Rocky 10 still lists both UEFI and BIOS booting as supported, with UEFI recommended.
Verify the Result From the Command Line
After a repair, confirm which side of UEFI vs Legacy BIOS you landed on, plus the Secure Boot state, boot order, and that the ESP actually has files on it.
LinuxTeck
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mokutil --sb-state
efibootmgr
# The ESP should hold a vendor folder and the fallback loader
sudo ls /boot/efi/EFI/
sudo ls /boot/efi/EFI/BOOT/
# Boot time split (firmware and loader show up on UEFI with systemd-boot)
systemd-analyze
UEFI vs Legacy BIOS: 7 Differences Side by Side
Here's the UEFI vs Legacy BIOS comparison in one table, just the seven differences that change how you run Linux.
| Feature | Legacy BIOS | UEFI | Verdict |
|---|---|---|---|
| 1. Partition table (GPT vs MBR) | MBR normally, GPT only with a BIOS boot partition | GPT normally, MBR also works | UEFI |
| 2. Boot disk size | 2 TiB limit on MBR with 512-byte sectors | No practical limit with GPT | UEFI |
| 3. Where boot code lives | MBR sector plus the gap after it | Plain files on a FAT32 EFI System Partition | UEFI |
| 4. Secure Boot | Not available | Supported through shim and MOK keys | UEFI |
| 5. Dual boot with Windows | One boot sector, chainloading, easy to overwrite | Separate NVRAM entry per OS | UEFI |
| 6. Boot speed | Slower POST, extra legacy init | Faster firmware stage when CSM is off | UEFI, but varies by board |
| 7. Very old hardware or odd VMs | Sometimes the only option | Missing on pre-2010 boards | Legacy, only when forced |
Boot speed is the UEFI vs Legacy BIOS row people argue about most. In one hardware forum thread a user reinstalled in legacy mode and found it booted faster than UEFI on his board. Replies pointed at CSM being enabled and vendor firmware quirks, and another user found UEFI ended up quicker once he did a full cold shutdown. So yes, UEFI is usually quicker, but your motherboard firmware gets a vote too.
Concept:
There's one real case for legacy boot that comes up on Reddit: people running several Linux installs on one disk. With legacy boot, GRUB's os-prober tends to pick up every install with no extra effort, while UEFI setups can need some NVRAM and ESP housekeeping. If you're stuck on BIOS-only hardware with a disk over 2 TiB, create a 1 MiB BIOS boot partition (the bios_grub flag in parted, "biosboot" in the Rocky installer). Our Rocky Linux 10.2 install guide shows where those partitioning choices appear.
Enterprise Insight:
Settling UEFI vs Legacy BIOS is only half the job on a server. Turn Secure Boot on, set a firmware admin password so nobody flips the box back into CSM, and disable USB boot once it's provisioned. Also worth knowing: Ubuntu 26.10's signed GRUB no longer reads /boot on LVM, LUKS, Btrfs, XFS or ZFS while Secure Boot is on, so keep /boot on ext4 for new builds. The Linux server hardening checklist covers the rest.
UEFI vs Legacy BIOS Red Flags: When Boot Mode Is the Real Problem
Plenty of "GRUB is broken" posts turn out to be UEFI vs Legacy BIOS mismatches. These are the three that come up most.
Common Mistake: "No bootable device" right after a clean install:
The installer was started in one mode and the firmware is set to the other. Usually the USB stick shows up twice in the one-time boot menu, once plain and once with a UEFI: prefix, and the plain one got picked. Boot the live USB again, choose the UEFI: entry, and confirm with [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS before reinstalling. Making the stick UEFI-only and turning CSM off avoids it entirely. Our Ubuntu 24.04 install guide shows where this choice appears.
Common Mistake: "grub-install: error: cannot find EFI directory":
GRUB is trying a UEFI install but the ESP isn't mounted at /boot/efi. Happens a lot in chroot repairs from a live USB. Check with findmnt /boot/efi and lsblk -f, mount the vfat partition, run it again. If there is no vfat partition at all, the system was installed in legacy mode and you're using the wrong --target. Keep the system initialization cheat sheet open during these repairs.
Security Warning: "Key was rejected by service" when loading a driver:
Secure Boot is on and an out-of-tree module (NVIDIA, some WiFi drivers, VirtualBox, ZFS) isn't signed with a key the firmware trusts. This is the number one reason Reddit threads tell beginners to "just disable Secure Boot." On a desktop that's your call. On a server, enroll a Machine Owner Key with sudo mokutil --import MOK.der instead. Confirm the cause with mokutil --sb-state and sudo dmesg | grep -i "key was rejected". If a service depends on that module, our systemd service errors guide helps trace the fallout.
UEFI vs Legacy BIOS - FAQ
Q1: Is UEFI better than Legacy BIOS?
For almost every Linux install today, yes. UEFI gives you GPT by default, Secure Boot, a clean multi-OS setup through NVRAM entries, and it's the mode distros test first. Legacy still makes sense on BIOS-only hardware or a disk that already has an MBR install you don't want to redo. Check what you're on with [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS. More one-liners are in our system initialization cheat sheet.
Q2: Does UEFI require GPT, and can UEFI boot MBR drives?
No and yes. UEFI pairs naturally with GPT, but most UEFI firmware will boot an MBR disk as long as there's a FAT32 partition holding the .efi loader. Check your disk with sudo fdisk -l /dev/sda | grep -i "disklabel type", where gpt means GPT and dos means MBR. If you're planning a new layout, see how LVM works in Linux before you partition.
Q3: Can I switch from Legacy BIOS to UEFI without reinstalling Linux?
Yes, but back everything up first. Roughly: convert the disk with sgdisk -g /dev/sda, make room for a 512 MB FAT32 ESP, mount it at /boot/efi, add it to /etc/fstab, install the EFI GRUB packages, then flip the firmware to UEFI. If root is on LVM, shrinking a volume to make space is far easier. On a fresh machine a reinstall is honestly quicker and less risky.
Q4: What happens if I disable Secure Boot on Linux?
The system still boots, and unsigned drivers like NVIDIA or out-of-tree WiFi modules load without fuss. What you lose is protection against a tampered bootloader or kernel module, which matters most on laptops and servers with disk encryption. Check the current state with mokutil --sb-state. Our UEFI Secure Boot guide shows how to keep it on and still load your drivers.
Q5: Can I dual boot Linux and Windows in UEFI mode?
Yes, and it's actually easier than legacy. Both systems share one ESP, each keeps its own folder and NVRAM entry, and neither overwrites the other's boot code. The only rule: both must be installed in the same mode. After installing, run sudo efibootmgr -v to make sure both entries are there and in the order you want. Our Ubuntu 24.04 install guide covers the installer side.
Q6: What is CSM, and should I turn it off?
CSM is the Compatibility Support Module, the part of UEFI firmware that pretends to be an old BIOS. Turn it off unless you need to boot something with no UEFI support. With CSM on, the boot menu shows duplicate USB entries, and it's easy to start the installer in the wrong mode. It can also slow down POST. On UEFI with systemd-boot, systemd-analyze even shows separate firmware and loader times so you can see the difference.
Final Thoughts: UEFI vs Legacy BIOS Is an Easy Call
UEFI vs Legacy BIOS really comes down to where the boot code lives. BIOS runs a tiny chunk from the first sector. UEFI loads a file from its own partition and keeps proper boot entries, which is what gets you GPT, Secure Boot and painless dual booting.
Getting UEFI vs Legacy BIOS right is a two minute decision. Check the mode before installing, keep every OS on the disk in the same mode, and save legacy for hardware that leaves you no choice. For your next install, start with the Rocky Linux 10.2 guide, then lock it down with Secure Boot.
Further Reading on LinuxTeck:
UEFI Secure Boot on Linux - how shim, MOK keys and signed kernels fit together.
systemd Targets and Boot Modes Explained - what happens after GRUB hands off to the kernel.
How LVM Works in Linux - storage layouts that make repartitioning much less painful.
Linux Server Hardening Checklist - next steps once the boot chain is sorted.
LinuxTeck - A Complete Linux Infrastructure Blog
LinuxTeck covers everything from beginner Linux commands to advanced Linux system administration and DevOps career guidance, written by practitioners for professionals working on Ubuntu, Rocky Linux, RHEL, and enterprise Linux environments every day.
Thank you for reading and for being part of this journey. If this article saved you time, consider buying me a coffee. Every contribution helps me keep producing in-depth, practical Linux content for readers like you.
Thank you for your endless support
