Fixing Broken apt Dependencies: apt --fix-broken install Explained

apt --fix-broken install (short form: apt -f install) is the command purpose-built to repair a broken dependency state on Debian-based systems such as Ubuntu. When an install is interrupted or a package lands without its dependencies, apt refuses to do anything else until the inconsistency is resolved — and this command resolves it by downloading missing dependencies, completing half-finished configuration, and, if necessary, removing the package that cannot be satisfied. You run it with no package names attached; fixing the system is the operation.

How apt gets into a broken state

APT (Advanced Package Tool) is a dependency-resolving front end; the actual unpacking and configuration is done underneath by dpkg, the Debian package manager, which records every package’s state in its database at /var/lib/dpkg/status. Each package moves through states during an install — unpacked, half-configured, installed — and dpkg journals those transitions so it always knows exactly where it stopped.

That bookkeeping is what breaks visibly when an operation dies mid-flight. The common causes:

• An interrupted install — a dropped SSH session, Ctrl+C, a full disk, or a power loss while dpkg is unpacking or running a package’s configuration scripts. Packages are left in intermediate states, and every later apt install or apt upgrade aborts with “unmet dependencies” messages telling you to run the fix.
• Installing a .deb directly with dpkg -i package.deb. dpkg performs no dependency resolution; if the package needs libraries that are not present, dpkg unpacks it anyway and then marks it broken. (The modern alternative, apt install ./package.deb, resolves dependencies from the repositories up front and avoids the whole problem.)
• Conflicting or held packages — a partial upgrade, a pinned version, or a third-party repository whose package depends on versions your release does not ship.

The key mental model: apt deliberately locks itself down when the dependency graph is inconsistent. Refusing to layer new changes on a broken base is a safety feature, and the error output explicitly points at the repair command.

What apt —fix-broken install actually does

Given a broken state, apt --fix-broken install asks the resolver to compute the smallest set of actions that returns the system to consistency, then executes it:

1. Downloads and installs any dependencies that are missing for already-unpacked packages.
2. Lets dpkg finish configuring anything left half-configured.
3. Proposes removing packages whose dependencies cannot be satisfied at all — it shows the plan and asks for confirmation before acting.

Because you invoke it without arguments, there is no ambiguity about intent: you are not requesting new software, you are asking apt to make the existing state whole. It is idempotent in practice — running it on a healthy system simply reports nothing to do. The -f short form appears constantly in real error messages (apt --fix-broken install is what recent Ubuntu prints; older documentation shows apt-get install -f), and both spellings drive the same resolver logic.

Two situations it does not cover: a dpkg run that was interrupted before apt’s resolver is even in play (dpkg will tell you to run dpkg --configure -a first), and stale or unreachable repository metadata (that is apt update territory).

The repair toolbox, side by side

Command	What it fixes
apt --fix-broken install	Unmet/broken dependencies; completes or rolls back a partial install
dpkg --configure -a	Finishes configuration of every unpacked-but-unconfigured package after dpkg itself was interrupted
apt update	Stale or missing repository metadata (not a dependency repair at all)
apt clean / apt autoclean	Clears the downloaded-package cache in /var/cache/apt/archives — useful when a corrupted download keeps failing
apt autoremove	Removes orphaned dependencies no longer needed — housekeeping, not repair

A practical recovery sequence after a badly interrupted upgrade is sudo dpkg --configure -a followed by sudo apt --fix-broken install: first let dpkg finish what it already unpacked — including hooks like the initramfs rebuild that kernel packages trigger — then let apt fill any dependency gaps.

One caution that shows up in real life more than it should: if apt reports that it “could not get lock /var/lib/dpkg/lock-frontend,” that is a different problem — another package process (an unattended-upgrades run — typically launched by a systemd timer — or a stuck installer) holds the lock. Verify no apt/dpkg process is running (ps aux | grep -E 'apt|dpkg') before doing anything about lock files; deleting locks under a live process corrupts exactly the state this article is about repairing.

Why dpkg -i is the classic trigger

The scenario worth internalizing end to end: you download some-tool.deb from a vendor site and run sudo dpkg -i some-tool.deb. dpkg unpacks it, hits missing dependencies, and exits with errors; the package now sits half-installed, and apt starts refusing normal operations. sudo apt --fix-broken install reads the recorded (but unmet) dependencies, pulls them from the configured repositories, installs them, and completes the vendor package’s configuration. The pair — dpkg -i then apt -f install — was the standard two-step for years, and understanding why it works (dpkg records what is missing; apt knows how to fetch it) is exactly the depth the exam wants. Today, sudo apt install ./some-tool.deb collapses the two steps into one and never enters the broken state.

How the XK0-006 exam tests this

• The signature scenario: an apt operation on Ubuntu is interrupted partway through, every subsequent apt command reports unmet dependencies and refuses to continue, and you must pick the command specifically designed to repair that state — apt --fix-broken install. Distractors are plausible-sounding neighbors: apt update (metadata only), apt autoremove (orphan cleanup), or apt clean (cache deletion).
• A dpkg -i aftermath question: a manually installed .deb fails on missing dependencies, and the follow-up command that completes the install is the fix-broken form.
• A sequencing pattern: after an interruption at the dpkg layer, the credited order runs dpkg --configure -a and then the apt repair — testing that you know which layer each tool operates on.
• A conceptual check on the apt/dpkg split: apt resolves dependencies and fetches from repositories, dpkg installs and tracks state in /var/lib/dpkg, and dpkg alone never resolves dependencies.

Package management questions like these land in the System Management domain — see the full XK0-006 study guide for how the exam is weighted, and drill them with practice questions until the repair sequence is reflex.

Quick reference

• apt --fix-broken install (or apt -f install) repairs unmet-dependency states; run it with no package names.
• It installs missing dependencies, finishes half-configured packages, and may propose removals to restore consistency.
• Interrupted installs and dependency-less dpkg -i installs are the two classic causes of the broken state.
• dpkg --configure -a completes configuration after dpkg itself was cut off — run it before the apt repair when both apply.
• apt update refreshes repository metadata; it does not fix dependencies.
• apt install ./package.deb installs a local .deb with dependency resolution, avoiding the breakage entirely.
• dpkg tracks package state in /var/lib/dpkg/status; apt caches downloads in /var/cache/apt/archives.
• Never delete apt/dpkg lock files without first confirming no package process is still running.