G4 desktop, Fedora 44 on SDA. Decided to try RakuOS on a spare NVMe. Booted the G4 again and Fedora wouldn’t boot from SDA.
The EFI entry exists. The files are there. But the UEFI firmware just skips SDA and boots something else.
understanding the problem
Your computer’s EFI system (UEFI firmware) has a boot order list. That list points to files on disk that tell the firmware how to boot each OS. If that pointer gets broken or the bootloader itself isn’t properly initialized, the entry becomes dead weight. It exists but doesn’t work.
When you install another distro on a different drive, the UEFI firmware can lose track of what it’s supposed to do with Secure Boot settings. It gets paranoid. Even if you disabled Secure Boot in BIOS, the firmware cached the old state or just doesn’t trust you anymore.
the standard fix (what works 90% of the time)
First, regenerate the GRUB configuration file. This tells GRUB what operating systems are available and how to boot them:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
What this does: GRUB scans your disks, finds all installed OSes, and writes them into a config file. It found my CachyOS on NVMe and Fedora on SDA.
Output on my system:
Generating grub configuration file ...
Found CachyOS on /dev/nvme0n1p2
Adding boot menu entry for UEFI Firmware Settings ...
done
That worked fine. Then I tried to actually install the bootloader to the EFI partition:
sudo grub2-install --efi-directory=/boot/efi /dev/sda
What this does: grub2-install writes the actual bootloader code to your EFI System Partition on /dev/sda. This is what the firmware actually reads when it boots. It’s like writing the actual boot instructions to disk.
But it threw this at me:
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. Make sure Secure Boot is
disabled before proceeding.
Translation: “Hey, I think Secure Boot is on, and I won’t write the bootloader if it is, because Secure Boot will just refuse to load it anyway.”
checking if secure boot is actually off
This is the part where you verify. BIOS says Secure Boot is off, but grub2-install doesn’t believe it. Check what the system actually thinks:
mokutil --sb-state
What this does: mokutil is the “Machine Owner Key” utility. It talks directly to the firmware and tells you the actual Secure Boot state, not what BIOS settings say. This is the source of truth.
Output on my system:
SecureBoot disabled
54 52 10
Secure Boot is literally disabled. The firmware confirmed it. But grub2-install still refused.
checking the boot entries
Let’s see what the firmware actually has registered:
efibootmgr -v
What this does: efibootmgr lists every boot entry the firmware knows about. It shows the order they boot in, what they point to, and whether they’re active. The -v flag shows verbose details.
My output (simplified):
BootOrder: 0006,0000,0004,0003
Boot0006* Fedora 44 HD(1,GPT,e7578f70-a442-4cdb-9c71-83899fcd2b5e,0x800,0x12c000)/\EFI\fedora\shimx64.efi
Boot0001* Fedora HD(1,GPT,e7578f70-a442-4cdb-9c71-83899fcd2b5e,0x800,0x12c000)/\EFI\fedora\shimx64.efi
Translation: Boot entry 0006 is first in the boot order. Both 0006 and 0001 point to the same EFI file (shimx64.efi) on the same partition. Everything looks right on paper. The firmware should follow that pointer.
But it doesn’t. Why? Because the actual GRUB bootloader code in the EFI System Partition is out of sync with the boot entry. The entry points to the file, but the file isn’t properly initialized. The firmware looks at the entry, tries to follow it, finds nothing it recognizes, and gives up.
the actual fix
This is the part that works:
sudo grub2-install --efi-directory=/boot/efi --force /dev/sda
The --force flag is the key. It tells grub2-install: “Stop complaining about Secure Boot. I verified it’s off with mokutil. Write the bootloader anyway.”
What this actually does: grub2-install writes the bootloader code directly to the EFI System Partition. It initializes the firmware’s EFI environment so that when the boot entry points to shimx64.efi, the firmware can actually find it and boot it.
Output on my system:
Installing for x86_64-efi platform.
Done. No errors.
That’s it. No complaints. The bootloader is now written.
why this works
The problem was never the boot entry itself. The entry existed and pointed to the right place. The problem was that the bootloader code wasn’t actually initialized in the EFI partition. The entry was a pointer to nothing.
When you installed RakuOS on a different drive, the UEFI firmware’s internal state got confused. Maybe it cached old Secure Boot settings, maybe it just got paranoid. Either way, grub2-install didn’t trust that Secure Boot was actually off.
But you verified it with mokutil. The firmware confirmed it. So using --force is safe. It just writes what should have been there all along.
the full steps i actually ran
- Regenerate GRUB config:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
- Verify Secure Boot is off:
mokutil --sb-state
# SecureBoot disabled
- Check the boot entries (optional but useful):
efibootmgr -v
# Both Fedora entries pointing to the right EFI file!
- Force grub2-install to write the bootloader:
sudo grub2-install --efi-directory=/boot/efi --force /dev/sda
- Reboot:
sudo systemctl reboot
Fedora 44 on SDA booted. Back in business.
takeaway
Multibooting or testing other distros on spare drives can leave the UEFI firmware in a confused state. grub2-install gets paranoid about Secure Boot even when it’s actually off.
Always verify actual state with mokutil before wasting time. If grub2-install still refuses despite mokutil confirming Secure Boot is disabled, use --force. It’s safe. The bootloader just needs permission to initialize itself.
Don’t re-disable Secure Boot. Don’t reinstall packages in different versions. Just force it and move on.