1. Overview
In this tutorial, we’ll discuss how to restore a boot partition that has been corrupted while performing maintenance or admin operations. This can also happen due to hardware issues or a misconfiguration of the software.
We’ll begin by presenting a baseline from which we’ll discuss different solutions. We’ll assume that we have a CD/DVD or a USB connection in our device.
2. Situation of the Broken EFI Boot Partition
Before discussing the solutions, let’s understand some concepts.
EFI (Extensible Firmware Interface) is a specification that describes how the architecture of the platform firmware needs to be to load properly.
UEFI is the Unified Extensible Firmware Interface, which replaces the legacy BIOS (Basic Input/Output System) in new devices, and whose aim is to be a way to interact with the system hardware.
UEFI first does a self-check and initializes the device. Then, it uses efibootmgr to read the boot entries, determines the location of the EFI application (which usually is a bootloader), and launches it. This contrasts with the legacy BIOS, which checks the boot record on the first device to find the bootloader.
Even if the boot partition isn’t strictly necessary, it can still be handy. If we’ve created it, the /boot partition will have a specific filesystem type. We’d also need a bootloader (or bootstrap loader) to start our computer. This is the first piece of software that a system runs when starting. It’s in charge of giving control to the kernel which starts the rest of the operating system.
The most known bootloader is GRUB (GRand Unified Bootloader). GRUB is a bootloader that we can use to boot from one of several operating systems installed on a given system or even choose a specific kernel configuration.
Alternatives to GRUB are ELILO (EFI LInux LOader) or executing the Linux kernel directly from the firmware. One solution to a broken boot partition is to reinstall GRUB. However, depending on the state of our device, this might not be even possible with the common procedure and requires some extra steps.
Now, it’s time to attempt to fix our EFI boot partition!
3. Bootloader Reinstallation With GRUB Tools
The first thing we can try is to reconfigure the bootloader from within itself. We’ll focus on the tools that GRUB provides. For that, we’ll need a live USB that allows UEFI boot mode.
There are special distributions to solve problems with EFI, such as the USB version of rEFInd or rEFIt. We need to flash with UEFI boot mode because otherwise, we won’t see the EFI variables, so subsequent steps might fail.
We may need to change the booting order to load from the USB. Once we’ve booted from the live USB, we need to mount the EFI system partition:
$ sudo mount /dev/sda1 /mnt/boot/efi
In this case, the boot partition is /dev/sda1. We can use grub-install to copy the GRUB images into the specified directory:
$ grub-install --efi-directory=/mnt/boot/efi
We should have now GRUB reinstalled into the boot sector. Since the configuration of the drives shouldn’t have changed, we can directly update the bootloader:
$ sudo update-grub
We still need to make it bootable and instruct efibootmgr where our partitions are. Let’s assume we’ve one Linux distribution in /dev/sdXY:
$ efibootmgr --create --disk /dev/sdX --part Y --label LINUX_DISTRO
We’re creating a boot entry for the raw device X and the virtual device Y with the label LINUX_DISTRO. efibootmgr has plenty of other options that we can certainly check, such as passing extra command line arguments or specifying a different loader.
Before leaving the live USB, we can verify that everything worked as expected and the records that we added are there:
$ efibootmgr -v
If we can see an entry for our LINUX_DISTRO, we can reboot the computer without the live USB and access our system.
4. GRUB Reinstallation With Package Manager
If the bootloader reconfiguration fails to give us a working system, we can reinstall the bootloader with the package manager of a distribution. For that, we also need a flashed USB as discussed before. Once we’ve booted into the system, we’ll need to mount all the partitions:
$ sudo mount /dev/sda2 /mnt
$ sudo mount /dev/sda1 /mnt/boot/efi
$ for i in /dev; do sudo mount -B $i /mnt$i; done
The root partition needs to go first (/dev/sda2), then the EFI system partition (/dev/sda1), and finally the loop to mount all the other partitions available. At this point, the network might be unavailable by default. To fix this, we need to relocate the resolv.conf file to the mounting point:
$ sudo cp /etc/resolv.conf /mnt/etc/
The last preparatory step is to change the apparent location into the broken system with chroot. With chroot we tell the OS that is being currently loaded from the external USB to change the root directory for a given process and its children:
$ sudo chroot /mnt
Now, depending on the distribution that we installed on our live USB, the package manager in the following command might vary. Anyway, we need to reinstall the bootloader (GRUB in this case) in our system:
$ sudo apt-get install --reinstall grub-efi
Apart from the package manager and the option flags, the package name may also be different. For example, we can find it as grub-efi-amd64. This should give us a reinstalled GRUB bootloader. As before, we need to update GRUB, create an entry for EFI, and verify that everything worked:
$ sudo update-grub
$ efibootmgr --create --disk /dev/sdX --part Y --label LINUX_DISTRO
$ efibootmgr -v
Finally, we need to exit chroot with Ctrl+D, unmount the chrooted partition, and reboot the system. With this approach, we’ll get a fresh bootloader installation that might solve the corrupted state of the partition.
5. Boot Partition Reformatting
If the previous procedure didn’t work, we can also take one extra step in between to try to fix the problem. We can reformat the corrupted EFI partition before reinstalling GRUB. One option is to use mkdosfs:
$ mkdosfs -F 32 /dev/sdXY
We’re specifying a 32-bit FAT size for the raw device X and the virtual device Y.
Then we can reinstall GRUB, from either GRUB itself or the package manager. However, before upgrading GRUB with update-grub, and since we’ve formatted the partition, we need to modify the contents of the /etc/fstab file.
There are several ways to refer to the partition, the two most common ones being kernel name descriptors and file system UUID**.** Kernel descriptors refer to /dev/sdXY but are an ill-suited option since they’re not persistent and might change every time we boot. We generally encounter file system UUIDs in the /etc/fstab file, but they change when we format a partition. To get the UUID we use blkid:
$ sudo blkid
/dev/sdXY: UUID="42fb295d-7801-4166-1111-ff4abad3fe73" TYPE="ext4" PARTUUID="10145678e-07"
...
We can also opt for another option to refer to the partitions in the /etc/fstab file. The disk by-id option remains constant after formatting, although still not after partition. The file system UUID entry (first item in each line) is the ID of the partition:
UUID=42fb295d-7801-4166-1111-ff4abad3fe73 ...
However, the disk by-id is the identifier of the disk manufacturer and other partition information:
/dev/disk/by-id/ata-SAMHDTF645AY121AM6T-part1 ...
We can retrieve the by-id from the disks by inspecting the corresponding folder:
$ ls -l /dev/disk/by-id/
total 0
lrwxrwxrwx 1 root root 9 Dec 21 09:50 ata-SAMHDTF645AY121AM6T -> ../../sda
lrwxrwxrwx 1 root root 10 Dec 21 09:50 ata-SAMHDTF645AY121AM6T-part1 -> ../../sda1
...
Anyway, once the /etc/fstab has been updated, we can complete the procedure with update-grub and the creation of entries for EFI.
6. Skip GRUB Altogether
Bootloaders have a lot of functionalities such as unlocking encrypted file systems or changing kernel parameters. However, if we’re dealing exclusively with EFI operating systems we can skip GRUB (or any other bootloader). Bootloaders such as GRUB were essential in the past, but on UEFI systems, the firmware already contains the bootloader.
We use GRUB in our modern EFI systems as a boot manager. Nevertheless, GRUB is considerably more complex than other managers, as the previously mentioned rEFInd. Without a bootloader, we’ll boot faster but less interactively for diagnosing our system. This process isn’t recommended if we don’t have other alternative booting methods (such as a USB because the bootloader can help when something goes wrong).
We can embed the kernel parameters in the EFI boot entry. EFISTUB allows the EFI firmware to load the kernel. Assuming that we already have the EFI system partition available by any of the previous procedures, we can create an entry in efibootmgr:
$ efibootmgr --create --disk /dev/sdX --part Y --label LINUX_DISTRO --loader /vmlinuz-linux --unicode 'root=##BLOCK_IDENTIFIER## rw initrd=\initramfs-linux.img'
As before, we’re creating a boot entry with the label LINUX_DISTRO for the raw device X and the virtual device Y, which is where the EFI system partition resides. Moreover, we’re specifying the loader and a list of kernel parameters that we can further customize. We need to replace the ##BLOCK_IDENTIFIER## with the information for our block, either the file system UUID or the by-id information.
**We can also change the boot order in which the different entries of the efibootmgr are tested:
**
$ efibootmgr --bootorder 0002,0000,0001 --unicode
The boot order tries to boot the first entry in the list (which is the third distribution with identifier 0002), then the second one in the list (distribution 0000), and so on. We can get this information the same way we validated our input earlier:
$ efibootmgr -v
Once everything is set up, we can reboot our system.
7. Conclusion
In this article, we’ve learned four alternatives to fix a broken EFI partition.
We should always start by attempting to reinstall the bootloader: first with the tools that the bootloader might provide and second with the package manager of the distribution. If this fails, we can try to reformat the partition before reinstalling the bootloader.
Finally, we can also skip the bootloader to get our EFI system back and running.