/boot/efi, or the partition lacks the necessary FAT32 filesystem and mount permissions. Resolving this requires verifying the partition type, ensuring it is correctly mounted, and then re-running the installation command with elevated privileges.
Understanding the Root Cause
Theefibootmgr utility interacts directly with the UEFI firmware variables stored on the EFI System Partition. When you run grub-install, it attempts to write a boot entry into these variables. If the tool cannot find the mount point where the ESP resides, it fails with a "No such file or directory" error. This is distinct from permission errors or missing files within the partition; it is fundamentally a path resolution issue.
In many fresh Arch Linux installations, users may have formatted their ESP but forgotten to mount it before running the initial setup commands. Alternatively, the mount point might be configured in /etc/fstab but not actively mounted in the current session. Another common scenario involves dual-boot setups where the ESP was created during a previous Windows installation, but the user is attempting to install GRUB without mounting that existing partition.
Verifying the EFI System Partition
Before attempting any fixes, you must confirm which partition serves as your EFI System Partition. You can identify it using thelsblk command or by checking the partition table with fdisk -l. Look for a partition marked with the type code EF00 (for EFI System).
Once identified, check if it is currently mounted. Run the following command to see all mounted filesystems:
mount | grep efi
/dev/sda1) mounted at /boot/efi, then the partition is not active. This absence is the direct cause of the error. Even if the partition exists on disk, grub-install cannot access it without a mount point.
Mounting the Partition Correctly
To resolve the immediate error, you need to mount the ESP to the standard directory/boot/efi. First, create the directory if it does not exist:
sudo mkdir -p /boot/efi
/dev/sdX1 with your actual partition identifier:
sudo mount /dev/sdX1 /boot/efi
mount | grep efi again. You should now see the partition listed. It is also wise to ensure the directory has the correct permissions so that GRUB can write its files:
sudo chmod 755 /boot/efi
Reinstalling GRUB
With the ESP properly mounted, you can now retry the GRUB installation. The command varies slightly depending on whether you are installing for x86_64 or ARM architectures, but the core syntax remains similar. For most standard desktop systems, use:sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
--bootloader-id flag ensures that the boot entry is named "GRUB" in the UEFI firmware menu. If this command completes without error, the boot entry has been successfully registered.
Following the installation, it is crucial to generate the GRUB configuration file. Without this step, GRUB will not know which kernels or operating systems to load. Use the following command:
sudo grub-mkconfig -o /boot/grub/grub.cfg
Preventing Future Issues
To avoid this error in future reinstalls or system updates, ensure that your/etc/fstab file includes the correct entry for the EFI partition. The entry should look something like this:
/dev/sdX1 /boot/efi vfat umask=0077 0 2
umask=0077 option ensures that only the root user can read and write to the EFI partition, which is a security best practice. Always verify that the UUID matches your specific partition by running blkid.
Additionally, if you are managing a multi-boot system, be aware that other operating systems might modify the EFI variables. In such cases, understanding how modules are loaded can help troubleshoot deeper initialization issues. See Understanding the Loading of Modules by initramfs in Linux for insights into early boot processes.
Frequently Asked Questions
Why does the error persist even after mounting?
If the error persists, check if you are running the command with sufficient privileges. Ensure you are using sudo or are logged in as root. Additionally, verify that the partition is indeed formatted as FAT32, as ext4 or other filesystems will not work for the EFI partition.
Can I use a different mount point than /boot/efi?
Yes, but you must specify it explicitly in the grub-install command using the --efi-directory flag. However, sticking to /boot/efi is recommended for compatibility with most package managers and scripts that expect the standard layout.
What if my ESP is on a different drive?
The physical location of the drive does not matter as long as it is mounted correctly. GRUB writes to the UEFI variables via the mounted filesystem, not directly to the hardware block device. Just ensure the correct partition is mounted at the specified directory.
How do I fix a broken grub.cfg after reinstalling?
If the installation succeeds but you cannot boot, regenerate the configuration file using grub-mkconfig -o /boot/grub/grub.cfg. This ensures that the bootloader detects your installed kernels and initramfs images correctly.
Is this error related to Secure Boot?
No, this specific error is unrelated to Secure Boot settings. It is purely a filesystem and path resolution issue. Secure Boot errors usually manifest as signature verification failures or explicit warnings about unsigned kernels.