Upgrading a Single-Node Proxmox VE Host from 8.4 to 9.2

I recently upgraded my single-node Proxmox host from Proxmox VE 8.4 to Proxmox VE 9.2 using an in-place APT upgrade. The process was generally straightforward, but the important part was treating it as a Debian major-version upgrade—not just clicking “Upgrade” in the web UI.

The host started on:

pve-manager/8.4.19/a68fb383814bb1e6
running kernel: 6.8.12-38-pve

Afterward, it was running:

proxmox-ve: 9.2.0
pve-manager: 9.2.20
proxmox-kernel-7.0.14-19-pve-signed

This post documents the process, the Ceph repository issue I encountered, and the enterprise repository error that appeared after the upgrade.

Important cautions

Before beginning:

Make tested backups of every VM and container.
Plan for downtime and shut down important guests cleanly.
Have physical console method available if possible.
If upgrading remotely, use tmux or screen so a dropped SSH session does not interrupt APT.
Do not follow the Ceph steps below if you operate a real Proxmox-managed Ceph cluster; that requires a separate, staged Ceph upgrade process.

Proxmox VE 9 is based on Debian 13 “Trixie,” while Proxmox VE 8 is based on Debian 12 “Bookworm.” That makes this a distribution upgrade: package repositories must be changed from Bookworm to Trixie before the final upgrade is performed.[1]

Check the starting state

First, confirm the installed Proxmox version and inspect all package versions:

pveversion
pveversion -v

Run Proxmox’s pre-upgrade checker:

pve8to9 --full

The checker identifies common upgrade blockers, including outdated packages, VM and LXC configuration concerns, bootloader issues, Ceph configuration, incompatible kernel modules, legacy cgroup settings, and storage configuration problems.

Also inventory the guests on the node:

qm list
pct list

qm list shows full QEMU/KVM virtual machines, while pct list shows LXC containers.

Before changing repositories, make sure PVE 8 is fully up to date:

apt update
apt dist-upgrade

Then reboot if a newer PVE 8 kernel was installed, rerun the checker, and resolve any failures before continuing.

Back up the host configuration

VM backups are the priority, but it is also useful to preserve the host configuration and package inventory:

mkdir -p /root/pve8-pre-pve9

cp -a /etc/pve \
      /etc/network/interfaces \
      /etc/hosts \
      /etc/resolv.conf \
      /etc/apt \
      /root/pve8-pre-pve9/

dpkg --get-selections > /root/pve8-pre-pve9/dpkg-selections.txt
pveversion -v > /root/pve8-pre-pve9/pveversion-before.txt

This does not replace proper VM backups, but it makes it much easier to reconstruct networking, storage definitions, repository configuration, and package choices if troubleshooting becomes necessary.

Review APT repositories

My Proxmox VE 8 host used traditional .list repository files. The starting configuration looked like this:

deb http://ftp.us.debian.org/debian bookworm main contrib non-free-firmware
deb http://ftp.us.debian.org/debian bookworm-updates main contrib non-free-firmware
deb http://security.debian.org bookworm-security main contrib non-free-firmware

deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

I checked every configured repository before making changes:

grep -R --line-number --no-messages \
  -E '^(deb|Types:|URIs:|Suites:|Components:)' \
  /etc/apt/sources.list \
  /etc/apt/sources.list.d/

It is important to identify:

Third-party Debian repositories
Vendor repositories for drivers or storage products
NVIDIA, DKMS, or custom kernel-module repositories
An enabled PVE enterprise repository without a valid subscription
Ceph repositories

Any repository that does not support Debian Trixie can block the upgrade or create an unsupported mixture of packages. Proxmox recommends reviewing third-party repositories and package compatibility before moving from PVE 8 to PVE 9.[1]

Investigate any Ceph repository

I found this old enabled repository:

deb http://download.proxmox.com/debian/ceph-quincy bookworm no-subscription

That does not necessarily mean Ceph is actively used, but it must be investigated before changing anything (I was playing about with node settings). If the host has a real hyperconverged Ceph deployment, the supported path requires upgrading Ceph before the PVE 9/Debian 13 transition. Proxmox documents the current Ceph upgrade path from Reef to Squid, and a Quincy installation requires staged upgrades rather than a direct leap.[1][2]

I checked the local Ceph state:

pveceph status
ceph --version
ceph -s
dpkg -l | grep -E '^(ii|hi)\s+(ceph|librados|librbd)'

My output showed:

binary not installed: /usr/bin/ceph-mon

and:

ceph version 17.2.8 ... quincy (stable)

but ceph -s failed because no usable cluster configuration could be found:

Error initializing cluster client: ObjectNotFound(...)

This indicated that old Ceph client packages were installed, but the Proxmox host was not operating a local Ceph monitor or OSD cluster. The appropriate action was not to upgrade Ceph; it was to disable the stale repository:

mv /etc/apt/sources.list.d/ceph.list \
   /etc/apt/sources.list.d/ceph.list.disabled

A filename ending in .disabled is ignored by APT. I left the installed Ceph packages in place for the time being rather than adding an unnecessary package removal step during the OS upgrade.

To confirm no Ceph storage was configured in Proxmox, I could also check:

grep -nEi 'ceph|rbd|cephfs' /etc/pve/storage.cfg

Switch Bookworm to Trixie

After confirming there was no active Ceph cluster and after completing the PVE 8 preparation, I backed up the sources list:

cp -a /etc/apt/sources.list /root/sources.list.bookworm-pre-pve9

Then I changed the Debian and no-subscription PVE repository entries from bookworm to trixie:

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

The resulting /etc/apt/sources.list was:

deb http://ftp.us.debian.org/debian trixie main contrib non-free-firmware
deb http://ftp.us.debian.org/debian trixie-updates main contrib non-free-firmware
deb http://security.debian.org trixie-security main contrib non-free-firmware

deb http://download.proxmox.com/debian/pve trixie pve-no-subscription

The no-subscription PVE repository is appropriate for a home-lab system without a paid Proxmox subscription. The enterprise repository requires a valid subscription key.[3][4]

Before allowing APT to change packages, validate the new source configuration:

apt update
apt policy proxmox-ve pve-manager
apt -s dist-upgrade

The -s option tells APT to simulate the upgrade. It displays what would be installed, upgraded, or removed without changing the system.

At this stage, stop if APT proposes removing critical packages such as:

proxmox-ve
pve-manager
pve-kernel-*
ifupdown2
zfsutils-linux

Also carefully inspect any planned removal of custom network drivers, NVIDIA packages, DKMS modules, or storage tooling.

Use tmux for a remote upgrade

Because this was a remote upgrade, I installed and used tmux after reviewing the APT plan:

apt install tmux
tmux new -s pve9-upgrade

The -s argument means “session name.” It creates a named persistent terminal session called pve9-upgrade.

Inside that session, run the upgrade:

apt dist-upgrade

If the SSH connection drops, reconnect and resume the session:

tmux attach -t pve9-upgrade

To detach without stopping the upgrade, press:

Ctrl+b, then d

Tmux keeps the shell and APT process alive after the SSH client disconnects. It is much safer than using nohup, backgrounding APT, or assuming a long-running SSH connection will remain stable.[5][6]

Run post-upgrade checks

After the upgrade completed, I ran:

pve8to9 --full
pveversion -v
systemctl --failed

The key result was:

PASS: already upgraded to Proxmox VE 9

The checker also reported:

WARN: a suitable kernel (proxmox-kernel-7.0) is installed,
but an unsuitable (6.8.12-38-pve) is booted, missing reboot?!

That warning is expected. The installed Proxmox VE 9 kernel was:

proxmox-kernel-7.0.14-19-pve-signed

but the host was still running the old Proxmox VE 8 kernel until reboot.

The checker found no failures:

TOTAL:    47
PASSED:   39
SKIPPED:  5
WARNINGS: 3
FAILURES: 0

The remaining warnings were not blockers:

The current kernel was old because the machine had not rebooted yet.
The node is a one-node cluster, so it has fewer than three quorum-providing members.
No active time synchronization daemon was detected.

The cluster warning is normal for a single-node Proxmox installation. The NTP warning should be corrected, but it does not prevent a successful reboot.

Fix the enterprise repository error

After the upgrade and reboot, apt update failed with:

Err:5 https://enterprise.proxmox.com/debian/pve trixie InRelease
401 Unauthorized

Although the old PVE 8 enterprise .list file was commented out, PVE 9 had created a new Deb822-format source file:

/etc/apt/sources.list.d/pve-enterprise.sources

I found it with:

grep -R --line-number --no-messages \
  'enterprise.proxmox.com' \
  /etc/apt/sources.list \
  /etc/apt/sources.list.d/

The fix for a no-subscription host was to disable the new enterprise source:

mv /etc/apt/sources.list.d/pve-enterprise.sources \
   /etc/apt/sources.list.d/pve-enterprise.sources.disabled

Then:

apt update
apt -s dist-upgrade

APT ignores files that do not end in .list or .sources, so renaming the file is a safe and reversible way to disable it. Proxmox documents that the enterprise repository can be disabled when it is not available to the node.[7][8]

Reboot into the PVE 9 kernel

Before rebooting, I verified guest status:

qm list
pct list

Then I shut down any important VMs cleanly:

qm shutdown <VMID>

Finally:

reboot

After the system returned, the first verification commands were:

uname -r
pveversion
systemctl --failed
pvecm status
pvesm status
zpool status
qm list

The important confirmation is that uname -r reports the PVE 9 kernel:

7.0.14-19-pve

or a newer 7.0-series PVE kernel.

The web interface may retain old PVE 8 JavaScript and CSS files in the browser cache, so after logging in I performed a hard refresh:

Ctrl+Shift+R

Configure time synchronization

The final remaining upgrade-checker warning was:

WARN: No (active) time synchronisation daemon (NTP) detected

For a server, reliable time matters for logs, TLS certificates, backups, authentication, and future clustering. I checked the existing state:

timedatectl status
systemctl status chrony --no-pager

If Chrony is not installed, install and enable it:

apt update
apt install chrony
systemctl enable --now chrony
chronyc tracking
chronyc sources -v

Proxmox recognizes multiple NTP implementations, but Chrony is a strong choice for a server or home-lab host because it continually disciplines the clock and handles intermittent connectivity well.[9][10]

Final result

The Proxmox node successfully moved from PVE 8.4 to PVE 9.2 with:

Debian 13 Trixie repositories
The Proxmox no-subscription repository
Proxmox VE 9.2.20
The PVE 7.0 kernel
No active Ceph repository or local Ceph deployment
No enterprise repository authorization errors
A clean post-upgrade validation path

The biggest lessons were simple:

Treat a Proxmox major-version upgrade as a full Debian release upgrade.
Run pve8to9 --full before and after the package transition.
Investigate old Ceph repositories before modifying them.
Simulate the APT transaction before accepting it.
Use tmux for remote work.
Expect the enterprise repository to reappear in a new .sources file after upgrading to PVE 9.
Reboot before judging whether the new Proxmox kernel is working.

The official PVE 8 → 9 upgrade guide remains the authoritative reference and should be checked before beginning, especially for multi-node clusters, Ceph installations, passthrough hardware, and nonstandard storage or networking setups.[1]