How to Rescue a Fedora System That Won't Boot Using a Live USB

Systemd & Boot
2026-04-17T12:13:01+00:00
Fix a non-booting Fedora system by booting a Live USB, mounting the root partition, and reinstalling GRUB via chroot.

You run a routine dnf upgrade

You run a routine dnf upgrade, the screen flashes, and the next morning your monitor shows grub rescue> instead of your desktop. Or maybe a failed disk check left the filesystem in a read-only state and systemd refuses to start. The system is still there, but the path to the kernel is broken. You need to step outside the broken environment and repair it from the inside.

Boot the Live USB. Open a terminal. Follow the steps below to mount your disk, enter a chroot environment, and restore the boot chain.

What's actually happening

A Linux boot process is a chain of handoffs. The firmware loads the bootloader, the bootloader loads the kernel, and the kernel mounts the root filesystem and starts systemd. When that chain breaks, you are stuck at the first missing link. Chrooting from a Live USB gives you a working environment that can see and modify the broken disk. Think of it like using a spare key to enter a house where the main lock is jammed. You are not replacing the house. You are just fixing the lock from the inside.

The Live USB runs a completely separate kernel and userspace. It does not know about your installed system's partitions, users, or services until you explicitly attach them. Mounting the root partition gives the Live system access to your files. Binding /dev, /proc, and /sys gives the chroot environment access to hardware and kernel interfaces. Running chroot swaps the root directory for the Live session, making your installed system the active environment. You can then run package managers, bootloader installers, and filesystem checkers exactly as if you had booted normally.

Run journalctl -xe on a working system to see how systemd reports boot failures. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. You will not have that luxury on a broken boot, which is why the chroot method exists.

Mount the partitions before you guess. Half the time the symptom is a missing EFI mount point.

The rescue procedure

Follow these steps in order. Skipping a bind mount or mounting the wrong partition will leave you in a chroot that cannot see disks or network interfaces.

  1. Boot the Fedora Live USB and open a terminal. Select Troubleshooting then Rescue a Fedora system if your ISO includes it, or just open a terminal from the desktop. The rescue environment automates some mounts, but doing it manually guarantees you know exactly what is attached.

  2. Identify your root partition. You need the device name for the partition that holds /. Run lsblk to see the disk layout. Look for the partition that matches your expected size and filesystem type. If you use LVM, the device will be under /dev/mapper/ or /dev/vg_name/lv_name. If you use btrfs, the root subvolume is usually mounted at /.

Here's how to list block devices and identify the correct root partition for your system.

# List all block devices with filesystem labels and mount points
lsblk -f
# Identify the root partition device name from the output
# Replace /dev/nvme0n1p3 below with your actual root partition
ROOT_DEV="/dev/nvme0n1p3"
  1. Mount the root partition to /mnt. This creates the base directory for the chroot environment. If your system uses a separate /boot or /boot/efi partition, mount those as well. The bootloader configuration lives in /boot, so it must be visible inside the chroot.

Here's how to attach your root partition and any separate boot partitions to the Live environment.

# Mount the root filesystem to the temporary mount point
mount "$ROOT_DEV" /mnt
# Mount a separate /boot partition if it exists
# mount /dev/nvme0n1p2 /mnt/boot
# Mount the EFI system partition for UEFI systems
# mount /dev/nvme0n1p1 /mnt/boot/efi
  1. Bind mount the virtual filesystems. The chroot environment needs access to hardware devices, kernel parameters, and system services. Without these mounts, commands like dnf, grub2-install, or systemctl will fail with permission or device errors.

Here's how to attach the necessary virtual filesystems so the chroot environment can interact with the kernel and hardware.

# Bind mount /dev to expose block devices and terminals
mount --bind /dev /mnt/dev
# Bind mount /proc to expose kernel parameters and process info
mount --bind /proc /mnt/proc
# Bind mount /sys to expose hardware and driver information
mount --bind /sys /mnt/sys
# Bind mount /run to expose runtime service state
mount --bind /run /mnt/run
  1. Enter the chroot environment. This switches the Live session's root directory to your installed system. You are now operating inside your broken Fedora installation, but with a working Live kernel underneath.

Here's how to switch your terminal session into the mounted system environment.

# Change root to the mounted system directory
chroot /mnt
# Verify you are inside the installed system
# The prompt should reflect the hostname of your installed Fedora
hostname
  1. Check the filesystem if the boot failure followed a crash or power loss. A dirty filesystem will prevent the kernel from mounting / cleanly. Run fsck on the root partition before touching the bootloader. Unmount the partition first if it is still mounted read-only.

Here's how to verify filesystem integrity before attempting bootloader repairs.

# Exit chroot temporarily to run fsck on the root partition
exit
# Unmount the root partition if it is still attached
umount /mnt
# Run filesystem check with automatic repair
fsck -y /dev/nvme0n1p3
# Remount the root partition for the next steps
mount /dev/nvme0n1p3 /mnt
# Re-enter the chroot environment
chroot /mnt
  1. Reinstall the bootloader and regenerate the configuration. GRUB reads the kernel and initramfs from /boot. If the configuration file is missing or points to the wrong UUID, the system will drop to grub rescue>. Run grub2-install to write the bootloader to the disk, then run grub2-mkconfig to scan /boot and write a fresh configuration file.

Here's how to restore the GRUB bootloader and regenerate its configuration file.

# Install GRUB to the disk device (not the partition)
# Use /dev/sda or /dev/nvme0n1 for BIOS systems
grub2-install /dev/nvme0n1
# Generate a fresh GRUB configuration file
grub2-mkconfig -o /boot/grub2/grub.cfg
# Verify the configuration file was written
ls -l /boot/grub2/grub.cfg
  1. Exit the chroot and unmount everything cleanly. Leaving bind mounts attached can cause filesystem warnings on the next boot. Unmount in reverse order to avoid dependency errors.

Here's how to cleanly detach the chroot environment and prepare for reboot.

# Exit the chroot environment
exit
# Unmount virtual filesystems in reverse order
umount /mnt/run
umount /mnt/sys
umount /mnt/proc
umount /mnt/dev
# Unmount the root partition
umount /mnt
# Reboot the system
reboot

Reboot before you debug. Half the time the symptom is gone once the bootloader chain is restored.

Verify it worked

Watch the boot sequence carefully. The firmware should hand off to GRUB, GRUB should load the kernel, and systemd should start without dropping to an emergency shell. If the system boots normally, open a terminal and check the boot journal for lingering warnings.

Here's how to confirm the boot process completed successfully and review recent service logs.

# Check the current boot status and recent journal entries
journalctl -b -p warning
# Verify systemd reached the graphical or multi-user target
systemctl get-default
# Confirm the bootloader configuration matches the running kernel
grub2-editenv list

Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. GRUB configuration files generated by grub2-mkconfig live in /boot/grub2/, which is managed by the package manager. Manual edits to grub.cfg will be overwritten on the next kernel update.

Run journalctl -b first. Read the actual error before guessing.

Common pitfalls and what the error looks like

The grub2-install command will refuse to proceed and print Installing for i386-pc platform. grub2-install: error: will not proceed with blocklists. This happens when you pass a partition device like /dev/sda1 instead of the whole disk /dev/sda. GRUB needs the disk device to write the boot code to the partition table. Pass the disk device, not the partition.

If you see [FAILED] Failed to start systemd-fsck-root.service during boot, your filesystem check failed or the root partition UUID changed. The kernel cannot mount a corrupted root filesystem. Run fsck from the Live USB before reinstalling GRUB.

SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. A broken boot is rarely caused by SELinux. It is almost always a bootloader or filesystem issue.

The dnf upgrade --refresh command is the normal weekly maintenance command. dnf system-upgrade is for crossing major Fedora releases. They are different commands. Don't conflate them. A botched system-upgrade can leave you unable to boot. Run this from a backup VM first if you can.

Trust the package manager. Manual file edits drift, snapshots stay.

When to use this vs alternatives

Use a Live USB chroot when the bootloader is missing, the root filesystem is corrupted, or systemd fails to start and you cannot access a working shell. Use dnf system-upgrade when you are crossing major Fedora releases and want a managed transaction that handles kernel and package dependencies automatically. Use btrfs rescue or xfs_repair when the filesystem metadata is damaged and standard fsck cannot recover the structure. Stay on the upstream Workstation if you only deviate from the defaults occasionally. Use Silverblue when you want a known-good base image you can always roll back to. Use Server when you are running services and not a desktop.

Snapshot the system before the upgrade. Future-you will thank you.

Where to go next