How to fix dpkg: unrecoverable fatal error, aborting in APT

First read the full error: dpkg usually names the exact file or package it choked on (for example a truncated status file, a specific info/<package>.* file, or an entry in updates/). Note it down — later steps target it.

Before touching anything, make sure no package operation is actually in progress. Removing files or locks while apt or dpkg is mid-transaction can corrupt the database further.

# Show any running apt/dpkg processes
ps aux | grep -E 'apt|dpkg' | grep -v grep

If you see an active apt, apt-get, dpkg, or unattended-upgrade process, let it finish or wait for it to exit. Do not kill it unless it is clearly hung.

The safest first repair is to ask dpkg to complete any transaction that was cut short. This is non-destructive and resolves the majority of cases caused by an interrupted install.

sudo dpkg --configure -a

Then repair any broken dependency state:

sudo apt-get install -f

If both commands complete without the fatal error, run sudo apt update to confirm the system is healthy again.

dpkg stages in-progress changes in /var/lib/dpkg/updates/. A corrupt file here is a frequent cause of this exact error and is safe to clear — dpkg rebuilds it from status.

Inspect the directory first:

ls -la /var/lib/dpkg/updates/

If the error referenced a file in this directory, move the contents aside (do not delete blindly) and reconfigure:

sudo mkdir -p /var/lib/dpkg/updates.bak
sudo mv /var/lib/dpkg/updates/* /var/lib/dpkg/updates.bak/ 2>/dev/null
sudo dpkg --configure -a

If this resolves things, you can remove the backup directory later.

If the error points at a corrupt or truncated status file, dpkg keeps a recent backup at /var/lib/dpkg/status-old. Restoring it rolls back to the last known-good state.

Check what is available and confirm the backup is non-empty:

ls -la /var/lib/dpkg/status*

If status-old exists and has a sensible size, preserve the bad file first, then restore:

sudo cp /var/lib/dpkg/status /var/lib/dpkg/status.bad
sudo cp /var/lib/dpkg/status-old /var/lib/dpkg/status
sudo dpkg --configure -a

Keeping status.bad lets you recover if the backup turns out to be older than expected. After this, run sudo apt update to verify.

If the error names one specific package (for example wireless-regdb), its info files under /var/lib/dpkg/info/ may be damaged. Move that package's info files aside rather than deleting them outright, so you can restore if needed.

# Replace PACKAGE with the name from the error
sudo mkdir -p /root/dpkg-info-bak
sudo mv /var/lib/dpkg/info/PACKAGE.* /root/dpkg-info-bak/ 2>/dev/null
sudo dpkg --configure -a

Then reinstall the package cleanly so its metadata is regenerated:

sudo apt-get install --reinstall PACKAGE

Use dpkg --remove --force-remove-reinstreq only as a last resort if reinstall is impossible, since it discards the package's recorded state. Prefer --reinstall first.

Database corruption is often a symptom of a full or failing disk. Rule these out, especially on SD-card systems.

# Is the root filesystem full?
df -h /

# Look for I/O errors or bad-sector warnings
sudo dmesg | grep -iE 'error|i/o|sector' | tail -20
sudo journalctl -p err -b --no-pager | tail -30

If the root filesystem is near capacity, free space and retry:

sudo apt-get clean
sudo apt-get autoclean

If you see persistent I/O errors or bad sectors, the storage device is failing. Back up your data and plan to replace the disk or SD card — software repairs will not hold on bad media.

This is unrelated to the corruption error and should only be done if you have confirmed (Step 1) that no apt or dpkg process is active and you separately see a lock-related message. Removing locks while a real transaction is running can corrupt the database further, which is the opposite of what you want here.

# Re-verify nothing is running first
ps aux | grep -E 'apt|dpkg' | grep -v grep

# Only if the output above is empty:
sudo rm -f /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock /var/cache/apt/archives/lock
sudo dpkg --configure -a