The Boot Partition

/boot and /boot/efi sitting side by side on the same system is one of the most common sources of genuine confusion in Linux storage — two similarly named things, both clearly related to starting the system, doing meaningfully different jobs. This chapter exists specifically to untangle that, since the confusion is understandable rather than a sign you’ve missed something obvious.

Two Different Boot Paths

The core reason two different things exist here is that there are two fundamentally different ways a machine can start up Linux, and each has its own requirements for where boot-critical files need to live.

Legacy BIOS boot is the older approach. The system’s firmware (BIOS) reads a small amount of boot code from a fixed location at the very start of the disk — the Master Boot Record mentioned in the last chapter — which then hands off to a bootloader (almost always GRUB on Linux) capable of finding and loading the actual kernel. Critically, BIOS firmware doesn’t understand filesystems at all — it just executes raw code from a known disk location.

UEFI boot is the modern replacement. UEFI firmware is considerably more capable — among other things, it can read a FAT filesystem directly and execute files from it, without needing an intermediate bootloader stage stored in a fixed disk location the way BIOS requires.

/boot: Kernel And Bootloader Files, Either Way

Regardless of which boot path a system uses, /boot holds the same core set of files: the Linux kernel image itself, the initial RAM disk (initramfs, a minimal filesystem loaded before the real root filesystem is available), and GRUB’s own configuration. This is an ordinary directory containing ordinary files, readable with all the tools you already know — ls /boot works exactly like ls anywhere else.

Whether /boot needs to be its own separate partition, rather than just a directory inside your main root filesystem, depends on context you haven’t covered yet: it becomes necessary in setups using LVM (covered in the next two chapters) or certain other advanced filesystem configurations, because some bootloader configurations can’t reliably read a kernel image from inside an LVM logical volume directly. Keeping /boot on its own plain, simple partition sidesteps that entirely. On a straightforward setup without LVM, a separate /boot partition often isn’t strictly required — but it’s an extremely common convention regardless, partly for this exact forward-compatibility reason.

/boot/efi: The EFI System Partition (ESP)

This is the piece that’s genuinely new, and only exists on UEFI systems at all. Since UEFI firmware can read a FAT filesystem directly, there needs to be an actual FAT-formatted partition it can find and read before Linux itself, or any of Linux’s own filesystem drivers, are even running yet. That partition is called the EFI System Partition (ESP), conventionally mounted at /boot/efi, and it holds the actual bootloader executable itself — a .efi file UEFI firmware can load and run directly.

Unlike /boot, the ESP has real, non-negotiable requirements:

• It must be formatted as FAT32 — not ext4, not any other Linux filesystem, because UEFI firmware only understands FAT.
• It must be its own actual partition — never just a directory — since firmware reads it at a level below where “directories inside another filesystem” means anything yet.
• It’s typically small — a few hundred megabytes is standard, since it only needs to hold bootloader files, not kernels or general system data.

Side By Side

Checking Which Boot Mode A System Is Using

You don’t need to guess — Linux exposes this directly. If a system booted via UEFI, a specific directory exists:

ls /sys/firmware/efi

If that directory exists and lists contents, the system booted UEFI. If it doesn’t exist at all (“No such file or directory”), the system booted via legacy BIOS instead. This is a genuinely reliable, quick way to know which of the two boot paths from earlier in this chapter actually applies to the machine in front of you, without needing to inspect partition tables or guess from hardware age.

Why This Matters When Partitioning

This chapter exists in the middle of the partitioning discussion specifically because it’s a real, practical hazard: on a UEFI system, accidentally deleting, reformatting, or overwriting the ESP during a partitioning session leaves the system unable to boot at all — there’s no bootloader for firmware to find. This is exactly the kind of mistake the lsblk-before-you-act habit from the last two chapters exists to prevent — confirming you know precisely which partition is the ESP before running anything against it, every time.

What’s Next

With the boot partition’s role fully untangled, the next chapter moves to the layer that sits on top of every partition, boot-related or not: filesystems — what they actually are, and why ext4, xfs, and btrfs genuinely differ from one another rather than being interchangeable options.