Fix Ubuntu Package Dependency Conflicts: A Step-by-Step apt/dpkg Guide

Fix Ubuntu Package Dependency Conflicts: A Step-by-Step apt/dpkg Guide

apt locking up with “unmet dependencies” looks scarier than it is. Nothing installs, nothing removes, and the error text reads like the system is falling apart. It almost never is.

This happens a lot on Ubuntu boxes that have run for a while, especially ones with a few PPAs installed or a history of interrupted upgrades. It’s also one of the most fixable problems out there, if you work the recovery steps in order. This guide follows that order: diagnose with apt-get check, try the standard dpkg/apt repair, escalate to aptitude‘s interactive resolver for tangled conflicts, and only then reach for low-level dpkg force flags or database recovery. Along the way, we’ll cover the PPA habits that cause most of these problems, and how to tell when a repair isn’t worth your time anymore.

Prerequisites

• Ubuntu Server or Desktop, any currently supported LTS or interim release (this guide was tested on Ubuntu 24.04 LTS “Noble Numbat” with apt 2.7.x and dpkg 1.22.x)
• sudo or root access on the box
• A terminal: SSH session, local shell, or a terminal window on Ubuntu Desktop
• Internet access to reach Ubuntu archive mirrors (some fixes need to download replacement packages)

If you’re on a Mac: apt and dpkg have no native macOS build. They’re Debian/Ubuntu-specific tools. You’ll need a real Ubuntu environment first. See the macOS section below before continuing.

Quick Diagnosis

Before jumping to a specific fix, run these three commands. Together they tell you whether you have a dependency conflict, an interrupted install, or something worse.

sudo apt-get check

apt-get check scans the installed package database for dependency problems. It changes nothing. A clean system returns to the prompt with no output. A broken one names the offending package:

Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
You might want to run ‘apt –fix-broken install’ to correct these.
The following packages have unmet dependencies:
libssl3 : Depends: libssl3t64 (>= 3.0.13) but it is not installed
E: Unmet dependencies. Try ‘apt –fix-broken install’ with no packages (or specify a solution).

Next, check whether any package is stuck mid-install:

sudo dpkg --audit

And check what apt actually wants to do about it (dry run, no changes made):

sudo apt --fix-broken install --dry-run

Read the summary line. It tells you how many packages will be installed, upgraded, or removed. If that number is small and reasonable, proceed to the standard fix below. If it wants to remove a dozen packages, including ones you clearly need, skip ahead to the aptitude section.

Common Issues

Problem: “You have held broken packages” or “unmet dependencies”

Symptoms:

• apt install/apt upgrade exits immediately with E: Unmet dependencies
• apt-get check names a specific package with an unsatisfied Depends: line
• The system otherwise behaves normally; you just can’t install or upgrade anything

Why it happens: A package on your system needs a library version your repositories can’t provide. This often shows up right after you add a PPA that expects a newer or different library than the main Ubuntu archive has. It can also follow a partial apt upgrade that installed some, but not all, of a set of interdependent packages.

Fix:

sudo apt-get update
sudo apt --fix-broken install

apt --fix-broken install (shorthand: apt -f install) is Ubuntu’s automatic dependency repair command. It figures out which packages to install, upgrade, or remove to make the system consistent again. It shows you the plan first and waits for your confirmation:

Correcting dependencies… Done
The following additional packages will be installed:
libssl3t64
The following packages will be upgraded:
libssl3 libssl3t64
2 upgraded, 0 newly installed, 0 to remove, 0 not upgraded.
Need to get 3,458 kB of archives.
Do you want to continue? [Y/n]

Verify:

sudo apt-get check

No output means the dependency tree is consistent again.

For more information on Linux privilege escalation and how it relates to package management, see our guide.

Problem: dpkg reports packages “half-configured” or in a “very bad inconsistent state”

Symptoms:

• Error text mentioning half-configured, half-installed, or “package is in a very bad inconsistent state”
• Any apt command fails before it even gets to your actual request
• Often follows a forced reboot, killed SSH session, or power loss during an update

Why it happens: The package was unpacked (its files were extracted to disk) but its post-install script never finished running. dpkg won’t let apt proceed until every pending package is fully configured or removed.

Fix:

sudo dpkg --configure -a

The -a flag tells dpkg to resume configuration for every package left in a pending state, not just one. You’ll see it work through each package in turn:

Setting up libapache2-mod-php8.3 (8.3.6-0ubuntu0.24.04.1) …
Setting up php8.3-cli (8.3.6-0ubuntu0.24.04.1) …
Processing triggers for man-db (2.12.0-4build2) …

Follow it immediately with the fix-broken pass. A half-configured package often leaves dependency gaps behind:

sudo apt --fix-broken install

Verify:

sudo dpkg --audit

No output means nothing is left in a pending state.

> Tip: dpkg --configure -a and apt --fix-broken install fix different problems, and you usually need both. dpkg --configure -a finishes interrupted installations. apt --fix-broken install fixes dependency graph problems (missing, conflicting, or mismatched versions) and can install or remove packages to do it. Run dpkg first, then apt.

For more information on installing and running Flatpak applications, see our guide.

Problem: apt’s resolver wants to remove packages you actually need

Symptoms:

• apt --fix-broken install or apt upgrade proposes removing packages unrelated to what you’re trying to fix
• The proposed removal list includes something critical (a kernel package, a desktop environment component, a production service)

Why it happens: apt’s built-in resolver picks the first solution that satisfies dependencies. It doesn’t search for the “best” one, and it doesn’t show you alternatives. When a conflict has more than one valid fix, apt commits to a single path, even if it’s not the one you’d choose.

Fix: Install aptitude and let its interactive resolver propose alternatives.

sudo apt install aptitude
sudo aptitude install <package-name>

Aptitude’s dependency solver shows you a proposed action list. You can cycle through other valid solutions before committing to any of them:

The following NEW packages will be installed:
libgd3{a} libgd-tools{a}
0 packages upgraded, 2 newly installed, 0 to remove, 0 not upgraded.
Need to get 312 kB of archives. After unpacking 891 kB will be used.
Accept this solution? [Y/n/q/?]

Press n to see the next candidate solution, e to examine it in detail, or y/Enter to accept the one shown. Keep cycling with n until you find a resolution that doesn’t touch anything critical.

Verify:

sudo apt-get check

> Tip: aptitude and plain apt/dpkg share the same package database, so switching between them is safe. You’re not running two competing package managers, just two front ends to the same install.

For more information on installing software from tar.gz files on Ubuntu, see our guide.

Problem: A package is stuck requiring reinstallation and won’t budge

Symptoms:

• dpkg -l shows the package with status flags iU or rU (reinstall required)
• apt --fix-broken install fails with something like dpkg: error processing package X (--configure): package is in a very bad state
• The package’s .deb no longer exists in any configured repository (it was pulled by the maintainer, superseded, or was a one-off local install)

Why it happens: dpkg marked the package reinstreq after a failed operation. Now it won’t let apt do anything else until that package is reinstalled, but no valid package is available to satisfy the reinstall.

Fix: Force-remove it. This is the first genuinely invasive step in this guide, and it overrides dpkg’s normal safety checks. Use it only when you’ve confirmed the package can’t be repaired or reinstalled normally.

> Warning: --force-remove-reinstreq bypasses dpkg’s consistency checks. Only use it on a package you’ve confirmed is unrecoverable. Used carelessly, it can leave configuration files or dependent packages in an odd state. Note the package name before running this; you may need to reinstall it cleanly afterward.

sudo dpkg --purge --force-remove-reinstreq <package-name>

dpkg: warning: overriding problem because –force enabled:
dpkg: warning: package is in a very bad inconsistent state; you should
reinstall it before attempting a removal
Removing <package-name> (2.4.1-1) …
Purging configuration files for <package-name> (2.4.1-1) …

Then let apt clean up whatever dependency chain that package was part of:

sudo apt --fix-broken install

Verify:

dpkg -l | grep <package-name>

No matching line (or a deinstall ok config-files/no-output result) confirms it’s gone.

For more information on Active Directory Certificate Services troubleshooting, see our guide.

Problem: apt and dpkg fail entirely with database or parsing errors

Symptoms:

• Every apt/dpkg command fails, even apt-get check
• Errors referencing the status file itself rather than a specific package
• Often preceded by a disk-full condition or a hard power-off mid-write

Why it happens: /var/lib/dpkg/status (the live database dpkg uses to track every installed package) has been truncated, emptied, or corrupted. This is rarer than a simple dependency conflict, but more serious. Nothing package-related works until it’s fixed.

Fix: dpkg keeps an automatic backup of this file at /var/lib/dpkg/status-old, written before every update. Check both files first:

ls -la /var/lib/dpkg/status*

-rw-r–r– 1 root root 0 Jul 24 09:12 /var/lib/dpkg/status
-rw-r–r– 1 root root 2847213 Jul 22 03:31 /var/lib/dpkg/status-old

A status file at 0 bytes, or much smaller than status-old, confirms the corruption. This looks like the scariest error in the whole guide. It’s actually one of the easiest to fix, because dpkg already made you a backup. Copy it back, then reconcile the gap:

&gt; Warning: You’re about to overwrite the live package database. Keep the .bad copy until you’ve verified the restored system works. Don’t delete it in the same session.

sudo cp /var/lib/dpkg/status /var/lib/dpkg/status.bad
sudo cp /var/lib/dpkg/status-old /var/lib/dpkg/status

Verify:

sudo apt-get check
sudo apt --fix-broken install

status-old is a snapshot from the previous update. Packages installed or removed after that snapshot won’t show up in it. Cross-check with your shell history or /var/log/apt/history.log, and manually reinstall anything added after the status-old timestamp.

For more information on PowerShell vs Bash for system administration, see our guide.

Problem: apt update fails with 404 errors or repository signature errors

Symptoms:

• apt update completes with one or more 404 Not Found lines
• Or NO_PUBKEY / expired signature errors tied to a specific source
• The error names a specific ppa.launchpadcontent.net or third-party URL

Why it happens: A PPA was removed by its maintainer. Or it doesn’t publish builds for your current Ubuntu release codename, common right after upgrading from one LTS to the next. Or its signing key expired.

Fix: Identify the failing source from the apt update output, then remove it:

sudo add-apt-repository --remove ppa:some-maintainer/some-ppa

If it wasn’t added via add-apt-repository (e.g., a manually dropped .list file), delete the file directly:

sudo rm /etc/apt/sources.list.d/some-repo.list
sudo apt update

Verify:

sudo apt update

Clean output with no 404s or signature warnings confirms the fix.

For more information on resolving unmet dependencies errors, see this article or this Q&amp;A thread.

Error Messages Table

Error Message	What It Means	Fix
You have held broken packages	A package’s dependencies can’t currently be satisfied	sudo apt --fix-broken install
E: Unmet dependencies	Dependency graph inconsistency, often after a PPA install	sudo apt-get update && sudo apt --fix-broken install
package is in a very bad inconsistent state	Interrupted install left the package half-configured	sudo dpkg --configure -a
dpkg was interrupted, you must manually run 'sudo dpkg --configure -a'	Same as above: dpkg is telling you directly	sudo dpkg --configure -a
dpkg: dependency problems prevent removal	Removing this package would break something depending on it	Use aptitude remove to see alternatives, or confirm the dependent package can also go
reinstallation required / status flag iU/rU in dpkg -l	Package marked for mandatory reinstall but no valid .deb is available	sudo dpkg --purge --force-remove-reinstreq <pkg>
E: Sub-process /usr/bin/dpkg returned an error code	A postinst/prerm script failed: check the named package’s log	sudo dpkg --configure -a, then check /var/log/dpkg.log
404 Not Found on apt update	A repository (often a PPA) no longer publishes for your release	Remove the offending source, then apt update
NO_PUBKEY / signature verification failed	Repository’s signing key is missing or expired	Re-import the key or remove the repository
Empty or garbled output from any dpkg/apt command	/var/lib/dpkg/status is corrupted or truncated	Restore from /var/lib/dpkg/status-old

Platform-Specific Issues

On macOS

apt and dpkg are Ubuntu/Debian tools with no native macOS build. You can’t run any of the commands above directly in the Mac’s own shell. To follow this guide on a Mac, you need an actual Ubuntu environment:

• Virtual machine (recommended for full-system work): install UTM, Parallels Desktop, or VirtualBox, then create an Ubuntu VM from the official ISO at ubuntu.com/download. Once you’re in the VM’s terminal, everything in this guide works exactly like a bare-metal install.
• Docker container (fine for quick command testing, not full package-state recovery, containers don’t reproduce the interrupted-upgrade or disk-full scenarios that cause most of these problems):

docker run -it ubuntu:24.04 bash

Once you’re inside the VM or container’s shell, every command in this guide runs exactly as written. apt, dpkg, and aptitude behave the same no matter the host.

On Windows

This guide doesn’t target Windows, but it’s worth noting: Windows users reach the same tools via WSL2 (wsl --install -d Ubuntu). The recovery commands are identical once you’re inside the WSL Ubuntu shell. There’s no Windows-specific version of any apt/dpkg behavior.

Configuration Issues

A handful of configuration mistakes cause most of the conflicts covered above:

Mixing release codenames in sources.list. Manually editing /etc/apt/sources.list to point at a different Ubuntu codename, like leaving jammy entries after upgrading to noble, gives you two incompatible package sets at once. Check every file for consistency:

grep -r "^deb " /etc/apt/sources.list /etc/apt/sources.list.d/ | awk '{print $3}' | sort -u

You should see exactly one codename (e.g., noble) across all entries, aside from intentional -updates, -security, and -backports suffixes.

Packages held with apt-mark hold. A held package is deliberately excluded from upgrades. That’s useful for pinning a known-good kernel. But it’s also a common cause of “unmet dependencies” when everything else moves forward and the held package doesn’t. List your holds:

apt-mark showhold

Remove a hold with sudo apt-mark unhold <package> if it’s no longer intentional.

PPAs added for the wrong release. Adding a PPA built for jammy (22.04) on a noble (24.04) system either fails silently or pulls in incompatible library versions. Always confirm a PPA supports your current codename before adding it.

Getting Help

If you’re still stuck after working through the escalation path above, these are the first places to look and ask:

• Logs: /var/log/apt/history.log (what apt has done), /var/log/apt/term.log (raw terminal output of past apt runs), and /var/log/dpkg.log (every dpkg state transition, useful for pinpointing exactly when a package broke)
• Debug info to gather before asking for help: lsb_release -a; apt-cache policy <package> (shows installed vs. candidate versions and which repo each comes from); and dpkg -l | grep -v ^ii (lists every package not in the normal “installed” state)
• Ubuntu Community Help Wiki: help.ubuntu.com/community/AptGet/Howto
• Manual pages: dpkg(8) and apt-get(8) document every flag referenced in this guide
• Ask Ubuntu and the Ubuntu Forums for community troubleshooting threads. Search the exact error text before posting; most of these problems have already been solved publicly.

Prevention Tips

• Practice PPA hygiene: Before adding a PPA, confirm it publishes builds for your current release codename. Periodically audit /etc/apt/sources.list.d/ and remove PPAs you no longer use with ppa-purge. It reverts affected packages back to the archive version instead of just deleting the source.
• Don’t skip apt update before apt upgrade: Running upgrades against a stale package index often triggers partial, inconsistent upgrades.
• Never force-quit mid-upgrade: If an SSH session drops or a terminal closes during apt upgrade, the process usually keeps running server-side. Check with ps aux | grep apt before you assume you need to step in.
• Snapshot before major changes: If you’re on ZFS, LVM, or a VM with snapshot support, take one before a distribution upgrade or a batch of PPA installs. It turns an unrecoverable mess into a five-minute rollback.
• Keep DEBIAN_FRONTEND=noninteractive out of interactive sessions. It’s useful in automation scripts, where it stops debconf prompts from hanging unattended installs. But in a session you’re watching, it can silently accept defaults you didn’t intend.

When to Consider a Clean Reinstall

Say you’ve worked through apt-get check, dpkg --configure -a, apt --fix-broken install, aptitude‘s interactive resolver, and force-removal of the specific offending packages. If the system is still broken, or a new conflict pops up every time you fix the last one, stop and do the math. Extensive dependency graph corruption, often from mixing release codenames or a botched do-release-upgrade, can take hours to untangle by hand, with no guarantee the result is stable afterward.

At that point, a clean reinstall from a documented config, or a restore from a known-good snapshot, is usually faster and more trustworthy than continued manual repair. That’s why it pays to keep your /etc changes, package lists (apt-mark showmanual > packages.txt), and PPA sources documented separately, outside the machine itself.

Frequently Asked Questions

How do I check what’s causing a broken package error in Ubuntu?

Run sudo apt-get check. It scans the full dependency tree without changing anything, and names the package with the unsatisfied dependency. Follow up with apt-cache policy <package> to see which repository is providing the conflicting version.

What’s the difference between dpkg –configure -a and apt –fix-broken install?

dpkg --configure -a finishes configuring packages that were unpacked but never completed setup; it fixes interrupted installs. apt --fix-broken install fixes dependency graph problems by installing, upgrading, or removing packages as needed. Run dpkg first, then apt.

When should I use aptitude instead of apt to fix dependencies?

Use it when apt’s resolver wants to remove packages you need, or when a conflict clearly has more than one valid solution. Aptitude’s interactive resolver lets you cycle through alternatives (n for next) instead of locking in apt’s one default choice.

How do I remove a package that dpkg won’t let me remove normally?

If it’s stuck in a reinstreq state with no valid package available to satisfy reinstallation, force-remove it: sudo dpkg --purge --force-remove-reinstreq <package>. Then run apt --fix-broken install to repair the rest of the dependency chain. Use this only as a last resort.

How do I recover if /var/lib/dpkg/status gets corrupted?

Compare file sizes with ls -la /var/lib/dpkg/status*. If status is empty or truncated and status-old looks intact: back up the bad file, copy status-old over status, then run apt-get check and apt --fix-broken install to confirm consistency. Reinstall anything you added after the status-old snapshot was taken.

How can I avoid dependency conflicts from PPAs in the future?

Only add PPAs that explicitly support your current Ubuntu codename. Audit /etc/apt/sources.list.d/ periodically, and remove unused PPAs with ppa-purge instead of deleting the source file. Deleting the file alone leaves installed packages behind at a version the archive won’t manage.

At what point is it faster to just reinstall Ubuntu?

When you’ve gone through the full escalation (check, configure -a, fix-broken, aptitude, targeted force-removal) and new conflicts keep surfacing, or the corruption stems from mixing release codenames. At that point, a clean reinstall from documented configs is usually faster than continued manual recovery.

Wrapping Up

Most broken-package situations get fixed by the first two commands: dpkg --configure -a and apt --fix-broken install. You’ll rarely need to go further than that. The escalation path in this guide covers the minority of cases where those aren’t enough, and working through it in order keeps you from reaching for a destructive fix when a safe one would’ve worked.

Step	Action	Applies To
1	sudo apt-get check	Diagnosing any broken-package situation
2	sudo dpkg --configure -a	Interrupted installs, half-configured packages
3	sudo apt --fix-broken install	Dependency graph inconsistencies
4	sudo aptitude install <pkg>	Resolver wants to remove packages you need
5	sudo dpkg --purge --force-remove-reinstreq <pkg>	Package stuck in unrecoverable reinstreq state
6	Restore /var/lib/dpkg/status-old	Corrupted dpkg database
7	Clean reinstall or snapshot restore	Repair attempts keep surfacing new conflicts

Last updated: 2026-07-24 | Applies to Ubuntu 24.04 LTS and other currently supported releases, tested with apt 2.7.x and dpkg 1.22.x