You dropped into a bare prompt
You run a routine package update, resize a partition, or change disk encryption settings, and the next boot stops at a black screen. The system either hangs at the manufacturer logo or drops you into a bare grub> prompt. The panic is understandable. The operating system is still there. Your files are intact. The bootloader just lost its map.
What is actually happening
GRUB is the first program the firmware runs after the power button is pressed. It reads the disk geometry, locates the kernel and the initial ramdisk, and hands execution over to Linux. When GRUB breaks, it is almost always because the EFI System Partition got reformatted, the /boot directory structure changed, or the configuration file got overwritten by a manual edit. The root filesystem is untouched. You need to boot from external media, mount the installed system, and tell GRUB where everything lives again.
Think of GRUB like a concierge at a hotel. The guest rooms are fine. The concierge just forgot where the keys are. You are going to hand the keys back and update the directory. On modern UEFI hardware, the firmware loads a signed shim binary first. The shim verifies the signature chain and then loads GRUB. If the shim or GRUB binary gets wiped, the firmware has nothing to execute. The repair process restores that chain and rebuilds the menu configuration.
The repair procedure
You will need a Fedora Live USB. If you do not have one, grab the latest Workstation ISO from getfedora.org and write it to a drive. Boot from it and select Try Fedora. Open a terminal on the live desktop. You will work entirely from this environment until the system reboots.
Here is how to identify your disk layout so you know exactly what to mount.
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT
# WHY: Shows device names, sizes, filesystem types, and current mount points.
# WHY: Look for your root partition (usually ext4 or btrfs) and the EFI partition (vfat, ~100-500MB).
Note the device paths. The root partition is typically /dev/nvme0n1p2 or /dev/sda2. The EFI partition is usually /dev/nvme0n1p1 or /dev/sda1. If you use LVM or btrfs subvolumes, the root mount point will differ, but the EFI partition remains a standard FAT32 volume. Write the paths down before proceeding.
Here is how to mount the installed system and prepare the virtual filesystems for a chroot environment.
sudo mount /dev/nvme0n1p2 /mnt
# WHY: Attaches your actual root filesystem to the live environment's /mnt directory.
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
# WHY: Mounts the EFI partition. Skip this line only if you are on legacy BIOS hardware.
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
# WHY: Binds virtual filesystems so the chroot environment can access hardware, processes, and runtime data.
The bind mounts are mandatory. Without /dev and /proc, package managers and bootloader utilities will fail with permission errors or missing device nodes. Fedora follows the standard Linux convention where /etc holds user modifications and /usr/lib holds package defaults. The chroot will respect that boundary once the virtual filesystems are linked. Never edit files in /usr/lib/ to fix boot issues. Edit /etc/ or use the restoration tools.
Here is how to drop into the installed system.
sudo chroot /mnt
# WHY: Changes the root directory for the current shell to /mnt, giving you a live view of the installed OS.
You are now inside your broken system. The prompt will look normal. Run the bootloader installation command next. The exact command depends on your firmware type.
Here is the command for UEFI systems, which covers almost every machine built in the last decade.
grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=fedora
# WHY: Compiles and installs the GRUB EFI binary into the mounted EFI System Partition.
# WHY: The --bootloader-id flag creates a dedicated folder in /EFI/ to avoid conflicts with other OSes.
# WHY: This command also writes the necessary EFI variables so the firmware knows where to look.
Here is the command for legacy BIOS or MBR systems.
grub2-install /dev/nvme0n1
# WHY: Writes the GRUB stage1 bootloader to the Master Boot Record of the entire disk.
# WHY: Never pass a partition number like /dev/nvme0n1p1 here. The MBR lives in the first 512 bytes of the disk.
# WHY: The command scans the disk for the core image and links the two stages together.
If the command finishes without errors, the binary is in place. The configuration file still needs to be rebuilt.
Here is how to regenerate the GRUB menu configuration.
grub2-mkconfig -o /boot/grub2/grub.cfg
# WHY: Scans the system for kernels, initramfs images, and other operating systems.
# WHY: Writes the output to the main configuration file that GRUB reads at boot time.
# WHY: This step is required every time you change kernel versions or add new disks.
On some UEFI installations, the configuration file lives at /boot/efi/EFI/fedora/grub.cfg instead. Check both paths if the first one returns a file not found error. The grub2-mkconfig command usually handles the correct path automatically, but explicit verification prevents silent failures.
Here is how to cleanly exit the chroot and reboot.
exit
# WHY: Returns to the live environment shell.
sudo umount -R /mnt
# WHY: Recursively unmounts all bind mounts and the root filesystem in the correct order.
sudo reboot
# WHY: Restarts the machine so the firmware can load the freshly installed bootloader.
Run journalctl first. Read the actual error before guessing.
Verify the boot chain
Watch the boot sequence carefully. The GRUB menu should appear, listing the current kernel and any older recovery kernels. Select the top entry and let it load. If the desktop appears, the repair is complete. Open a terminal and run journalctl -xe to check for lingering warnings. The x flag adds explanatory text and the e flag jumps to the end of the log. Most sysadmins type journalctl -xeu <unit> by muscle memory. Look for any grub or boot related errors. If the logs are clean, the system is stable.
Reboot before you debug. Half the time the symptom is gone once the bootloader chain is restored.
Common pitfalls and exact error strings
The repair process usually works on the first try. When it fails, the error message tells you exactly what went wrong.
Secure Boot can block unsigned bootloader binaries. If the system hangs at the manufacturer logo or drops to a firmware setup screen, enter the UEFI settings and verify Secure Boot status. Fedora ships a signed shim binary that chains to GRUB. If you compiled a custom kernel or modified the EFI partition manually, the signature chain breaks. Re-enable Secure Boot only after restoring the original Fedora shim.
SELinux context drift happens when files are copied or mounted incorrectly. If grub2-install prints Error: Could not stat source file or complains about missing labels, run restorecon -Rv /boot inside the chroot before regenerating the configuration. This resets the security contexts to their package defaults. SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling the security module.
Dual boot setups often lose Windows entries after a GRUB reinstall. The GRUB menu will only show Linux kernels. This happens because os-prober is not installed by default on newer Fedora releases. Install it and rebuild the menu.
sudo dnf install os-prober
# WHY: Adds the utility that scans other partitions for Windows, macOS, or other Linux installations.
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
# WHY: Regenerates the menu with the newly discovered operating systems.
If you see [FAILED] Failed to start grub-bootmenu.service during boot, your configuration file references a missing kernel or an incorrect initramfs path. Run ls /boot/vmlinuz-* and ls /boot/initramfs-* to verify the files exist. Mismatched versions cause the boot menu to fail silently. Fedora's release cadence is six months. The N-2 release goes EOL when N+1 ships. Plan upgrades on that cycle to avoid orphaned kernel entries in the menu.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use this versus other tools
Use the Live USB chroot method when the bootloader binary is missing, corrupted, or pointing to the wrong partition. Use dnf reinstall grub2-efi shim when the package files are intact but the configuration got overwritten by a manual edit. Use btrfs rescue or lvm vgchange -ay when the root filesystem itself is unmounted or marked as inactive. Use the firmware recovery console when the EFI System Partition was accidentally formatted and needs to be recreated from scratch.