Broken dependencies in dnf almost never get fixed by reflexively running dnf install --best --allowerasing. To fix broken dependencies in dnf, read the actual transaction error, refresh your metadata, and trace the failing chain with dnf repoquery --deplist and /var/log/dnf.rpm.log. The real problem is usually stale cache, a mismatched third-party repo, or one genuinely orphaned package. Fix the root cause. Do not nuke packages until the red text goes away.

Last updated: 2026-07-21

I've lost enough evenings to this to skip the guessing. Those .rpm files are just containers. The web of dependencies behind them is where things break, and I'll show you the exact steps I use to cut through it.

What does dnf actually mean when it reports broken dependencies?

Read the error before you type anything. When dnf's depsolver cannot build a working transaction, it prints the exact reason near the bottom, and people scroll right past it.

There are three phrases worth learning by sight. nothing provides X needed by Y means a real unmet dependency: something wants a library or package that no enabled repo ships. package A conflicts with B means two packages cannot coexist. And Skipping packages with broken dependencies means dnf quietly dropped something to save the rest of the transaction.

That last line is the trap. dnf tells you a package was skipped but not always why, so you think the update worked. Run dnf check to list existing dependency problems on the installed system. That tells you whether the break is already on disk or only in the pending transaction.

For the full history, read /var/log/dnf.rpm.log and /var/log/dnf.log. Every transaction, every erase, every failure is timestamped there. When a package broke last Tuesday and you have no idea what changed, that log is the answer.

Check whether your metadata is stale before blaming the packages

Stale cache causes more phantom dependency errors than actual broken packages. dnf resolves against its cached copy of each repo's metadata, and that copy expires on a schedule. If the cache is old, dnf hunts for a version the mirror already replaced.

So run this first:

sudo dnf clean all
sudo dnf --refresh upgrade

clean all wipes the cached metadata and packages. The --refresh flag forces a fresh download of repo data before it resolves anything. Most "broken dependency" reports vanish right here, because the error was never the package. It was dnf reading a menu from last week.

Then confirm your repos are reachable with dnf repolist. A repo that shows zero packages or times out is your real suspect, not the software you were trying to install. Check the output before you go further.

How do you fix dnf skipped packages with broken dependencies?

Force the error into the open, because a skipped package hides its reason by design. Add --best to make dnf attempt the newest version and fail loudly instead of silently dropping it.

1. Run sudo dnf --best upgrade and read the nothing provides line it prints.
2. Take the named package and run dnf repoquery --deplist <package> to see its full dependency list and which provider each one expects.
3. Cross-check the missing provider with dnf repoquery --whatprovides '<capability>'. If nothing comes back, no enabled repo ships it. That's your gap.
4. If a weak dependency is the culprit, retry with --setopt=install_weak_deps=False to skip the optional recommends and get the core package in.

Weak dependencies are the "recommends" a package would like but does not strictly need. dnf pulls them by default, and sometimes one of them is what's actually broken. Turning them off is a clean test, so don't leave it set forever.

If deplist shows the chain resolves fine but dnf still skips it, the break is one layer deeper: a conflict, not a missing provide. That's a different fix.

Telling a broken dependency apart from a package conflict

dnf blurs these two, and the fix is completely different, so pin down which one you have. A broken dependency is a hole: something is missing and needs to be provided. A conflict is a collision: two things both want the same file or capability and cannot both install.

Chasing a conflict as if it were a missing dependency is how you end up erasing packages you needed. Read which noun dnf used, "provides" or "conflicts", and treat them as separate problems.

When –best and –allowerasing help, and when they make it worse

Use --best freely as a diagnostic. Use --allowerasing only after you have read exactly what it plans to erase. These flags are not a reflexive first move, and treating them like one is how a one-package problem becomes a stripped system.

Here is what happens. --best tells dnf to insist on the newest version and report the precise failure instead of falling back. That's useful. It surfaces the real error. --allowerasing permits dnf to remove installed packages to satisfy the transaction. It will happily rip out something important to make the math work.

The rule I follow: dnf always prints the removal list before it acts. Read that list. If it wants to erase your desktop environment or a database you run, abort. If it's clearing one orphaned library you don't use, let it. The flag is fine. Running it blind is not.

How do you fix broken dependencies in Fedora without breaking your system?

Fedora breaks dependencies in a few predictable ways, and the order you fix them in matters. Work from most common to most drastic.

The usual causes are a half-finished release upgrade, leftover packages from a disabled COPR, and kernel module builds that lag behind a new kernel. Each has a safe move.

For a single broken package that upstream ships correctly, force a clean reinstall with sudo dnf --refresh reinstall package_name. The refresh pulls fresh metadata, and the reinstall replaces every file from that package. This is my go-to on Fedora, CentOS, and RHEL when one package is corrupt but the repo is healthy.

For kernel module mismatches, akmod or dkms rebuilds often trail a kernel bump, which shows up as a module that won't load. My guide to the failed to load kernel modules error walks the diagnosis. If a fresh kernel is the trigger, boot the previous one and confirm it's stable before you do anything else. My notes on rolling back a kernel update cover that safely.

For a stalled release upgrade, finish it with dnf system-upgrade rather than upgrading package by package. Piecemeal upgrades across a release boundary are how you get a genuinely wedged system.

Removing broken packages without losing what you still need

Never dnf remove a package before you know what depends on it. dnf will pull out its dependents too, and it will not ask twice.

Run this first:

dnf repoquery --whatrequires <package>
dnf repoquery --installed --whatrequires <package>

The first lists everything in your repos that needs the package. The second scopes it to what you actually have installed, which is the answer you care about. If that list is empty, the package is a safe orphan and you can remove it clean.

If the list names software you use, you have a choice to make, not a command to run. Either find a replacement that satisfies the same dependents, or fix the broken package instead of deleting it. To sweep up truly orphaned leftovers afterward, sudo dnf autoremove clears packages nothing else requires. Check its removal list before you confirm, same as always.

Isolating a problematic third-party repository

A single misbehaving third-party repo poisons every transaction, so learn to switch repos off one at a time. RPM Fusion, COPR, and vendor repos ship builds that sometimes conflict with Fedora's own, and dnf can't tell you which repo is wrong. You have to test.

Start with dnf repolist to see what's enabled. Then retry your failing command with a repo disabled:

sudo dnf --disablerepo="suspect-repo" upgrade

If the error disappears, you found it. The opposite flag, --enablerepo, and --repo let you narrow further. When one repo consistently ships conflicting versions, the priorities plugin lets you rank Fedora's repos above it so the official build always wins.

To disable a repo for good, don't delete files at random. Set enabled=0 in its .repo file under /etc/yum.repos.d/, or remove that one file if you're done with the repo entirely. Deleting the wrong .repo file just trades one broken state for another.

Reinstalling from other sources when the repo build is broken

When the official build itself is broken, you have three fallbacks, each with a catch. Reach for them in order of least risk.

First, downgrade. If the current version is broken and the previous one worked, sudo dnf downgrade <package> rolls back to the last release in the repo. Pair it with versionlock if you need it pinned until upstream fixes the build, but remember a pin means you also stop getting security updates for that package.

Second, COPR. A community build often has the fix before the main repo does. Enable only the specific COPR you need, and disable it once the official package catches up, or you'll drift out of sync.

Third, build from source. This is the last resort, not the first. A source build sits outside dnf's database, so dnf can't track or update it, and it will happily install a conflicting copy of the same package later. Only go here when nothing packaged works.

The official dnf documentation covers downgrade, reinstall, and the versionlock plugin in detail if you want the full flag list.

Should you report the bug to maintainers, and how?

File it when the break is reproducible on a clean system with only Fedora's own repos enabled. That's the line. If disabling third-party repos makes the error vanish, it's not a Fedora packaging bug and the wrong maintainer gets your report.

A useful report names the exact package version and includes real output, not a paraphrase. Maintainers need three things: the full dnf error text, the relevant lines from /var/log/dnf.rpm.log, and the output of rpm -q <package> so they know your exact build. Add the repos you had enabled with dnf repolist.

Fedora tracks these in Bugzilla, and Fedora's package management sits in the dnf project upstream. A report with the actual logs gets fixed. A report that says "dnf is broken" gets closed. Give them something reproducible.

FAQ

Does dnf distro-sync fix broken dependencies?

Sometimes, and it's worth a try when versions are tangled. dnf distro-sync aligns every installed package to what your enabled repos currently offer, upgrading or downgrading as needed. That resolves the mess you get after mixing repos or a partial upgrade. Read its removal list before confirming, because syncing can pull out packages that no longer match any repo.

What's the difference between dnf check and dnf repoquery?

dnf check inspects packages already installed on disk and flags existing dependency, duplicate, or obsolete problems. dnf repoquery asks questions about packages and their relationships across your repos, installed or not. Use check to find what's already broken, and repoquery to trace why a specific package won't resolve.

How do I fix broken packages on other distributions?

The tool changes, the idea doesn't: read the error, then run the repair command. On Debian and Ubuntu, sudo apt install -f attempts to correct broken dependencies in place, and sudo dpkg --configure -a finishes any half-installed package. Use apt update --fix-missing to refresh the package list while ignoring missing pieces. On Arch, pacman -Qk checks installed packages for missing files.

Where does dnf log its transactions?

In /var/log/dnf.log for general activity and /var/log/dnf.rpm.log for the actual install, erase, and reinstall operations. You can also run dnf history for a numbered list of past transactions and dnf history undo <id> to reverse one. That history is the fastest way to see what changed right before things broke.

Is dnf clean all safe to run?

Yes. It deletes cached metadata and downloaded package files, nothing you can't re-fetch. The next transaction just downloads fresh copies, which is exactly what you want when stale cache is the suspect. It won't touch installed software or configuration, so run it whenever a dependency error smells like bad metadata.

Related on this blog

• How to remove unused kernel modules – Step-by-Step Guide