What's the difference between apt --fix-broken install and dpkg --configure -a?

dpkg --configure -a resumes partially completed package configuration scripts — it handles packages that were unpacked but never configured. apt --fix-broken install works at a higher level, asking the dependency resolver to satisfy or remove conflicting and missing dependencies. Run dpkg --configure -a first, then apt --fix-broken install.

Is it safe to delete dpkg lock files?

Only if you've confirmed no apt, dpkg, or package manager process is actually running. Use lsof on the lock file path to check. Removing a lock held by a live process can corrupt the package database.

Will apt --fix-broken install remove packages I want to keep?

It can. Always read apt's proposed changes before typing Y. If apt wants to remove something important, the safer path is identifying the conflicting package and handling it manually with dpkg.

Why does this keep happening after I install .deb files manually?

Manually installed .deb files bypass apt's dependency resolver. If the .deb requires a package version not available in your repos, it leaves the system in a broken state every time. Use apt install ./package.deb instead of dpkg -i so apt can resolve dependencies automatically.

How do I find which package is actually broken?

Run sudo dpkg --audit for a list of all packages in an inconsistent state. You can also run sudo apt -f install and read the error output carefully — it names the offending package and which dependency constraint it violates.

How to Fix dpkg "Broken Packages" Errors

A broken package state in dpkg stops apt dead in its tracks. Every subsequent install, upgrade, or removal command fails until the underlying inconsistency is resolved. This happens when a package install is interrupted (power loss, Ctrl+C, full disk), when dependencies can't be satisfied, or when you force-install a .deb manually. The fix is usually straightforward, but the right sequence matters.

Understanding the Error

Before running any fix, read the actual error message. The two most common forms are:

"dpkg was interrupted" — a previous dpkg run didn't finish cleanly. Package scripts are stuck in a half-configured or half-installed state.
"broken packages" / "unmet dependencies" — apt's dependency solver can't satisfy requirements for one or more packages, often because a package was removed manually or a third-party repo went out of sync.

The commands below address both. Run them in order; stop as soon as the problem is resolved.

Step 1: Update the Package Index

Always start with a fresh package index so apt works with current dependency data. A stale cache can cause phantom dependency errors.

sudo apt update

If apt update itself fails with a broken-packages error, skip to Step 2 and return here afterward.

Step 2: Configure Any Pending Packages

When dpkg is interrupted mid-install, packages are left in an "unpacked but not configured" state. dpkg --configure -a resumes all pending post-install and configuration scripts.

sudo dpkg --configure -a

You may see a lot of output as scripts run. Errors here usually point to a specific package name — note it. If the command exits cleanly, run sudo apt update && sudo apt upgrade to confirm the system is healthy again. If errors remain, continue.

Step 3: Let apt Fix Broken Dependencies

apt --fix-broken install (historically apt-get -f install) tells the dependency resolver to figure out what's missing or conflicting and either install missing dependencies or remove the offending package.

sudo apt --fix-broken install

The install at the end is not a typo — it's required. When no package name is given, apt operates only on the broken state. Review what apt proposes before confirming, especially if it plans to remove packages you care about.

Step 4: Force-Remove a Stuck Package (if needed)

If steps 2 and 3 identify a specific broken package that can't be configured or removed normally, use dpkg's force flags. Replace packagename with the actual package.

Remove ignoring dependencies

sudo dpkg --remove --force-remove-reinstreq packagename

If removal fails, purge instead

sudo dpkg --purge --force-all packagename

Use --force-all carefully. It bypasses all safety checks. Only use it on the specific broken package, not as a general habit. After forcing removal, run sudo apt --fix-broken install again to let apt re-satisfy any dependencies that package was providing.

Step 5: Reinstall a Broken Package

Sometimes the package itself is present but corrupted on disk. Reinstalling fetches a clean copy and re-runs its scripts.

sudo apt reinstall packagename

If apt refuses because the package is in a broken state, use dpkg directly:

sudo dpkg -i --force-confask /var/cache/apt/archives/packagename_*.deb

The cached .deb may not exist if the cache was cleaned. In that case, download it manually with apt download packagename first.

Step 6: Rebuild the Package Database

The dpkg database lives in /var/lib/dpkg/. In rare cases — filesystem errors, abrupt shutdowns during database writes — the database files themselves become inconsistent. Signs include errors like database is locked even when no apt/dpkg process is running, or status database area is locked.

Check for stale locks first

sudo lsof /var/lib/dpkg/lock-frontend
sudo lsof /var/lib/dpkg/lock

If no output appears, no process holds the lock and the lock files are stale. Remove them:

sudo rm /var/lib/dpkg/lock-frontend
sudo rm /var/lib/dpkg/lock
sudo rm /var/cache/apt/archives/lock

Rebuild the database from installed packages

sudo dpkg --clear-avail
sudo dpkg --update-avail /dev/null
sudo apt-cache gencaches

For severe database corruption, dpkg provides a built-in repair tool:

sudo dpkg --audit

This lists every package in an inconsistent state. Use the output as a checklist — either reinstall or purge each listed package, then rerun dpkg --configure -a.

Step 7: Clean and Rebuild the apt Cache

Corrupted or mismatched cached package files can cause download and hash-mismatch errors that look like broken packages but aren't a dpkg database problem.

sudo apt clean
sudo apt autoclean
sudo apt update

apt clean removes all cached .deb files. autoclean only removes those no longer downloadable. After updating, try the original failing operation again.

Verification

After any combination of the above steps, run a full consistency check:

sudo dpkg --audit
sudo apt --fix-broken install
sudo apt upgrade

dpkg --audit should produce no output. apt --fix-broken install should say 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded (exact numbers vary). A clean apt upgrade confirms the system is healthy.

Troubleshooting

"dpkg: error: dpkg frontend lock is locked by another process"

Another apt, dpkg, unattended-upgrades, or package manager UI (GNOME Software, Synaptic) is running. Check with ps aux | grep -E 'apt|dpkg' and wait for it to finish, or kill it if it's genuinely stuck. Only remove lock files after confirming no real process holds them.

Dependency loop involving a PPA or third-party package

Third-party packages frequently lag behind Ubuntu/Debian releases. If a PPA package is causing the broken state, disable the PPA, reinstall the system version, then re-enable:

sudo add-apt-repository --remove ppa:someowner/somerepo
sudo apt --fix-broken install
sudo apt install packagename   # installs from official repos

"Sub-process /usr/bin/dpkg returned an error code (1)"

This generic error means a maintainer script (preinst, postinst, prerm, or postrm) crashed. The full output above this line names the package. Look for the script in /var/lib/dpkg/info/packagename.postinst and check /var/log/dpkg.log for context. Reinstalling the package (apt reinstall packagename) replaces the scripts and usually clears this.

Disk full during install

A full /var or / partition is a common root cause. Free space first (df -h), then rerun dpkg --configure -a.