Fix broken apt and dpkg after an interrupted update

Updated November 2026

An update that stopped halfway leaves dpkg with packages unpacked but not configured, and apt refuses to do anything else until that is finished. In almost every case the fix is to let any running update finish, run sudo dpkg --configure -a, then sudo apt --fix-broken install. Don't delete lock files or force-remove packages first.

Do this first.

Check whether apt, dpkg or unattended-upgrades is still running (see below). If it is, wait. Killing it is what usually breaks things.
Check free space with df -h / /boot /var. A full disk makes every fix fail.
Don't reboot while packages are half-configured, especially if a kernel, initramfs or bootloader package was in the update.
Keep the error message. Copy the exact text before you try fixes.

Symptoms

E: Could not get lock /var/lib/dpkg/lock-frontend or Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.
Unmet dependencies. Try 'apt --fix-broken install' with no packages, or “you have held broken packages”.
Errors from update-initramfs or “No space left on device” while a kernel is installed.
apt update fails with NO_PUBKEY or “The following signatures couldn't be verified”.

Step 1: Lock errors

apt and dpkg use lock files so two package operations can't run at the same time. On current Debian and Ubuntu these are /var/lib/dpkg/lock-frontend, /var/lib/dpkg/lock, /var/lib/apt/lists/lock and /var/cache/apt/archives/lock. A lock error almost always means another process really is working, often the automatic updates started by the apt-daily and apt-daily-upgrade timers shortly after boot. Find it:

ps -ef | grep -E '[a]pt|[d]pkg|[u]nattended'
sudo fuser -v /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock

If a process is listed, wait for it to finish. Unattended upgrades can take several minutes. Watch progress with sudo tail -f /var/log/dpkg.log.

Don't just delete the lock files. A lock file left behind by a dead process does no harm: the lock is released when the process exits. If fuser shows nothing and the error persists, the problem is not the lock. Deleting lock files while dpkg is still running lets a second process write to the package database at the same time and can corrupt it.

If a process has clearly hung (no new lines in /var/log/dpkg.log for a long time and no CPU use), stop it gently with sudo kill PID, wait, and only use kill -9 as a last resort. Then go to step 2.

Step 2: Finish configuring packages

This completes every package that was unpacked but not configured. It is safe to run more than once:

sudo dpkg --configure -a

The dpkg manual describes -a as configuring “all unpacked but unconfigured packages”. It may ask configuration questions; answer them. If it stops with an error, read the first error, not the last line. Then check what dpkg still considers broken:

sudo dpkg --audit

Package scripts may restart services while they configure. Expect a short blip on web or database servers.

Step 3: Fix broken dependencies

sudo apt update
sudo apt --fix-broken install

--fix-broken (-f) tells apt to “correct a system with broken dependencies in place”. It installs missing dependencies, or proposes removing packages it can't satisfy. Read the list before you answer Y. If it wants to remove something important (your web server, database, openssh-server, ubuntu-server or a kernel meta-package), answer N and find out why first.

Then complete the interrupted upgrade:

sudo apt upgrade

Unmet dependencies

Ask apt to show exactly what conflicts:

apt-cache policy PACKAGE
sudo apt install PACKAGE

Common causes are a third-party repository that ships a newer or older version of a distribution package, sources for two different releases mixed in /etc/apt/sources.list.d/, or a manually installed .deb. Disable the extra repository (comment out its lines or rename its file so it doesn't end in .list or .sources), run sudo apt update, and retry.

Held packages

A held package is never upgraded, so its dependents can't be either. List and release holds:

apt-mark showhold
sudo apt-mark unhold PACKAGE

Someone may have held it on purpose. Check your change notes before you unhold, and see roll back a bad update for when holding is the right call.

Step 4: Full /boot

Many servers have a small separate /boot. When it fills up, a new kernel installs but its initramfs can't be written, and dpkg stops in the middle. Check:

df -h /boot
uname -r
dpkg --list 'linux-image-*' | grep '^ii'

Remove kernels you no longer need with apt, never with rm in /boot:

sudo apt autoremove --purge

If apt refuses because of the broken state, purge one specific old kernel. Pick a version that is not the one uname -r shows and not the newest one being installed:

sudo apt purge linux-image-OLD-VERSION
sudo dpkg --configure -a
sudo apt --fix-broken install

Never remove the running kernel or all kernels. Keep at least the running kernel and one known-good older one. If /boot is still too small, see disk full.

Step 5: NO_PUBKEY and key errors

An error like NO_PUBKEY 1234ABCD... means apt can't verify a repository's signature. For Debian and Ubuntu's own repositories this is rare; reinstall the keyring package (debian-archive-keyring or ubuntu-keyring). For a third-party repository the vendor has usually rotated or expired its key.

The old fix, apt-key adv --recv-keys, is the wrong tool. apt-key trusted a key for every repository on the system, was deprecated for years, and is no longer shipped with APT 3.0 in Debian 13. The current method ties each key to one repository with signed-by:

sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://vendor.example.com/repo-key.asc | sudo gpg --dearmor -o /etc/apt/keyrings/vendor.gpg
gpg --show-keys /etc/apt/keyrings/vendor.gpg

Compare the fingerprint that gpg --show-keys prints with the one on the vendor's documentation page before you trust it. Then point the repository at that key file. In the newer deb822 format (/etc/apt/sources.list.d/vendor.sources):

Types: deb
URIs: https://vendor.example.com/debian
Suites: stable
Components: main
Signed-By: /etc/apt/keyrings/vendor.gpg

or in the one-line format (/etc/apt/sources.list.d/vendor.list):

deb [signed-by=/etc/apt/keyrings/vendor.gpg] https://vendor.example.com/debian stable main

Run sudo apt update. The Debian wiki says third-party keys must not go in /etc/apt/trusted.gpg.d, because a key there is trusted for every repository. If a vendor's install script put one there, move it to /etc/apt/keyrings and add signed-by.

Don't turn off signature checks. Options such as trusted=yes or allow-insecure=yes make the error go away by accepting unsigned packages. That is exactly what an attacker in the middle needs.

Confirm it is fixed

sudo dpkg --audit prints nothing.
sudo apt update finishes without errors or warnings about signatures.
sudo apt upgrade shows nothing pending, or only what you held on purpose.
apt-mark showhold lists only packages you held on purpose.
If a kernel or libc was updated, check whether a reboot is needed: see restart after updates. Reboot in a maintenance window (reboot).

Prevent it next time

Run updates inside tmux or screen so a dropped SSH session doesn't kill dpkg.
Keep 20% or more free on /, /var and /boot, and let apt autoremove clean old kernels.
In scripts use apt-get, not apt; Ubuntu's documentation says apt is meant for interactive use.
Keep third-party repositories to a minimum, each with its own signed-by key.
Take a snapshot before big upgrades. See automatic updates and patch fast.

When to get help

Call your hosting provider or a Linux administrator if dpkg --configure -a fails on core packages (libc6, systemd, dpkg itself), if /var/lib/dpkg/status is damaged or empty, if the server no longer boots (kernel boot failure), or if you find packages or keys you didn't add, which can be a sign of compromise (signs of compromise).