dpkg: error: subprocess installed post-installation script returned error exit status 1 – recovering from a failed upgrade

Answer first

Lowest risk recovery method. If a verified pre-upgrade Btrfs/LVM/ZFS snapshot of the root filesystem exists and loss of changes made after the snapshot is acceptable, snapshot rollback poses the lowest risk of database corruption. It restores /var/lib/dpkg atomically without manual edits.

If no verified snapshot exists, the lower risk path is to clear the stale frontend lock safely and finish configuration with dpkg, without manual edits to the status file. Completing configuration is lower risk than manual status edits when the failure is isolated to a postinst exit status 1.

Backup precautions for /var/lib/dpkg/status. Stop all package tools first, then copy the dpkg database tree with permissions and timestamps preserved to a location outside the root filesystem. Record the installed set before any change.

cp -a /var/lib/dpkg/status /var/lib/dpkg/status-old /var/lib/dpkg/available /backup/dpkg/
cp -a /var/lib/dpkg/info /backup/dpkg/info
dpkg --get-selections > /backup/dpkg/selections-$(date -Iseconds).txt

Restore only with dpkg stopped and test in a chroot before applying to production. Do not edit status manually unless validated; syntax errors render dpkg unusable.

Non-invasive consistency verification. Use read-only queries that do not trigger maintainer scripts.

dpkg --audit
dpkg -C
dpkg-query -W -f='${Package}\n' | wc -l

Compare package count and critical package names against the pre-recovery manifest. Confirm lock files are absent and no dpkg/apt processes remain.

Confirmed facts vs likely explanation

Confirmed. A postinst exit status 1 leaves the package in half-configured or unpacked state recorded in /var/lib/dpkg/status. The dpkg frontend lock remains because the frontend process was interrupted, not because the database is corrupt. Safe recovery requires confirming no dpkg/apt processes are running before touching locks.

Likely explanation. The lock cannot be released automatically because the frontend process that created /var/lib/dpkg/lock-frontend terminated abnormally. The database itself is often intact; the error is a state problem, not corruption.

Safe steps for this case

1. Verify no package manager processes are running. Do not remove lock files until this is confirmed.
2. Make the backup described above before any intervention.
3. If a verified pre-upgrade snapshot exists and post-snapshot changes can be discarded, rollback the snapshot. Reconcile /etc and user data changes afterwards.
4. If no snapshot is usable, clear stale locks only after process check, then run dpkg --configure -a and resolve reported dependency issues with the package manager, avoiding manual status edits.
5. Run dpkg --audit and dpkg -C and compare dpkg-query output to the backup manifest.

One missing diagnostic detail that changes the recommendation: is there a verified pre-upgrade snapshot that includes /var/lib/dpkg and /etc, and is loss of all changes since that snapshot acceptable for this system? The answer determines whether snapshot rollback is viable versus completing configuration.