Right, let’s talk about the EFI System Partition (ESP). This little slice of your disk is the UEFI’s VIP lounge; it’s the only place the firmware’s bouncers are programmed to look for bootloader applications. Think of UEFI as a slightly dim but very strict security guard. It won’t, and in fact can’t, just go poking around your ext4 or btrfs partitions looking for a file. It only speaks FAT. Yes, really. The 30-year-old File Allocation Table. The designers of UEFI made a choice here: reliability and universal support over modernity. It’s a bit like requiring every car to start with a hand crank, but you have to admit, it always works.

So, the ESP is almost always a FAT32 (sometimes FAT16 for tiny drives) formatted partition. It gets a specific GUID in the GPT partition table (C12A7328-F81F-11D2-BA4B-00A0C93EC93B) so the firmware can pick it out of a lineup instantly. You’ll find it mounted at /boot/efi on most Linux installations. This isn’t just a suggestion; messing with this mount point is a fantastic way to have a very unbootable Tuesday morning.

The Layout of the ESP

The UEFI spec defines a very specific directory structure that bootloaders must follow. It’s not a free-for-all. The main path is EFI/ and underneath that, you typically find a directory for each installed OS or bootloader vendor, like EFI/ubuntu/, EFI/fedora/, or EFI/systemd/. This is how you avoid the “Windows installs itself and helpfully makes your Linux installation vanish from the boot menu” problem. Well, in theory. Windows is still a bit of a diva about this and sometimes overwrites the default boot entry anyway. It’s best to not give it the chance.

Inside an vendor directory, you’ll find the actual bootloader application, which is just an executable file with a .efi extension. For GRUB, this is usually called grubx64.efi or shimx64.efi (if you need Secure Boot). There will also be a directory for its modules and a configuration file (grub.cfg), but we’ll get to that.

You can see exactly what your UEFI firmware sees by listing the contents of your ESP:

sudo mount /dev/nvme0n1p1 /boot/efi  # If it's not already mounted
tree /boot/efi/EFI

Which should output something sensible like:

/boot/efi/EFI/
├── fedora
│   ├── grub.cfg
│   ├── grubx64.efi
│   ├── fonts
│   └── x86_64-efi
├── ubuntu
│   ├── grub.cfg
│   ├── shimx64.efi
│   └── BOOT.CSV
└── Microsoft
    └── Boot
        └── ... [a bunch of Windows stuff we politely ignore]

How GRUB Actually Works in UEFI Mode

Forget everything you knew about GRUB from the old BIOS days. There’s no more stage1, stage1_5, stage2 mess written into the magical post-MBR gap. Under UEFI, GRUB is just another UEFI application. When you install it, what you’re really doing is:

  1. Compiling or copying a GRUB EFI executable (e.g., grubx64.efi) to the ESP.
  2. Using the efibootmgr tool to create a boot entry in NVRAM. This entry is essentially a pointer that tells the firmware: “Hey, to boot this thing, please run the file located at \EFI\ubuntu\grubx64.efi on the first hard drive.”

This is a vastly cleaner system. The bootloader is a discrete file on a normal filesystem, not a fragile sprinkle of magic bytes across your disk.

Here’s the command you’d use to see these boot entries. It’s one of the most important tools in your UEFI toolkit:

sudo efibootmgr -v

This will list all entries, their boot order, and the exact path the firmware will use. If GRUB gets borked, you can often fix it by recreating this entry.

The Critical Split: grubx64.efi vs. grub.cfg

Here’s the part that trips up a lot of people. The grubx64.efi file in the ESP is not all-knowing. It’s actually quite stupid on its own. Its primary job is to understand the filesystem drivers for your real Linux partition (e.g., ext4, btrfs, xfs), load additional modules from /boot/grub/x86_64-efi/, and then find and execute the real configuration file: grub.cfg.

And this is the crucial bit: grub.cfg almost always lives on your root Linux filesystem, not in the ESP. The path is typically /boot/grub/grub.cfg. The grubx64.efi file has this path hardcoded into it when you run grub-install.

This is a genius separation of concerns. The ESP holds the small, FAT-compatible bootloader binary, while the complex, frequently-updated configuration and all the module guts live on your high-performance Linux filesystem. When you update your kernel and run update-grub, you’re only modifying the grub.cfg on your root partition. The grubx64.efi file in the ESP remains untouched, blissfully unaware of the changes, just dutifully pointing at the config file it was told to.

The most common pitfall? Your root partition failing to mount. If grubx64.efi can’t find /boot/grub/grub.cfg because your crypttab is wrong or your fstab has a typo, it will drop you into a rescue shell. It’s not that GRUB is broken; it’s that it can’t read its instructions. Always double-check your fstab UUIDs.