Back to guides

linux troubleshooting guide

APT and dpkg Problems: First Checks Before Repair

Inspect locks, held packages, broken package states, repositories, and upgrade previews before running package repair commands.

Problem

APT or dpkg reports locks, interrupted installs, kept-back packages, broken states, or repository warnings. The wrong repair command can remove packages, restart services, or make a production host worse.

First rule

Read package state and simulate changes before installing, removing, purging, or forcing configuration.

Audience

Ubuntu and Debian VPS owners, Linux administrators, and certification students practicing package management

Cert context

Useful for LPIC-1 and Linux+ style package-management practice. This is unofficial study support, not provider-approved training.

quick start

Safe first commands

  1. apt list --upgradable 2>/dev/null
  2. apt-cache policy nginx openssl
  3. dpkg -l | awk '$1 !~ /^ii/ {print}'
  4. apt-get -s upgrade

Read pending changes first

Before repair, capture what APT thinks is available and which packages would change. Simulation output is safer than starting an upgrade under pressure.

  1. apt list --upgradable 2>/dev/null
  2. apt-get -s upgrade

Check package origin and candidate

Repository and signing problems often show up as surprising candidates. Check policy before blaming the package itself.

  1. apt-cache policy nginx openssl
  2. apt-cache policy | sed -n '1,80p'

Inspect dpkg state

Interrupted package operations leave dpkg states that should be understood before running repair commands.

  1. dpkg -l | awk '$1 !~ /^ii/ {print}'
  2. dpkg-query -W -f='${Package}\t${Status}\n' | grep -v 'install ok installed'

Review held and kept-back packages

Held packages and kept-back upgrades are not automatically errors. They can reflect dependency changes, kernel updates, or intentional pins.

  1. apt-mark showhold
  2. apt-get -s upgrade | sed -n '/kept back:/,/^Inst/p'

triage logic

How to read the result

simulation shows removals

The proposed repair is no longer a simple update and can remove services or libraries.

Next: Stop and inspect package policy, pins, and dependency conflicts before approving changes.

dpkg has non-ii states

A previous operation may be unpacked, half-configured, removed-but-config-files-left, or failed.

Next: Capture the state and inspect package logs before running configure or fix-broken commands.

repository candidate is unexpected

A repository, pin, architecture, or signing issue may be steering APT toward the wrong source.

Next: Review apt policy and repository files before installing.

safety notes

Slow down here

  • Do not run package repair commands during a production incident without reading the simulated action.
  • Package operations can restart services or replace config files.
  • Keep terminal output from the first failure; it is often more useful than the later repair output.

Independent study support

These guides are cert-adjacent practice material, not official training, endorsement, exam dumps, or real exam questions.

related commands

Command cards