The boot loop that won't end
You upgraded your system, a package manager transaction interrupted, or a kernel update went sideways. The screen hangs at a blinking cursor. The desktop environment refuses to load. You are staring at a system that refuses to boot, and a full reinstall feels like throwing away months of configuration. Grab a Fedora Live USB. You can mount your broken installation from a clean environment and fix the damage without touching your data.
What actually broke
A Fedora installation is a collection of packages, configuration files, and a bootloader sitting on disk. When a package transaction fails mid-flight, or when a critical system library gets overwritten by a third-party repository, the on-disk state no longer matches what the kernel expects at boot. The system tries to load services, finds missing binaries, and drops you to an emergency shell or a black screen.
The initramfs is the first piece of software that runs. It mounts the root filesystem and hands control to systemd. If the initramfs cannot find the kernel modules for your storage controller, or if systemd cannot read its unit files because /usr is empty, the boot process stops. The Live USB gives you a completely separate, working operating system. You use it as a bridge to reach your broken disk, mount the filesystems, and run repair commands in a controlled environment. Think of it like using a tow truck to jump-start a car with a dead battery. The tow truck does not replace the engine. It just gives you enough power to turn the key and run diagnostics.
Reboot before you debug. Half the time the symptom is gone.
Mounting the broken system
Boot the Live USB and select Try Fedora. Wait for the desktop to load. Open a terminal. The first step is finding your root partition. Fedora usually uses LVM on top of LUKS encryption, or plain partitions on older installs. You need the exact device path before you mount anything.
Run this command to map out your disk layout and identify the filesystem labels.
lsblk -f
# -f shows filesystem types and labels so you can spot your root partition
# Look for ext4 or xfs with a label like fedora_localhost or /
# Note the device path like /dev/nvme0n1p3 or /dev/mapper/fedora-root
# LUKS volumes show crypto_LUKS and require cryptsetup open first
Once you have the path, mount it to /mnt. This becomes the new root for your repair session. If you use a separate boot partition, mount it inside the chroot tree so the bootloader tools can find their files.
Attach the root and boot partitions to the temporary mount point.
sudo mount /dev/mapper/fedora-root /mnt
# Mount the actual root filesystem to /mnt for the chroot session
# Adjust the device path to match your lsblk output exactly
sudo mount /dev/nvme0n1p2 /mnt/boot/efi
# Mount the EFI system partition if your machine uses UEFI
# Skip this step if your system uses legacy BIOS boot
The chroot environment needs access to hardware and process information. You must bind-mount the virtual filesystems from the Live USB into the mounted tree. Without these, tools like dnf and systemd will fail because they cannot read device nodes or kernel parameters.
Link the Live USB virtual filesystems into your mounted installation.
sudo mount --bind /dev /mnt/dev
# Gives the chroot access to block devices and terminals
sudo mount --bind /proc /mnt/proc
# Exposes kernel and process information to the mounted system
sudo mount --bind /sys /mnt/sys
# Provides hardware and driver data for package managers
sudo mount --bind /run /mnt/run
# Shares runtime sockets and lock files needed by modern services
Chrooting and fixing packages
Enter the mounted system. The chroot command changes the apparent root directory for the current shell. You are now operating inside your broken installation, but using the Live USB kernel and hardware.
Switch your shell into the mounted filesystem.
sudo chroot /mnt /bin/bash
# Changes the root directory to /mnt for all subsequent commands
# You are now inside your installed Fedora system
# Run env to confirm PATH and HOME point to the mounted tree
Check the package database first. A corrupted RPM database or a missing critical package will cause boot failures. Verify the integrity of installed packages and look for mismatches.
Scan the package database for missing files or checksum mismatches.
rpm --verify --all 2>&1 | grep -v '^$'
# Checks every installed package against the RPM database records
# Prints lines starting with S5MDGcT if files differ in size, hash, or permissions
# Empty output means the database matches the disk state
If the verification output shows missing core packages or the command itself fails with a database error, rebuild the RPM metadata. This forces rpm to rescan the filesystem and reconstruct its internal indexes.
Reconstruct the package database and reinstall damaged packages.
rpm --rebuilddb
# Forces RPM to rescan /var/lib/rpm and rebuild its internal indexes
# Run this only when rpm commands fail with database lock or corruption errors
dnf reinstall coreutils systemd bash
# Pulls fresh copies of critical packages from the configured repositories
# Use specific package names instead of reinstalling everything blindly
If a third-party repository injected conflicting files, or if a partial dnf upgrade left the system in an inconsistent state, sync the package tree with the official repositories. This command aligns your installed versions with the repository metadata. Remember that dnf upgrade --refresh is the normal weekly maintenance command. dnf distro-sync is for crossing major Fedora releases or repairing severe version drift. They are different commands.
Align your installed packages with the official Fedora repositories.
dnf distro-sync --allowerasing
# Downgrades or removes packages that no longer match the repository versions
# The --allowerasing flag permits removing conflicting packages to resolve dependencies
# Run this only after verifying your repository configuration in /etc/yum.repos.d
Rebuilding the bootloader
Package repairs often leave the bootloader untouched. If your system drops to a GRUB shell or fails to find the kernel, you need to reinstall the bootloader stage files and regenerate the configuration.
Reinstall the GRUB EFI binary and regenerate the configuration file.
grub2-install --target=x86_64-efi --efi-directory=/boot/efi
# Writes the GRUB EFI executable to the mounted EFI system partition
# The --target flag matches your UEFI architecture
grub2-mkconfig -o /boot/grub2/grub.cfg
# Scans /boot for kernels and initramfs images to build the menu
# Outputs the final configuration file that GRUB reads at startup
Legacy BIOS systems use a different installation path. The bootloader writes to the Master Boot Record instead of an EFI partition.
Install GRUB to the disk partition table for legacy BIOS machines.
grub2-install /dev/sda
# Writes the boot stage to the MBR of the specified disk device
# Do not include a partition number like /dev/sda1
grub2-mkconfig -o /boot/grub2/grub.cfg
# Generates the menu configuration identical to the UEFI workflow
Verifying the repair
Exit the chroot environment and unmount the filesystems in reverse order. A clean unmount confirms that no processes are holding files open and that the disk state is consistent.
Leave the chroot and detach the mounted partitions safely.
exit
# Returns to the Live USB shell and closes the chroot environment
sudo umount -R /mnt
# Recursively unmounts /mnt and all bind-mounted subdirectories
# Run mount | grep /mnt to verify everything detached cleanly
Reboot the machine and remove the Live USB when the firmware prompts you. Watch the boot sequence. The system should load the kernel, mount the root filesystem, and drop you to a login prompt or desktop. Run journalctl -xe after login. Read the actual error before guessing.
Common pitfalls and what the error looks like
The chroot will fail if you skip the bind mounts. You will see mount: /mnt/dev: special device /dev does not exist or dnf: error while loading shared libraries: libcurl.so.4: cannot open shared object file. The virtual filesystems must be linked before entering the chroot.
SELinux denials frequently appear after manual package repairs. If services refuse to start after your fix, check the audit log. SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/.
Trigger a filesystem relabel on the next boot if services fail with permission errors.
touch /.autorelabel
# Creates a marker file in the root of the mounted system
# The initramfs detects this file and runs a full SELinux scan on boot
# Expect a longer boot time while labels are rewritten
Repository misconfigurations break dnf distro-sync. If you see Error: Failed to download metadata for repo 'updates', your network configuration inside the chroot is missing, or the repository mirrors are unreachable. Verify /etc/resolv.conf exists and contains valid nameservers before running package commands. Fedora's release cadence is 6 months. The N-2 release goes EOL when N+1 ships. Plan upgrades on that cycle. If your repositories point to an archived release, dnf will refuse to download packages.
Live USB vs rescue modes
Use the Live USB chroot when the system cannot mount the root filesystem or when the initramfs is completely broken. Use the built-in rescue mode when the kernel loads but a single service or configuration file causes the failure. Use emergency mode when you need a root shell but cannot afford to reboot or disconnect from a remote server. Stay on the Live USB when you suspect disk corruption and need to run fsck before touching the package manager.
Trust the package manager. Manual file edits drift, snapshots stay.