Common Failure Patterns

Chapter 8
Checking Dependencies & Troubleshooting Broken Packages
Diagnosing and fixing the most common real-world package management failures, on both Debian and RedHat-based systems

Every concept from Chapters 1-7 occasionally collides with reality — interrupted installs, conflicting dependencies, partially-removed packages. This chapter is the practical troubleshooting reference for when something genuinely goes wrong, covering both families side by side.

Common Failure Patterns

Interrupted install (power loss, killed terminal)
A package is left "half-configured" — installed but never finished its setup scripts.
apt: dpkg --configure -a · dnf: dnf install --skip-broken, or rpm verification
Unmet dependencies
A package needs something not currently available — wrong version installed, or no source provides it at all.
apt: apt --fix-broken install · dnf: dnf install (auto-resolves) or check repo availability
Held/conflicting packages
Two packages require incompatible versions of the same shared dependency — neither side can install cleanly.
Identify the conflict explicitly, choose one side, or find an alternative package
Locked package database
Another package manager process is still running, or crashed leaving a stale lock file.
Wait for genuine processes to finish; only remove a stale lock if truly certain nothing is using it

Debian/APT Troubleshooting in Practice

$ # Symptom: "dpkg was interrupted, you must manually run 'dpkg --configure -a'"
$ sudo dpkg --configure -a

$ # Symptom: "The following packages have unmet dependencies"
$ sudo apt --fix-broken install

$ # Symptom: held back, won't upgrade automatically
$ sudo apt install <package> # explicitly naming it often resolves a hold

$ # The full recovery sequence, in order, for a genuinely broken state
$ sudo dpkg --configure -a
$ sudo apt --fix-broken install
$ sudo apt update
$ sudo apt upgrade

E: Unable to locate package — a deceptively simple error

$ sudo apt install some-typo-name
E: Unable to locate package some-typo-name

Almost always either a genuine typo, a package that needs a repository not yet configured (Chapter 3), or simply running apt install without ever having run apt update on a fresh system — check the spelling first, then whether the right repository is actually enabled.

RedHat/dnf Troubleshooting in Practice

$ # Check for general consistency issues across the whole installed package set
$ sudo dnf check

$ # Clean cached metadata if it seems stale or corrupted
$ sudo dnf clean all
$ sudo dnf makecache

$ # Identify exactly what's blocking a specific install
$ sudo dnf install nginx -v # verbose output shows the actual resolution attempt

$ # If a package's history shows a problematic transaction, undo it specifically
$ dnf history
$ sudo dnf history undo <transaction-id>
dnf clean all + makecache is the RPM-world equivalent of "just try refreshing everything"
A surprising number of confusing dnf errors (packages that should clearly exist not being found, version mismatches that don't make sense) trace back to stale local metadata cache rather than a genuine system problem — clearing and rebuilding it is a cheap, safe first troubleshooting step before assuming something more serious is wrong.

Resolving a Genuine Dependency Conflict

  1. Read the actual error message carefully. Both apt and dnf name the specific conflicting packages and versions explicitly — this is rarely a vague, unsolvable mystery.
  2. Check if one side has a newer version available that resolves the conflict — sometimes a repository simply hasn't been refreshed (Chapter 2/5).
  3. Consider whether one of the conflicting packages is genuinely needed — removing the less important one is often the simplest real resolution.
  4. As a last resort, search for whether this is a known, documented issue — dependency conflicts in well-maintained distributions are usually already discussed publicly, with a known workaround.
Forcing an install past a dependency conflict is almost always the wrong move
Both apt and dnf offer ways to forcibly ignore dependency checks entirely — genuinely tempting when frustrated, but this routinely produces a system with software that's installed yet doesn't actually work correctly, sometimes in ways that aren't obvious until much later. Understanding and resolving the actual conflict, even if slower, avoids trading a clear error message now for a confusing, hard-to-diagnose failure later.

Chapter 8 Quick Reference

  • Interrupted install: dpkg --configure -a (apt) / verify with rpm -V (dnf)
  • Unmet dependencies: apt --fix-broken install (apt) / dnf generally auto-resolves, dnf check for consistency (dnf)
  • Full apt recovery sequence: dpkg --configure -a → apt --fix-broken install → apt update → apt upgrade
  • E: Unable to locate package — check for typos first, then whether the right repository is enabled
  • dnf clean all + dnf makecache — cheap first step for confusing dnf errors, often a stale metadata cache
  • dnf history undo <id> — rolls back a specific problematic transaction
  • Resolving real conflicts: read the error carefully, check for newer versions, consider removing the less critical package
  • Never force past a dependency conflict — trades a clear error now for a confusing failure later
  • Next chapter: other package managers overview — snap, flatpak, pacman