Fix "dpkg Was Interrupted" in Kali Linux (all versions) & Debian

Kali Linux stops part way through an update and prints this, in the tone of a machine that thinks you should have known better:

E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.

So do exactly that. Open a terminal and run sudo dpkg --configure -a. It finishes the installation that got cut off, and for around nine people in ten that is the entire fix, in about ten seconds. Follow it with sudo apt --fix-broken install, then sudo apt update && sudo apt full-upgrade, and your machine is back.

Before i go for the solution, i know few of you reading this blog had couple of doubts on whether i'm still alive as the number of posts that i wrote has reduced a lot from days to Months to now years. A Big Sorry! As i'm getting busy with the so called life on the other end, i'm unable to focus much on writing posts. I will ensure to dedicate time for our site!

This page exists for the tenth person — the one for whom dpkg --configure -a also fails. Almost every other result stops at the command and wishes you luck. That is the point where people start deleting files out of /var/lib/dpkg/ on the advice of a forum thread from 2014, and turn a two-minute repair into a reinstall.

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

The Saturday It Cost Jake Four Thousand Rupees

Jake runs a small phone shop. Two counters, a repair bench at the back, and one elderly desktop that does unlock reports, invoices and the occasional data recovery job for a walk-in customer. That desktop runs Kali, because his nephew set it up and because the tools he needs for the recovery work live there.

On a Saturday morning — the busiest day of his week — he started an update, watched it scroll, decided after about forty seconds of silence that it had frozen, and closed the terminal window.

It had not frozen. It was unpacking a large package.

From then on, every single command he tried refused with the same red line. The customer waiting for a recovered phone backup was told to come back Monday. She did not come back at all. Jake puts that at roughly four thousand rupees between the job itself and the two friends she would have sent.

He called Ethan on the Sunday, already four search results deep and one keystroke away from running rm -rf inside /var/lib/dpkg/.

"Stop," Ethan said. "Genuinely, stop. That command would have cost you the machine instead of the afternoon. What you actually did is far less dramatic than it looks, and once you understand it you will never be frightened of it again."

What the Error Actually Means

"You type apt ten times a week," Ethan said. "But apt is not the thing that installs software."

There are two tools stacked on top of each other, and knowing which is which is most of the diagnosis:

• apt is the manager. It reads your repository lists, works out what depends on what, downloads the .deb files, and decides the order things happen in. A .deb file is simply a Debian package: an archive containing the program's files plus a few small scripts that run before and after installation.
• dpkg is the workman. It takes one .deb at a time and physically puts it on the disk. It knows nothing about repositories or dependencies; it does what apt tells it.

Your error came from the workman, not the manager. That is why the fix is a dpkg command and not an apt one, and it is why running apt update over and over changes nothing.

Installing a package happens in two separate stages

This single fact explains the entire error, and most of the rest of this page.

1. Unpack. The files come out of the .deb and are written to their real locations on disk — binaries into /usr/bin, libraries into /usr/lib, defaults into /etc.
2. Configure. The package's setup script runs. It creates system users, generates configuration, registers and starts services, rebuilds caches, and sometimes rebuilds the initramfs — the small startup filesystem your kernel loads before it can reach your real disk.

Those are genuinely separate steps, and a package sitting between them is in a state Debian calls half-configured or, in the listing codes, unpacked. The files exist. Nothing has been set up. The program is on the disk and may not run at all.

Jake closed his terminal between stage one and stage two on a package that was midway through unpacking. That is the whole of what happened to his machine.

Reading the package states, so you stop guessing

Two minutes of learning here pays for itself every time something breaks. Run:

dpkg -l | grep -v '^ii'

That lists every package that is not in the normal healthy state. On a working machine it returns a header and almost nothing else. The two-letter code at the start of each line is your diagnosis:

So dpkg -l | grep '^iU' gives you the precise list of packages your interruption stranded. If that list comes back empty, your problem is something else entirely and no amount of --configure -a will help — which is a genuinely useful thing to learn in five seconds rather than after an hour.

The other command worth knowing takes no arguments and prints nothing at all when your system is healthy:

sudo dpkg -C

-C is short for --audit. It hunts for packages in a broken state and describes what is wrong with each one in plain English. Silence means you are clean. This is the command to finish with, and we come back to it at the end.

One Question Decides Everything That Follows

Do not read this whole page. Run one command and let the answer send you to one of two places.

sudo dpkg --configure -a

The -a means all: configure everything currently sitting unfinished, not one named package. Watch what it does, and answer the one question that matters:

That is the whole diagnostic. Everything below is one of those five doors opened wide.

Route 1 — The Clean Repair (Nine Cases in Ten)

The command completed. You are nearly finished, but not quite — an interruption usually leaves two kinds of damage, and you have only repaired one of them.

Step 1 — answer the configuration question correctly, if it appears

Part way through, you may get a purple full-screen prompt or a text question like Configuration file '/etc/ssh/sshd_config' followed by a menu of options. This is the moment people panic and pick randomly.

• Press Enter to keep the version currently installed. This is the safe answer if you never deliberately edited that file, and it is the default for a reason.
• Press D first if you want to see the differences before choosing. It shows you exactly what would change. Press Q to leave the diff view.
• Choose the package maintainer's version only if you know you never customised the file and you want the new defaults.

If you did customise it — a hardened SSH config, a proxy setting, a custom repository entry — keep yours and merge the new options in by hand afterwards. The new file is always saved alongside as filename.dpkg-dist, so nothing is lost either way.

Step 2 — repair the dependencies the interruption stranded

sudo apt --fix-broken install

An interrupted upgrade often leaves package A installed while package B, which A depends on, never arrived. dpkg cannot solve that, because dpkg does not do dependencies — apt does. This command works out what is missing and fetches it.

Older guides write it as sudo apt-get -f install. Identical command, older spelling.

Step 3 — bring the whole system back into line

sudo apt update
sudo apt full-upgrade

The original upgrade never finished, so finish it properly. One Kali-specific point that matters more than most people realise:

Step 4 — confirm you are actually clean, rather than hoping

sudo dpkg -C                  # prints nothing when healthy
sudo apt-get check            # verifies the dependency tree
dpkg -l | grep -v '^ii' | tail -n +6   # should list nothing

Three commands, five seconds, and you know rather than assume. If all three are quiet, the machine is genuinely repaired and you can stop reading.

One last thing worth doing if the interrupted upgrade touched the kernel or any driver: reboot. A running kernel is not replaced under your feet, and until you reboot, the version you are running is not the version that is installed.

Route 2 — When dpkg --configure -a Fails Too

This is the section that does not exist anywhere else, and it is why most people are still searching after they ran the command they were told to run.

The single insight that unlocks this: dpkg is not broken. One package is. Find its name and stop treating this as a mysterious system-wide fault.

dpkg: error processing package some-package-name (--configure):
 installed some-package-name package post-installation script
 subprocess returned error exit status 1

Errors were encountered while processing:
 some-package-name

The name under Errors were encountered while processing is your real problem. If several are listed, work on the first one — the others are usually just waiting on it.

Everything below assumes you have that name. Work down the cases in order; they are ordered by how often they turn out to be the answer.

Case A — the disk is full, and the error never says so

This is the most common hidden cause by a wide margin, and it is the one people check last. A default 20 GB virtual disk on a Kali VM fills faster than anyone expects, particularly once you have pulled down a few large toolsets or a local model.

df -h /            # space on the root filesystem
df -h /boot        # separate, small, and fills up with old kernels
df -i /            # inodes - can run out with space still free

That third line catches a case almost nobody checks. An inode is the record that tracks one file; a filesystem has a fixed number of them. You can have twelve gigabytes free and still be unable to create a single new file. The resulting error is indistinguishable from a full disk.

/boot deserves its own line because on many installs it is a small separate partition, and every kernel update adds an initramfs image to it. Three or four old kernels will fill it, at which point kernel package configuration fails while df -h / shows the root filesystem perfectly healthy.

Reclaiming space, safest first:

sudo apt clean                       # cached .deb downloads, often several GB
sudo journalctl --vacuum-size=100M   # trim system logs
sudo apt autoremove --purge          # orphaned dependencies and old kernels
sudo du -xh / --max-depth=2 2>/dev/null | sort -rh | head -20

apt clean is completely safe. Those files are only cached copies of packages that are already installed and can be downloaded again if ever needed. On a machine that has been rolling for a year it routinely frees two to five gigabytes.

autoremove deserves one glance before you confirm it. It removes packages that were installed as dependencies and are no longer needed, which is normally exactly right — but on Kali it occasionally proposes removing something that belongs to a metapackage you actually use. Read the list. It is also the correct way to clear out old kernels from a full /boot.

The du line finds the real culprit when the first three are not enough. In practice it is a forgotten ISO in your home directory, a runaway log, a Docker image cache, or a downloaded model file. If you have been experimenting with local AI on this machine, that last one is not a small number — our guide to running Gemma 4 offline on Kali Linux covers roughly how much disk those weights want, and it is a common reason a Kali VM quietly runs out of room and starts interrupting installs.

Free the space, then run sudo dpkg --configure -a again. In this case it usually just works.

Case B — reinstall the one package that is failing

sudo apt install --reinstall some-package-name

This fetches a fresh copy of that package and runs its setup from a clean start. It resolves the majority of single-package failures, because the usual cause is a file that was half-written when the interruption happened.

If apt complains that it cannot fetch the package, your repository lists are stale or unreadable — run sudo apt update first. If that fails with a signature or key error rather than a dpkg error, you are looking at a different problem entirely, and we cover it separately in fixing the Kali missing-key and sub-process /usr/bin/sqv error. That post handles everything that goes wrong before a download starts; this one handles everything that goes wrong after.

Case C — the failure is a configuration file conflict

If the error mentions a path under /etc/, a setup script is refusing to overwrite something and has given up rather than guess. Make dpkg ask you properly instead:

sudo dpkg --configure -a --force-confask

It will show you the difference and let you choose. Take the maintainer's version unless you personally edited that file and remember why.

If you are repairing a machine unattended and genuinely do not care, these two options decide silently:

# keep every existing config file, take no new ones
sudo apt -o Dpkg::Options::=--force-confold full-upgrade

# take every new config file, discard your edits
sudo apt -o Dpkg::Options::=--force-confnew full-upgrade

On a server being rebuilt from a script, confold is the sane default. On your own workstation, answer the questions — the prompt exists because a file you edited is about to change, which is information you want.

Case D — it hangs, and killing it is how you got here

Long silences during configuration are normal. These are the usual reasons, none of which is a fault:

• Rebuilding the initramfs after a kernel or driver update — genuinely slow, especially in a VM on a mechanical disk.
• Regenerating font, icon, man-page or GTK caches — thousands of small files, no output while it works.
• Restarting services where one is refusing to stop, and systemd is patiently waiting out a ninety-second timeout.
• A prompt you cannot see, drawn off-screen or behind another window, waiting for a keypress that will never come.

Before you conclude anything, prove whether it is working. In a second terminal:

ps aux | grep -E 'dpkg|apt'      # is it still there?
sudo tail -f /var/log/dpkg.log   # live view of what it is doing
top                              # is anything using CPU or disk?

/var/log/dpkg.log is the single most underused file in this whole subject. It records every package state change with a timestamp. If new lines are still appearing, the job is alive and you should leave it alone.

If it is genuinely wedged for more than fifteen minutes with no log activity and no CPU use, the least damaging way out is Ctrl+C once, then run sudo dpkg --configure -a again and read the package name it stops on. Do not use kill -9. A hard kill during a database write is one of the very few ways to genuinely damage /var/lib/dpkg/status.

Case E — a service refuses to start, so the package refuses to configure

Some packages start a service as their final step, and treat a failure to start as a failure to install. Common with database, web and VPN packages. The message usually contains Job for something.service failed.

systemctl status some.service
journalctl -xeu some.service --no-pager | tail -40

Nine times out of ten the real cause is in those forty lines: a port already in use, a syntax error in a config file you edited, or a missing directory. Fix that, then run sudo dpkg --configure -a again. The package will configure once its service can start.

If you genuinely do not need that service running right now, mask it, configure the package, then unmask it afterwards. That is a legitimate escape hatch rather than a hack.

Case F — unmet dependencies and held broken packages

If apt reports Unable to correct problems, you have held broken packages, it is telling you it cannot find a combination of versions that works. On Kali this almost always means one of three things:

• You added a Debian, Ubuntu or third-party repository to a Kali system. Do not. Kali is built against its own package set, and mixing repositories produces exactly this deadlock. Your sources should contain the single official kali-rolling entry and nothing else — on current Kali (2026.2 and later) that entry lives in the DEB822-format file /etc/apt/sources.list.d/kali.sources, on older installs in /etc/apt/sources.list. Either location is fine; a second repository in either is not.
• You caught the mirror mid-sync and half the new versions are not there yet. Wait a few hours and run sudo apt update && sudo apt full-upgrade again. This is a normal, transient state on a rolling distribution.
• Something is pinned or held. Check with apt-mark showhold and release with sudo apt-mark unhold packagename.

The diagnostic command that actually explains the deadlock, rather than restating it:

sudo apt-get -o Debug::pkgProblemResolver=true full-upgrade

It is verbose, but it names which package is blocking which, which is the information you need and which the short error withholds.

Case G — the last resort, and its one genuine danger

If a single package refuses everything above and you can live without it:

sudo dpkg --remove --force-remove-reinstreq some-package-name
sudo apt --fix-broken install
sudo apt install some-package-name

Note the third line. Removing the package is not the fix; removing it so the rest of the system can finish, then installing it again cleanly, is the fix. People forget the third line and then wonder why something stopped working a week later.

A Different Error in Similar Clothes: Could Not Get Lock

One other message gets mistaken for ours constantly, and the mix-up matters because the wrong fix for it is the destructive one:

E: Could not get lock /var/lib/dpkg/lock-frontend.
It is held by process 2891 (apt)

That is not an interrupted job. It is a running one. Our error means a past installation never finished. The lock error means another process is using the package system right now, and the correct fix is usually to do nothing and wait. Find out who is holding it:

ps aux | grep -E 'apt|dpkg|packagekit'
sudo fuser -v /var/lib/dpkg/lock-frontend

On Ubuntu the holder is nearly always the unattended-upgrades service quietly doing its job. On Kali it is more likely a second terminal you forgot about, a GUI package tool, or a VM restored from a snapshot that was taken mid-update. Let it finish — killing it turns the lock error into our error.

If the process list comes back empty and the lock is genuinely stale after a crash, a reboot clears it cleanly. Failing that, lock and lock-frontend are the only two files under /var/lib/dpkg/ you may ever delete, and only after that ps line shows nothing package-related running.

Why "Just Delete the dpkg Files" Destroys Installs

Every long thread about this error contains one confident reply telling you to clear out /var/lib/dpkg/. Before you weigh that advice, know what actually lives there:

• status — the package database itself. One text file recording every package on your system, its version, its state, and its dependencies. There is no second copy in normal use.
• info/ — every package's file list and its maintainer scripts, the very scripts --configure runs.
• updates/ — a journal of changes being applied to status, so a crash mid-write can be replayed instead of corrupting the database.
• lock and lock-frontend — the two lock files. The only expendable things in the directory.

If someone — a past you included — has already deleted it, two straws are worth grasping before you reach for the ISO: dpkg keeps the previous version of the database alongside as status-old, and Debian systems keep gzipped daily copies under /var/backups/:

sudo cp /var/lib/dpkg/status-old /var/lib/dpkg/status
ls /var/backups/dpkg.status*    # older daily copies, if you need one

Restore the newest copy you have, run sudo dpkg --configure -a, and you may walk away with nothing worse than a story.

Kali 2026.2 Notes: DEB822 Sources, WSL2 and Live USBs

Three environment quirks, so you are not surprised by any of them:

• Sources moved in 2026.2. Current Kali keeps its repository entry in the DEB822-format file /etc/apt/sources.list.d/kali.sources, and your old /etc/apt/sources.list may be empty or absent. That is normal, changes nothing about this repair, and older guides pointing at the old file are simply out of date. Not sure which release you are on? Our two-command guide to checking your Kali version settles it.
• WSL2 behaves the same, with one twist. The error, the repair and the package states are identical. The twist is the cause: closing the terminal tab or running wsl --shutdown mid-upgrade is the WSL equivalent of pulling the power cord, and it is how most WSL users meet this error. Case E is rarer there because fewer services run under WSL.
• A live USB without persistence forgets your repair. The fix works, then evaporates at reboot along with everything else. Nothing is wrong with the commands; that is what a non-persistent live session is.

If It Will Not Even Boot — and the Honest Case for Reinstalling

An upgrade interrupted at the worst possible moment — mid-kernel, mid-libc — can leave a machine that never reaches the login screen. This looks terminal. It usually is not.

First door: recovery mode from the GRUB menu

Hold Shift (BIOS) or tap Esc (UEFI) at power-on to get the GRUB menu, choose Advanced options, then a recovery mode entry, and drop to the root shell. The disk is mounted read-only there, so remount it first:

mount -o remount,rw /
dpkg --configure -a

Reboot. In our interrupted-kernel test this alone brought the machine back.

Second door: chroot from the live ISO

If recovery mode itself will not load, boot the Kali live USB and repair the installed system from outside. A chroot simply means running commands as if the installed disk were the running system:

sudo mount /dev/sda2 /mnt        # your root partition - check with: lsblk
for d in dev proc sys; do sudo mount --bind /$d /mnt/$d; done
sudo chroot /mnt
dpkg --configure -a
exit

Reboot without the USB. If you no longer have install media, grab it from our Kali download links and checksum guide — and verify the checksum, since a corrupt ISO is a spectacularly bad rescue tool.

When reinstalling genuinely is the right call

Almost never — but not never. Three situations, honestly:

• The package database is gone. Someone deleted files under /var/lib/dpkg/ and the status-old and /var/backups/ copies are missing or ancient. There is nothing left to repair.
• A core package is unrecoverable. If libc6, systemd, dpkg itself, bash or the running kernel is the wreck and the chroot cannot rebuild it, the repair costs more than the rebuild.
• It is a disposable lab VM. No shame in it. If rebuilding from a snapshot or ISO takes twenty minutes and repairing takes an evening, rebuild.

If you do reinstall, copy out /home, anything under /etc you customised, and your keys and loot directories first — the chroot above is also the way to reach those files on an unbootable machine.

Making Sure There Is No Next Time

Every cause in this post is a variation on one event: an install stopped part way. So prevention is short:

• The only safe time to stop an upgrade is while it is still downloading. Downloads resume; nothing has been touched yet. The moment you see Unpacking or Setting up, the point of no return has passed — let it finish, however frozen it looks. sudo tail -f /var/log/dpkg.log in a second terminal will show you it is alive.
• Upgrading over SSH? Run it inside tmux or screen so a dropped connection does not take the upgrade down with it.
• Check df -h / before a big upgrade, and keep a couple of gigabytes of headroom. Laptop users: plug in first.
• If the only upgrade that ever fails on your machine is Metasploit's enormous one, that is its own subject — our guide to updating Metasploit on Kali covers it properly.

And Jake? His desktop was repaired in four minutes on the Sunday — Route 1, one configuration question, Enter. On the Monday he bought a small UPS for the shop machine, which cost him less than the customer he lost, and he now runs updates before opening rather than mid-rush. Most usefully of all, he knows what a forty-second silence during Unpacking is: a machine working, not a machine frozen.

The whole repair, one last time — and the final line is the promise from earlier, the command that proves you are clean by printing nothing at all:

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt update && sudo apt full-upgrade
sudo dpkg -C                      # silence here means you are done

Prefer the same territory laid out as a plain escalation ladder — one command, and if that fails, the next — without the shop, the story or the hard cases? We keep a separate step-by-step walkthrough of fixing dpkg was interrupted on Kali and Debian for exactly that reader.

Your Questions, Answered Straight

What does dpkg was interrupted actually mean?

An earlier installation stopped between its two stages: the files were unpacked onto disk, but the setup scripts never ran, so those packages sit recorded as half-installed. dpkg refuses all new work while that record is open. sudo dpkg --configure -a finishes the interrupted job.

How do I fix the dpkg was interrupted error in Kali Linux?

Run sudo dpkg --configure -a, then sudo apt --fix-broken install, then sudo apt update && sudo apt full-upgrade. Most machines are healthy after the first command. Use full-upgrade on Kali — it is a rolling release, and plain upgrade silently holds packages back.

What if sudo dpkg --configure -a fails as well?

Then dpkg is not the problem — one package is. Read the error processing package line, work on that name alone with sudo apt install --reinstall packagename, and check df -h / and df -i /, because a full disk causes this and rarely says so. The full ladder is in Route 2.

Do I need sudo, or should I run it as root?

Either, as long as the command has root privileges — it writes system directories and runs setup scripts, so an ordinary user cannot. Recent Kali installs use a sudo-capable normal user, so sudo dpkg --configure -a is right; at a root prompt, drop the sudo.

Is it safe to delete files under /var/lib/dpkg?

No, with one narrow exception. That directory is the package database; delete the status file and the system no longer knows what is installed, which is unrecoverable short of the status-old backup or a reinstall. Only lock and lock-frontend are ever safe to remove, and only with nothing package-related running.

Does deleting /var/lib/apt/lists fix dpkg was interrupted?

No. Those are apt's downloaded repository lists — the other side of the system from the interruption. Deleting the directory itself also breaks apt update until you run sudo mkdir -p /var/lib/apt/lists/partial. This post recommended it in 2022; we withdrew that above.

What causes dpkg to be interrupted in the first place?

Anything that stops an install part way: Ctrl+C because it looked frozen, a closed terminal, a dropped SSH session, a dead laptop battery, a power cut, a suspended or hard-reset VM, a full disk, or the out-of-memory killer. Installation is not atomic, so any stop leaves work half-done.

Is dpkg was interrupted the same as the could not get lock error?

No. The lock error means another process is using the package system right now, and the fix is to wait for it. Ours means a past job never finished, and the fix is sudo dpkg --configure -a. Applying the lock-error fix to our error is how people end up deleting files they should not.

Will dpkg --configure -a delete my files or settings?

No. It only completes work already in progress. Your home directory, documents, keys and personal settings are untouched. The one thing it may do is ask about a configuration file under /etc that both you and the package changed — and it asks rather than deciding for you.

How long should dpkg --configure -a take?

Usually seconds to two minutes; ten or more if many packages were stranded. It will look stalled while rebuilding an initramfs, regenerating caches or restarting services — long silences are normal. Do not interrupt it: interrupting is what created the problem.

What do the iU and iF codes in dpkg -l mean?

Package states. ii is healthy; iU is unpacked-but-unconfigured, exactly what an interruption leaves; iF is half-configured, a setup script failed; iH is half-installed, usually a full disk; rc is removed with harmless leftover config. dpkg -l | grep -v '^ii' lists only the unhealthy ones.

My disk is not full but I still get a space error. Why?

Check inodes with df -i / and check /boot separately with df -h /boot. A filesystem can have gigabytes free yet be unable to create one new file if its inodes are exhausted, and a small /boot full of old kernels stops kernel configuration while the root filesystem looks healthy.

Does this fix work on Debian, Ubuntu and Raspberry Pi OS?

Yes. dpkg sits underneath every Debian-derived distribution, so the error, cause and repair are identical on Debian, Ubuntu, Mint, Raspberry Pi OS, Parrot, Pop!_OS and Kali. Only the failing package names differ — and on Ubuntu, unattended-upgrades is a more common cause than on Kali.

My Kali system will not boot after an interrupted upgrade. What now?

Boot to the GRUB menu, choose Advanced options, then a recovery mode entry, drop to a root shell and run mount -o remount,rw / followed by dpkg --configure -a. If recovery mode fails too, boot the live ISO and repair through chroot — both walkthroughs are above. This is recoverable far more often than people assume.

Should I reinstall Kali Linux if dpkg is broken?

Almost never. Reinstalling is right in three situations only: the files under /var/lib/dpkg/ are already deleted, a core package such as libc6, systemd, dpkg itself or the running kernel is unrecoverable, or it is a disposable lab VM that rebuilds faster than it repairs.

Can I stop dpkg asking me about configuration files?

Yes, but think first. -o Dpkg::Options::=--force-confold on an apt command keeps your existing configuration files silently; --force-confnew takes the maintainer's versions silently. On a workstation, answer the prompts — each one is telling you a file you edited is about to change, which is information you want.

Worth Reading Next

Revision note. Originally published 25 December 2022. Rewritten and re-tested on Kali Linux 2026.2 (bare metal, VMware and WSL2), Debian 12 and Ubuntu 24.04, with every failure state reproduced deliberately. 

Happy breaking :)