> ## Content Index > Fetch the complete content index at: https://anantafatur.dev/llms.txt > Use this file to discover other available public pages before exploring further. # Proxmox 8 to 9 Upgrade: Fixing Meta-Package and Repo Errors - URL: https://anantafatur.dev/proxmox-8-to-9-upgrade-fixing-meta-package-and-repo-errors/ - Published: 2026-08-14T19:15:23.000Z - Updated: 2026-08-14T19:15:23.000Z - Description: I walked through upgrading a Proxmox VE 8 server to version 9, resolving a scary meta-package removal warning and a split-brain APT repository configuration. - Author: Ananta 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. ```bash 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](https://pve.proxmox.com/wiki/Upgrade%5Ffrom%5F8%5Fto%5F9) 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. ```bash 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. ```bash 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. ```text 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. ```bash 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.