Grub install ошибка не удалось найти каталог efi

I just now encountered this issue. I booted a rescue USB stick. Let me describe the fix that worked for me.

Prowling around with gdisk -l /dev/sda I can see that my original root partition is /dev/sda2. To access it, I type sudo mount /dev/sda2 /mnt

So far, so good. Let me first describe what didn’t work, and then a solution. Some pages advise chroot /mnt and then grub-install, but this won’t work; giving the grub-install: error: cannot find EFI directory. error.

Following other suggestions, I see that my EFI partition is /dev/sda1 so I try sudo mount /dev/sda1 /mnt/boot/efi and chroot again. Now, grub complains about missing /dev so I mount --bind /dev/ /mnt/dev. … But then grub complains about something else. It’s snowballing out of control. chroot is not the answer.

What did work was this: grub-install -d /mnt/usr/lib/grub/x86_64-efi --boot-directory=/mnt/boot /dev/sda

Note that the -d flag is mandatory, as otherwise, grub tries to use /usr/lib/grub/i386-pc from the rescue image, which does not contain the correct stuff.

Yayy! My system is now bootable again!

In the Linux environment, encountering errors during or after installing a bootloader like GRUB can be frustrating, especially when it involves the EFI directory. A common error is the ‘Cannot Find EFI Directory’ after running grub-install. The issue can occur due to several reasons, from incorrect booting mode to issues with the EFI System Partition (ESP). This guide aims to demystify these EFI directory troubles.

We will delve into the potential reasons behind the ‘Cannot Find EFI Directory’ error and provide step-by-step solutions to address them. Understanding these problems and their remedies will not only help you solve current issues, but also prevent future ones, ensuring smoother booting processes. Ready to unravel the mysteries of EFI directory errors? Let’s dive in!

Understanding the Context

Before we dive deep into the troubleshooting, let’s understand the components at play: Grub, EFI, and the /dev/sda location.

Grub (GRand Unified Bootloader): Grub is the bootloader commonly used in Linux. Its main job is to manage the sequence of events that happens right after your computer is powered on. It makes sure your operating system gets up and running. We’ll often interact with Grub for operations such as installing a new OS, managing multiple OS on one system, or repairing a broken system.

EFI (Extensible Firmware Interface): EFI is a specification detailing an interface that helps hand off control of the system for the pre-boot environment (i.e., after the system is powered on, but before the operating system starts) to an operating system. EFI can replace the older BIOS firmware interface present in all computers. EFI boot loaders understand both a filesystem (for example, FAT32) and EFI boot applications, which provide a more flexible pre-OS environment.

/dev/sda: This represents your first master drive. It’s the equivalent of C:\ in Windows. The “sda” is short for “SCSI disk a,” and it’s the name given to the first hard drive in a Linux system.

So, if you’re using a command like sudo grub-install –boot-directory=/mnt/boot /dev/sda, you’re essentially instructing the system to install Grub in the boot directory of your first hard drive. The /mnt/boot directory is where the bootloader files are stored.

Unraveling the Error: “Cannot Find EFI Directory”

Now that we understand the different components, let’s tackle the error at hand. When you try to install Grub and receive the “Cannot find EFI directory” error message, it means that the installation process is unable to locate the EFI system partition.

But why does this happen? It’s usually because the directory where the EFI partition should be mounted (/mnt/boot/efi in most cases) doesn’t exist, or there’s no EFI partition to mount at all, or it could be because your system is not booting in UEFI mode but rather in Legacy mode.

Practical Example and Detailed Walkthrough

I believe booting into the legacy mode is a common issue for most users. Here is how you can fix it in such a scenario.

Scenario 1

First, you need to confirm if your system uses UEFI or BIOS. In case of UEFI, there should be an EFI system partition. If there isn’t, then it’s possible your system is using BIOS.

You can check if your system is running in UEFI mode by executing the following command in the Linux terminal:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

If the result is “UEFI”, then you’re in UEFI mode, otherwise, you’re in BIOS mode.

In case of UEFI, GRUB should be installed in the EFI system partition, and the correct command for this would be:

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB

Please note that “/boot/efi” should be replaced with the path where your EFI system partition is mounted.

Before running the above command, ensure that the EFI system partition is properly mounted. You can mount it with:

sudo mount /dev/sda1 /boot/efi

Replace “/dev/sda1” with the appropriate device for your EFI system partition. You can find this out by running lsblk or fdisk -l and looking for the EFI system partition.

If your system is booting in BIOS mode, your original command should work, but please ensure that the /mnt/boot directory exists and is the actual boot directory.

Remember to chroot into the system you’re trying to fix before installing GRUB. If you’re trying to repair the GRUB on a system you’re chrooted into, you would install it without the –boot-directory flag like this:

sudo grub-install /dev/sda

This will install GRUB to the MBR of the first disk. Ensure that the device you’re installing to (/dev/sda in this example) is correct for your system.

Scenario 2

Let’s go through a practical example to better illustrate this. Imagine you’ve got a fresh new system, and you’re trying to install Ubuntu on it. You boot up the live Ubuntu via a USB stick, partition your hard drive, and everything seems to be going well. But when you get to the grub installation part, you hit this error.

Step 1: Identifying the EFI Partition
Firstly, we need to find if there’s an existing EFI partition on your disk. You can use the lsblk or fdisk command to list the disk partitions. Look out for a partition type that says ‘EFI System’.

sudo fdisk -l

For instance, you might see an output similar to this:

Device Start End Sectors Size Type
/dev/sda1 2048 999423 997376 487M EFI System
/dev/sda2 999424 250068991 249069568 118.8G Linux filesystem
Here, /dev/sda1 is the EFI system partition.

Step 2: Mounting the EFI Partition
Once you’ve identified the EFI partition, the next step is to mount it. You would need to create the mount point if it doesn’t exist.

sudo mkdir -p /mnt/boot/efi

Then, mount the EFI partition:

sudo mount /dev/sda1 /mnt/boot/efi

Here, replace /dev/sda1 with the name of your EFI partition.

Step 3: Re-running the Grub-install Command
Now, you can re-run the grub-install command:

sudo grub-install --boot-directory=/mnt/boot /dev/sda

After these steps, your problem should ideally be resolved.

Common Troubleshooting Tips

Sometimes, despite mounting the EFI partition correctly, you may still run into the same error. This could be due to several reasons.

No EFI System Partition: If there’s no EFI partition, you will need to create one. Use a partitioning tool like gdisk or parted to create an EFI system partition (usually about 500 MB). Make sure to format it as FAT32.

Incorrect Boot Mode: Your system may be in Legacy/BIOS mode instead of UEFI mode. If your system firmware setup (often accessible by pressing F2, F10, or DEL during startup) has an option to set the boot mode, ensure it’s set to UEFI.

Missing EFI Boot Manager: If the EFI boot manager is missing or corrupted, the grub-install command may fail. You might need to use a boot repair tool to fix this.

I hope this detailed guide helps you the next time you encounter the “Cannot find EFI directory” error after running grub-install. These errors may be frustrating, but remember, every problem you solve is a step towards becoming a more knowledgeable Linux user.

And hey, who doesn’t love the feeling of victory after conquering a troublesome error? As for the ones that take a little longer to fix, well, they make for great stories at tech parties! Happy troubleshooting, and may your codes be error-free (or at least, less error-prone)!