You upgraded Fedora and now the package manager is stuck
You ran dnf system-upgrade to jump from Fedora 40 to 42. The terminal finished without errors, you rebooted, and now your desktop environment is missing, your audio driver is gone, or dnf itself complains about broken dependencies. The upgrade process crossed release boundaries and left your package database in a transitional state. This happens when third-party repositories lag behind, when pre-release snapshots linger, or when the transaction manager hits an unexpected conflict.
What is actually happening
Fedora tracks every file on your system through a central RPM database. During a major release upgrade, the repository metadata changes completely. Package names shift, dependencies get rewritten, and old versions get retired. The upgrade transaction tries to swap everything out in one atomic operation. When it stumbles, the database ends up pointing to a mix of old release files and new release metadata.
Think of it like renovating a house while people are still living in it. You replace the wiring and plumbing, but a few rooms still have the old fixtures. The system boots because the kernel and initramfs survived, but user space is fragmented. dnf refuses to install new software because it cannot resolve the dependency graph across two different release versions. The package manager sees packages that belong to Fedora 40 sitting next to repositories that only serve Fedora 42. It blocks further transactions to prevent you from breaking the system further.
Reboot before you debug. Half the time the symptom is gone after a clean initramfs rebuild.
The recovery procedure
Follow these steps in order. Running them out of sequence can leave the RPM database in an inconsistent state.
- Realign installed packages to the new release repositories.
Here is how to force the package manager to match your installed software with the current release metadata.
sudo dnf distro-sync
# Realigns every installed package to the best available version
# in the active repositories. Unlike a normal upgrade, this command
# will downgrade packages if the repo version is lower than what
# is currently installed. This corrects leftover pre-release snapshots.
- Identify and remove packages that no longer exist in the repositories.
Old packages that were retired from Fedora will not be updated by distro-sync. Find them and remove what you do not need.
sudo dnf list extras
# Lists packages installed on the system that are not available
# in any currently enabled repository. These are usually retired
# or renamed packages from the previous release.
Review the output. Remove anything you no longer use.
sudo dnf remove <package-name>
# Removes the orphaned package and any dependencies that were
# installed solely for it. Run this for each package from the
# extras list that you do not actively use.
- Clean up orphaned dependencies.
sudo dnf autoremove
# Removes packages that were automatically installed as dependencies
# but are no longer required by any manually installed package.
# This keeps the system lean after removing orphaned software.
- Reinstall packages with missing or corrupted files.
If individual applications crash or report missing libraries, reinstall the affected packages.
sudo dnf reinstall <package-name>
# Downloads the package again and overwrites the existing files.
# This fixes cases where the upgrade transaction interrupted a
# file extraction or where disk I/O errors corrupted the payload.
For widespread corruption, verify the entire system and reinstall failing packages in bulk.
sudo rpm -Va 2>/dev/null | awk '{print $NF}' | xargs -I{} rpm -qf {} 2>/dev/null | sort -u | xargs sudo dnf reinstall -y
# Verifies all installed packages against the RPM database.
# Extracts the file path, maps it back to the owning package,
# deduplicates the list, and forces a reinstall of every package
# that reports a mismatch in size, checksum, or permissions.
- Rebuild the RPM database if transactions fail with database errors.
A corrupt RPM database causes confusing errors that look like package conflicts. Rebuild it when dnf refuses to parse metadata.
sudo rpm --rebuilddb
# Reconstructs the RPM database indexes from the actual files
# on disk. This takes a few minutes on a typical desktop system.
# Run this only when you see explicit database lock or parse errors.
- Disable third-party repositories that have not caught up to the new release.
Third-party repositories like RPM Fusion or COPR may not yet have packages built for the new Fedora release. Disable a suspect repository temporarily and retry the sync.
sudo dnf distro-sync --disablerepo=rpmfusion-free --disablerepo=rpmfusion-free-updates
# Temporarily ignores the specified repositories during the sync.
# This prevents the package manager from pulling incompatible
# packages that block the transaction. Re-enable them once the
# third-party maintainers publish updated builds.
- Clear the metadata cache and retry.
Stale cache files can make dnf think the repositories are still serving the old release.
sudo dnf clean all
# Removes all cached metadata, package files, and database locks.
# Forces the next command to download fresh repository information.
sudo dnf distro-sync
# Runs the realignment again with clean metadata. This often
# resolves phantom conflicts caused by cached repository states.
Run journalctl -xe after the sync finishes. Read the actual error before guessing.
Verify the system is clean
Run a full verification pass to confirm every file matches the RPM database.
sudo rpm -Va
# Checks every installed package against its recorded metadata.
# A clean run produces no output. Any lines printed indicate
# differences in file size, permissions, or cryptographic hashes.
Check the boot journal for lingering service failures.
journalctl -b -p err
# Shows only error-level messages from the current boot.
# Look for dependency resolution failures, missing shared libraries,
# or service start timeouts that survived the package sync.
If rpm -Va returns clean and journalctl shows no critical errors, your system is aligned with the new release. Reboot once more to ensure all services load with the updated libraries.
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and error patterns
You will see specific error strings when the upgrade leaves fragments behind. Recognize them early to avoid forcing transactions that break the system.
The dnf distro-sync command will refuse to proceed and print Error: Transaction test error: package python3-3.12.x conflicts with python3-3.13.y. The conflict is intentional. Read the next paragraph before forcing. Fedora intentionally splits major Python versions across releases. Forcing the install will break the entire scripting stack. Run dnf distro-sync without --skip-broken to let the solver handle the transition.
If you see [FAILED] Failed to start NetworkManager.service during boot, your network configuration probably references a missing interface name. Fedora switched to predictable network interface naming years ago. Old ifcfg files in /etc/sysconfig/network-scripts/ may still reference eth0. Edit /etc/. Never edit /usr/lib/. The user configuration directory overrides the package defaults.
SELinux denials often masquerade as package corruption. When a service fails to start after an upgrade, check the audit log before reinstalling software.
journalctl -t setroubleshoot
# Filters the journal for SELinux troubleshooting messages.
# Each denial includes a one-line summary and a suggested fix.
# Most post-upgrade denials are resolved by running restorecon
# on the affected directory tree.
dnf upgrade --refresh is the normal weekly maintenance command. dnf system-upgrade is for crossing major Fedora releases. They are different commands. Do not conflate them. Running system-upgrade on a stable system will trigger an unnecessary reboot cycle and can interrupt running services.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
When to use this vs alternatives
Use dnf distro-sync when you need to realign installed packages with the current release repositories after a major upgrade. Use dnf system-upgrade when you are preparing to cross release boundaries and want a staged, reboot-aware transaction. Use rpm --rebuilddb when the package manager reports database parse errors or lock failures that block all transactions. Use dnf reinstall when individual applications crash due to missing or corrupted files after an interrupted upgrade. Use dnf autoremove when you want to clean up dependencies that were pulled in by retired packages. Stay on the upstream Workstation if you only deviate from the defaults occasionally.