Disk partitioning explained: GPT, MBR, and the EFI system partition

level:Beginner

Early in an Arch install you face a blank disk and a decision that sounds scarier than it is: how to carve it up. You will choose a partition table format, create a partition or two, and pick where things mount. A beginner can take a simple, standard layout and be completely fine — this is not where you need to be clever. This post explains what a partition actually is, the difference between the two partition table formats you will hear about, why there is a special little partition called the EFI system partition, and a layout you can copy with confidence.

What a partition is

A physical disk is just a long sequence of storage blocks. A partition is a contiguous region of that disk that the operating system treats as an independent unit — its own logical drive, with its own filesystem. Partitioning lets you keep separate things separate: you might put the system's boot files in one region and everything else in another, or wall off a region for another operating system entirely.

A partition is not the same as a filesystem. Partitioning draws the boundaries; making a filesystem (with a tool like mkfs) is what makes a partition usable for storing files. Those are two distinct steps, and the choice of which filesystem to put inside a partition — ext4, Btrfs, and so on — is its own topic, covered in the filesystems explainer. Here we are only drawing the boundaries.

The partition table

Something has to record where each partition starts and ends. That map is the partition table, written in a reserved area at the front of the disk. The format of that table is the first real choice you make, and there are two: GPT and MBR.

GPT vs MBR

MBR, the Master Boot Record, is the older scheme, dating to the early 1980s. It works but carries real limits: it supports disks only up to about 2 TiB, and it allows just four primary partitions (you can exceed that only with an awkward "extended partition" workaround) (Wikipedia: Master boot record).

GPT, the GUID Partition Table, is the modern replacement and part of the UEFI standard. It handles disks far larger than 2 TiB, allows many partitions by default (the UEFI spec reserves room for 128), and stores a backup copy of the table plus checksums so a single corrupted sector does not lose your whole layout. The Arch Wiki recommends always using GPT for UEFI booting, because some UEFI firmware refuses to boot from an MBR disk while in UEFI mode (Arch Wiki: Partitioning). For practically every machine made in the last decade, GPT is the answer and MBR is legacy.

The EFI system partition

If your machine boots via UEFI, you need a dedicated partition the firmware can read before any operating system loads: the EFI system partition, or ESP. What it is: a small partition formatted as FAT (in practice FAT32). Why it has to exist: UEFI firmware does not understand Linux filesystems, so there must be one region in a format it can read before any OS is running. How the firmware uses it: it reads .efi program files straight off that partition. The ESP is where your bootloader lives — and on Arch, typically where the kernel and initramfs live too. When you power on, the firmware reads the ESP, finds the bootloader, and the bootloader takes it from there.

⛔ Danger If the disk already holds another operating system, reuse its existing ESP rather than reformatting it. Reformatting an existing ESP destroys the other OS's boot loader and can leave that system unbootable.

A few concrete points the Arch Wiki settles. The ESP must be FAT32. For size, the wiki notes that an ESP is usually at least 100 MiB, and that if you mount it at /boot and install only one kernel, 400 MiB is sufficient; many people simply make it around 1 GiB to leave comfortable headroom for multiple kernels, microcode, and the odd extra file, and that is a reasonable default (Arch Wiki: EFI system partition). For where to mount it, the simplest approach on a single-OS Arch system is to mount the ESP directly at /boot, since that is where the kernel and initramfs images already go, so everything the bootloader needs sits in one place. Mounting at /efi with a separate boot partition is also valid but is an advanced layout you do not need yet.

A sensible beginner layout

For a fresh single-OS install on a modern machine, two partitions are enough:

An EFI system partition, FAT32, around 1 GiB, mounted at /boot.
A root partition filling the rest of the disk, holding your actual Linux filesystem, mounted at /.

That is genuinely all you need. Optionally you can add swap — space the system uses to extend memory and to support hibernation — either as a third partition or, more flexibly, as a swap file inside root. Whether you want swap and how much depends on your RAM and whether you hibernate; that decision has its own swap explainer. When in doubt, skip a dedicated swap partition and add a swap file later, since a file is trivial to resize or remove.

It helps to picture what sits where on the disk and why each region is separate. The table at the front records the map; the ESP is walled off because the firmware must read it before any Linux filesystem is understood; root holds everything else. How they stack on one physical disk:

One disk, one partition table, and the regions it maps out.

flowchart TD
  A["Physical disk"] --> B["Partition table<br/><i>GPT</i>"]
  B --> C["ESP<br/><i>FAT32, mounted at /boot</i>"]
  B --> D["swap<br/><i>optional</i>"]
  B --> E["root<br/><i>ext4, mounted at /</i>"]

The tools

The Arch live environment ships several partitioning tools, and they overlap in what they do (Arch Wiki: Partitioning):

fdisk and cfdisk (from util-linux) handle both GPT and MBR. cfdisk has a friendly full-screen menu and is the easiest interactive choice for a beginner.
gdisk and cgdisk (from GPT fdisk) are GPT-only, with cgdisk offering a similar full-screen interface.
parted works on both schemes and is scriptable; a graphical front end, GParted, exists if you prefer pointing and clicking.

Any of these will do the job. For a first install I would reach for cfdisk: create a GPT table, make the small ESP, give it the EFI System type, then make root with the rest.

Which scheme?

💡 Tip Use GPT on any machine from the last decade; reserve MBR for genuinely old hardware that boots only via legacy BIOS.

Use GPT on any machine from roughly the last decade — anything that boots via UEFI, which is the overwhelming majority of laptops and desktops today. It has no awkward partition limits, survives sector corruption better, and is what UEFI expects. Pair it with a FAT32 EFI system partition mounted at /boot and you are following the mainstream, well-documented path.

Use MBR only when you are forced to: genuinely old hardware that boots via legacy BIOS and cannot do UEFI. That is a shrinking population of machines, and if you are reading this for a current laptop you almost certainly are not in it. When unsure, choose GPT — it is the safe default and the one the rest of the modern stack assumes.

If you have used Windows or macOS, you have already been running on GPT without thinking about it: both have used GPT under the hood on modern UEFI machines for years. So this is not a Linux quirk — it is the standard layout your other systems quietly assume too.

ℹ️ Note Modern Windows and macOS installations also use GPT on UEFI machines, so GPT is the cross-platform standard rather than anything specific to Linux.

The choice comes down to one fact about the machine. What decides it is how the machine boots; why it decides it is that UEFI firmware expects GPT and some firmware will refuse an MBR disk in UEFI mode; how to pick:

Let the firmware mode choose for you; GPT for anything modern.

flowchart TD
  A["How does the machine boot?"] -->|"UEFI, last decade"| B["GPT"]
  A -->|"old BIOS-only"| C["MBR"]

How this fits the Arch install

This is exactly the work in part 1 of the install, the boot-and-disks stage, where you pick a partition table, create the ESP and root, and mount them under /mnt before installing anything. Part 1 mounts the ESP at /mnt/boot, matching the layout recommended here, so part 2 can install the kernel and bootloader straight into it. Once boundaries are drawn you choose a filesystem to fill root — see the filesystems explainer — and decide on swap. The full sequence, with both install parts and the companion explainers, lives on the Arch install hub.

A short close

Partitioning is just drawing a map on a disk and recording it in a table. The format to record it in is GPT on any modern UEFI machine, with MBR reserved for old BIOS hardware. The one partition that trips up newcomers is the EFI system partition — a small FAT32 region the firmware reads to find your bootloader — but once you know why it exists, the standard layout of a roughly 1 GiB ESP at /boot plus a root partition for everything else is something you can set up in a couple of minutes and never revisit.