How to Fix “Failed to Mount /boot/efi” During Boot in Ubuntu

Powering on your Ubuntu desktop or server only to watch the boot sequence abruptly freeze with a red error line declaring “Failed to mount /boot/efi” or “Dependency failed for /boot/efi”—before dropping into an emergency maintenance shell—is a critical startup disruption. The system warns: “You are in emergency mode. After logging in, type ‘journalctl -xb’ to view system logs”.

The /boot/efi mount point represents your system’s EFI System Partition (ESP), a dedicated FAT32/vfat partition where UEFI firmware stores bootloader binaries like GRUB and shim. When Ubuntu fails to mount this partition during boot, the issue is typically caused by dirty filesystem flags following an unexpected power cutoff, filesystem corruption in the FAT32 allocation table, a modified partition UUID following dual-boot Windows updates, or corrupted mount options inside /etc/fstab. This guide walks you through repairing the EFI partition and restoring normal boot.

Method 1: Identify the Failing EFI Partition UUID via Emergency Shell

In the emergency maintenance shell, enter your root administrative password to access the command prompt. First, determine which physical partition houses the EFI System Partition.

1. In the emergency shell, inspect your connected storage block devices:

   lsblk -f

2. Look for a small partition (typically 100MB to 512MB in capacity) formatted with the vfat filesystem. For example, /dev/nvme0n1p1 or /dev/sda1.
3. Check the true hardware UUID assigned to that vfat partition:

   blkid /dev/nvme0n1p1

   (Replace /dev/nvme0n1p1 with your actual vfat EFI partition).
4. Take note of the UUID string (e.g., UUID="ABCD-1234").

Method 2: Check and Update the /etc/fstab Mount Entry

If a recent disk clone, partition resize in GParted, or Windows installation changed the EFI partition UUID, Ubuntu cannot locate the partition described in /etc/fstab.

1. Remount the root filesystem in read-write mode so configuration changes can be saved:

   mount -o remount,rw /

2. Open the filesystem table configuration in the nano editor:

   nano /etc/fstab

3. Locate the line referencing /boot/efi. It will look similar to:

   UUID=ABCD-1234  /boot/efi       vfat    umask=0077      0       1

4. Compare the UUID in this file against the true UUID obtained via blkid in Method 1.
5. If the strings differ, edit the UUID to match the output from blkid.
6. To prevent a future corrupted EFI mount from dropping your system into emergency mode, append the nofail option to the mount string:

   UUID=ABCD-1234  /boot/efi       vfat    umask=0077,nofail  0  2

7. Save the file by pressing Ctrl + O followed by Enter, then exit by pressing Ctrl + X.

Method 3: Repair Corrupted FAT32 EFI Filesystem via fsck.vfat

Because the EFI partition is formatted with the older FAT32 filesystem, sudden power interruptions frequently leave “dirty” filesystem bits or broken cluster chains that systemd refuses to mount automatically.

1. Ensure the EFI partition is unmounted:

   umount /boot/efi

2. Run the dedicated DOS/FAT filesystem check and repair tool:

   fsck.vfat -a -v /dev/nvme0n1p1

   (Replace /dev/nvme0n1p1 with your EFI partition identifier).
3. The command flags perform the following operations:
   • -a: Automatically repairs detected inconsistencies without interactive prompts.
   • -v: Displays verbose diagnostic information regarding repaired clusters.
4. If the tool detects a dirty bit (“0x41: Dirty bit is set. Fs was not properly unmounted”), it will clear the flag cleanly.
5. Test mounting the partition manually:

   mount /boot/efi

6. If the command completes without printing any errors, the partition is restored.

Method 4: Reinstall GRUB and Update Bootloader Configurations

Once the EFI partition is mounted read-write, update GRUB boot records to ensure all kernel images synchronize with the EFI stub.

1. Reinstall GRUB to the target drive:

   grub-install /dev/nvme0n1

   (Specify the parent drive identifier without partition number).
2. Rebuild the GRUB configuration file:

   update-grub

3. Reboot your system:

   reboot

4. Ubuntu will now boot directly into the desktop or multi-user target without stopping at emergency mode.

Ubuntu /boot/efi Diagnostics Reference Table

Refer to this reference matrix to isolate EFI mount failures:

Observed Symptom	Underlying Root Cause	Recommended Solution
“Timed out waiting for device /dev/disk/by-uuid”	UUID mismatch in /etc/fstab following partition change	Check blkid; update UUID in /etc/fstab
“mount: wrong fs type, bad superblock”	Corrupted FAT32 allocation table or dirty bit	Run fsck.vfat -a -v /dev/sdX1 on EFI partition
Emergency mode loops on Control-D	Critical systemd mount unit dependency failure	Remount root rw; add “nofail” option to /boot/efi in fstab
Error began immediately after Windows dual-boot update	Windows Fast Startup locked or modified ESP partition	Disable Fast Startup in Windows Control Panel
EFI partition completely missing from lsblk	Accidentally formatted or deleted during OS repartition	Create new FAT32 partition via gdisk; reinstall GRUB

Preventing Windows Dual-Boot Fast Startup Interference

If your PC dual-boots Ubuntu alongside Windows 11 or 10, Windows features a setting called Fast Startup. When Windows shuts down with Fast Startup enabled, it puts the NTFS drives and shared EFI partition into a hibernated, locked state. When Ubuntu boots next, the Linux kernel detects the locked filesystem and refuses to mount /boot/efi. Boot into Windows, open classic Control Panel > Power Options > Choose what the power buttons do, click Change settings that are currently unavailable, and uncheck Turn on fast startup.