Recreating /boot/efi
After finding out about the lack of space in /boot/efi (see above), I decided to make that partition larger. Note that there was some old directory in /boot/efi which should not have been there, pointed out in the comment above, it looked strange to me as well but at that point I had already made space to grow the partition by shrinking the main partition by 400M and moving everything inbetween to the right. Unfortunately, the fat16 filesystem within that partition could not be resized:
# fatresize -v -s 200Mi /dev/nvme0n1p1
fatresize 1.1.0 (20240717)
part(start=2048, end=1023999, length=1021952)
Resizing file system.
No Implementation: GNU Parted cannot resize this partition to this size. We're working on it!
Unable to grow the filesystem, I decided to recreate it.
I followed this part of the Fedora documentation:
After formatting it with FAT32, mounting it and updating its UUID in /etc/fstab
, as documented, I installed the suggested packages.
Re-install the necessary packages.
# dnf reinstall grub2-efi grub2-efi-modules shim-\*
Packages for argument 'grub2-efi-modules' available, but not installed.
=>
# dnf install grub2-efi grub2-efi-modules shim-\*
Package "grub2-efi-x64-1:2.12-21.fc41.x86_64" is already installed.
Package "shim-x64-15.8-3.x86_64" is already installed.
Installing:
grub2-efi-aa64-modules noarch 1:2.12-21.fc41 updates 5.7 MiB
shim-ia32 x86_64 15.8-3 fedora 2.1 MiB
shim-unsigned-ia32 x86_64 15.8-2 fedora 1.4 MiB
shim-unsigned-x64 x86_64 15.8-2 fedora 1.8 MiB
Installing dependencies:
grub2-efi-ia32 x86_64 1:2.12-21.fc41 updates 5.2 MiB
I did not notice that it installed GRUB files for 32-bit architecture. It seemed promising that there were now some files in /boot/efi.
That should’ve been it, according to the documentation:
If you already have a working GRUB2 EFI configuration file, you do not need to do anything else.
Following this advice, I rebooted, only to find out that the boot menu would be gone, the system did not boot anymore.
Under “More information”, there’s a hint in the doc:
Under EFI, GRUB2 looks for its configuration in /boot/efi/EFI/fedora/grub.cfg
# rm -f /boot/efi/EFI/fedora/grub.cfg
# dnf reinstall grub2-common
Although recreating it was possible with this command, it did not fix the boot manager.
Recovery
I booted a Fedora live system from USB and used the usual procedure to enter the local installation:
root@localhost-live:/home/liveuser130# mkdir -m 0 /mnt/sysimage
root@localhost-live:/home/liveuser# mount -o subvol=root /dev/nvme0n1p4 /mnt/sysimage
root@localhost-live:/home/liveuser# mount /dev/nvme0n1p2 /mnt/sysimage/boot/
root@localhost-live:/home/liveuser# mount -o umask=0077,shortname=winnt /dev/nvme0n1p1 /mnt/sysimage/boot/efi/
root@localhost-live:/home/liveuser# mount -B /dev /mnt/sysimage/dev
root@localhost-live:/home/liveuser# mount -B /proc /mnt/sysimage/proc
root@localhost-live:/home/liveuser# mount -B /sys /mnt/sysimage/sys
root@localhost-live:/home/liveuser# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
root@localhost-live:/home/liveuser# chroot /mnt/sysimage
That’s where I ran dnf reinstall grub2-common
but that wasn’t enough to fix it.
Being used to non-EFI setups, I initially forgot to add efivars
(/sys/firmware/efi/efivars
was empty within the chroot):
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
… and without noticing that there’s a section “Restoring the bootloader” with slightly different commands (including dnf reinstall grub2-efi-\*
which should’ve included the x64 package), I used the good old grub2-install
command (which as per documentation should not be necessary). This made me aware that the subdirectory for the x64 architecture is missing:
# grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Fedora
grub2-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory.
# ls -la /usr/lib/grub/x86_64-efi
ls: cannot access '/usr/lib/grub/x86_64-efi': No such file or directory
# ls -la /usr/lib/grub/
total 0
drwxr-xr-x. 1 root root 32 Mar 25 01:00 .
dr-xr-xr-x. 1 root root 1788 May 11 22:57 ..
drwxr-xr-x. 1 root root 5540 May 20 20:21 arm64-efi
drwxr-xr-x. 1 root root 6812 May 11 22:21 i386-pc
This made me wonder why there are two subdirectories for the wrong architecture. They were there because grub2-efi-ia32
and shim-ia32
had been installed earlier (note the asterisk in the doc: dnf install ... shim-\*
). So I forcefully removed these two packages and installed the x64 one:
# dnf remove grub2-efi-ia32 shim-ia32-15.8-3.x86_64
Failed to resolve the transaction:
Problem: The operation would result in removing the following protected packages: grub2-efi-ia32, shim-ia32
# rpm -e --nodeps grub2-efi-ia32 shim-ia32
# dnf install grub2-efi-x64 grub2-efi-x64-modules shim-x64
# ls -la /usr/lib/grub/
total 0
drwxr-xr-x. 1 root root 52 May 20 21:34 .
dr-xr-xr-x. 1 root root 1788 May 11 22:57 ..
drwxr-xr-x. 1 root root 5540 May 20 20:21 arm64-efi
drwxr-xr-x. 1 root root 6812 May 11 22:21 i386-pc
drwxr-xr-x. 1 root root 6608 May 20 21:34 x86_64-efi
This created the subdirectory x86_64-efi
that grub2-install was expecting.
# grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Fedora
Installing for x86_64-efi platform.
grub2-install: error: This utility should not be used for EFI platforms because it does not support UEFI Secure Boot. If you really wish to proceed, invoke the --force option.
Make sure Secure Boot is disabled before proceeding.
Note I did not force it. Seems like the missing piece was grub2-efi-x64-modules
.
That and the efivars
mount I initially forgot to include in the chroot.
Now the system is working again.
Conclusion
After recreating the EFI partition, following the [documentation] to “Install the bootloader files” was not enough, the system would not boot anymore.
A live system had to be used to restore the boot loader.
The original error and the missing x64 package may have been unique features in this particular case, so I added some details above hoping it’ll be useful somehow.
When you have to fix a broken boot loader, don’t forget that you may be working on an EFI system. I knew that and still set up only the standard bind mounts (without efivars) and ran grub2-install.
Finally, the kernel-install
command from above was now successful, it created a new boot menu entry.
# kernel-install -v add 6.14.5-200.fc41.x86_64 /lib/modules/6.14.5-200.fc41.x86_64/vmlinuz
...
About to execute /usr/lib/kernel/install.d/99-grub-mkconfig.install add 6.14.5-200.fc41.x86_64 /boot/efi/d4033fa8d6ca48a68402a365aef6f348/6.14.5-200.fc41.x86_64 /lib/modules/6.14.5-200.fc41.x86_64/vmlinuz
Successfully forked off '(direxec)' as PID 19214.
/usr/lib/kernel/install.d/99-grub-mkconfig.install succeeded.
(sd-exec-strv) succeeded.
Boot entry confirmed working:
# ls /boot/*x86*.img
/boot/initramfs-6.14.5-200.fc41.x86_64.img /boot/initramfs-6.8.9-100.fc38.x86_64.img
# grubby --info=ALL | grep title | grep x86
title="Fedora Linux (6.14.5-200.fc41.x86_64) 41 (Forty One)"
title="Fedora Linux (6.8.9-100.fc38.x86_64) 38 (Thirty Eight)"