You press the power button, the screen flashes the Fedora logo, and then it hangs. Or it drops you into a grub rescue> prompt with a blinking cursor. You just ran a routine dnf upgrade, maybe tweaked a kernel parameter, or a power cut interrupted a disk write. The system is stuck, and you need to get back to your desktop or server without wiping everything.
What's actually happening
Booting is a chain. The firmware hands off to the bootloader, which loads the kernel and initramfs, which then mounts the root filesystem and starts systemd. If any link breaks, the chain stops. Most boot failures on Fedora come down to three things. GRUB cannot find the kernel files. The initramfs is missing or corrupted. The storage driver is not available to mount the root partition. Think of it like a relay race. The baton drops at a specific handoff, and the runner stops. Your job is to find exactly where the drop happened.
Fedora keeps multiple kernel versions by default. When dnf upgrade runs, it installs the new kernel, runs dracut to build a matching initramfs, and updates the GRUB menu. If the power cuts during that process, or if a package dependency breaks, the new kernel might exist without a valid initramfs. GRUB will still load it, but the system will panic immediately because it cannot find the drivers to read the disk.
Run journalctl -b -1 -xe from a working terminal to see the exact failure point. The -b -1 flag targets the previous boot. The -x flag adds explanatory text to error lines. The -e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. Use that pattern to isolate the failing service.
Read the actual error before guessing. A botched upgrade can leave you unable to boot. Run this from a backup VM first if you can.
The fix: Rescue, chroot, and repair
You will need a Fedora Live USB. Insert it, boot from it, and open a terminal. The goal is to mount your installed system and run repair commands inside it. This avoids the broken bootloader entirely.
Mount the installed system
Identify your root partition first. The lsblk command shows the disk layout and filesystem types. Look for the partition with ext4 or xfs that matches your installed system size.
# List block devices to find the root partition
lsblk -f
# Mount the root partition to /mnt
sudo mount /dev/nvme0n1p3 /mnt
# Mount boot and EFI partitions if they are separate
sudo mount /dev/nvme0n1p2 /mnt/boot
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
Convention aside: Fedora installs on UEFI systems use a separate EFI System Partition. It usually mounts to /boot/efi. If your system uses legacy BIOS, you only need to mount the root partition and possibly a separate /boot.
Bind the virtual filesystems
A chroot environment needs access to hardware devices, process information, and runtime directories. Binding these paths makes the isolated environment behave like a running system. Commands like dnf or dracut will fail silently without them.
# Bind proc, sys, and dev to the chroot environment
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /dev /mnt/dev
# Bind run for systemd and temporary files
sudo mount --bind /run /mnt/run
# Enter the installed system
sudo chroot /mnt
Diagnose the failure point
You are now inside your broken system. Check the boot logs to see what actually failed. The journalctl command shows the last boot's events. If the system dropped to an emergency shell, the logs will contain the exact unit that triggered the halt.
# View the previous boot's journal, jump to end, show explanatory text
journalctl -b -1 -xe
# Filter specifically for systemd mount failures
journalctl -b -1 -u systemd-*.mount
If the output contains a line like the one below, the initramfs is missing the required storage driver. The kernel loaded, but it cannot mount the real root filesystem.
[FAILED] Failed to start Switch Root.
See 'systemctl status sysinit.target' for details.
Dependency failed for /sysroot.
Rebuild the bootloader
If the logs show GRUB errors or missing kernel files, regenerate the bootloader configuration. The grub2-mkconfig command scans /boot and rebuilds the menu. The grub2-install command writes the bootloader binaries to the disk. Always specify the raw disk device, not a partition.
# Reinstall GRUB to the EFI partition (UEFI systems)
grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=fedora
# Regenerate the GRUB configuration file
grub2-mkconfig -o /boot/grub2/grub.cfg
# Verify the new configuration contains the latest kernel
grep menuentry /boot/grub2/grub.cfg
Rebuild the initramfs
If the logs show Failed to start Switch Root or Dependency failed for /sysroot, the initramfs is broken. The initramfs contains the drivers needed to mount your root filesystem. If you updated the kernel but dracut failed, the new kernel cannot find your disk. Force a rebuild of the initramfs for the current kernel.
# Rebuild initramfs for the currently running kernel version
dracut -f --kver $(uname -r)
# Verify the new initramfs exists and has a recent timestamp
ls -lh /boot/initramfs-$(uname -r).img
# Check that critical drivers are actually inside the image
lsinitrd | grep -E "(nvme|xfs|ext4|dm-crypt)"
Convention aside: dracut -f overwrites the existing image. If you are troubleshooting a specific older kernel, pass the exact version string instead of $(uname -r). Fedora keeps multiple kernels by default. You can always boot an older one from the GRUB advanced menu if the newest one fails.
Check the filesystem table
A typo in /etc/fstab or a changed disk UUID will cause systemd to hang waiting for a mount that never arrives. Compare the UUIDs in the file with the actual disk output.
# Show current UUIDs for all mounted and unmounted filesystems
blkid
# Open the filesystem table for inspection
nano /etc/fstab
If the UUIDs match, the issue is likely a missing storage driver or an LVM/cryptsetup configuration problem. Run lsinitrd to verify the required drivers are actually inside the initramfs. Exit the chroot, unmount everything in reverse order, and reboot.
# Exit the chroot environment
exit
# Unmount in reverse order to avoid stale mount errors
sudo umount /mnt/run
sudo umount /mnt/dev
sudo umount /mnt/sys
sudo umount /mnt/proc
sudo umount /mnt/boot/efi
sudo umount /mnt/boot
sudo umount /mnt
# Reboot the system
sudo reboot
Run journalctl -b -1 -xe first. Read the actual error before guessing.
Verify it worked
Watch the boot sequence carefully. If the system reaches the login prompt, open a terminal and check the current boot status. The systemctl command shows whether critical units started cleanly.
# Check the overall boot status and highlight failed units
systemctl status --failed
# Review the current boot journal for any lingering warnings
journalctl -b -p warning
If systemctl status --failed returns nothing, the repair succeeded. Run dnf upgrade --refresh to ensure all packages are synchronized and metadata is fresh. dnf upgrade --refresh is the normal weekly maintenance command. dnf system-upgrade is for crossing major Fedora releases. They are different commands. Don't conflate them.
Reboot before you debug. Half the time the symptom is gone.
Common pitfalls and what the error looks like
Editing the wrong configuration directory is the most frequent mistake. Files in /usr/lib/ ship with the package and get overwritten on updates. Files in /etc/ are for user modifications. Always edit /etc/. Never edit /usr/lib/.
You will see error: unknown filesystem in the GRUB prompt when the bootloader cannot read the partition table. This usually means the partition type was changed to something GRUB does not recognize, or the EFI system partition is missing the boot flag.
If you encounter Failed to start Switch Root. Dependency failed for /sysroot, the initramfs is definitely broken. The kernel loaded, but it cannot find the drivers to mount the real root filesystem. Rebuilding with dracut -f fixes this in ninety percent of cases.
SELinux denials can also block boot services. You will see avc: denied messages in journalctl -t setroubleshoot. Read those one-line summaries before disabling SELinux. A missing file context or a mislabeled script is usually the culprit. Run restorecon -Rv /path/to/affected/dir to fix labeling.
UEFI secure boot will reject unsigned third-party kernel modules. If you installed a proprietary GPU driver or a custom kernel, the system will drop to a recovery shell. Disable secure boot in the firmware settings, or sign the modules with a MOK key.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use this vs alternatives
Use the rescue chroot method when the bootloader or initramfs is corrupted but the root filesystem is intact. Use a live USB with dd or clonezilla when the partition table or disk geometry is damaged. Use dnf reinstall grub2-efi shim when package files are missing or truncated. Use systemd-boot when you want a simpler, file-based bootloader that avoids GRUB configuration drift. Stay on GRUB if you need advanced menu scripting or legacy BIOS compatibility.