You ran sudo dnf upgrade and the system won't start
You ran sudo dnf upgrade, the screen went black, and the fans spun up like a jet engine. You waited. Nothing happened. You forced a reboot, and now the system drops to a (initramfs) prompt or hangs on a kernel panic. The monitor shows text you don't recognize. You need to get back to your desktop or server without wiping the disk.
The panic is normal. Fedora updates the kernel frequently, and occasionally a driver conflict, a filesystem error, or a bootloader misconfiguration breaks the chain. The system stops to protect your data. Recovery is usually straightforward. You just need to identify where the chain snapped and apply the right fix.
What the boot chain looks like
Fedora booting is a sequence of handoffs. The firmware hands control to the bootloader. The bootloader loads the kernel and the initramfs. The kernel mounts the root filesystem and hands off to systemd. Systemd starts services and launches the display manager. If any link breaks, the system stops.
A broken kernel module stops the kernel. A corrupted filesystem stops the mount. A missing bootloader entry stops the load. A misconfigured service stops systemd. The symptom depends on where the break occurs. A kernel panic points to the kernel or initramfs. A drop to (initramfs) points to the root filesystem. A black screen after the logo points to the display manager or a service failure.
Identifying the break point tells you which recovery path to take. Fedora keeps the last three kernels by default. This safety net exists exactly for this moment. If the current kernel is bad, an older one is almost always available.
Boot an older kernel when the current one panics
The fastest recovery is to boot a previous kernel. Fedora retains the last three kernel packages. If the update broke the latest kernel, the previous version usually works.
At the GRUB menu, select the entry with an older kernel version. If the menu is hidden, hold Shift or press Esc repeatedly during POST to reveal it. Once the system boots, remove the broken kernel to prevent it from being selected again.
Check which kernels are installed and remove the one causing the panic.
# List all installed kernel packages to find the version string
rpm -q kernel
# Remove the specific broken kernel package. dnf will keep the working ones.
sudo dnf remove kernel-6.8.0-100.fc41.x86_64
If you see a conflict error during removal, the package manager is protecting dependencies. Do not force the removal. Check if another package requires the kernel.
Error: Transaction test error: package kernel-core-6.8.0-100.fc41.x86_64 is needed by (installed) kernel-modules-6.8.0-100.fc41.x86_64
The error means you must remove the related packages together. dnf handles this automatically if you specify the base kernel package. Run sudo dnf remove kernel-6.8.0-100.fc41.x86_64 and let dnf pull in the dependencies for removal.
Boot the older kernel first. Verify the system works before deleting the broken kernel.
Force rescue mode by editing GRUB parameters
When the system fails to start services or drops to a shell, rescue mode gives you a root shell with minimal services running. This mode bypasses the normal boot target and lets you fix configuration files or reinstall packages.
At the GRUB menu, highlight the kernel entry and press e to edit the boot parameters. Find the line starting with linux. Move the cursor to the end of that line. Append systemd.unit=rescue.target. Press Ctrl+X to boot with the modified parameters.
linux /vmlinuz-6.8.0-100.fc41.x86_64 root=UUID=abc-123 ro quiet systemd.unit=rescue.target
The systemd.unit=rescue.target parameter overrides the default boot target. Systemd loads the rescue target instead of graphical.target or multi-user.target. This stops most services and drops you to a root prompt.
If the system asks for a root password, enter it. If you don't have a root password set, rescue mode may prompt you to create one. Use this opportunity to set a secure password.
Rescue mode gives you a root shell. Use it to fix configuration files or reinstall packages.
Repair filesystem errors from a Live USB
If the system drops to an (initramfs) prompt or reports filesystem errors, the root filesystem is likely corrupted. This can happen after an unclean shutdown, a power loss, or a disk failure. The kernel refuses to mount a corrupted filesystem to prevent data loss.
You cannot repair the root filesystem while it is mounted. Boot from a Fedora Live USB to access the disk without mounting it. Open a terminal in the Live environment.
Identify your root partition and run the filesystem check.
# List partitions with filesystem types to identify the root volume
lsblk -f
# Run filesystem check and auto-fix errors. Replace /dev/sda2 with your root partition.
sudo fsck -y /dev/sda2
If you use Btrfs, the standard fsck tool does not apply. Use the Btrfs-specific check tool.
# Check and repair Btrfs filesystem. Replace /dev/sda2 with your root partition.
sudo btrfs check --repair /dev/sda2
The --repair flag on Btrfs is aggressive. Only use it if the standard check reports errors that cannot be fixed otherwise. Btrfs has built-in redundancy. The repair tool can sometimes break data if the metadata is severely damaged.
If fsck reports errors it cannot fix, the disk may be failing. Back up your data immediately and replace the drive.
Run fsck on the unmounted partition. Never run fsck on a mounted root filesystem.
Reinstall GRUB from a chroot environment
When the bootloader is missing or corrupted, the system cannot find the kernel. This happens after a disk replacement, a partition resize, or a failed GRUB update. The firmware may show a "No bootable device" error or drop to a GRUB rescue prompt.
Boot from a Fedora Live USB. Mount your installed system and chroot into it to run commands as if you had booted normally.
# Mount the root filesystem to access the installed system
sudo mount /dev/sda2 /mnt
# Mount the EFI partition for UEFI systems. Adjust path if your layout differs.
sudo mount /dev/sda1 /mnt/boot/efi
# Bind mount virtual filesystems so chroot has access to devices and processes
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
# Change root into the installed system
sudo chroot /mnt
Once inside the chroot, reinstall GRUB and regenerate the configuration.
# Reinstall GRUB for UEFI systems. Adjust --efi-directory if your layout differs.
grub2-install --target=x86_64-efi --efi-directory=/boot/efi
# Regenerate the GRUB configuration file to detect all installed kernels
grub2-mkconfig -o /boot/grub2/grub.cfg
For legacy BIOS systems, the installation command differs. Use the disk device, not the partition.
# Reinstall GRUB for legacy BIOS. Replace /dev/sda with your disk device.
grub2-install /dev/sda
# Regenerate the configuration
grub2-mkconfig -o /boot/grub2/grub.cfg
The grub2-mkconfig command reads /etc/default/grub and scans for kernels. Always run it after reinstalling GRUB. A fresh install without a new config leaves the menu stale.
Exit the chroot, unmount the filesystems, and reboot.
# Exit the chroot environment
exit
# Unmount the bind mounts
sudo umount /mnt/sys
sudo umount /mnt/proc
sudo umount /mnt/dev
# Unmount the EFI and root partitions
sudo umount /mnt/boot/efi
sudo umount /mnt
Regenerate the config after reinstalling GRUB. A fresh install without a new config leaves the menu stale.
Verify the fix and read the logs
After recovery, you need to understand what broke. The logs contain the exact error that stopped the boot. Fedora stores logs in the journal. You can read logs from previous boot sessions even after a reboot.
Check the errors from the failed boot.
# Show errors from the previous boot session to confirm the failure source
journalctl -b -1 -p err
The -b -1 flag selects the previous boot. The -p err flag filters for error priority and above. This output shows the critical failures without the noise of informational messages.
If you see a service failure, check the status of that unit.
# Check the status and recent logs for a specific service
journalctl -xeu NetworkManager.service
The -xe flags add explanatory text and jump to the end. The -u flag filters by unit. This is the standard way to debug service failures.
Read the previous boot logs. The error message tells you exactly what broke.
Common pitfalls that break the boot
Forcing package updates breaks the system. If dnf reports a conflict, do not use --best or --skip-broken blindly. Resolve the dependency. A conflict usually means a third-party repository is providing a package that clashes with Fedora's packages. Remove the conflicting repo or pin the version.
Editing files in /usr/lib causes drift. Package updates overwrite those changes. Edit configuration in /etc. Files in /etc are user-modified. Files in /usr/lib ship with the package. The package manager manages /usr/lib.
SELinux denials can stop services. If a service fails to start, check the SELinux logs before disabling the security module.
# View SELinux denial messages with one-line summaries
journalctl -t setroubleshoot
The setroubleshoot service parses raw SELinux denials and provides actionable advice. Disabling SELinux hides the problem and leaves the system vulnerable. Fix the policy or restore the context instead.
Display manager failures look like boot failures. If the system boots but shows a black screen, the display manager may have crashed. Switch to a TTY with Ctrl+Alt+F3. Log in and check the status of GDM or SDDM.
# Check the status of the GNOME display manager
systemctl status gdm
Trust the package manager. Manual file edits drift, snapshots stay.
Choose the recovery path
Use the older kernel entry when the current kernel panics or hangs immediately after boot. Use rescue mode when the system fails to start services or drops to a shell. Use a Live USB and fsck when the system reports filesystem errors or cannot mount the root partition. Use chroot and grub2-install when the bootloader is missing or corrupted. Use journalctl to diagnose the cause after you have restored access.