GRUB not showing up after dnf update

I have a dual boot setup, with Fedora 30 KDE and Windows 10. After upgrading my system using dnf update, my system no longer boots into GRUB, but only Windows. In order to boot GRUB, I have to go to the boot menu, and browse the UEFI file system to get to the grubx64.efi file.
The boot order in my BIOS only has the Windows boot loader.
Is there any way to restore the boot experience how it used to be?

What does the efibootmgr command says in output, I guess entry isn’t listed there as well? You could either create entry manually with that same command, somewhat like:

efibootmgr -c -g -d /dev/disk/by-id/yourdrivehere -p PARTNUM -L "Fedora" -l '\EFI\Fedora\grubx64.efi'

Or alternatively reinstalling grub2-efi and shim packages should do that automatically

3 Likes

Thanks for replying!

Here’s the output of efibootmgr:

Timeout: 0 seconds
BootOrder: 0000,0001,0002,9999
Boot0000* Fedora
Boot0001* Windows Boot Manager
Boot0002* Internal Hard Disk
Boot9999* USB Drive (UEFI)

Seems to look ok, should I reinstall grub2-efi and shim anyway?

Did you replace “PARTNUM” with a number and “yourdrivehere” with an ID? It’s probably 1, but could be 2. Send sudo blkid to tell us more. Also, on a system with secure boot enabled, the command should be sudo efibootmgr --create --disk /dev/<identifier, possibly sda> --part <number, possibly 1> --label Fedora --loader "\EFI\fedora\shimx64.efi"

Nope, that’s what was the output. I have / on an NVME SDD, and /home and swap on a HDD.

Here’s the output of sudo blkid:

/dev/sda1: LABEL=“DATA” UUID=“B2BAA29ABAA25A9D” TYPE=“ntfs” PARTLABEL=“Basic data partition” PARTUUID=“702ba8c8-9d71-4b3d-973f-b0b3be7e4b19”
/dev/sda2: LABEL=“RECOVERY” UUID=“6AA0A557A0A52A91” TYPE=“ntfs” PARTLABEL=“Basic data partition” PARTUUID=“46914b8a-5ab5-4745-a023-ac5e37684e6a”
/dev/sda3: LABEL=“fedora_home” UUID=“5f8269d0-278d-4526-8c22-2fb924a37180” TYPE=“ext4” PARTUUID=“f2d8b09d-2866-40e0-bbd6-c097232f0864”
/dev/sda4: LABEL=“fedora_swap” UUID=“152c7b2a-9d48-4d9e-8ff0-ca0c58d5cf27” TYPE=“swap” PARTUUID=“669293cf-b283-4745-89c5-44ed34094e00”
/dev/nvme0n1: PTUUID=“709dbfdc-53c1-4294-a97a-5d8ec6e41349” PTTYPE=“gpt”
/dev/nvme0n1p1: UUID=“8E6D-9648” TYPE=“vfat” PARTLABEL=“EFI System Partition” PARTUUID=“4bf61064-96ca-4b25-9383-863b5c7f1e28”
/dev/nvme0n1p2: PARTLABEL=“Microsoft reserved partition” PARTUUID=“cb39971c-8625-417e-877f-4c277c4bdc5e”
/dev/nvme0n1p3: LABEL=“Windows” UUID=“3A3606B336066FE5” TYPE=“ntfs” PARTLABEL=“Basic data partition” PARTUUID=“0db6bfbc-c21f-4925-bfb6-944036b07f2c”
/dev/nvme0n1p4: LABEL=“Windows RE tools” UUID=“0AB419EAB419D951” TYPE=“ntfs” PARTLABEL=“Basic data partition” PARTUUID=“0df3252d-84ad-452a-935d-0d365846cb99”
/dev/nvme0n1p5: LABEL=“fedora_root” UUID=“f7548a91-a3d2-4ec2-8573-c7f313417cda” TYPE=“ext4” PARTUUID=“682f39f1-81d6-4b56-b37e-aa32fe05d936”

I believe I disabled secure boot in the BIOS, but I will double check

1 Like

In that case, the correct command for your system is sudo efibootmgr --create --disk /dev/nvme0n1 --part 1 --label Fedora --loader "\EFI\fedora\shimx64.efi". Run efibootmgr -v after that and send the output.

You can clean up any unnecessary entries with sudo efibootmgr -B -b <4 digit bootorder number>

I find it safer to use shim anyway. If secure boot is disabled, shim will just load grub, but if it is enabled, loading grub directly won’t work.

2 Likes

Thanks.
I confirmed that secure boot is disabled. I did try to boot from the shimx64.efi file from the boot manager but that didn’t work. Booting from the shimx64-fedora file brought be to GRUB. Should I run sudo efibootmgr --create --disk /dev/nvme0n1 --part 1 --label Fedora --loader "\EFI\fedora\shimx64-fedora.efi" instead?

If secure boot is disabled (and you plan on leaving it that way), you can simply boot grubx64.efi directly if you want (shim could be useful for you anyways, but you would know if it was).

But here’s some background: shimx64.efi and shimx64-fedora.efi are the same file, with one difference (I’m 99% sure about this, I’ll get back to you if I was wrong). shimx64.efi was signed by Microsoft, whereas shimx64-fedora.efi was signed by fedora’s key. Both contain fedora’s key, which grubx64.efi is signed by, so both will boot fedora’s grub.

UEFI is an open specification, but practically, Microsoft ended up in charge of the key situation because of their monopoly on the consumer market. shimx64.efi is therefore the default bootloader, the entry that fedora configures upon install, as it will work out-of-the-box on the largest number of systems. shimx64-fedora.efi is provided in instances that you want only fedora’s key to be enrolled in your system (this is my (quite confident) guess. Again, I’ll get back to you if I turn out to be wrong).

2 Likes

To directly answer your question: sure. You can try grubx64.efi if you want, but if it’s working, there’s no need to look further.

Also, while the two shim files aren’t exactly the same once stripped, diff says that the difference is just a newline after/in the header. I’ll consider that as good enough.

2 Likes

Thanks for the info! The command sudo efibootmgr --create --disk /dev/nvme0n1 --part 1 --label Fedora --loader "\EFI\fedora\shimx64-fedora.efi"worked perfectly and the system boots into GRUB again. Thanks for your help!

1 Like