Proxmox VE 8 auf 9: Ein Abend, 644 Pakete und ein DNS-Server, der sich selbst abschaltet
Mein Proxmox läuft auf einem Mini-PC ohne Bildschirm und Tastatur, irgendwo im Regal, und er ist seit Monaten das, was man in der IT „stabil“ nennt: unangetastet.
Auf dem Mini-PC laufen Home Assistant als VM, AdGuard Home als Container und ein Proxmox Backup Server, dessen Daten auf einer USB-SSD liegen. AdGuard ist zugleich der DNS-Server meines Heimnetzes. Wer jetzt ahnt, wo das hinführt: Ja, der Rechner, den ich gleich aktualisiere, ist derjenige, von dem mein Netz seine Namen bekommt. Das Upgrade von 8.4 auf 9.2 heißt außerdem, von Debian 12 auf 13 zu springen und vom Kernel 6.8 auf 7.0, und das auf einem Gerät, an das ich nur per SSH komme. Ich bin optimistisch, aber mit Rückweg.
Der Checker findet einen Fehler, den ich gar nicht habe
Proxmox liefert für den Sprung ein Prüfwerkzeug mit, pve8to9. Vorher bringt man 8.4 auf den letzten Stand und lässt es dann laufen:
apt update && apt dist-upgrade
pveversion
pve8to9 --fullErgebnis: 43 Prüfungen, 32 bestanden, 5 übersprungen (Cluster, Ceph und Verwandtes, das ich nicht habe), drei Warnungen und ein Fehler. Der Fehler: Das Meta-Paket systemd-boot ist installiert und macht bei Upgrades anderer Boot-Pakete Ärger. Das Wiki sagt dazu, man solle es entfernen, wenn pve8to9 es empfiehlt, es sei denn, man hat bewusst einen eigenen systemd-boot-Start eingerichtet.
Ich wollte aber nicht blind entfernen, was mit dem Start des Rechners zu tun hat, und das schon gar nicht auf einem Gerät ohne Bildschirm. Also erst nachsehen, womit er wirklich bootet:
proxmox-boot-tool status
ls /sys/firmware/efi >/dev/null 2>&1 && echo EFI || echo BIOS
efibootmgr -v
ls /boot/efi/EFIDas Ergebnis war eindeutig. proxmox-boot-tool ist bei mir gar nicht im Einsatz, der Rechner startet per UEFI, und der aktive Eintrag zeigt auf GRUB über Shim. Im EFI-Ordner liegen nur BOOT und proxmox, kein systemd. systemd-boot war also nur eine Altlast, die nach dem Proxmox-Wiki bei den Installations-ISOs 8.1 bis 8.4 mitgeliefert wurde. Dann kann es weg:
apt remove systemd-bootVor dem Bestätigen habe ich die Liste angesehen. Es sollte nur systemd-boot verschwinden, 251 kB. Stehen dort proxmox-ve, pve-manager oder grub-*, bricht man ab. Danach waren GRUB und Shim noch da, und der Checker zeigte 33 bestanden, drei Warnungen, null Fehler. Ein Fehler weniger, ohne dass ich ein einziges Mal geraten habe.
Die leisen Warnungen sind die gefährlichen
Von den drei Warnungen war eine harmlos: Drei Gastsysteme liefen noch, das war so gewollt. Die anderen beiden haben es in sich.
Die erste betraf /etc/sysctl.conf. Die Datei enthielt net.ipv6.conf.all.forwarding=1, sogar zweimal, ein Rest aus einer Zeit, in der ich dachte, ich würde mich an so etwas erinnern. Das Wiki warnt, dass diese Datei mit dem neuen systemd nicht mehr gelesen wird. Die Einstellung wäre nach dem Neustart still verschwunden, ohne Fehlermeldung, und ich hätte irgendwann gerätselt, warum IPv6 plötzlich nicht mehr weitergeleitet wird. Also in eine eigene Datei, die gelesen wird:
cp /etc/sysctl.conf /root/sysctl.conf.bak
echo "net.ipv6.conf.all.forwarding=1" > /etc/sysctl.d/99-ipv6-forwarding.conf
sed -i 's/^net\.ipv6\.conf\.all\.forwarding=1/# &/' /etc/sysctl.conf
sysctl --system | grep forwardingDer Wert blieb 1, jetzt aus der neuen Datei.
Die zweite Warnung: Das Paket amd64-microcode fehlte. Es bringt CPU-Sicherheitsupdates mit, und es steckt in der Paketquelle non-free-firmware, die in meiner Quellenliste nicht stand. Also Quelle ergänzen und Paket installieren:
sed -i.bak 's/ main contrib$/ main contrib non-free-firmware/' /etc/apt/sources.list
apt update
apt install amd64-microcodeDie Meldung, dass das Microcode-Update beim nächsten Start geladen wird, passt zum geplanten Neustart. Danach blieb nur noch die erwartete Warnung wegen der laufenden Gastsysteme.
Und noch etwas fiel beim Blick in die Quellen auf: eine Netdata-Quelle, noch auf Bookworm. Netdata lief auf dem Rechner, und ich hatte es fast vergessen. Fremdquellen sind beim Distributionswechsel die Sorte Fehler, die man erst nach der Umstellung bemerkt. Dazu unten mehr.
Erst sichern, dann Mut
Bevor irgendetwas am System geändert wird, kommt die Sicherung. Im Proxmox Backup Server habe ich einen manuellen Lauf gestartet (Datacenter, Backup, Run now). Er dauerte von 18:26 bis 18:28 Uhr und lief ohne Fehler durch, etwa zwei Minuten für drei Gastsysteme.
Das ist die Sicherung der Gastsysteme. Die Konfiguration des Hosts selbst sichert das nicht, deshalb noch ein Archiv der wichtigsten Dateien, das ich auf meinen Rechner kopiert habe:
tar czf /root/pve-config-vor-upgrade.tar.gz /etc/pve /etc/network/interfaces /etc/apt /etc/sysctl.d /etc/sysctl.conf /etc/hosts /etc/fstab
scp root@<Host>:/root/pve-config-vor-upgrade.tar.gz ~/
chmod 600 ~/pve-config-vor-upgrade.tar.gz
tar tzf ~/pve-config-vor-upgrade.tar.gz | head -5Das Archiv ist 81 KB groß. /etc/pve enthält auch Schlüssel, deshalb die Rechte 600, und die letzte Zeile prüft, ob das Archiv sich überhaupt öffnen lässt. Zusätzlich habe ich ein manuelles Backup von Home Assistant heruntergeladen. Der Grund: Alle meine PBS-Sicherungen liegen auf derselben USB-SSD am Mini-PC. Wenn der Rechner Probleme macht, habe ich sonst Backups, die genauso weg sind wie der Rechner, und eine Sicherung, die auf dem gleichen Gerät liegt, ist eine hübsch ordentliche Kopie des Problems.
tmux, Quellen und eine vergessene Fremdquelle
Das Upgrade selbst läuft eine Viertelstunde und darf nicht abbrechen, nur weil meine SSH-Verbindung zuckt. Das Wiki empfiehlt bei reinem SSH-Zugang deshalb tmux oder screen. Auf meinem Rechner habe ich dazu zwei Abkürzungen in der .bashrc:
alias sshpve='ssh root@<Host>'
alias pveupgrade='ssh -t root@<Host> "tmux new -A -s upgrade"'Beim ersten Versuch kam tmux: command not found. Auf dem Host war tmux gar nicht installiert, das fällt natürlich erst auf, wenn man es braucht. Ein apt install tmux später ging es.
Dann die Quellen. Platz hatte ich (94 GB, davon 12 belegt), und die Audit-Meldungen im Journal habe ich vorab abgestellt. Die Netdata-Quelle, die noch auf Bookworm stand, habe ich vor dem Umschalten deaktiviert, die Debian-Quellen von bookworm auf trixie umgestellt und die Proxmox-9-Quelle als eigene Datei im neuen Format angelegt:
cp /etc/apt/sources.list.d/netdata.sources /root/netdata.sources.bak
sed -i 's/^Enabled: Yes/Enabled: no/' /etc/apt/sources.list.d/netdata.sources
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
mv /etc/apt/sources.list.d/pve-install-repo.list /root/pve-install-repo.list.bak
cat > /etc/apt/sources.list.d/proxmox.sources << 'EOF'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF
apt updateapt update lief ohne Fehler und meldete 644 aktualisierbare Pakete. Eine Kontrolle auf übrig gebliebene Bookworm-Zeilen mit grep -rn bookworm /etc/apt/sources.list /etc/apt/sources.list.d/ | grep -v ':#' fand nur die absichtlich deaktivierte Netdata-Quelle. Die Quellen waren damit sauber, und der Download aus dem nächsten Schritt konnte starten.
Der DNS-Server fährt mit
Hier liegt die eigentliche Pointe dieses Abends. AdGuard Home läuft als Gast auf dem Rechner, den ich gerade aktualisiere, und ist der DNS-Server meines Heimnetzes. Sobald ich ihn stoppe, kann der Host selbst keine Namen mehr auflösen, und ohne Namen holt apt nichts mehr aus dem Netz. Ein Upgrade, das mittendrin seine eigenen Pakete nicht mehr findet, ist die Art Abend, die man nicht erleben will.
Die Lösung ist banal und trotzdem leicht zu vergessen: erst alles herunterladen, solange DNS noch läuft, und erst dann installieren.
apt dist-upgrade --download-onlyDie Zusammenfassung des Laufs: 644 Pakete werden aktualisiert, 183 sind neu, 60 werden entfernt, 1.024 MB Download und etwa 2,1 GB zusätzlicher Platz. Der Rechner hatte vorher 78 GB frei, das reichte locker. Bei den 60 Entfernungen wollte ich sicher sein, dass darunter nichts Wichtiges ist, und habe sie vorher trocken durchlaufen lassen, ohne etwas zu verändern:
apt dist-upgrade -s | grep -E '^Remv (proxmox-ve|pve-manager|proxmox-backup|grub|shim|zfs|lxc|qemu)'
apt dist-upgrade -s | grep '^Remv' | awk '{print $2}' | tr '\n' ' 'Die erste Zeile blieb leer. Die vollständige Liste bestand fast nur aus ersetzten Bibliotheken, viele mit dem Zusatz t64, und aus Python-Altlasten wie python3-distutils. Nichts, was ich vermissen würde.
Erst die Gäste, dann das System
Die Reihenfolge beim Herunterfahren hatte ich mir vorher überlegt: zuerst Home Assistant, dann der Backup-Server, und AdGuard ganz zuletzt, damit das Heimnetz so lange wie möglich Namen auflösen kann.
qm shutdown <VMID>
pct shutdown <CTID>
qm list
pct listDie beiden Listen am Ende zeigen, ob wirklich alles steht. Dann in der tmux-Sitzung der eigentliche Schritt:
apt dist-upgradeWährend der Installation kommen Fragen. Die Frage, ob Dienste bei Paket-Upgrades ohne Rückfrage neu gestartet werden sollen (sie taucht bei libc6 auf), habe ich mit der Vorgabe No beantwortet. Bei der Liste der neu zu startenden Dienste (postfix, ssh, cron) habe ich die Vorauswahl bestätigt, und ein Neustart von ssh trennt bestehende Verbindungen nicht. Bei den Konfigurationsdateien habe ich mich an die Empfehlungen im Wiki gehalten, und im Verlauf wurde keine Datei abgefragt, mit der ich nicht gerechnet hätte. Die Installation dauerte etwa 13 Minuten. Ein Tipp noch: tmux scrollt anders als ein normales Terminal (Strg+B, dann [), und der Bildschirm war nach dem Download schon voll.
Vor dem Neustart habe ich nachgesehen, wo ich stehe:
pveversion
dpkg -l grub-efi-amd64 | tail -1
pve8to9 --full | grep -E 'FAIL|WARN|FAILURES'Der pve-manager stand auf 9.2.24, GRUB auf 2.12-9+pmx2. Das war der Punkt, auf den ich am meisten geachtet habe. Das Wiki warnt, dass bei UEFI-Boot mit Root auf LVM ohne die korrigierte GRUB-Version der Start mit „disk lvmid not found“ scheitern kann, und mein Rechner ist genau so aufgebaut. Der Checker zeigte null Fehler und drei Warnungen: Kernel-Neustart nötig (klar), Backup-Speicher nicht aktiv (der Container war ja gestoppt) und keine Zeitsynchronisation. Die letzte war neu.
Ohne Bildschirm gibt es keinen zweiten Versuch
Zuerst die Warnung wegen der Zeit. Ein Blick ins Journal von chrony zeigte:
journalctl -u chrony --no-pager -n 25Die Meldung lautete „Fatal error: Could not send notification to $NOTIFY_SOCKET“. Der Dienst startete im Mischzustand aus neuem System und altem Kernel nicht, und ein Neustart des Dienstes half auch nicht. Meine Vermutung war, dass der Neustart des Hosts das löst. Belegen kann ich nur, dass der Fehler vor dem Neustart auftrat und danach nicht mehr.
Dann das, was mir bei einem Gerät ohne Monitor die meisten Sorgen gemacht hat: der Name der Netzwerkschnittstelle. Ein neuer Kernel kann ihn ändern. Steht in der Konfiguration noch der alte Name, kommt der Rechner nach dem Neustart ohne Netz hoch, und ich käme nur mit Bildschirm und Tastatur wieder heran, die ich nicht angeschlossen habe. Proxmox 9 liefert dafür ein Werkzeug mit, pve-network-interface-pinning:
pve-network-interface-pinning generate --interface <alter Name> --target-name nic0
diff /etc/network/interfaces /etc/network/interfaces.newDas Werkzeug legt eine .link-Datei an, die den Namen an die MAC-Adresse bindet, und schreibt die neue Konfiguration in interfaces.new. Der diff zeigte nur zwei Stellen, an denen der alte Name durch nic0 ersetzt wurde. Übernommen wird das Ganze beim Neustart. Beim Befehl habe ich mich auf Forum und Blogs gestützt und nicht auf das Handbuch, aber dass es das Werkzeug gibt, steht im Wiki.
Dann reboot. Nach drei bis fünf Minuten war der Host wieder erreichbar, und die Gastsysteme starteten per Autostart von selbst. Eine Kontrolle danach:
pveversion
uname -r
ip -br a
systemctl --failed
qm list
pct list
systemctl status chrony --no-pager | head -5Das Ergebnis: pve-manager 9.2.24, Kernel 7.0.14-26-pve, Schnittstelle nic0 und die Bridge vmbr0 oben, keine fehlgeschlagenen Dienste, und chrony lief wieder, mit einer Abweichung von etwa 0,3 Millisekunden zur Referenzzeit. pve8to9 --full zeigte danach null Warnungen und null Fehler. Ein manueller Backup-Test nach dem Upgrade lief von 20:04 bis 20:05 Uhr durch, in knapp zwei Minuten und ohne Fehler. Offline waren die Gastsysteme insgesamt rund 20 Minuten, mein Heimnetz-DNS eingeschlossen. Wer in der Zeit etwas im Netz suchen wollte, hat es gemerkt.
Aufräumen, wenn alles läuft
Das Upgrade bringt Hinterlassenschaften mit, und zwei davon habe ich direkt am selben Abend erledigt.
Die erste war Netdata. Ich habe erst geprüft, ob es für Debian 13 ein Repository gibt, und die Quelle dann zurückgeschaltet:
curl -sI http://repository.netdata.cloud/repos/stable/debian/trixie/InRelease | head -1
sed -i 's#Suites: bookworm/#Suites: trixie/#; s/^Enabled: no/Enabled: Yes/' /etc/apt/sources.list.d/netdata.sources
apt updateDie zweite war eine Fremdquelle, die das Upgrade selbst angelegt hatte. Beim apt update kam ein 401 Unauthorized von enterprise.proxmox.com: Das Upgrade hatte eine Datei pve-enterprise.sources für das kostenpflichtige Repository hinterlassen. Ohne Abo gibt es den Fehler bei jedem Update, also habe ich die Quelle deaktiviert:
cp /etc/apt/sources.list.d/pve-enterprise.sources /root/pve-enterprise.sources.bak
echo "Enabled: no" >> /etc/apt/sources.list.d/pve-enterprise.sources
apt updateBeim Netdata-Update hielt apt upgrade das Hauptpaket zurück, weil eine neue Abhängigkeit nötig war. apt full-upgrade zog es nach, und dabei kamen libmongoc-1.0-0t64 und libutf8proc3 neu dazu. Netdata lief danach weiter.
Was ich bewusst noch nicht getan habe: apt autoremove. Die Paketverwaltung meldet alte Entwicklerpakete und zwei alte Kernel, die weg könnten. Das kommt erst nach ein paar stabilen Tagen, und den Kernel 6.8.12 lasse ich als Rückweg stehen. Optional wäre noch apt modernize-sources für das neue Quellenformat und das Skript gegen die LVM-Autoaktivierung, das der Checker als Hinweis ausgegeben hat. Der Backup-Server ist ein eigener Gast mit eigenem Upgrade-Weg, den habe ich an diesem Abend nicht angefasst.
Von 18 Uhr bis kurz nach 20 Uhr hat das alles gedauert, die reine Installation dreizehn Minuten. Wenn man die Zeit für Planung und Prüfung am Mittag mitrechnet, war der Hauptaufwand nicht das Upgrade, sondern das Wissen, was vorher zu tun ist. Der Mini-PC läuft jetzt auf 9.2, und ich werde ihm in den nächsten Tagen mit der üblichen Mischung aus Zuversicht und Misstrauen beim Laufen zusehen.
