E: dpkg was interrupted — repair a half-finished apt install

E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem. means an earlier install or upgrade stopped before dpkg finished setting packages up, and apt will not touch anything until that is completed. Run the command it names, then let apt repair the dependencies. If dpkg --configure -a fails as well, the lines above Sub-process /usr/bin/dpkg returned an error code (1) name the package and the reason: fix that cause and run it again, without deleting anything in dpkg’s database.

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt update && sudo apt upgrade

If all three finish without an error, you are done. The rest of this article is for when one of them fails or seems to hang.

Why was dpkg interrupted?

Installing a package happens in two phases: dpkg unpacks the files, then runs the package’s configuration scripts. While it works, dpkg keeps a journal in /var/lib/dpkg/updates/. If the run ends early, the journal is left behind and apt refuses to continue until the configuration is finished. Common reasons:

• The SSH session dropped in the middle of an upgrade, and apt was killed with it.
• The server rebooted or lost power, including a reboot you started while unattended-upgrades was still working in the background.
• The kernel’s OOM killer ended apt or a package script on a small server. See process killed by the OOM killer.
• The disk, or just /boot, filled up during the install.
• Someone pressed Ctrl+C because the upgrade looked stuck.

The logs show what was happening when it stopped:

tail -n 30 /var/log/dpkg.log
sudo tail -n 60 /var/log/apt/term.log     # full output of recent apt runs

Is it safe to run dpkg --configure -a?

sudo dpkg --configure -a is safe. It runs the configuration step for every package that was unpacked but not yet configured, which is exactly what the interrupted run would have done next. It does not touch fully installed packages, and running it twice does no harm.

If it answers dpkg: error: dpkg frontend lock was locked by another process with pid 1234, something is still running. That is usually unattended-upgrades, which finishes on its own. Wait for that PID rather than removing the lock; our guide to Could not get lock /var/lib/dpkg/lock covers how to tell a live process from a stale one.

What does “dpkg returned an error code (1)” mean?

When dpkg --configure -a or apt fails, the last line is always the same generic E: Sub-process /usr/bin/dpkg returned an error code (1). That line only says that dpkg failed. The reason is printed above it. A typical failure looks like this:

Setting up nginx (<version>) ...
Job for nginx.service failed because the control process exited with error code.
See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details.
dpkg: error processing package nginx (--configure):
 installed nginx package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 nginx
E: Sub-process /usr/bin/dpkg returned an error code (1)

Two facts matter: the package (nginx here) and the phase (--configure, plus “post-installation script”). The package’s files are already in place, but its setup script exited with an error, so dpkg marked it unfinished. To see every package in that state:

sudo dpkg --audit
dpkg -l | grep -v '^ii'

dpkg -l always prints five header lines, so ignore those. In the two-letter state on each package line, the first letter is what you asked for (i = install, r = remove) and the second is where the package actually is:

• iU: unpacked, not configured yet. dpkg --configure -a handles it.
• iF: half-configured. Its script ran and failed. Fix the cause, then configure again.
• iH: half-installed. Unpacking itself was cut off. Reinstall the package.
• A third letter R (as in iHR) means “reinstallation required”.
• rc: removed, only its configuration files remain. That is harmless and not part of this problem.

To see what a failing script actually tries to do, read it at /var/lib/dpkg/info/<package>.postinst.

What usually breaks a package script?

A service that will not start

Many packages start or restart their service at the end of setup. If the service fails, the setup fails. In the example above, nginx could not start, typically because of a config error or because another program already holds port 80:

sudo systemctl status nginx --no-pager
sudo journalctl -xeu nginx --no-pager | tail -n 20
sudo nginx -t                            # config syntax
sudo ss -tlnp | grep -E ':(80|443) '     # who holds the port?

Fix the config, or stop whatever is on the port (Apache is a common one, see Address already in use), then run sudo dpkg --configure -a again. The same pattern applies to MariaDB, PHP-FPM, Postfix and every other daemon.

A full disk or a full /boot

A kernel update that runs out of room in /boot fails while building the initramfs, with lines such as update-initramfs: failed for /boot/initrd.img-… and No space left on device. Check both filesystems:

df -h / /boot
uname -r                                       # the kernel you are running: keep it
dpkg -l 'linux-image-*' | grep '^ii'           # installed kernels

Remove one old kernel that is not the running one with sudo apt purge linux-image-<old-version>. If apt refuses because of the broken state, sudo dpkg --purge linux-image-<old-version> does the same at dpkg level. Then configure again. For a full root filesystem, see No space left on device.

Dependencies that are not configured

dpkg: dependency problems prevent configuration of X means X waits for another package that is itself unfinished. Fix the first package in the chain, or let apt resolve the whole chain:

sudo apt --fix-broken install      # same as: sudo apt-get -f install
sudo dpkg --configure -a

If the repair stops at apt update with a NO_PUBKEY error, a third-party repository’s key is missing: see GPG error: NO_PUBKEY. If apt cannot find a package it wants to reinstall, see Unable to locate package.

What if one package cannot be configured or removed?

Sometimes a package is so broken that neither configuring nor removing it works, and dpkg says package is in a very bad inconsistent state; you should reinstall it before attempting a removal. Try a reinstall first. Only if that fails, force the removal of that one package:

sudo apt install --reinstall <package>        # try this first

sudo dpkg --remove --force-remove-reinstreq <package>
sudo apt --fix-broken install
sudo apt install <package>                    # bring it back cleanly

Why does dpkg --configure -a hang?

It is almost always waiting for something. Open a second SSH session and look at what dpkg has started:

ps -ef --forest | grep -B2 -A4 '[d]pkg'

• A systemctl start that never returns. A service is stuck starting. Check it with systemctl list-jobs and that unit’s journal.
• A question nobody can see. A debconf dialog or a Configuration file … Modified (by you or by a script) prompt is waiting for input. Run the command in the foreground of a real terminal. To keep your own config files without being asked, use sudo dpkg --force-confdef --force-confold --configure -a.
• debconf is locked. /var/cache/debconf/config.dat is locked by another process means an earlier, stuck run still holds it. Find it with sudo fuser -v /var/cache/debconf/config.dat (fuser is in the psmisc package; sudo lsof works too), end that process with sudo kill <PID>, and run the configure step again.

What is the equivalent on Rocky, AlmaLinux and RHEL?

dnf has no “dpkg was interrupted” message. An interrupted transaction usually leaves old and new versions of some packages installed side by side. Rocky and Alma 9 ship dnf 4, where this is the safe order:

sudo dnf history info last        # what the last transaction was doing
sudo dnf check                    # duplicates and broken dependencies
sudo dnf remove --duplicates      # drop the older copy of each duplicated package
sudo dnf upgrade                  # or re-run whatever command was interrupted

Run sudo rpm --rebuilddb only if rpm itself reports a damaged database, not as a routine step.

How do I prevent it next time?

• Run upgrades inside tmux or screen. Start with tmux new -s upgrade. If SSH drops, log in again and tmux attach -t upgrade picks up where you were.
• Do not reboot while apt is busy. Check with pgrep -a 'apt|dpkg|unattended' first. On a fresh server, unattended-upgrades often runs in the first minutes after boot.
• Keep room in /boot. sudo apt autoremove --purge removes kernels that are no longer needed.
• Take a snapshot before a release upgrade, such as Debian 12 to 13 or Ubuntu 22.04 to 24.04. If the new kernel then fails to boot, see VPS keeps rebooting.

On a VMHeaven Standard KVM server, snapshots and a VNC console are in the panel, so a release upgrade that goes wrong after a snapshot is a rollback rather than a rebuild.

Frequently asked