Story / scenario opener
You just finished installing Fedora on a fresh drive or alongside Windows. You close the installer, hit reboot, and the screen goes dark. The BIOS or UEFI boot menu appears, but Fedora is nowhere to be found. Only Windows Boot Manager or a blank option shows up. You did not format the drive. You did not skip the bootloader step. The system simply refuses to acknowledge the new installation.
What is actually happening
Modern computers use UEFI firmware instead of legacy BIOS. The firmware does not scan hard drives for operating systems. It reads a small list of boot entries stored in non-volatile memory called NVRAM. Each entry points to a specific EFI executable on the EFI System Partition. The Fedora installer normally writes this entry automatically. It places shimx64.efi in /boot/efi/EFI/fedora/ and registers it with the firmware.
When Fedora disappears from the boot menu, the installer failed to write the NVRAM entry, or the firmware ignored it. This usually happens for three reasons. The ESP was not mounted correctly during installation. Secure Boot is enabled and the firmware rejects an unsigned or mismatched bootloader. Or Windows Fast Startup left the ESP in a read-only state, blocking the installer from writing the boot record. The files are still on the disk. The firmware just does not know where to look.
Think of NVRAM like a physical address book taped to the motherboard. The firmware only calls the numbers written in that book. If the installer crashes before writing the Fedora entry, the book stays empty. The disk contains the operating system, but the firmware has no way to find it. The boot chain relies on three files working together. shimx64.efi verifies signatures under Secure Boot. It hands control to grubx64.efi, which loads the kernel and initramfs. If the firmware cannot find the first file, the chain never starts.
Check the installer logs before touching the disk. Run journalctl -xeu anaconda from a live environment to see exactly where the bootloader step failed.
The fix
Boot into a Fedora live USB or recovery environment. You need a working terminal to inspect the disk layout and rebuild the boot entry. Open a terminal and check whether the EFI System Partition is mounted.
# Check if the ESP is mounted at the expected path
mount | grep efi
If the output is empty, mount the ESP manually. The partition usually has the EFI filesystem type and is labeled EFI. Find it with lsblk or blkid, then mount it.
# Identify the EFI partition device node
lsblk -f | grep -i efi
# Mount it to the standard bootloader path
sudo mount /dev/nvme0n1p1 /boot/efi
Verify that the Fedora bootloader files actually exist. The installer should have placed shimx64.efi and grubx64.efi in the correct directory.
# List the Fedora EFI directory to confirm files are present
ls -l /boot/efi/EFI/fedora/
If the files are there, the firmware just needs a new NVRAM entry. Use efibootmgr to create it. This tool talks directly to the UEFI firmware and writes the boot record without touching the disk layout.
# Create a new boot entry pointing to the Fedora shim
sudo efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "Fedora" --loader /EFI/fedora/shimx64.efi
# Set the new entry as the first option in the boot order
sudo efibootmgr --bootnext 0000
Reboot the machine. The firmware will now read the new entry and chainload the Fedora bootloader. If efibootmgr fails with a permission error, your firmware may have locked NVRAM writes. Disable Secure Boot temporarily in the firmware setup, run the command again, and re-enable Secure Boot afterward.
Always mount the ESP before running bootloader commands. Unmounted partitions cause silent failures that look like missing files.
Verify it worked
Check the NVRAM boot list before you reboot. The output should show your new Fedora entry with a valid file path.
# Display all registered UEFI boot entries with full paths
sudo efibootmgr -v
Look for the line containing Fedora and shimx64.efi. If it appears, the firmware has accepted the entry. Reboot and select it from the boot menu. If the system drops to a grub rescue> prompt instead of loading the desktop, the GRUB configuration is missing or corrupted. That is a separate issue from the missing boot menu entry.
Run efibootmgr -v first. Read the actual boot order before guessing which partition holds the bootloader.
Common pitfalls and what the error looks like
Secure Boot is the most frequent blocker. UEFI firmware checks the digital signature of every EFI executable before running it. Fedora ships with a signed shimx64.efi that chains to grubx64.efi. If the firmware database is out of date, it rejects the signature and hides the entry. You will see a message like Security Violation or Boot Failed on a black screen. The fix is to update the firmware or temporarily disable Secure Boot.
Windows Fast Startup causes silent failures. When enabled, Windows hibernates the kernel instead of shutting down completely. It locks the EFI System Partition in read-only mode. The Fedora installer cannot write the boot entry and fails silently. Disable Fast Startup in Windows power settings before installing Linux.
Legacy BIOS systems do not use EFI at all. If your machine is older than 2011, it likely uses MBR partitioning and grub2-install writes to the master boot record. The commands above will fail with EFI variables are not supported on this system. Check your firmware type with uname -r and dmesg | grep -i efi. If it says EFI not detected, you are on legacy BIOS. Use sudo grub2-install /dev/sda instead.
Mounting the wrong partition breaks the chain. The ESP must be a FAT32 partition with the boot and esp flags. Mounting a Linux ext4 partition to /boot/efi will cause efibootmgr to write to the wrong filesystem. The firmware will ignore it. Always verify the filesystem type before mounting.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. If you need to regenerate the GRUB configuration after fixing the boot entry, run sudo grub2-mkconfig -o /boot/grub2/grub.cfg from the installed system. Do not copy files manually from /usr/lib/grub/. The package manager will overwrite them on the next dnf upgrade --refresh.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use this vs alternatives
Use efibootmgr when you need direct control over the firmware boot order and want to bypass package manager scripts. Use grub2-install when you prefer the system to handle shim and GRUB chainloading automatically. Use the Windows Boot Manager when you want Windows to handle the initial boot and chainload Linux through BCD entries. Stay on the automatic installer defaults when you only have one operating system and want zero manual configuration.