After upgrading to Fedora 40 I am having problems to boot the linux system. I am on a x86_64 machine with EFI secure boot enabled. Newly installed kernels end up in /boot/efi/<machine-id>/<kernel-version> along with their corresponding initrd files. The grub loader entries are installed to /boot/efi/loader/<machine-id>-<kernel-version>.conf and correctly refer to the aforementioned kernel/initrd files. So far, so well. I then execute grub2-mkconfig -o /boot/grub2/grub.cfg to update the boot loader configuration, and reboot.
The boot process then stops at the grub> prompt. From there I can use the linux and initrd commands to manually load the kernel and initrd files, and then issue the boot command. This boots the kernel, but it stops in the initrd because it fails to mount the root file system. Again, I do this manually, mounting it on /sysroot, an exit the initrd shell. This finally starts the system.
Because the first stop is at the grub prompt, I conclude that the early EFI/shim bootstrap stages have been successful, and that grub is somehow unable to access its configuration. But so far I havenât been able work out why this is. Nor have I found a way to debug this problem.
I did as advised. This populated /boot with kernel and initrd files, and also created entries in /boot/loader/entries that look correct. I then executed grub2-mkconfig again and rebooted - and ended up at the grub> prompt again.
No.
There are 2 grub.cfg files.
The pointer located at /boot/efi/EFI/fedora/grub.cfg is used to redirect grub (when booting with uefi) to the actual file at /boot/grub2/grub.cfg.
Secure boot has nothing to do with the location of the grub.cfg file.
You may be thinking of someone using sdboot, but that seems to not be the case here since grub would not be used when using sdboot.
This somewhat improved the situation. While the bootstrap process still stops at the grub> prompt, I can now use the configfile command to manually load grub.cfg, which then brings up a boot menu containing all installed kernels. After selecting one of them, I get an error message saying no server found, but after hitting the return key the boot process continues, and the system starts as expected.
I also noticed that the output of kernel-install inspect still seems to be incorrect. It refers to /boot/efi/<machine-id>, which no longer exists:
That is no problem as long as you have KERNEL_INSTALL_LAYOUT=other.
It could be that the contents of /boot/efi/EFI/fedora/grub.cfg is not correct.
The UUID in that file should match the UUID of the /boot file system as shown when running lsblk -f.
I am a bit confused about this KERNEL_INSTALL_LAYOUT stuff. My understanding is that BLS means that configuration entries are stored in individual configuration fragments in /boot/loader/entries, as opposed to inlining them in grub.cfg itself. So, isnât the configuration I have (with /boot/loader/entries) a BLS configuration?
In this context, KERNEL_INSTALL_LAYOUT=bls means systemd-boot instead of grub2. That also implies that the kernel and initrd will be stored in the ESP instead of the boot file system.
Actually, the error message displayed is error: ../../grub-core/net/net.c:1394:no server is specified.. This seems to indicate that grub attempts to access a network resource, which IMO it is not supposed to do.