You picked the wrong boot entry and now the system won't start
You plug in the USB drive, press F12, and see two entries for the same device. One says UEFI: Fedora, the other just says Fedora. You pick the one without the prefix because it looks simpler. The installer runs, you finish, and the next reboot drops you into a grub rescue> prompt or the firmware reports No bootable device. The firmware mode you chose at that exact moment locks in the partition layout and bootloader path for the entire installation. Fedora's installer, Anaconda, adapts to the mode you booted it in. If you boot the installer in BIOS mode, you get a BIOS installation. If you boot in UEFI mode, you get a UEFI installation. The mode is baked in at install time.
Reboot before you debug. Half the time the symptom is gone.
What's actually happening
Think of the firmware as the building's front desk. Legacy BIOS is an old desk that only accepts paper forms. It shouts commands to the first sector of the disk and expects the bootloader to live in the Master Boot Record. UEFI is a modern desk with a computer. It reads a structured directory called GPT, looks for a specific folder on a FAT32 partition, and executes a signed binary file.
The difference changes how the disk is partitioned, where the bootloader lives, and whether Secure Boot can function. UEFI requires an EFI System Partition (ESP) formatted as FAT32. The ESP holds the bootloader binaries in /EFI/fedora/. Legacy BIOS writes the bootloader to the MBR or, if you use GPT, to a special bios_grub partition. Secure Boot only works on UEFI systems because it relies on the firmware verifying digital signatures in the boot chain. Fedora ships with a Microsoft-signed shim bootloader, so Secure Boot works out of the box.
The firmware mode locks the disk layout. Choose correctly before the installer touches the disk.
How to check which mode your system booted in
The kernel exposes the firmware interface through sysfs. If the system booted in UEFI mode, the EFI runtime variables are mounted. If the directory is missing, the system booted in Legacy BIOS mode.
Here's how to check whether the EFI runtime interface is present and active.
# Check if the EFI runtime interface is mounted.
# An empty output means BIOS mode. A list of files means UEFI mode.
ls /sys/firmware/efi/efivars
# List UEFI boot entries stored in firmware NVRAM.
# This command fails on BIOS systems with "EFI variables are not supported".
sudo efibootmgr -v
Check the directory first. The presence of /sys/firmware/efi is the definitive signal.
Booting the Fedora installer in UEFI mode
Modern hardware defaults to UEFI, but many systems enable CSM (Compatibility Support Module) by default. CSM creates a hybrid boot menu that allows UEFI firmware to emulate BIOS. This invites mistakes. Disable CSM in the firmware settings to force a clean UEFI environment.
Here's how to write the ISO and boot the installer in UEFI mode.
# Write the ISO to the USB device. Replace /dev/sdX with your actual device.
# The oflag=direct flag improves write performance by bypassing the page cache.
sudo dd if=Fedora-Workstation-Live-x86_64-40-1.6.iso of=/dev/sdX bs=4M status=progress oflag=direct
# Sync the write buffer to ensure all data is flushed to the device.
# Skipping this step can result in a corrupted USB drive.
sudo sync
Enter the firmware setup by pressing F2, F10, Del, or Esc at startup. Disable CSM or Legacy Boot support. Save and exit. Boot the USB drive and select the entry labeled UEFI: [Drive Name]. Anaconda will detect the UEFI environment and automatically create an EFI System Partition.
Disable CSM in the firmware settings. A hybrid boot menu invites mistakes.
Recovering a broken UEFI boot entry
If the boot entry gets deleted or corrupted, the firmware won't find Fedora. You can restore the bootloader from a Live USB without reinstalling. This procedure requires mounting the root filesystem and chrooting into the installed system.
Here's how to restore the GRUB bootloader from a Live environment.
# Mount the root filesystem to prepare for chroot.
# Adjust /dev/nvme0n1p2 to match your root partition.
sudo mount /dev/nvme0n1p2 /mnt
# Mount the EFI System Partition at the correct path inside the chroot.
# The path must be /mnt/boot/efi for UEFI systems.
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
# Bind mount virtual filesystems so the chroot environment functions correctly.
# This provides access to /proc, /sys, and /dev inside the target system.
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /dev /mnt/dev
# Enter the installed system.
sudo chroot /mnt
Inside the chroot, reinstall GRUB to the ESP. The --target flag specifies the architecture and firmware interface. The --efi-directory flag points to the mounted ESP.
# Reinstall the GRUB bootloader to the EFI System Partition.
# The --target flag specifies the architecture and firmware interface.
# The --efi-directory flag points to the mounted ESP.
grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Fedora
# Regenerate the GRUB configuration file.
# This scans for kernels and other operating systems.
grub2-mkconfig -o /boot/grub2/grub.cfg
# Exit the chroot environment.
exit
Unmount the filesystems and reboot. The firmware should now detect the restored boot entry.
Reinstall GRUB from the chroot. The bootloader binary must match the firmware mode.
Verify it worked
After installation or recovery, confirm the boot entry exists and the ESP is mounted correctly. The ESP must be formatted as vfat and mounted at /boot/efi.
Here's how to verify the UEFI boot configuration and ESP mount point.
# List the UEFI boot entries stored in the firmware NVRAM.
# Look for a Fedora entry with a Boot#### number.
sudo efibootmgr -v
# Verify the EFI System Partition exists and is mounted correctly.
# The filesystem must be vfat and mounted at /boot/efi.
findmnt /boot/efi
# Check the bootloader chain in the ESP.
# The shim loads GRUB, which loads the kernel.
ls -l /boot/efi/EFI/fedora/
Run efibootmgr before you reboot. If the entry is missing, the firmware won't find the OS.
Common pitfalls and what the error looks like
Mixing firmware modes and partition schemes causes boot failures. UEFI requires GPT. Legacy BIOS works with MBR or GPT. If you use GPT with Legacy BIOS, you must create a bios_grub partition. This is a 1MB partition with type BIOS boot. GRUB stores its core image here. Without it, grub2-install fails with Embedding is not possible.
Secure Boot denials appear when unsigned modules or kernels are loaded. The kernel taints itself and logs a warning. If the shim blocks an unsigned kernel, the boot stops entirely.
Here's what a Secure Boot denial looks like in the journal.
kernel: signature and/or required key missing - tainting kernel
kernel: Loading module signed with unknown key
kernel: module verification failed: signature and/or required key missing - tainting kernel
Third-party modules like NVIDIA drivers require Machine Owner Key (MOK) enrollment. Use mokutil --import to enroll a key and reboot to complete the process. Fedora's akmods package handles this automatically for RPM Fusion drivers.
Edit /etc/default/grub to change boot parameters. Never edit /boot/grub2/grub.cfg directly. That file is generated and will be overwritten. Run sudo grub2-mkconfig -o /boot/grub2/grub.cfg after changes.
If you see grub rescue>, you booted the wrong mode or the partition table is corrupted. Restore the backup or reinstall.
When to use this vs alternatives
Use UEFI mode when you have hardware manufactured after 2012 and want Secure Boot support. Use UEFI mode when you need to boot from disks larger than 2TB. Use Legacy BIOS mode only when your hardware predates 2012 and lacks UEFI firmware. Use Legacy BIOS mode when you are maintaining a server that requires a specific legacy driver stack incompatible with UEFI.
Default to UEFI. Legacy BIOS is a compatibility shim for obsolete hardware.