Table of Contents
Overview
An aborted SSH connection left my do-release-upgrade half-done and the system stuck in a loop of “dpkg was interrupted” errors. By hiding /var/lib/dpkg/info, running apt-get -f install, and restoring the directory, I completed the upgrade without reinstalling the OS. This guide explains each step, what lives inside the info directory, other causes of failed upgrades, and best practices to avoid the problem next time.
Why Ubuntu LTS Upgrades Fail
1. Lost SSH or Console Sessions
Although do-release-upgrade spawns a screen session, a broken network path can still leave packages half-configured if you disconnect before it reaches a safe checkpoint.
2. Low Disk Space
The upgrader needs several gigabytes for .deb files and unpacked trees; if /, /var, or especially /boot is full, dpkg aborts mid-transaction.
3. Third-Party PPAs and Local Builds
Out-of-date PPAs or self-compiled packages can introduce dependency versions that Jammy cannot satisfy, causing the upgrade to roll back.
4. Package Database Corruption
Power loss, kernel panic, or manual termination while dpkg writes status files can corrupt entries under /var/lib/dpkg, leading to the classic configure-a prompt.
5. Stale Lock Files
Residual locks under /var/lib/apt/lists/lock or /var/cache/apt/archives/lock can block any further package operations.
What’s Inside /var/lib/dpkg/info?
Each installed package stores maintainer scripts (preinst, postinst, prerm, postrm), a list of installed files, and hash checksums in this directory. If a script is only partially written, dpkg will stop on every attempt to finish configuration.
Step-by-Step Repair
| Command | Purpose |
|---|---|
sudo mv /var/lib/dpkg/info /var/lib/dpkg/info_silent | Isolates broken scripts so dpkg can’t execute them. |
sudo mkdir /var/lib/dpkg/info | Provides an empty staging directory for new metadata. |
sudo apt-get update | Refreshes the package index against Jammy mirrors. |
sudo apt-get -f install | Forces dependency resolution, unpacks missing packages, and reruns any pending postinst scripts. |
sudo mv /var/lib/dpkg/info/* /var/lib/dpkg/info_silent | Prevents mixing newly generated files with the old set. |
sudo rm -rf /var/lib/dpkg/info | Removes the placeholder. |
sudo mv /var/lib/dpkg/info_silent /var/lib/dpkg/info | Restores a now-consistent metadata directory. |
Why it Works – With maintainer scripts out of the path, dpkg simply records that they ran successfully and continues the upgrade. Afterward, legitimate metadata is merged back, leaving future package operations intact.
Other Quick-Fix Scenarios
| Symptom | Cure |
|---|---|
| Only database interrupted | sudo dpkg --configure -a |
Disk full in /boot | sudo apt-get autoremove --purge old kernels |
| PPA dependency loop | sudo ppa-purge ppa:user/ppa then retry upgrade |
| Bad mirror or partial downloads | Revert sources.list to previous release, apt update, retry upgrade |
Preventing the Problem Next Time
- Run inside
tmuxorscreenbefore you start. - Clean and check free space with
apt cleananddf -h - Disable unsupported PPAs until maintainers publish Jammy packages
- Apply all pending updates first:
apt update && apt full-upgrade - Snapshot the system (VM, ZFS, LVM) for instant rollback.
- Use non-interactive flags if automating:
DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade
Conclusion
A dropped SSH session left my Ubuntu upgrade in limbo, but a simple metadata shuffle brought dpkg back to life. By understanding the role of /var/lib/dpkg/info and letting apt-get -f install finish the heavy lifting, you can usually rescue a stalled LTS hop without reinstalling. Follow the preventive checklist and your next upgrade should complete smoothly.
