problem hub

Preview first

APT or dpkg repair needed

Inspect package state, held packages, candidates, and simulated changes before running repair commands.

Safest first command

apt-get -s upgrade

Before you run this

Expected output: A simulated package transaction showing packages that would be upgraded, kept back, installed, removed, or configured.

When not to use it: Do not run fix-broken, dist-upgrade, configure, purge, or remove commands until the simulated action makes sense.

Expected output example

Inst openssl [3.0.2-0ubuntu1] (3.0.2-0ubuntu1.18 Ubuntu:22.04/jammy-updates)
Conf openssl (3.0.2-0ubuntu1.18 Ubuntu:22.04/jammy-updates)

How to read the result

Simulation output shows what APT would do without changing packages. Look for removals, held packages, broken states, or unexpected repositories before running a real repair.

What to check next

Simulation shows packages would be removed

Means: APT's proposed repair may widen the outage or remove dependencies.

Next step: Inspect package candidates and origins before accepting the transaction.

Check the Installed and Candidate Package Version

dpkg state is not ii

Means: A package may be half-installed, unpacked, or awaiting configuration.

Next step: List broken dpkg states and inspect the specific package before repair.

Find Broken or Leftover dpkg States

Packages are kept back or held

Means: A hold, dependency change, or phased update may block the upgrade path.

Next step: Review held and kept-back packages before changing holds.

Find Held Packages Blocking Patches

Preview package changes

APT and dpkg repairs can remove packages or restart services. Use simulation and package-state inspection first.

apt-get -s upgrade
dpkg -l | awk '$1 !~ /^ii/ {print}'
apt-mark showhold

Check package origin

Repository, pinning, architecture, and signing issues often show up as unexpected package candidates.

Package lock branch

If apt or dpkg reports a lock, prove whether a package manager is still running before touching lock files. Timers and unattended upgrades can legitimately hold locks.

ps -ef | grep -E 'apt|dpkg|dnf|yum|pacman' | grep -v grep
sudo lsof /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock 2>/dev/null
systemctl list-timers apt-daily* --no-pager

Bad fixes to avoid

Do not delete apt or dpkg lock files until you have proven no package manager is running. Do not run dist-upgrade, remove packages, or force dpkg states before reading the simulation and package status. Do not paste repository tokens or private mirror URLs into public tickets.

Common causes

Interrupted dpkg configure step
APT lock held by another package process
Held packages
Unsigned or stale repository
Mixed distro releases or third-party repos

What not to change yet

Do not remove packages because a forum command says so.
Do not run dist-upgrade on production before reading the simulation.
Do not delete lock files until you know no package manager is running.

Stop and escalate if

The system is production and package repair could restart critical services.
dpkg or apt metadata appears corrupted beyond a normal interrupted install.
The package set includes kernel, libc, OpenSSH, database, or boot-related components.

platform notes

Distro and service notes

Debian/Ubuntu

Use apt-get -s and dpkg status checks before repair commands.

Services

Package upgrades can restart services; schedule maintenance when needed.

Rollback

Know how the package was installed before purging or downgrading.

supporting commands