The Role of the EFI System Partition
In systems using GPT (GUID Partition Table) with UEFI firmware, the EFI System Partition serves as the critical storage location for bootloaders. Unlike traditional BIOS systems that rely on the Master Boot Record and active partition flags, UEFI requires a dedicated FAT32-formatted partition. This partition must be flagged with the EF00 GUID type in the partition table. The firmware does not scan the entire disk for boot files; instead, it looks at a hardcoded list of valid device paths and checks for specific directories within the ESP.
The ESP is mounted automatically by the Linux kernel during the early boot process, but its primary function before the OS loads is simply to provide a read-only interface for the firmware. Any bootloader intended to work with UEFI must reside here. For GRUB, this means the core binaries are stored in a specific subdirectory structure that the firmware can parse without needing complex drivers or filesystem knowledge beyond FAT32 support.
How the Firmware Locates GRUB
The UEFI firmware maintains a list of boot entries in NVRAM (Non-Volatile RAM). Each entry contains a description and a path to the executable file. Commonly, the default entry points to /EFI/BOOT/BOOTX64.EFI or /EFI/ubuntu/grubx64.efi. When you power on the machine, the firmware iterates through these entries. It attempts to load the file at the specified path. If the file exists and is a valid PE/COFF executable, the firmware hands control over to it.
This mechanism allows for multiple operating systems to coexist. For example, Windows typically places its bootloader at /EFI/Microsoft/Boot/bootmgfw.efi, while Ubuntu places GRUB at /EFI/ubuntu/grub.cfg along with the grubx64.efi binary. The presentation of the menu happens entirely within the GRUB executable after it has been loaded into memory by the firmware. The firmware itself does not render any menus; it only acts as the loader.
Configuration via grub.cfg
Once GRUB takes control, it reads its configuration file, grub.cfg, which is also located on the ESP. This file dictates what options appear in the boot menu. It lists available kernels, initramfs images, and other operating systems detected on the disk. The content of this file is generated by the update-grub command (or grub-mkconfig) based on templates in /etc/grub.d/ and settings in /etc/default/grub.
If the menu appears empty or shows errors, it usually indicates that grub.cfg is missing, corrupted, or misconfigured. You can verify the existence of this file by mounting the ESP and checking the directory. A healthy system will have a complete grub.cfg that references the correct UUIDs for the root filesystem. For more details on fixing a broken configuration, see Linux Boots Grub - How to Fix a Broken grub.cfg.
Troubleshooting Missing Menus
Several issues can prevent the GRUB menu from appearing. First, ensure the ESP is properly formatted as FAT32. Some modern distributions require the ESP to be unmounted or mounted with specific options during installation to ensure compatibility. Second, check if the UEFI boot order is set correctly. If the firmware tries to boot from a different device first, it may skip the GRUB entry entirely.
If the system boots directly into the OS without showing the menu, the timeout setting in /etc/default/grub might be set to zero. Changing GRUB_TIMEOUT to a value like 5 or 10 seconds will force the menu to pause. Additionally, secure boot policies can sometimes block unsigned bootloaders. In such cases, you may need to enroll MOK keys or disable secure boot temporarily. Another common issue arises when the EFI partition is accidentally deleted or corrupted. Refer to Accidentally Deleted UEFI Partition: Can't Boot Linux Mint for recovery steps.
Reconstructing the Boot Environment
In rare cases, the EFI file itself may become damaged or overwritten, especially after dual-booting with older versions of Windows. Reinstalling GRUB involves mounting the ESP and running grub-install targeting the correct EFI directory. This regenerates the necessary executables and updates the NVRAM boot entries. It is crucial to specify the target platform (e.g., --target=x86_64-efi) to ensure the correct binary architecture is installed.
For users dealing with legacy setups where Windows 7 was previously part of the chain, reconstructing the EFI file might be necessary to restore visibility in the GRUB menu. See How to Reconstruct EFI File to Make Windows 7 Reappear on GRUB for specific guidance on merging legacy and UEFI boot paths.
Frequently Asked Questions
Why does my computer boot straight to Windows without showing GRUB?
This usually happens because the UEFI firmware's default boot entry points to the Windows bootloader rather than GRUB. You can change this by entering your BIOS/UEFI setup utility and adjusting the boot priority order to place the Linux GRUB entry first.
Can I use a non-FAT32 filesystem for the EFI System Partition?
No, the UEFI specification strictly requires the EFI System Partition to be formatted as FAT32. This ensures that all firmware implementations, regardless of vendor, can read the bootloader files without needing proprietary drivers.
What should I do if the GRUB menu says "error: unknown filesystem"?
This error indicates that GRUB cannot read the partition containing grub.cfg or the kernel images. It often occurs if the ESP is not mounted correctly or if the grub.cfg references incorrect UUIDs. Running update-grub from a live USB can regenerate the correct configuration.
Does Secure Boot affect how the GRUB menu is displayed?
Secure Boot does not change the visual presentation of the menu, but it prevents unsigned bootloaders from executing. If your GRUB binaries are not signed with a trusted key, the firmware will refuse to load them, potentially resulting in a blank screen or a direct fallback to another OS.
How can I manually edit the GRUB menu entries at runtime?
You can edit entries temporarily while GRUB is loading by pressing 'e' on the desired line. This opens an editor where you can modify kernel parameters. However, these changes are lost upon reboot unless you save them permanently in /etc/default/grub or add a custom script in /etc/grub.d/.