A routine Proxmox VE update should not begin with the Upgrade button. First identify the kind of change, confirm that the node can be recovered, and decide what must stop or move. Those checks take longer than refreshing the package list, but they prevent a normal maintenance task from turning into an improvised repair.
This checklist covers package updates within an installed Proxmox VE major version. It deliberately does not compress a major-version migration into a few commands. Proxmox publishes a separate upgrade guide when the Debian base, repositories, and compatibility requirements change.
Classify the update before changing anything
Open the node’s Summary page and record the installed Proxmox VE version. From a shell, pveversion -v provides a package-level inventory that can be saved with the maintenance notes. Then read the available package list and change information under Node > Updates.
There are two different jobs to recognize:
- Routine package update: the configured repositories remain on the same Debian and Proxmox VE release family.
- Major-version upgrade: the target changes the Proxmox VE major version, Debian release, repository suite, or a related platform such as Ceph.
Stop if the task is a major-version upgrade. Follow the current version-specific Proxmox guide from beginning to end, including its readiness checker and known-issue sections. For example, Proxmox maintains a dedicated Proxmox VE 8 to 9 upgrade guide. Commands copied from a point-update article are not a substitute.
As of August 13, 2026, Proxmox lists Proxmox VE 9.2 as the current installer release. An ISO version is not a reason to reinstall a working node, and it does not show whether newer packages are available to an installed system. The configured repositories determine the package update path.
Capture a useful pre-update record
A short baseline makes a failed check easier to interpret. Save the node name, installed version, running kernel, active guests, storage status, and any current task errors. On a cluster, also confirm that every expected member is online and that the cluster is healthy before taking one node out of service.
| Check | Record | Stop condition |
|---|---|---|
| Package state | pveversion -v and available update list |
Broken dependencies or an unexpected release family |
| Storage | Configured targets, active state, and free capacity | Full, missing, degraded, or read-only storage |
| Guests and tasks | Running VM and container IDs plus active jobs | Backup, restore, migration, or replication still writing |
| Access | Web interface, SSH, and independent console path | No way to reach the host if networking fails after reboot |
Resolve storage trouble before installing packages. The Proxmox storage-full checklist separates root filesystems, LVM-thin pools, ZFS, network shares, and backup targets. An update needs working room for downloaded packages, unpacking, logs, and a possible new kernel.
Review Node > Updates > Repositories as well. The current Proxmox administration guide documents the enterprise repository for subscription users and the no-subscription repository as the alternative when a valid enterprise subscription is not present. Do not mix suites, enable a test repository casually, or replace repository definitions merely to silence an error.
Prepare recovery that matches the node
Confirm that important VMs and containers have a recent successful backup on the intended destination. Check the job result, timestamp, included guests, and destination capacity. A green task entry shows that a job completed; it does not prove that every application has been restored successfully. Keep encryption keys and recovery credentials separate from the system they unlock.
If the backup destination is still undecided, compare the failure separation and restore workflow in the NAS, USB drive, and Proxmox Backup Server guide. A second copy on the same host does not protect against a failed boot disk or an unavailable node.
Guest backups also do not capture every host-specific detail. Record customized network files, storage definitions, passthrough settings, repository configuration, certificates, and any other deliberate host changes. The exact recovery set depends on the installation. Never assume that an old shell history can reconstruct it.
Finally, arrange access that survives a management-network problem. Physical keyboard and display access is enough for a nearby home-lab node. A remote system may need a tested IPMI, KVM, or other host-independent console. Do not schedule a remote reboot if the only recovery path depends on the network configuration being updated.
Give the node a quiet maintenance window
Finish or pause jobs that can conflict with maintenance. Move or shut down workloads according to their availability needs. A standalone node may require guest downtime. A cluster may allow guests to migrate elsewhere, but only when the destination has the required storage, networking, capacity, and compatible configuration.
Update one cluster node at a time. Confirm that the remaining cluster can carry its guests and preserve quorum before beginning. Do not treat simultaneous updates as a time-saving default. They remove the known-good peer that can help distinguish a node problem from a broader service problem.
Write down the start condition and an abort rule. Examples include an unexpected repository change, a package removal that was not anticipated, an unresolved configuration-file prompt, or a storage error. Stopping to read the exact message is safer than repeatedly accepting defaults.
Install the packages and keep the output
Proxmox supports updates through the web interface or APT. In the interface, select the node, open Updates, refresh the package list, review it, and start the upgrade from that node. Keep the task output until verification is complete.
For a routine command-line update on the current release family, the documented sequence is:
apt update
apt full-upgradeThe administration guide also presents the equivalent apt-get update and apt-get dist-upgrade form. Use one documented path. Read the proposed changes before confirming, remain available for configuration prompts, and do not disconnect the session intentionally while packages are being configured.
If APT stops with an error, preserve the output. Record the package name, repository URL, and first meaningful failure. Do not reboot merely to see whether the problem clears, and do not copy a force or removal command from an unrelated forum thread. A partially configured bootloader, kernel, storage package, or network component needs diagnosis before the next state change.
Reboot deliberately, then verify service
Some updates take effect without a reboot. A new kernel, firmware-related package, or an explicit updater notice may require one. Finish the package operation first, confirm that the node is ready to restart, and use a normal reboot. Do not power-cycle a node while package management is active.
After boot, verify the host before returning workloads:
- Confirm that the node reaches the web interface and expected management address.
- Check the running kernel with
uname -rand recordpveversion -vagain. - Verify cluster membership, storage availability, network bridges, and any hardware passthrough the node requires.
- Review the task log and system warnings for failures from the update or boot.
- Start or migrate back a limited workload, then confirm its network and storage access before restoring the rest.
- Refresh the update list and investigate any packages still pending unexpectedly.
Keep the pre-update record with the result. If the node fails a check, stop adding workloads and use the independent console, saved configuration, and backups prepared earlier. Package downgrades and kernel cleanup are recovery decisions, not routine final steps.
A completed update is a verified operating state: the expected packages are installed, the intended kernel is running, storage and networking are available, and representative guests work. The Upgrade button only starts that process.
Sources and research date
- Proxmox VE Administration Guide
- Proxmox VE System Administration guide
- Proxmox VE 8 to 9 upgrade guide
- Proxmox VE ISO downloads
Primary sources were reviewed August 13, 2026. This article is a documentation-based maintenance checklist. It does not claim LabGremlin updates, backups, restores, migrations, or compatibility testing on any Proxmox VE system.