Proxmox 8 to 9 Upgrade: Fixing Meta-Package and Repo Errors

Upgrading a hypervisor always makes me slightly nervous. It feels like replacing core parts of a system while everything is still running.

I recently upgraded a standalone Proxmox VE 8 node to Proxmox VE 9 (which moves the underlying Debian base from Bookworm to Trixie). I followed the official documentation, but I hit a problem almost immediately.

Here is what went wrong, how I investigated the repository conflicts, and how I fixed it.

The Scary Meta-Package Warning

So here is what happened. I updated my apt sources to point to Debian Trixie and started the upgrade process. I ran apt dist-upgrade and was immediately greeted by a massive warning block.

The pve-apt-hook script caught something bad. APT was trying to completely uninstall the proxmox-ve meta-package.

W: (pve-apt-hook) !! WARNING !!
W: (pve-apt-hook) You are attempting to remove the meta-package 'proxmox-ve'!
W: (pve-apt-hook)
W: (pve-apt-hook) If you really want to permanently remove 'proxmox-ve' from your system, run the following command
W: (pve-apt-hook)       touch '/please-remove-proxmox-ve'

If I had bypassed this hook, APT would have removed the entire hypervisor from the server.

Investigating the Conflict

The official Proxmox upgrade docs explicitly mention this exact scenario. Usually, this happens if you installed Proxmox on top of a vanilla Debian setup. The standard Debian kernel package (linux-image-amd64) conflicts with the new Proxmox 9 kernel setup.

I assumed this was my problem. I tried to remove the conflicting package.

root@proxmox:~# apt remove linux-image-amd64
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package 'linux-image-amd64' is not installed, so not removed

Well, that ruled out the easy fix. The kernel package was not even installed. I had to dig deeper to see what APT was actually looking at.

I ran apt policy and dumped my repository lists to see where my packages were coming from.

cat /etc/apt/sources.list
cat /etc/apt/sources.list.d/*

Fixing the Split-Brain Repositories

The output from the sources list revealed a classic split-brain configuration.

My base Debian repositories were correctly pointing to trixie. But my Proxmox repository line for Trixie was commented out with a #. To make matters worse, an old script (pve-nag-buster) had left a separate file in /etc/apt/sources.list.d/ that was actively pointing to the old Bookworm packages.

Because APT saw the brand new Debian 13 packages but only saw the old Proxmox 8 packages, it panicked. It realized the old hypervisor packages were incompatible with the new base OS. To resolve the dependency nightmare, APT decided the most logical choice was to just delete Proxmox entirely.

The fix was simple. I opened /etc/apt/sources.list and uncommented the correct Trixie line.

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

Then I deleted the leftover Bookworm file from the sources.list.d directory. Once the repositories were aligned, I ran apt update and apt dist-upgrade. The upgrade finished smoothly without trying to remove my hypervisor packages.

Clearing the Pre-Flight Checklist

After the core upgrade, I ran pve8to9. This is the built-in Proxmox checklist script that flags configuration issues.

My output was not completely green. I had 3 failures and 5 warnings. I walked through them one by one.

First, I had to remove the systemd-boot meta-package. Debian Trixie split this package into separate pieces. Leaving the old meta-package installed will break future bootloader upgrades. I removed it with a simple apt remove systemd-boot.

Next, the script warned me about my GRUB EFI removable bootloader. I just ran the exact commands the checker provided to force the EFI extra removable flag to true, and then I reinstalled grub-efi-amd64.

I also got hit with a missing time synchronization daemon warning. Accurate time is critical for Proxmox. I installed chrony, which is the standard NTP daemon for this environment.

Finally, I had a notice about LVM autoactivation. Proxmox 9 changes how LVM volumes activate to prevent clustering issues. I ran the provided migration script (/usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation) to update my local storage volumes.

The Final Repositories and Microcode

Honestly, I thought I was done, but I hit two final snags when trying to fix my missing Intel microcode package.

When I ran apt update, it threw a 401 Unauthorized error. APT was trying to pull from enterprise.proxmox.com. I do not have a paid enterprise subscription. I had clearly left a stale enterprise list file active. I deleted /etc/apt/sources.list.d/pve-enterprise.list to stop APT from checking it.

Then I tried to install the microcode.

apt install intel-microcode
Error: Package 'intel-microcode' has no installation candidate

Debian Trixie only enables open-source repositories (main and contrib) by default. The Intel microcode is proprietary. I had to edit /etc/apt/sources.list and append non-free and non-free-firmware to the Debian repository lines.

After one last apt update, the microcode installed perfectly. I ran pve8to9 one final time. Zero failures. Zero warnings. I rebooted the server, and it came back up flawlessly on the new Proxmox VE 9 kernel.