Proxmox VE 9 is a Debian version jump, from Debian 12 to Debian 13. That is the whole reason this upgrade needs care. You are not just updating one program, you are replacing the operating system underneath it while your virtual machines sit on top.

The upgrade itself is well trodden and usually uninteresting. What catches people is a short list of things that go wrong after the reboot, when the machine is either back or it is not. Those are the ones worth knowing about first.

Before anything: the five prerequisites

Proxmox’s upgrade instructions set out what has to be true before you start. In practice these are the five that matter.

You must already be on the latest 8.4. Not 8.2, not 8.3. If your pve-manager version is below 8.4.1, your package repositories are probably misconfigured, and the upgrade will not go cleanly from there.

If you run Ceph, upgrade Ceph first. Any Quincy or Reef cluster has to be on Ceph 19.2 Squid before you begin the Proxmox upgrade, not during and not after.

You need a way back in that is not SSH. IPMI, IKVM or physical access to the machine. If SSH is genuinely all you have, run the whole thing inside tmux or screen so a dropped connection does not kill the upgrade halfway through, and test on a machine you do not care about first.

You need 5 GB free on the root filesystem, and ideally more than 10 GB. This is the one people skip and then hit at the worst moment.

You need backups you have actually restored from. An untested backup is a hope, not a plan, and this is the upgrade where you find out which one you have.

Run the checker, and keep running it

Proxmox ships a script with the later 8.4 packages that inspects your specific machine and tells you what it does not like:

pve8to9 --full

It only looks. It changes nothing and fixes nothing, which means it is safe to run whenever you like and worth running more than once: before you start, after each thing you fix, and again after the upgrade. Its output changes depending on where you are in the process.

Run the full check at least once before you begin. It will not catch everything, because a Proxmox install can be customised well beyond what any script can anticipate, but it catches the common traps.

The five things that actually break

1. The machine will not boot, and GRUB says “disk not found”

This is the worst one, because it happens after the reboot when you think you are finished. It affects machines that boot in UEFI mode with root on LVM.

The symptom is a boot failure with an error naming a disk like lvmid/... that GRUB cannot find. It comes from a long-standing GRUB bug present in Proxmox VE 8 and earlier, and the fix is making sure the corrected GRUB is the one actually installed:

[ -d /sys/firmware/efi ] && apt install grub-efi-amd64

If your root is on ZFS, or the machine boots in legacy BIOS mode, this one cannot affect you.

2. Disks stop coming up on their own

From version 9 onwards, Proxmox creates new LVM volumes with autoactivation switched off, and activates them itself when a guest needs them. On a cluster with shared LVM storage over iSCSI or Fibre Channel, the old automatic behaviour was the cause of guest creation and migration failures, which is the problem this change was made to fix.

Your existing volumes keep the old setting, so the checker will point you at a migration script that turns it off for them too:

/usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation

If any guest volumes sit on shared LVM storage, run it. If everything is on local LVM, it is optional and you can leave it.

3. A bootloader package quietly rewrites your boot configuration

If your machine was installed from a Proxmox VE 8.1 to 8.4 ISO, it may carry a systemd-boot meta-package that it does not need, and which can change bootloader configuration by itself. Where the checker flags it, removing it is safe. The single exception is if you deliberately set up systemd-boot as your bootloader, in which case keep it.

4. HA groups disappear and become something else

Proxmox VE 9 retires HA groups in favour of HA rules. If you use high availability, your groups migrate to rules automatically, but only once every node in the cluster is on version 9. A part-upgraded cluster is the dangerous state to sit in.

If something looks wrong afterwards, the logs on the active CRM node will say why:

journalctl -eu pve-ha-crm

5. Older hardware meets a much newer kernel

Debian 13 brings a considerably newer Linux kernel. Hardware that was merely old before can become unsupported, and the failure shows up as a device that simply is not there any more after the reboot. Proxmox keeps a running list of these in the known upgrade issues section, which is worth reading against your own hardware rather than skimming.

The order that works

  1. Get every node to the latest 8.4 and confirm the cluster is healthy.
  2. Upgrade Ceph to Squid if you run it.
  3. Take a backup and restore one guest from it somewhere else, to prove the backup works.
  4. Run pve8to9 --full and clear what it reports.
  5. Move important guests off the node you are about to upgrade.
  6. Point the package repositories at Debian Trixie and the Proxmox VE 9 repository.
  7. Upgrade, then read what it says before rebooting.
  8. Reboot into the new kernel, then run pve8to9 again.
  9. Only then move to the next node.

On a cluster, that whole sequence happens one node at a time. There is no shortcut where you do all of them at once, and looking for one is how clusters end up in the part-upgraded state that causes the HA problem above.

If it goes wrong

The honest answer is that a failed distribution upgrade on a machine you cannot physically reach is a bad afternoon, which is why out-of-band access is on the prerequisite list rather than the nice-to-have list. Proxmox documents recovery from the GRUB failure specifically, because it is the one that strands people most often.

Everything on this page comes from Proxmox’s own documentation for the current release. The roadmap and release notes carry the per-version list of breaking changes, and it is worth checking that page for the exact version you are moving to, because the list grows with each point release.