Proxmox System Update

The official Proxmox recommendation

Proxmox's own upgrade guidance for a running host (within the same major version) is to run:

apt update && apt full-upgrade -y

That one line is the official command on any current Proxmox release. The hard part isn't the upgrade itself; it's making sure the repositories are clean, the right ones are enabled, and the host is in a sensible state afterwards.

What ProxMenux runs on top — verified against the script

This option runs exactly the apt command above, wrapped with the repo hygiene and post-upgrade cleanup the official upgrade guide also recommends. The list below maps 1:1 to scripts/utilities/proxmox_update.sh and the per-version worker scripts — nothing implied, every step is in the code:

• Detects the PVE major version (pveversion | grep -oP 'pve-manager/\K[0-9]+') and dispatches to update-pve8.sh or update-pve9_2.sh so the right codename and repo URLs are used.
• Cleans up repositories before touching apt: disables the enterprise source (which 401s without a subscription), removes legacy repo files, and writes a clean no-subscription source for the host's codename.
• Runs the upgrade non-interactively with DEBIAN_FRONTEND=noninteractive and --force-confdef --force-confold — meaning if a configuration file you already modified also changed upstream, your version stays in place. No silent overwrites of custom configs.
• Installs essential Proxmox packages if any are missing (zfsutils-linux, proxmox-backup-restore-image, chrony).
• LVM metadata sanity check against stray PV headers from passthrough disks (warn-only, no automatic fix).
• Cleans up afterwards: apt-get autoremove -y + apt-get autoclean -y.
• Reboot prompt only if the kernel actually changed (/var/run/reboot-required present or linux-image in the upgrade log).

Confirmation dialog

Selecting the option opens a summary of what the worker will do, requiring an explicit confirmation:

How the wrapper routes

What the worker does

Both workers (scripts/global/update-pve8.sh for PVE 8 and scripts/global/update-pve9_2.sh for PVE 9) follow the same outline, with version-appropriate repo URLs and package names:

1. Repo hygiene. Removes duplicate entries from /etc/apt/sources.list and /etc/apt/sources.list.d/. Comments out the enterprise repo if the host has no subscription and writes / enables the no-subscription source.
2. Apt update + full-upgrade. Pulls the latest package lists and applies all available upgrades for the current major version, running with DEBIAN_FRONTEND=noninteractive and --force-confdef --force-confold so any configuration file you customised keeps its current contents when upstream also changed it.
3. Essential packages check. Installs zfsutils-linux, chrony, ifupdown2 and a few others if the host is missing them.
4. LVM / storage sanity check. Repairs missing PV headers if detected.
5. Conflicting package removal. Drops packages known to clash on Proxmox (e.g. some time-sync daemons that fight chrony).

Post-update cleanup & reboot

After the worker exits, the wrapper runs:

apt-get autoremove -y    # drop unused dependencies pulled in by old packages
apt-get autoclean        # drop downloaded .deb files no longer in the index

Then it checks whether a reboot is needed. Two signals trigger the prompt:

• /var/run/reboot-required exists (created by the kernel package post-install hook)
• The update log contains linux-image entries (kernel was actually upgraded)

If either is true, a whiptail dialog asks "Some changes require a reboot to take effect. Do you want to restart now?". Decline to keep running on the old kernel until you choose to reboot manually (e.g. during a planned maintenance window).

What you see at the end

When the worker finishes, the terminal shows the cleanup output and (if the kernel changed) the reboot prompt:

When the no-subscription switch happens

Proxmox ships hosts with the enterprise repo enabled by default. Without a paid subscription, that repo returns 401 on apt-get update. The worker detects this and:

1. Comments out (or disables) /etc/apt/sources.list.d/pve-enterprise.list (or the deb822 equivalent)
2. Writes /etc/apt/sources.list.d/pve-no-subscription.list (or the deb822 proxmox.sources for PVE 9) with the matching codename (bookworm for PVE 8, trixie for PVE 9)
3. Re-runs apt-get update

If you have a paid subscription, comment out the no-subscription source and uncomment the enterprise one before running this option.

Cluster considerations

What it doesn't do

• Major-version upgrade. 8 → 9 is a separate operation — see Upgrade PVE 8 to PVE 9.
• Backup. No snapshots, no rollback. Apt operations are not transactional. Combine with your normal backup discipline (PBS, vzdump, ZFS snapshots).
• Container / VM updates. Only the host is upgraded; guests are left alone.
• Firmware updates. CPU microcode, NIC firmware, BIOS — out of scope.

Troubleshooting

Files involved

scripts/utilities/proxmox_update.sh           # this script (wrapper)
scripts/global/update-pve8.sh                 # worker for PVE 8 hosts
scripts/global/update-pve9_2.sh               # worker for PVE 9 hosts
scripts/global/common-functions.sh            # cleanup_duplicate_repos used by workers
/etc/apt/sources.list                         # may be edited
/etc/apt/sources.list.d/*                     # may be edited / created
/var/run/reboot-required                      # read to decide on reboot prompt
/var/log/apt/history.log                      # read to detect kernel changes

Related

• Upgrade PVE 8 to PVE 9 — for the major-version upgrade (different tool, different safety model).
• System Utilities Installer — to install the CLI tools you want around updates (htop / btop / ncdu).
• Utilities overview — back to the section overview.