Proxmox “dpkg was interrupted”: Fix Broken Packages Without Reinstalling

What “dpkg was interrupted” actually means

Proxmox runs on Debian. Debian uses dpkg to perform the low-level unpack/configure steps.
apt is the higher-level resolver/downloader that orchestrates dpkg.
When dpkg is interrupted—power loss, killed process, disk full, broken pre/postinst script,
or conflicting packages—it leaves a half-written state in /var/lib/dpkg/.

The infamous message is usually the package manager telling you:
“I can’t move forward until the pending configuration steps finish.”
That’s not a suggestion. It’s the transaction log asking you to replay the incomplete part.

There are two broad categories of “broken package” issues on Proxmox:

• Pure dpkg/apt state issues: lock files, interrupted configuration, missing dependencies,
  partial unpack. These are fixable on-host with careful commands.
• Repository/mismatch issues: mixing Debian releases, mixing Proxmox repos,
  or pinning gone wrong. These can look like dpkg errors but the fix is actually “stop feeding apt garbage.”

Your goal is not to “make apt stop complaining.” Your goal is to reestablish a clean, consistent package
database so future upgrades don’t become Russian roulette with your kernel, ZFS modules, or management UI.

One quote to keep you honest: “Hope is not a strategy.” — General Gordon R. Sullivan.
(Not a software engineer, but every on-call rotation agrees with him.)

Fast diagnosis playbook (first/second/third)

First: is dpkg actually running or just wedged?

If a legitimate package operation is still in progress, don’t “fix” it by killing it. Let it finish.
If it’s stuck, figure out why it’s stuck before you start deleting lock files like a medieval barber.

Second: is the filesystem healthy and writable?

“dpkg interrupted” frequently means “disk full” or “root filesystem went read-only.”
On a Proxmox host, that can be from log growth, a full local-lvm, a broken mirror, or an SSD having a day.

Third: is apt being fed sane repositories?

A node configured with the wrong Debian codename or mixed Proxmox repos can fail mid-upgrade and leave
dpkg half-configured. Fixing dpkg without fixing repos just replays the failure, but louder.

Then: repair dpkg state, repair dependencies, verify Proxmox services

Only after you know dpkg isn’t actively running and the system can write to disk do you run the repair steps.
The order matters: configure pending packages, repair dependencies, then finish the upgrade.

Interesting facts and short history (why this keeps happening)

1. dpkg predates apt. dpkg dates back to early Debian; apt was introduced later to handle
   dependency resolution and remote repositories more gracefully.
2. dpkg is intentionally “dumb.” It does not solve dependencies; it executes package scripts
   and records state. That simplicity is why it’s predictable—and why it can’t “guess” how to recover.
3. Debian package scripts are code, not metadata. Preinst/postinst scripts can do almost anything:
   update initramfs, restart services, rewrite configs. That’s power and peril.
4. Proxmox is a Debian distribution with opinionated packages. Proxmox layers its own kernel,
   management stack, and repo policies on top of Debian, which is why repo mixing hurts more here.
5. Locking is cooperative. The lock files in /var/lib/dpkg/ and
   /var/lib/apt/lists/lock are not magic; they’re convention. Deleting them while a process is active
   invites corruption.
6. Interrupted upgrades used to be more common on spinning disks. Slow I/O plus aggressive timeouts
   plus humans rebooting because “it looks stuck” created a lot of half-configured systems.
7. dpkg records fine-grained states. Packages can be “unpacked but not configured,” “half-configured,”
   “triggers pending,” etc. The exact state often tells you what kind of failure you’re dealing with.
8. Triggers exist to batch work. Things like update-initramfs or
   update-ca-certificates can be deferred via triggers—until an interruption leaves them pending.

Safety first on a Proxmox host (don’t brick the node)

On a laptop, you can brute-force your way through package repairs. On a Proxmox host running VMs/CTs,
you need a little discipline:

• Do not reboot “to clear it.” A reboot doesn’t fix dpkg state. It just adds a new variable,
  like services failing to start because their packages never finished configuring.
• Don’t restart pve services mid-upgrade unless you must. When management packages are in flux,
  bouncing pveproxy can cut your own access. Use SSH and keep one root shell open.
• Avoid remote-only heroics. If this is a datacenter node with no out-of-band access,
  schedule a window or ensure IPMI/iKVM works. “It’s just packages” is how you end up driving at midnight.
• Snapshot the root disk if you can. If the Proxmox OS is on ZFS root, take a snapshot.
  If it’s on LVM-thin and you have a hypervisor-level snapshot mechanism, use it. Rollback beats regret.

Joke #1: Deleting dpkg lock files blindly is like cutting the red wire because it “looks more confident.”
Sometimes it works. That’s not a compliment.

Practical repair tasks (commands, outputs, decisions)

Below are the tasks I actually run in production when a Proxmox node hits “dpkg was interrupted.”
Each task includes: a command, typical output, what it means, and the decision you make.
Do them in order unless you have a reason not to.

Task 1: Confirm apt/dpkg processes and whether they’re stuck

cr0x@server:~$ ps aux | egrep 'apt|dpkg' | egrep -v egrep
root      1523  0.0  0.1  21440  9820 ?        Ss   10:11   0:00 /usr/bin/dpkg --configure -a
root      1544  0.2  0.1  72868 11640 ?        S    10:11   0:03 /usr/bin/perl /usr/share/debconf/frontend /var/lib/dpkg/info/pve-manager.postinst configure

What it means: dpkg is running and actively configuring packages (here it’s in a postinst).

Decision: Wait. Check CPU/disk. If it’s truly hung (no I/O, no progress for a long time),
inspect logs and the script it’s running before killing anything.

Task 2: Check dpkg lock files without deleting them

cr0x@server:~$ sudo lsof /var/lib/dpkg/lock-frontend /var/lib/dpkg/lock
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
dpkg    1523 root    3uW  REG  252,0        0  811 /var/lib/dpkg/lock-frontend

What it means: The lock is held by dpkg PID 1523.

Decision: Do not remove locks. If a lock exists but no process holds it, that’s different.

Task 3: Verify root filesystem space (disk full is a classic)

cr0x@server:~$ df -hT /
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4   60G   59G  320M 100% /

What it means: You’re out of space. dpkg can’t unpack/configure reliably.

Decision: Free space first. Do not run repair commands until you have breathing room.

Task 4: Check if the filesystem went read-only

cr0x@server:~$ mount | grep ' on / '
/dev/sda2 on / type ext4 (ro,relatime,errors=remount-ro)

What it means: Root is mounted read-only. dpkg will fail repeatedly.

Decision: Stop. Inspect dmesg, storage health, and remount only if safe.
A read-only remount usually indicates filesystem errors or device issues.

Task 5: Read the last dpkg/apt log entries (find the real failure)

cr0x@server:~$ tail -n 40 /var/log/dpkg.log
2025-12-26 10:10:59 unpacked pve-manager:amd64 8.2.4
2025-12-26 10:11:01 configuring pve-manager:amd64 8.2.4
2025-12-26 10:11:04 status half-configured pve-manager:amd64 8.2.4
2025-12-26 10:11:04 error processing package pve-manager:amd64 (--configure):
 installed pve-manager package post-installation script subprocess returned error exit status 1

What it means: The failure is inside the package script (postinst), not dependency resolution.

Decision: You’ll likely need to read the postinst output (see next tasks) and fix the underlying cause.

Task 6: Run dpkg configuration replay (the canonical first fix)

cr0x@server:~$ sudo dpkg --configure -a
Setting up pve-manager (8.2.4) ...
Job for pveproxy.service failed because the control process exited with error code.
See "systemctl status pveproxy.service" and "journalctl -xeu pveproxy.service" for details.
dpkg: error processing package pve-manager (--configure):
 installed pve-manager package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 pve-manager

What it means: dpkg did its job; the package failed due to a service start/restart problem.

Decision: Don’t keep rerunning dpkg hoping it changes its mind. Debug the service failure.

Task 7: Inspect the failing service (pveproxy is the usual suspect)

cr0x@server:~$ systemctl status pveproxy.service --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Fri 2025-12-26 10:11:03 UTC; 12s ago
    Process: 1622 ExecStart=/usr/bin/pveproxy start (code=exited, status=255/EXCEPTION)
   Main PID: 1622 (code=exited, status=255/EXCEPTION)
     Status: "starting server"
     Error: unable to load certificate '/etc/pve/local/pve-ssl.pem': No such file or directory

What it means: dpkg is failing because pveproxy can’t start due to missing certs.
This is common after cluster filesystem issues, permissions problems, or incomplete pve-cluster state.

Decision: Fix the underlying Proxmox config (cert regeneration, /etc/pve health), then rerun dpkg.

Task 8: Check /etc/pve availability and cluster filesystem health

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   57
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             2025-12-26 10:12:01
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.1a
Quorate:          Yes

What it means: Cluster is quorate, which strongly suggests /etc/pve should be mounted and writable.

Decision: If not quorate, you may need to restore quorum or work in local mode carefully.
Non-quorate cluster nodes often have weird side effects during package scripts.

Task 9: Regenerate Proxmox certificates if that’s the blocker

cr0x@server:~$ sudo pvecm updatecerts --force
Generating new node certificate...
Restarting pveproxy and pvedaemon...
Done.

What it means: Node certs were regenerated and services restarted.

Decision: Retry dpkg --configure -a. If cert regeneration fails, inspect permissions and /etc/pve mount.

Task 10: Repair dependency problems automatically (when dpkg is not enough)

cr0x@server:~$ sudo apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Correcting dependencies... Done
The following packages will be upgraded:
  pve-manager pveproxy pvedaemon
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/2,914 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up pveproxy (8.2.3) ...
Setting up pvedaemon (8.2.3) ...
Setting up pve-manager (8.2.4) ...

What it means: apt found a consistent dependency plan and applied it. This often resolves partial upgrades.

Decision: If apt proposes removals of core Proxmox packages (e.g., pve-manager), stop and investigate repos/pinning.

Task 11: Identify “half-installed” packages and their states

cr0x@server:~$ dpkg -l | awk '$1 ~ /^(iF|iU|iH|iW|rc)$/ {print}'
iF  pve-manager   8.2.4   amd64   Proxmox Virtual Environment manager
iU  pve-kernel-6.8 6.8.12-4 amd64 Proxmox kernel image

What it means: These packages are not cleanly installed/configured.

Decision: Focus your debugging on these packages. A kernel image stuck in iU can break future boot logic or DKMS module builds.

Task 12: Check for held packages that prevent apt from resolving

cr0x@server:~$ apt-mark showhold
pve-kernel-6.8
zfs-dkms

What it means: Someone pinned packages in place. Sometimes that’s intentional; often it’s forgotten.

Decision: If holds block security/kernel updates, remove them deliberately and schedule reboot/testing.

Task 13: Remove holds (only after you understand why they existed)

cr0x@server:~$ sudo apt-mark unhold pve-kernel-6.8 zfs-dkms
Canceled hold on pve-kernel-6.8.
Canceled hold on zfs-dkms.

What it means: Packages can now move to versions apt considers consistent.

Decision: Immediately follow with apt-get -f install or apt full-upgrade to converge.

Task 14: Confirm repository configuration is sane (Proxmox-specific)

cr0x@server:~$ grep -R --line-number -E 'pve|proxmox|deb ' /etc/apt/sources.list /etc/apt/sources.list.d/*.list
/etc/apt/sources.list:1:deb http://deb.debian.org/debian bookworm main contrib
/etc/apt/sources.list:2:deb http://deb.debian.org/debian bookworm-updates main contrib
/etc/apt/sources.list:3:deb http://security.debian.org/debian-security bookworm-security main contrib
/etc/apt/sources.list.d/pve-no-subscription.list:1:deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

What it means: Debian release is Bookworm and Proxmox repo matches Bookworm. That’s good.

Decision: If you see mixed codenames (bullseye + bookworm) or both enterprise and no-subscription without intent, fix that first.

Task 15: Refresh package lists and spot immediate repo errors

cr0x@server:~$ sudo apt update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Hit:3 http://download.proxmox.com/debian/pve bookworm InRelease
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.

What it means: Repos are reachable and metadata is consistent.

Decision: If you see 401/403 or signature errors, do not proceed with upgrades until repo trust/access is fixed.

Task 16: Finish the repair with a controlled upgrade

cr0x@server:~$ sudo apt full-upgrade
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following packages will be upgraded:
  pve-kernel-6.8 pve-manager pveproxy pvedaemon
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 58.4 MB of archives.
After this operation, 312 MB of additional disk space will be used.
Do you want to continue? [Y/n] y

What it means: apt has a coherent plan. It’s upgrading core components; that’s normal on Proxmox.

Decision: Proceed during a maintenance window if kernel updates are involved. Plan the reboot.

Task 17: Verify the package database is clean

cr0x@server:~$ sudo dpkg --audit

What it means: No output is good: dpkg sees no broken/half-installed packages.

Decision: If it lists packages, you still have unfinished business—return to logs and failing scripts.

Task 18: Confirm Proxmox management services are healthy

cr0x@server:~$ systemctl is-active pveproxy pvedaemon pvestatd
active
active
active

What it means: The management plane is up.

Decision: If one is not active, check journalctl -u before you declare victory.

Task 19: Clean up old locks only if they’re stale (rare, but real)

cr0x@server:~$ sudo lsof /var/lib/dpkg/lock-frontend
cr0x@server:~$ sudo ls -l /var/lib/dpkg/lock-frontend
-rw-r----- 1 root root 0 Dec 26 10:05 /var/lib/dpkg/lock-frontend

What it means: No process holds the lock, but the file exists (that’s normal). Locks are files, not sockets.

Decision: Do not delete it just because it exists. Only act if apt explicitly complains about a lock and
you’ve verified no process holds it.

Task 20: When a package script is broken, rerun it with debug output

cr0x@server:~$ sudo sh -x /var/lib/dpkg/info/pve-manager.postinst configure
+ set -e
+ systemctl daemon-reload
+ systemctl try-restart pveproxy.service
Job for pveproxy.service failed because the control process exited with error code.
+ exit 1

What it means: The postinst is failing exactly at service restart.

Decision: Fix the service dependency (certs, ports, config, disk space) rather than hacking dpkg state.
If you must keep the node running, you can sometimes temporarily prevent restarts—but that’s a last resort and should be documented.

Joke #2: dpkg isn’t “broken,” it’s just holding you to the same standard your change manager pretends to have.

Three corporate mini-stories from the trenches

Incident caused by a wrong assumption: “It’s just a GUI package”

A mid-sized company ran a three-node Proxmox cluster hosting internal services: a Git server, monitoring, CI runners,
and a few Windows VMs nobody admitted owning. One afternoon, an admin saw updates pending and ran apt upgrade
on a node during business hours. The update stalled, then the node started returning “dpkg was interrupted.”

The wrong assumption was simple: they thought pve-manager was “just the web UI.” It isn’t. The package hooks
restart services, touches certificates, and depends on the cluster filesystem being healthy. During the upgrade, the node
briefly lost quorum due to a separate network change. The postinst tried to access /etc/pve, got partial state,
and failed. dpkg stopped mid-configuration.

Their first reaction was to reboot. The node came up, but the proxy didn’t. Now they couldn’t use the web UI to migrate workloads.
SSH still worked, but the team wasted time searching for “where Proxmox stores the GUI binary” like it was a desktop app.

The fix wasn’t dramatic. They restored cluster connectivity, confirmed quorum, regenerated node certs, reran
dpkg --configure -a, then finished the upgrade. The bigger lesson: on Proxmox, management packages
are operational packages. Treat them like you would treat a hypervisor kernel update.

Optimization that backfired: “Let’s auto-update everything nightly”

Another environment had a “modernization” initiative: fewer manual steps, more automation. They rolled out unattended upgrades
on Proxmox nodes. The idea was decent—security updates without humans forgetting. The implementation was not.

They didn’t align it with maintenance windows or storage reality. Some nodes had small root partitions and heavy log churn.
One night, unattended upgrades tried to pull a kernel update and new firmware packages while the root filesystem was nearly full.
dpkg unpacked halfway, then ran out of space. The node kept running VMs, but the next apt run showed “dpkg was interrupted.”

The truly fun part: their automation retried every hour. Every hour it hit the same failure, leaving the package database in a
perpetual “almost configured” state. Monitoring alarms were noisy but vague: “updates failing.” The team started ignoring them.

They fixed it by turning off unattended upgrades on hypervisors, adding explicit disk space checks,
and running updates during planned windows with post-checks: dpkg audit, service health, and a reboot queue for kernel changes.
Automation is great. Automating chaos is still chaos—just faster.

Boring but correct practice that saved the day: out-of-band access and snapshots

A third shop had a strict rule: any change to hypervisor packages required (1) out-of-band console tested,
(2) recent config backup, and (3) a rollback story. It sounded bureaucratic until a node died in the most boring way possible:
a firmware hiccup triggered a filesystem remount read-only during a package upgrade.

dpkg stopped mid-transaction. The node still hosted critical workloads, and the web UI became flaky because services couldn’t
update files in /var. But because they had iKVM and a ZFS root snapshot taken right before maintenance,
they could make a calm decision: attempt repair first, and if the filesystem required offline fsck, roll back and evacuate.

They checked disk health, confirmed the root pool had errors, and decided not to force writes. They migrated VMs off the node,
rebooted into a rescue environment, repaired the filesystem, then reran dpkg configuration. The snapshot wasn’t even needed,
but it reduced pressure. That’s what “boring” buys you: time to think.

Common mistakes: symptom → root cause → fix

1) Symptom: “Could not get lock /var/lib/dpkg/lock-frontend”

Root cause: Another apt/dpkg process is running (or hung), or a background tool is doing upgrades.

Fix: Use ps and lsof to identify the process. If it’s legitimate, wait.
If it’s a stuck process, inspect why (disk full, NFS hang, broken postinst). Kill only as a last resort,
then run dpkg --configure -a.

2) Symptom: “dpkg was interrupted, you must manually run ‘dpkg –configure -a’”

Root cause: Pending package configuration steps exist; dpkg database indicates incomplete state.

Fix: Run dpkg --configure -a. If it fails, follow the failing script/service,
not your feelings. Read /var/log/dpkg.log and journalctl.

3) Symptom: dpkg configure fails on pve-manager/pveproxy due to missing certs

Root cause: /etc/pve not mounted correctly, quorum issues, or certificates missing/corrupt.

Fix: Check pvecm status. Ensure quorum. Regenerate certs with
pvecm updatecerts --force, then rerun dpkg configuration.

4) Symptom: “No space left on device” during upgrade

Root cause: Root filesystem full; dpkg cannot unpack/configure. Sometimes it’s /boot full from old kernels.

Fix: Free space safely (clean apt cache, prune logs, remove old kernels if you know what you’re doing).
Then rerun dpkg --configure -a and apt-get -f install.

5) Symptom: apt wants to remove Proxmox meta-packages (pve-manager, proxmox-ve)

Root cause: Mixed Debian releases, wrong Proxmox repo, or pinning causing dependency conflicts.

Fix: Stop. Audit /etc/apt/sources.list*. Align codenames.
Remove conflicting repos. Re-run apt update and re-evaluate.

6) Symptom: dpkg loops on triggers (initramfs, ca-certificates) and never finishes

Root cause: The trigger command is failing (often due to missing disk space, broken kernel hook,
or a broken update-initramfs environment).

Fix: Run the trigger tool manually and capture errors. Fix underlying issue,
then rerun dpkg --configure -a.

7) Symptom: Package scripts hang forever

Root cause: Waiting on a service stop that never completes, blocked I/O, DNS hang in a script,
or an interactive prompt in a noninteractive session.

Fix: Check journalctl, confirm I/O health, and ensure noninteractive frontend
if running remotely. If necessary, set DEBIAN_FRONTEND=noninteractive for the repair run.

Checklists / step-by-step plan

Phase 0: Make sure you won’t regret this

• Confirm you have SSH access, and ideally out-of-band console.
• Confirm you can survive a management-plane restart (keep one session open).
• Check free space and filesystem health first.
• If clustered: confirm quorum. Package scripts touching /etc/pve hate ambiguity.

Phase 1: Diagnose the failure mode quickly

1. Check running processes: ps aux | egrep 'apt|dpkg'.
2. Check locks with lsof.
3. Check disk space (df -h) and mount flags (mount).
4. Read /var/log/dpkg.log and recent journal entries for the failing unit.

Phase 2: Repair dpkg state and dependencies

1. Run dpkg --configure -a.
2. If it fails, fix the cause (service config, certs, storage, repos).
3. Run apt-get -f install to correct dependencies.
4. Run apt full-upgrade to converge the system.
5. Verify dpkg --audit returns nothing.

Phase 3: Proxmox-specific sanity checks after repair

1. Check management services: systemctl is-active pveproxy pvedaemon pvestatd.
2. Confirm cluster status (if applicable): pvecm status.
3. Confirm kernel/modules alignment if ZFS is in play: ensure new kernel and zfs packages installed cleanly before reboot.
4. Plan reboot if kernel upgraded; don’t “just do it” during peak load.

FAQ

1) Can I fix “dpkg was interrupted” without rebooting?

Usually yes. dpkg/apt repairs are userland operations. Rebooting doesn’t resolve the dpkg database state.
Only reboot when you’ve installed a new kernel or fixed a filesystem issue that requires it.

2) Is running dpkg --configure -a always safe on Proxmox?

It’s the correct first step, but “safe” depends on why dpkg was interrupted. If disk is full or root is read-only,
it will fail and may worsen things. Verify filesystem health first.

3) apt wants to remove proxmox-ve or pve-manager. Should I allow it?

No, not casually. That’s a sign of repository mismatch or dependency chaos.
Fix repos and pinning first. Removing meta-packages can leave you with a Franken-Debian host
that still runs VMs until it doesn’t.

4) What if dpkg is stuck running a postinst script?

Identify which script with ps, then check its dependencies: service restarts, files under /etc/pve,
DNS, or storage. If it’s truly hung (no I/O, no progress), investigate with logs and a traced rerun of the script.
Killing dpkg is last resort and should be followed by immediate repair steps.

5) Do I need to stop VMs/containers before repairing packages?

Not always. Many repairs can be done live. But if you’re upgrading the kernel, ZFS stack, or core Proxmox services,
schedule a window. The host can keep running workloads, but management access may flicker during restarts.

6) Why does a certificate error break dpkg?

Because package scripts often restart services to activate new versions. If pveproxy can’t start due to missing
SSL files, the postinst exits non-zero. dpkg treats that as “package not configured” and stops the transaction.

7) How do I know the package database is clean again?

Run dpkg --audit (no output is good), check dpkg -l for odd states (iF, iU), and ensure
apt-get -f install has nothing left to correct.

8) When is reinstalling Proxmox actually justified?

If the OS disk is corrupted beyond reasonable repair, if repositories were mixed for a long time and dependency resolution
requires massive removals, or if you can’t trust the node’s baseline. Even then, evacuate workloads first and rebuild cleanly.

9) Does clustering change how I should repair packages?

Yes. Clustered nodes depend on quorum for consistent /etc/pve behavior. If you’re non-quorate,
some management operations and scripts can fail. Restore quorum first if possible.

10) Can I “force” dpkg to ignore failing scripts?

You can, but you shouldn’t unless you’re doing controlled surgery and documenting it.
Forcing installs while ignoring postinst failures can leave services unconfigured and the node subtly broken.
Fix the cause instead.

Conclusion: next steps that actually help

“dpkg was interrupted” is not a reason to reinstall Proxmox. It’s a reason to slow down and repair state like an adult:
verify dpkg isn’t actively running, verify the system can write to disk, verify repositories make sense, then replay the
configuration and fix the specific script or service that failed.

Practical next steps:

1. Run the fast diagnosis: processes → disk/mount health → repos.
2. Repair with dpkg --configure -a, then apt-get -f install, then apt full-upgrade.
3. Confirm dpkg --audit is clean and Proxmox services are active.
4. If a kernel changed, schedule the reboot—don’t “wing it.”
5. After recovery, fix the root cause: disk sizing, repo hygiene, maintenance windows, and out-of-band access.