October 4, 2026: checking what finished during a Proxmox upgrade disconnect

I patched my three-node Proxmox cluster one node at a time. All three finished on pve-manager 9.2.21 and kernel 7.0.14-20-pve, with quorum maintained and guests back in their intended states. Two SSH connection resets during the session needed more attention than the package totals.

After each reset, I had to establish what had actually happened before deciding what to run next. On one node, the upgrade had not started. On another, the package transaction had already finished. The disconnected terminal looked much the same in both cases.

The first reset came before the upgrade

The connection dropped during a sequence that stopped guests before upgrading the host. I had not yet confirmed whether the guest shutdown loop had finished or the upgrade had begun.

I reconnected and checked package and process state. dpkg --audit was clean. The process search appeared to find package-manager commands, but those matches were the search command’s own arguments, not running upgrade processes. Checking the matches mattered: treating them as real work would have given me the wrong picture of the node.

The checks established that the upgrade had not started. I ran it again, and it completed with 189 packages upgraded, three installed and none removed, matching the earlier simulation. Before rebooting, I checked package consistency, confirmed the new kernel was registered and kept the old kernel available as a fallback.

The next reset left a different state

On another node, a connection reset left me checking the same things: package processes, package consistency, stopped guests and cluster health. There were no running package-manager processes, and the package audit was clean again.

That still did not distinguish an upgrade that never started from one that had completed. The next upgrade invocation reported nothing to do. Direct package and version checks showed that the target manager and kernel packages were already installed. The node was still running its previous kernel because it had not rebooted yet.

The first attempt had completed its package transaction before the reset. There was no unfinished upgrade to repair. After checking package consistency and kernel registration, I could proceed to the reboot.

Recovery meant checking the intended state

I worked through the nodes sequentially, validating recovery before moving on. The cluster retained quorum while a node was down, with the other two providing the required votes. All three nodes were back after recovery.

Guest recovery also needed a little more precision than checking that everything was running. A guest deliberately configured to stay stopped remained stopped. On another node, one guest needed an explicit start; the others started automatically. The final checks confirmed the intended guest states, active core services, clean package audits and working DNS.

The useful lesson from this session is how little a connection reset says about the work behind it. A clean package audit and no active package process were useful checks, but installed versions were needed to tell whether there was still an upgrade to perform. I had to reconnect and read the node’s state before choosing the next step.