Repair your Fedora's (EFI) GRUB Bootloader
It happened again - this time on my Fedora machine! I ended up with a laptop that won’t boot after some package changes. Last time that happened was ~ 4 years ago when Arch Linux could not decrypt my main partitions due to some changes on a crypto library. This time the accident was caused by a simple dnf command:
dnf autoremove
I intended to remove dangling packages from my system - expecting my package manager to know which packages are needed and which not. Unfortunately some really important packages (amongst some legacy packages) were removed. My laptop was not even able to start any boot loader - it booted straight to the device diagnosis application that the hardware manufacturer ships.
Investigating the issue
… What went wrong? As always with a non-booting system, a live system on a USB dongle helps…
Chroot Fedora in Live environment
The following steps are similar to the ones described on this Fedora Manual page: https://docs.fedoraproject.org/en-US/Fedora/22/html/Multiboot_Guide/common_operations_appendix.html#common-chroot_from_live
I booted up the live medium and set up a wired network connection. Wired, because it’s easier and I don’t need to mess around with Wifi.
Then I changed to terminal, changed to the root user via su and then mounted Fedora system that was installed on my disk:
lsblk will help to find the correct devices (looking at the partition sizes)
nvme0n1 259:0 0 477G 0 disk
├─nvme0n1p1 259:1 0 200M 0 part
├─nvme0n1p2 259:2 0 1G 0 part
└─nvme0n1p3 259:3 0 475,8G 0 part
In my case:
- nvme0n1p1: EFI partition
- nvme0n1p2: Boot partition (Linux Kernel, Bootloader)
- nvme0n1p3: System Partition: LUKS encrypted, with LVM. Includes rootfs, home, swap.
Depending on your system (and if you’re using LUKS and LVM) the tree might look different.
mkdir /mnt/sysimage
cryptsetup luksOpen /dev/nvme0n1p3 cryptdata
mount /dev/mapper/fedora_thomas--nb2-root /mnt/sysimage
mount /dev/nvme0n1p2 /mnt/sysimage/boot
mount /dev/nvme0n1p3 /mnt/sysimage/boot/efi
The final step to change to the existing Fedora system:
chroot /mnt/sysimage
You are now effectively in your old Fedora system - not in the live system, anymore! You can exit the chroot environment via exit.
Restore DNS
Your network connection inside the chroot will probably not work as it should. While pings should work, sometimes DNS resolving does not work due to a broken / invalid /etc/resolv.conf. In my case, resolv.conf was an invalid symlink. I replaced it like this:
mv /etc/resolv.conf /etc/resolv.conf.bak
touch /etc/resolv.conf
Now put the following into /etc/resolv.conf
nameserver 9.9.9.9
(… or select another DNS resolver IP address. I chose “Quad Nine”).
… check if resolving public names does work, now:
ping thomas-leister.de
Analyze the dnf log file
In /var/log/dnf.log I found the list of packages that was removed during the dnf autoremove and copied the section to a new text file.
The list includes the following packages:
grub2-efi-x64-1:2.04-15.fc32.x86_64
grub2-pc-1:2.04-15.fc32.x86_64
grub2-pc-modules-1:2.04-15.fc32.noarch
grub2-tools-efi-1:2.04-15.fc32.x86_64
grub2-tools-extra-1:2.04-15.fc32.x86_64
shim-x64-15-8.x86_64
You might get an idea why my system stopped booting successfully … ;-)
Reinstall GRUB and Shim
Run this command to reinstall all the important boot related packages that were removed by accident:
dnf reinstall grub2-efi grub2-pc grub2-pc-modules grub2-tools-efi grub2-tools-extra shim
And that’s basically it! Your system should be fine, again.
Exit the chroot, unmount all the drives and reboot:
exit
cd ~
umount /mnt/sysimage/boot/efi
umount /mnt/sysimage/boot
umount /mnt/sysimage
sync
reboot
Though, when I was busy with my repair, I obviously missed to install grub2-efi-x64 so I ended up with this message after a reboot:
Failed to open \EFI\fedora\grubx64.efi - Not Found Failed to load image \EFI\fedora\grubx64.efi: Not Found start_image() returned Not Found
It seemed clear to me that I needed to run
grub2-install --efi-directory=/boot/efi --target=x86_64-efi /dev/nvme0n1
To install GRUB on my SSD and restore that .efi file. Unfortunately I haven’t read https://fedoraproject.org/wiki/GRUB_2#Create_a_GRUB_2_configuration … and made things … worse and better and the same time? …
After “restoring” grubx64.efi the boot process took me to GRUB (at least), but stopped at the GRUB command prompt:
grub>
… not what I expected. It seemed like GRUB did not find its configuration file. I decided to load my existing config file EFI/fedora/grub.cfg (on the EFI partition) manually:
grub> configfile (hd0,gpt)/EFI/fedora/grub.cfg
At this stage I was able to boot my Fedora instance, again. But the GRUB problem was not yet resolved: I only booted when issuing the “configfile” command manually.
Cause of this problem was the: grub2-install command (as one could have read at the link mentioned earlier!): EFI + grub2-install don’t go well, I one can trust the red box in the Fedora wiki article. So I installed grub2-efi, created a new config file (just to be sure) and the boot was fixed!
dnf install grub2-efi
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
(grub2-efi will install a proper version of grubx64.efi which loads the GRUB config from the correct location. The grubx64.efi generated by the grub2-install command tried to load the config from a file that did not exist and therefore caused the issue with the grub> command line.)