Fix broken dependencies on Linux (APT and DNF)

sudo apt --fix-broken install repairs most broken dependencies on Debian/Ubuntu, sudo dnf distro-sync realigns the packages on RHEL/Fedora. These two commands are the first reflex when the package manager refuses to install or update anything. This guide is written for the administrator who already knows apt or dnf and is stuck on an interrupted installation, a version conflict or a lock. It shows how to qualify the failure without changing anything, then repair it from the least intrusive command to the most radical. The commands and outputs were checked on 30 September 2026 on Debian 13 (APT 3.0.3), Ubuntu 24.04 and AlmaLinux 10 (DNF 4.20.0).

What you will learn

• Diagnose the type of problem: interrupted installation, conflict or missing package
• Repair an interrupted APT/dpkg installation
• Solve a dependency conflict with APT and DNF
• Unlock a locked package manager
• Know the last-resort commands without breaking the system
• Prevent dependency problems

In what context?

Broken dependencies are a classic problem in Linux administration:

• An update was interrupted (network outage, accidental Ctrl+C, reboot during an apt upgrade), dpkg is in an inconsistent state
• You add a PPA or a third-party repository that provides an incompatible version of a shared library
• A package was removed manually with dpkg --remove --force and other packages depend on it
• After a distribution upgrade, some packages are no longer available in the new repositories
• apt install or dnf install fails with an unmet dependencies message and you do not know where to start

LFCS / RHCSA

The LFCS objectives place this skill in the Operations Deployment domain (search for, install, validate, and maintain software packages or repositories), and the RHCSA exam on RHEL 10 in the Manage software section. Knowing how to unlock a broken package manager is part of it: a package that refuses to install on exam day quickly costs several minutes.

Diagnose the problem

A broken dependency is not a single state: the package manager can be blocked by an interrupted transaction, by a package requiring a version missing from the repositories, or by a local database that no longer reflects the real contents of the disk. The three are fixed differently, and running the wrong command first often wastes time.

So start by qualifying the failure. The commands below change nothing: they only read the local state and are safe even on a production server.

Debian / Ubuntu

Check the state of dpkg

sudo dpkg --audit

If packages appear, they are in an inconsistent state (partial installation, incomplete configuration). On Debian 13, a package unpacked but never configured gives:

The following packages have been unpacked but not yet configured.
They must be configured using dpkg --configure or the configure
menu option in dselect for them to work:
 tree                 displays an indented directory tree, in color

Measured trap: dpkg --audit returns a zero exit code even when it reports a package. In a script, test its output, never its exit code.

Check APT dependencies

sudo apt-get check

Reading package lists...
Building dependency tree...
Reading state information...

If everything is clean, no error message appears. Otherwise, APT names the packages with unmet dependencies.

List broken packages

dpkg --audit reports the problematic packages, but without showing the exact status code that explains why. This code is read in the first two columns of dpkg -l: the first describes the desired action (i = install, r = remove, h = hold), the second the actual state (i = installed, U = unpacked, F = half-configured, H = half-installed, W = awaiting triggers, c = only the configuration files remain).

The reading rule fits in one sentence: an uppercase letter in the second column is always a problem. A third column R (Reinst-required) additionally flags a package that no command can repair without reinstalling. The following filter isolates these cases:

dpkg -l | grep -E '^[a-z][UFHW]'

No output means no package is in an inconsistent state. On Debian 13, a package that is only unpacked shows up as iU tree 2.2.1-1. The filter deliberately leaves out the rc lines, which are harmless: the package is removed, only its configuration files remain.

State	Meaning
ii	Correctly installed
iU	Unpacked but not configured
iF	Configuration failed
iHR	Interrupted installation, requires reinstallation
rc	Removed, configuration files remaining

Swipe to see more

RHEL / Fedora

Check RPM consistency

Unlike APT, DNF keeps no separate state file: everything lives in the RPM database (/var/lib/rpm). The check command therefore queries this database directly and tells you whether what is recorded as installed forms a consistent set.

sudo dnf check

It reports three families of anomalies: missing dependencies, duplicates (two versions of the same package installed side by side after a partial update) and conflicts between packages. On a healthy system, the command returns nothing and exits with a zero code.

List the problems

dnf check answers yes or no. To know which package exactly requires a dependency that cannot be found, you have to query the local repository with repoquery.

sudo dnf repoquery --unsatisfied

Each line returned is an installed package whose dependency is no longer provided by any active repository. It is the typical symptom of a disabled third-party repository or of a version upgrade that removed a library.

Check the transaction history

DNF logs every operation. This history is the fastest way to connect a failure to the last thing you did, which beats guessing.

sudo dnf history list

Look at the Action(s) column: a transaction marked Install or Upgrade just before the problem appeared is your prime suspect. The Altered column gives the number of packages touched, a high number points to a mass update. Then detail the suspicious transaction by its identifier:

sudo dnf history info <id>

Repair on Debian / Ubuntu

The five steps below go from the least destructive to the most intrusive: follow them in order, and stop as soon as dpkg --audit goes quiet again. Jumping straight to the end is the best way to remove packages that only needed reconfiguring.

One point of attention before starting: always read the summary APT proposes before confirming. The --fix-broken command is allowed to remove packages to restore consistency, and on a production server the list of removals deserves a look before the Y.

1. Finish pending dpkg configurations

   sudo dpkg --configure -a

   This command finishes configuring all partially installed packages. It is always the first thing to try.

2. Repair broken dependencies with APT

   sudo apt --fix-broken install

   APT downloads and installs the missing dependencies, or removes the inconsistent packages. Check what it proposes before confirming.

3. Update the package list

   sudo apt update

   If a repository was modified or removed, the local metadata may be out of date.

4. Retry the installation

   sudo apt install package-name

   Rerun the installation that failed in the first place. If APT still reports unmet dependencies, go back to step 2: apt install -f is only the short form of apt --fix-broken install, not a different repair.

5. Check the result

   sudo dpkg --audit
   sudo apt-get check

   dpkg --audit must display nothing. apt-get check shows its three reading lines (Reading package lists...) and no error. Judge by the output: on Debian 13, dpkg --audit returns a zero exit code even when it reports a package.

Special case: dpkg locked

If apt-get fails immediately with:

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 23 (apt-get)

Another process holds the lock, and the message already gives its PID and name. apt, on the other hand, does not stop: it waits for the lock to be released, repeating Waiting for cache lock: Could not get lock ..., which looks like a hang but is not one. Measured on Debian 13 and Ubuntu 24.04. First check what is running:

ps aux | grep -E 'apt|dpkg'

If an apt or dpkg process is still running, wait for it to finish. If the machine rebooted during an update and no process is running:

sudo rm /var/lib/dpkg/lock-frontend
sudo rm /var/lib/dpkg/lock
sudo dpkg --configure -a

Only remove the locks if no dpkg process is running

Removing a lock file while an apt is active can corrupt the dpkg database. Always check with ps aux | grep dpkg beforehand.

Special case: package impossible to remove

When a package carries the R flag (Reinst-required), dpkg refuses to handle it: it considers that its contents on disk are no longer reliable and demands a reinstallation. If the package no longer exists in any repository, you are stuck in a loop. The --force-remove-reinstreq option lifts precisely this safeguard.

sudo dpkg --remove --force-remove-reinstreq package-name
sudo apt --fix-broken install

The second command is not optional: the forced removal leaves the packages that depended on the victim in an unmet state, and --fix-broken restores the whole. Check the list of available options with dpkg --force-help before using another one: the entries marked [!] are considered dangerous by dpkg itself.

Force the reinstallation of a package

Some failures do not come from dependencies but from the files shipped by the package: a binary overwritten by hand, a configuration deleted by mistake, a file truncated by a full disk. In that case, reinstallation puts the original contents back without touching the dependencies.

sudo apt install --reinstall package-name

The package is downloaded again and reinstalled on top of the existing one, without going through a removal: the packages that depend on it are therefore never uninstalled along the way. The configuration files modified in /etc are kept, APT asks what to do if they differ from the maintainer's version.

Repair on RHEL / Fedora

The logic differs from APT's. DNF has no "half-configured" state: an RPM transaction is atomic, it succeeds or it fails. Failures therefore rarely come from an interruption, and much more often from a gap between the installed versions and those published by the active repositories. That is what distro-sync fixes, by realigning each package, including downgrading it if the repository offers a lower version.

As on the Debian side, follow the steps in order and check with dnf check after each one: no need to rebuild the RPM database if a simple resync was enough.

1. Synchronise the packages with the repositories

   sudo dnf distro-sync

   Aligns all installed packages with the versions available in the active repositories. Solves most post-update problems.

2. Reinstall a suspicious package

   sudo dnf reinstall package-name

3. Check and repair the RPM database

   sudo rpm --rebuilddb

   Rebuilds the RPM database if dnf reports errors accessing it.

4. Clean the cache

   sudo dnf clean all
   sudo dnf makecache

   Forces the metadata of all repositories to be downloaded again.

5. Check the result

   sudo dnf check

Undo a DNF transaction

This is DNF's decisive advantage over APT: each transaction is recorded with the exact list of packages touched and their previous versions, which makes rolling back possible in one command. Start by finding the identifier of the faulty transaction.

sudo dnf history list

ID | Command line             | Date and time    | Action(s) | Altered
 8 | install nginx            | 2026-04-15 14:30 | Install   | 3
 7 | update                   | 2026-04-14 09:00 | Upgrade   | 42

To undo transaction number 8:

sudo dnf history undo 8

DNF reverts the changes made by that transaction (removes the installed packages, restores the previous versions). The undo only succeeds if the old versions are still available in a repository or in the local cache: on a machine where dnf clean all was run after the update, the operation can fail for lack of RPMs to reinstall.

Solve a version conflict

A third-party repository that publishes its own version of a system library (often a newer variant of glibc, openssl or a Python module) takes precedence over the distribution's. The official packages compiled against the original version then end up with an unmet dependency. Three commands are enough to identify the culprit and then neutralise it.

# Identify the source repository
dnf repoquery --info package-name

# Exclude a repository temporarily
sudo dnf update --disablerepo=third-party-repo-name

# Lock a package at its current version
sudo dnf versionlock add package-name

--disablerepo only applies to the current command, it is a test with no lasting effect. versionlock, on the other hand, is persistent: the frozen package will no longer move, including during security updates. Write it down somewhere, a forgotten lock turns into debt six months later. The versionlock subcommand requires a separate plugin, whose installation is detailed with package locking below.

Problems caused by third-party repositories

Identify the problematic repositories

A dependency conflict very often comes from a repository added by hand: Ubuntu PPA, vendor repository, EPEL on RHEL. The first reflex is therefore to take an inventory of what is really enabled on the machine, which takes one command per distribution family.

# Debian/Ubuntu
grep -r "^deb " /etc/apt/sources.list /etc/apt/sources.list.d/

# RHEL/Fedora
dnf repolist

On Debian and Ubuntu, anything that does not point to deb.debian.org, archive.ubuntu.com or your internal mirror is a candidate. On RHEL, compare the repo id column with the list of repositories provided by the subscription: the identifiers that are not in it were added locally.

deb822 format since Ubuntu 24.04

On Ubuntu 24.04, /etc/apt/sources.list only contains a comment: the official repositories live in /etc/apt/sources.list.d/ubuntu.sources, in deb822 format (Types:, URIs:, Suites:). The lines no longer start with deb, so the grep above misses them. Also inspect /etc/apt/sources.list.d/*.sources, or use apt policy, which shows all sources whatever their format. The Debian 13 container image goes further: it has no sources.list at all, only debian.sources.

Temporarily disable a repository

Isolating a suspicious repository is a diagnostic test, not a fix. The goal is to answer a single question: does the problem disappear when this repository is no longer consulted? The manipulations below are reversible, which makes them safe even on a running server.

Debian / Ubuntu

# Rename the file to disable it
sudo mv /etc/apt/sources.list.d/third-party.list /etc/apt/sources.list.d/third-party.list.disabled
sudo apt update
sudo apt --fix-broken install

RHEL / Fedora

sudo dnf --disablerepo=third-party update
# Or permanent disabling
sudo dnf config-manager --set-disabled third-party

config-manager comes from the dnf-plugins-core package. On distributions that moved to DNF 5 (Fedora 41 and later), the syntax becomes dnf config-manager setopt third-party.enabled=0.

Check the packages coming from third-party repositories (APT)

Disabling a repository is not always enough: the packages it already installed stay in place, with their non-standard versions. The filter below brings them up by excluding the packages whose version contains ubuntu or debian, the usual marker of a package from the official repositories.

apt list --installed 2>/dev/null | grep -v "ubuntu\|debian"

It is a heuristic, not a truth: many official packages do not carry this marker in their version and will show up wrongly. To settle a specific package, apt policy package-name shows the exact source repository of the installed version.

Lock a package to prevent updates

When a newer version systematically breaks the installation, freezing the package at its version known to work gives you time to deal with the root of the problem. The two distribution families each have their own mechanism, with the same logic: lock, check, unlock.

Debian / Ubuntu

# Lock
sudo apt-mark hold package-name

# Check
apt-mark showhold

# Unlock
sudo apt-mark unhold package-name

RHEL / Fedora

# Install the versionlock plugin (python3-dnf-plugin-versionlock package)
sudo dnf install dnf-plugin-versionlock

# Lock
sudo dnf versionlock add package-name

# List
dnf versionlock list

# Unlock
sudo dnf versionlock delete package-name

Prevent problems

Almost all broken dependencies come from three actions: a transaction interruption, adding an uncontrolled third-party repository, and an update run without a prior test. The reflexes below cost a few seconds and save the hours of repair described above.

• Never interrupt apt upgrade or dnf update; if a Ctrl+C is necessary, run dpkg --configure -a or dnf distro-sync immediately afterwards
• Avoid untrusted third-party repositories: every PPA or external repository is a conflict risk
• Test major updates on a test server before production (apt upgrade --dry-run, dnf update --assumeno)
• Keep the metadata up to date: apt update before each installation
• Document the locked packages (apt-mark showhold, dnf versionlock list): a forgotten frozen package will become a problem later

Troubleshooting

This table links each raw error message met in a terminal to the command that fixes it. First look for the line whose symptom matches word for word what you are reading: package managers have a limited error vocabulary, and the message is almost always enough to decide without further diagnosis.

Symptom	Probable cause	Solution
Could not get lock /var/lib/dpkg/lock-frontend	Another APT or dpkg process active, PID given in the message	Check ps aux | grep dpkg, wait or remove the lock if no process
Unmet dependencies after install	Incompatible third-party repository	Disable the repository, apt --fix-broken install
dpkg --configure -a loops on an error	Broken postinst script of the package	dpkg --remove --force-remove-reinstreq package
dnf check reports duplicates	Partial update	dnf remove --duplicates then dnf distro-sync
Package X has no installation candidate	Repository removed or package withdrawn	apt update, check the sources
Error: Transaction check error (DNF)	Conflict between packages	dnf --best --allowerasing install package
Corrupted RPM database	Crash during a transaction	rpm --rebuilddb then dnf clean all

Swipe to see more

Keep this block at hand: these are the read-only commands to run first on a machine whose history you do not know. None of them changes anything, they only serve to decide which repair to run next.

# Quick diagnosis: Debian/Ubuntu
sudo dpkg --audit                    # Packages in an inconsistent state
sudo apt-get check                   # Unmet dependencies
apt-mark showhold                    # Locked packages

# Quick diagnosis: RHEL/Fedora
sudo dnf check                       # Dependency consistency
sudo dnf history list                # Latest transactions
dnf versionlock list                 # Locked packages

Key points

• dpkg --configure -a is always the first command after an interrupted installation on Debian/Ubuntu
• apt --fix-broken install solves the majority of APT dependency problems
• dnf distro-sync realigns all packages on RHEL/Fedora, it is the DNF-side equivalent of "fix broken"
• Never remove the lock files if a dpkg/apt process is still active
• dnf history undo lets you undo a problematic transaction, APT has no equivalent that simple
• Third-party repositories are the first cause of dependency conflicts, disable them to isolate the problem
• apt-mark hold and dnf versionlock lock a package to prevent incompatible updates
• As a last resort, dpkg --remove --force-remove-reinstreq removes an unrecoverable package

Knowledge check

Check that the essentials of this guide are acquired. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

×

See in the glossary →