Fix apt broken install: 5 quick solutions

You ran apt install or apt upgrade and got dropped into something like E: Sub-process /usr/bin/dpkg returned an error code (1) or dpkg: error processing package, and now every apt command just fails the same way. Nine times out of ten this is an interrupted install, a half-configured package, or a corrupted download sitting in /var/cache/apt/archives. It looks worse than it is — apt’s package database is almost never actually destroyed, just stuck mid-transaction. Fixing it takes about two minutes if you go in the right order, and going in the wrong order is how people end up reinstalling their whole system over a broken headers package. Below are five fixes, ranked by how often each one is actually the culprit, for Ubuntu 22.04/24.04 and Debian 12.

apt --fix-broken install

What “apt broken install” means and when you hit it

“Broken install” isn’t one error — it’s a state. apt’s dependency resolver has a package (or several) that’s half-configured, missing a dependency, or held at a version that conflicts with what you’re trying to install. You’ll usually see one of these:

E: Unable to correct problems, you have held broken packages

This means apt found a package marked “held” (frozen at its current version) that’s blocking the dependency chain for something else you’re installing.

E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution)

This means a package on your system needs a library or binary version that isn’t installed, isn’t available, or was removed out of order.

Both of these are local package database problems, not network issues. Your mirror is fine, your sources.list is fine, your internet connection is fine. This is not “repo is down” or “404 on package download” — those throw different errors entirely (Failed to fetch, 404 Not Found). A broken install means the metadata apt uses to track what’s installed, what’s configured, and what depends on what has gotten into a state it can’t resolve on its own.

You hit this after: a power loss or SSH drop mid-apt upgrade, running dpkg --force-all manually and skipping dependency checks, installing a .deb with dpkg -i that needed libraries apt didn’t know to pull in, or holding a package with apt-mark hold and forgetting about it six months later. None of it means your system is corrupted. It means apt’s transaction log has a loose thread, and the five fixes below pull it in the right order.

Clean broken packages with apt –fix-broken (most likely fix)

This is the fix that resolves the problem about 80% of the time. It applies to Debian 11/12, Ubuntu 20.04 through 25.10, Linux Mint 21/22, and Pop!_OS 22.04 — the underlying apt/dpkg machinery hasn’t changed in any way that matters here.

sudo apt --fix-broken install

This tells apt to look at the current state of /var/lib/dpkg/status, find whatever half-configured or conflicting package is blocking progress, and either finish setting it up or remove it if it can’t be reconciled. You’ll sometimes see the older syntax sudo apt-get -f install in forum posts — it’s the same operation, -f is just the legacy flag name from before apt got its own front-end binary.

Run the fix-broken command and confirm removals

Run the command above and read the output as it scrolls. If apt needs to remove something, you’ll see a prompt like:

The following packages will be REMOVED:
  libfoo-dev
Do you want to continue? [Y/n]

Press Y and hit enter. This is normal — the package being removed is almost always the broken one causing the conflict, not something you need. Watch for these lines as it finishes:

Setting up libfoo (2.4.1-3) ...
Processing triggers for libc-bin (2.39-1) ...

No lines starting with E: means apt considers the dependency tree resolved. Now clean up whatever got orphaned in the process:

sudo apt autoremove

This removes packages that were pulled in as dependencies but nothing on your system needs anymore — typically old kernel headers or leftover libraries. It will list what it’s removing before it does anything, so check the list once before confirming. If this command alone gets you back to a clean apt update && apt upgrade, stop here — you don’t need the rest of this article.

Unhold packages blocking apt if you see “held broken packages”

If apt install -f refuses to do anything and instead prints:

E: Unable to correct problems, you have held broken packages.

the cause isn’t a broken download or a bad mirror — it’s a package you (or a script, or a previous sysadmin) deliberately pinned with apt-mark hold. Holds exist to stop a specific version from being upgraded, usually because an update once broke something and someone locked it down to stop it from happening again. The problem is that apt’s dependency resolver can’t touch a held package even when it’s the exact thing blocking a fix, so it gives up instead of overriding your pin. This applies the same way on Ubuntu, Debian, Linux Mint, and any other apt-based distro — the hold flag lives in dpkg’s own state, not anywhere distro-specific.

List and remove holds blocking installation

Check what’s currently held before touching anything:

apt-mark showhold

This prints one package name per line, or nothing if there are no holds. If you see something like libfoo or nvidia-driver-535 in that list, that’s your blocker. For each one, remove the hold:

sudo apt-mark unhold libfoo

Expect output like Canceled hold on libfoo. This doesn’t uninstall or upgrade anything — it just clears the flag so apt is allowed to modify the package again. Repeat for every name apt-mark showhold listed. Then retry:

sudo apt install -f

Watch for lines like libfoo set to manually installed or libfoo set to automatically installed as apt resolves the tree normally. If the error is gone and apt proceeds to configure packages instead of bailing out immediately, this was your fix — no need to look further down this list.

Clear apt cache and update package lists if dependencies won’t resolve

If holds and half-configured packages aren’t the problem, the next suspect is stale metadata. Apt caches package lists and downloaded .deb files under /var/lib/apt/lists and /var/cache/apt/archives. If those go stale — a repo changed a package version, a mirror had a bad sync, or a partial download got left behind — apt’s resolver starts making decisions based on information that no longer matches what’s actually on the server. This applies the same way on Ubuntu 22.04/24.04, Debian 11/12, and Linux Mint 21/22. None of the commands below delete anything you can’t re-download.

Clean cache and refresh package metadata

Run these three in order:

sudo apt clean

This deletes cached .deb files from /var/cache/apt/archives. It produces no output on success — that’s normal. Nothing is lost except files apt can re-download anyway.

sudo apt autoclean

This removes only cached packages for versions you can no longer install, leaving current ones alone. Also silent on success.

sudo apt update

Expect a scroll of lines like Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease and Get:3 http://security.ubuntu.com/ubuntu noble-security InRelease [110 kB], ending with Reading package lists... Done. That last line means apt rebuilt its metadata from scratch. On Fedora the equivalent is sudo dnf clean all followed by sudo dnf makecache.

This whole sequence takes 30 seconds on a fast connection with a handful of repos enabled, up to two minutes if you’ve got PPAs or third-party repos like Docker’s or an Nvidia CUDA repo added. Once it finishes, retry:

sudo apt install -f

If the dependency error is gone and apt starts configuring packages, the cache was stale — done.

Remove and reinstall the problematic package if it’s corrupted

If --fix-broken and a metadata refresh didn’t fix it, the package itself is probably corrupted — a half-written control file, a broken postinst script, or a .deb that got interrupted mid-install. This is the culprit in maybe 15% of broken-apt cases, usually after a killed terminal or a power loss during an upgrade. The fix is a full removal and reinstall, not an upgrade — you’re throwing away the broken copy entirely and pulling a fresh one from the repo.

Remove and reinstall the broken package

Scroll back through your original apt install or apt upgrade output and find the exact package name next to lines like Errors were encountered while processing: or dpkg: error processing package. That’s your target. Then remove it:

sudo apt remove package-name

Confirm with Y when prompted. Expect output like Removing package-name (2.4.1-3ubuntu1) ... followed by a return to the prompt.

sudo apt install package-name

This re-downloads the package fresh from your configured repos, so a stable connection matters here — a dropped connection mid-download re-corrupts the same file. Expect Setting up package-name (2.4.1-3ubuntu1) ... near the end, which means the postinst script ran clean this time.

This is more aggressive than --fix-broken because it fully removes the package’s files before restoring them, rather than patching the dependency state in place. It’s still safe for ordinary application packages. It is not safe to improvise on for grub-pc, systemd, libc6, or anything your bootloader or shell depends on — removing those can leave a box that won’t boot or won’t run sudo at all. If one of those is the broken package, test the remove/reinstall sequence in a VM or snapshot first, or ask in a distro-specific forum before running it on bare metal.

Force dpkg to reconfigure if apt still won’t touch the package

If apt still refuses to install or upgrade anything after the previous fixes, the problem usually isn’t apt at all. It’s dpkg, the lower-level tool apt calls to actually unpack and configure packages on disk. When a system reboots mid-upgrade, runs out of disk space during an install, or gets killed with kill -9 on an apt process, dpkg can be left holding a package in a half-configured state. Apt sees that mess and refuses to proceed until it’s cleaned up. This applies to Debian, Ubuntu, and Mint across all supported versions.

Reconfigure dpkg and retry apt

sudo dpkg --configure -a

This tells dpkg to walk through every package marked as unconfigured and finish the job — running any leftover postinst scripts and finalizing package state. On a normal desktop system this takes a few seconds; on a server with a stuck kernel package or a large dependency chain, give it 1-5 minutes before assuming it’s frozen. You’ll see output like Setting up openssh-server (1:9.9p2-3ubuntu0.2) ... or a series of Processing triggers for man-db (2.12.0-4build2) ... lines. No output at all just means nothing was left unconfigured, which is fine.

Once that finishes, run the fix-broken pass again:

sudo apt install -f

Expect a clean return to the prompt with no dpkg: error processing package lines. That’s your signal the install chain is unstuck.

If dpkg --configure -a appears to hang for more than 5-10 minutes with no disk activity, press Ctrl+C, run sudo apt clean to clear the local package cache, and retry the command. Don’t kill dpkg mid-write more than once — repeated interrupts are what cause this state in the first place.

Verify the fix worked and prevent it from happening again

Test apt health and check for remaining issues

Before you close the terminal and move on, confirm apt is actually healthy instead of just quiet. Run an update first:

sudo apt update

This should end with Reading package lists... Done and no lines starting with E:. If you see an E: line here, one of the earlier fixes didn’t fully take — go back and rerun sudo dpkg --configure -a and sudo apt install -f.

sudo apt check

This audits the package database for broken dependencies without changing anything. You want All packages are in a consistent state or no output at all — both mean the same thing.

sudo apt upgrade -s

The -s flag simulates an upgrade without installing anything, so it’s safe to run at any time. You’ll get either a list of packages that would be upgraded, or 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Either result is fine — what you’re checking for is the absence of errors, not the presence of updates.

Run this trio monthly, or right after any interrupted apt session, as basic maintenance. It takes about 15 seconds and catches half-broken states before they turn into a 2am troubleshooting session.

Stop it from happening again

Most broken installs trace back to one thing: apt or dpkg getting killed mid-write, usually from a closed SSH session, a reboot during unattended-upgrades, or someone hitting Ctrl+C out of impatience. For anything that takes more than a minute — kernel upgrades, distro upgrades, large meta-packages — run it inside screen or tmux so a dropped connection doesn’t kill the process.

Don’t hand-edit files under /var/lib/dpkg or delete lock files while a real apt process is running — that’s how half-configured states happen in the first place. And if this keeps recurring on the same box, check systemctl status systemd-resolved and your network link; a flaky connection mid-download is a common repeat offender, especially on self-hosted boxes pulling from slow or overseas mirrors.

Frequently Asked Questions

Related Reads

• How to Reset SSH Connection: 5-Minute Fixes

  SSH connection frozen or hanging? Copy-paste fixes ordered by likelihood. Covers hung sessions, timeout errors, and stal…

• Disk Full But df Shows Space: Fix Inode Exhaustion

  Disk full error but df shows free space? Your inodes are exhausted. Find the culprit and fix it in 5 minutes with these …