What began as a routine Proxmox upgrade turned into a surprisingly useful infrastructure-recovery exercise.
My primary homelab server lab0 was still running Proxmox VE 8.4 on Debian 12 Bookworm. Since Proxmox VE 9 had been out for a while and moves the underlying distribution to Debian 13 Trixie, I decided it was time to make the jump.
This is the same host running much of the infrastructure from my homelab series, including my Wazuh VM.
So before changing anything, I started where every major upgrade should start:
pve8to9 --fullThe initial report was better than expected: 43 checks total, 29 passing, three warnings, and one failure.
The failure was the one that mattered most:
FAIL: systemd-boot meta-package installed.There were a few other cleanup items too:
AMD CPU microcode was missing.
Legacy settings remained in
/etc/sysctl.conf.LVM volumes were using the old autoactivation behavior.
Wazuh’s third-party repository appeared as an unusual APT suite.
One VM was still running.
None of that was catastrophic. But this is precisely why pre-upgrade checks exist: they turn hidden technical debt into an actionable checklist.
Full unedited upgrade process (with the help of ChatGPT).
Confirming the Boot Path
The first thing I wanted to understand was the bootloader warning.
Having the systemd-boot package installed does not necessarily mean the host actually boots using systemd-boot, so I checked the relevant state:
proxmox-boot-tool status
efibootmgr -v
dpkg -l | grep -E 'systemd-boot|grub|proxmox-boot'The key detail was this EFI entry:
Boot0004* proxmox ... \EFI\proxmox\shimx64.efiThe host also had the full GRUB stack installed. In other words, it was booting through Proxmox’s GRUB/shim path—not systemd-boot. The package was simply an unnecessary meta-package left behind on the system.
I removed it, reran the checker, and the failure disappeared.
That took the host from one failure to zero.
Cleaning Up Before the Upgrade
Next, I worked through the remaining warnings.
Updating LVM autoactivation
Proxmox 9 changes how newly created LVM and LVM-thin guest volumes use autoactivation. One of my existing VM disks still had the older behavior enabled.
Proxmox provides a migration script for this:
/usr/share/pve-manager/migrations/pve-lvm-disable-autoactivationIt found the affected volume and corrected it.
One important lesson: I had to run this script a second time later in the upgrade
