apt upgrade vs. dist-upgrade: Die stille Proxmox-Falle, in die jeder tappt

Wer lange genug in der Homelab-Welt unterwegs ist, sieht dieselbe Geschichte immer wieder aufs Neue: Jemand will Updates einspielen, ein winziger Befehl schlüpft am Muskelgedächtnis vorbei, und plötzlich hält der eigene Proxmox-Host nur noch mit Klebeband und Hoffnung zusammen. Die neueste Saga, die gerade die Runde macht, erzählt dieselbe Geschichte: ein falsch platziertes apt upgrade, über Automatisierung ausgeführt, ein verirrtes trixie-Repo, das niemand in den Sources bemerkt hatte, und ein völlig intaktes Proxmox-8-System, das plötzlich mit einer Handvoll fest verschweißter Proxmox-9-Pakete aufwacht.

Und genau darum geht es im Kern. Es geht nicht darum, dass jemand nachlässig war oder die Docs ignoriert hat. Es geht darum, wie unglaublich leicht man annimmt, dass apt upgrade – der Befehl, den die meisten Linux-Nutzer praktisch im Autopilot ausführen – überall völlig sicher ist. Auf Debian? Sicher. Auf Ubuntu? Meistens. Auf einem Hypervisor, der seine eigene Abhängigkeitslogik verdrahtet und tief mit der darunterliegenden Distro verwoben ist? Genau da fängt das Problem an.

Und fast jeder läuft früher oder später gegen diese Wand.

Der winzige Befehl, der Großes zerstört

Die Situation des Nutzers entwickelte sich auf schmerzhaft vertraute Weise: Er hatte gerade erst gelesen, dass apt upgrade Proxmox zerstören kann, aber ein Ansible-Tippfehler führte es trotzdem aus. Das Update lief still durch, zunächst wirkte nichts katastrophal, und die VMs liefen noch. Aber dann kam das große Symptom: Die Proxmox-Web-GUI war weg.

An diesem Punkt fangen die meisten an zu schwitzen. Wenn die GUI dunkel wird, der Node aber weiter bootet, befindet man sich in diesem Uncanny Valley, in dem das System lebt, aber nicht gesund ist. Und diesmal zeigte sich die rauchende Pistole in pveversion -v — eine wild gestreute Liste von Paketen sowohl aus Proxmox 8 (Bookworm) als auch aus Proxmox 9 (Trixie).

Ein partielles Major-Version-Upgrade. Die schlimmstmögliche Variante.

In dem Moment, in dem Kernkomponenten – wie pve-manager, libpve-* oder qemu-server – aus einer Major-Version stammen, die dem Rest Ihres Systems voraus ist, jonglieren Sie mit nicht zusammenpassenden Abhängigkeiten, die sich bei libc-Versionen, Kernel-Helpern oder Kern-Perl-Paketen nicht einig werden. Am Ende haben Sie Dutzende zurückgehaltene Pakete und einen Abhängigkeitsbaum, der aussieht wie umgekipptes Jenga.

Genau das ist hier passiert. Und viele Leute meldeten sich zu Wort: Ja, kenn ich.

Warum apt upgrade die Falle ist

Die Proxmox-Docs erklären das ausdrücklich, aber viele Leute – besonders die, die von Debian oder Ubuntu kommen – lesen einfach darüber hinweg:

• apt upgrade aktualisiert nur Pakete, die keine neuen Abhängigkeiten einführen.
• Proxmox benötigt bei Updates oft neue Abhängigkeiten, selbst bei kleineren.
• Blockieren Sie diese Abhängigkeiten, wenden sich Proxmox-Updates nur teilweise an — der gefährlichste Zustand, in dem man sein kann.

Auf einem normalen Linux-System ist diese Einschränkung meist harmlos. Aber ein Hypervisor ist keine normale Linux-Installation. Es ist ein eng orchestrierter Stack, in dem Web-UI, Cluster-Manager, QEMU, Speicher-Stack, Netzwerk-Bibliotheken und sogar der Klebecode dazwischen alle erwarten, synchron zu evolvieren.

apt upgrade auszuführen kann Ihnen Folgendes bescheren:

• neue Proxmox-Teile
• alte Proxmox-Teile
• nicht zusammenpassende Kernel
• unbegrenzt zurückgehaltene Pakete
• und Abhängigkeiten, die sich ohne einen Wechsel der Major-Repos nicht installieren lassen

So kommt es, dass ein einzelnes Update still und leise Pakete aus Proxmox 9 zieht, obwohl das System grundlegend noch auf Proxmox 8 basiert.

Was ist hier also tatsächlich passiert?

Nach einiger Grabungsarbeit fand der OP die rauchende Pistole: Eine apt-Quelle, die auf das Proxmox-9-„trixie"-Repo zeigte, war früher hinzugefügt worden, ohne dass es jemand bemerkt hatte. Als apt upgrade also lief, holte es sich nicht nur normale Patches — es mischte munter Pakete aus dem nächsten Major-Release mit ein.

Eine einzige Zeile in sources.list.d reichte aus, um Folgendes hereinzuziehen:

• neue Kernel-Helper
• neue Web-UI-Komponenten
• neue Cluster-Bibliotheken
• und eine Handvoll Pakete, die von Debian Trixie abhängen, nicht von Debian Bookworm

Ist diese Vermischung erst passiert, erreicht man einen Punkt ohne einfache Rückkehr. Man kann libc nicht downgraden, ohne das System zu zerstören. Man kann halb aktualisierte Proxmox-Pakete nicht downgraden, ohne Abhängigkeiten manuell hinterherzujagen. Und man kann nicht einfach alles sauber upgraden, weil der Rest des Systems auf Bookworm gepinnt ist.

Deshalb sagten mehrere Kommentatoren eine Variante desselben Satzes: An diesem Punkt könnte ein vollständiges Upgrade auf Proxmox 9 Ihr einziger stabiler Weg nach vorn sein.

Die Rettungsversuche, die vorgeschlagen wurden

Jede Menge Leute sprangen mit Lösungen ein — manche vorsichtig, manche mutig:

1. Versuchen Sie, das System zu reparieren mit:

apt update
apt --fix-broken install
dpkg --configure -a
apt clean
apt dist-upgrade

Das funktioniert, wenn Abhängigkeiten nur leicht verheddert sind.

In diesem Fall? Nicht wirklich.

Das System meldete über 70 zurückgehaltene Pakete und eine lange Liste unerfüllter Abhängigkeiten rund um libc, perl, OpenSSL und Kern-Proxmox-Module. Tauchen libc-Diskrepanzen auf, wissen Debian-Erfahrene: Der Raum füllt sich mit Rauch.

2. Versuchen Sie, GUI-Komponenten neu zu installieren

Manche Nutzer schlugen vor, neu zu installieren:

• pve-manager
• proxmox-widget-toolkit

Das funktionierte auch nicht. Das System verweigerte sich wegen unerfüllter Abhängigkeiten durch die nicht zusammenpassenden Debian-Versionen.

3. Die vermischten Repos erkennen und sich zu Proxmox 9 committen

Der mit Abstand praktischste Vorschlag war:

Wenn Sie ohnehin schon halb in Proxmox 9 drinstecken, können Sie auch gleich ganz reingehen.

Das bedeutet:

• jedes Bookworm-Repo auf Trixie umstellen
• ein vollständiges Upgrade ausführen
• Proxmox 9 fertigmachen lassen, was Proxmox 8 nicht mehr aufräumen kann

Das ist kein anfängerfreundliches Manöver. Aber insgesamt ist es weniger chaotisch, als zu versuchen, Dutzende Pakete chirurgisch zurückzurollen, die es in älteren Repos gar nicht mehr gibt.

4. Komplette Neuinstallation (die nukleare Option)

Das will niemand tun. Jeder weiß, das ist der „Ich gebe auf"-Knopf. Und der OP machte klar, dass er keine vollständigen VM-Backups hatte — nur Dateien.

Trotzdem gaben mehrere Antwortende zu, dass eine Neuinstallation die letzte sichere Route sein könnte, falls der Reparaturversuch scheitert und der Weg des Upgrades auf 9 abstürzt.

Warum selbst erfahrene Nutzer in diese Falle tappen

Viele Leute kommentierten mit einer Variante von:

„Moment … dist-upgrade ist der empfohlene Weg? Ich nutze apt upgrade schon seit einem Jahr."

Und das fasst irgendwie zusammen, warum das immer wieder passiert. Die Instinkte eines langjährigen Linux-Nutzers laufen den spezialisierten Regeln des Proxmox-Ökosystems tatsächlich zuwider. Der sicherere Debian-Befehl wird in dieser Umgebung zum gefährlichen.

Es gibt außerdem dieses kleine Detail: Proxmox selbst bündelt Upgrade-Werkzeuge wie:

• pveupdate
• pveupgrade

Aber viele Nutzer übersehen diese komplett, weil sich apt universell und vertraut anfühlt. Und weil Proxmox unter der Haube größtenteils einfach Debian ist, vergisst man leicht, dass manche Teile es nicht sind.

Das ergibt einen perfekten Sturm: ein Homelab-Setup, ein paar halb erinnerte Gewohnheiten, eine schnelle Automatisierungsanpassung, und plötzlich läuft Proxmox 8 mit den Kernel-Helpern von Proxmox 9 auf einem Debian-12-System, das glaubt, es sei halb Debian 13.

An diesem Punkt ist selbst das System verwirrt.

Die größere Lektion, zu der die Community immer wieder zurückkehrt

Der gesamte Thread unterstreicht etwas, das jede Menge Proxmox-Veteranen seit Jahren sagen:

Ihr Hypervisor ist nicht der Ort für Befehle aus Gewohnheit.

Das ist nicht wie ein Laptop-Update. Das ist nicht wie das Betreiben eines Webservers. Es ist eine ganze Orchestrierungsschicht, die unter Ihren VMs, Ihren Containern und in manchen Fällen Ihrem Speicher-Stack liegt.

Das bedeutet:

• Prüfen Sie immer Ihre Repos, bevor Sie updaten
• Nutzen Sie immer die von Proxmox empfohlenen Befehle
• Sichern Sie immer, bevor Sie ein Major-Upgrade durchführen
• Fahren Sie VMs immer herunter, bevor Sie tiefgreifende Upgrades durchführen
• Prüfen Sie alles, was Automatisierung berührt, immer dreifach

Denn die Ironie ist, dass ein einziger Tippfehler — buchstäblich eine Ein-Zeilen-Änderung — Stunden an Aufräumarbeit und die anhaltende Sorge verursachen kann, dass noch etwas anderes kaputt sein könnte.

Die stille Wahrheit: Das passiert öfter, als irgendjemand zugibt

Den Reaktionen nach zu urteilen, hat fast jeder in diesem Bereich genau diesen Fehler mindestens einmal gemacht. Manche entdeckten die dist-upgrade-Regel erst nach einem Schreckmoment. Andere sahen Abhängigkeiten kollabieren, nachdem sie apt upgrade ausgeführt hatten. Und jede Menge Leute gaben zu, nie bemerkt zu haben, dass die Proxmox-Docs ausdrücklich davor warnen, es zu benutzen.

Das ist eine dieser Mutproben. Die Art, die niemand will, der aber jeder irgendwann begegnet.

Und in gewisser Weise ist das der Grund, warum diese besondere Geschichte Anklang fand. Es ist nicht nur ein technisches Problem — es ist eine Erinnerung daran, dass selbst in einem Umfeld voller erfahrener Linux-Nutzer die Kleinigkeiten noch zählen. Die Tools, von denen man glaubt, sie am besten zu kennen, sind manchmal die, die am härtesten zubeißen.

Das Fazit für alle, die Proxmox betreiben

Wenn Sie sich sonst nichts merken, merken Sie sich das:

apt upgrade ist auf Proxmox nicht die sichere Option. apt dist-upgrade (oder full-upgrade) ist es.

Und falls Ihr System jemals anfängt, Pakete aus einem zukünftigen Release zu ziehen, halten Sie inne und prüfen Sie Ihre Repos dreifach, bevor Sie irgendetwas anderes anfassen.

Das ist der Unterschied zwischen einem sauberen Upgrade-Pfad und einem Wochenende, das damit verbracht wird, das Puzzle wieder zusammenzusetzen.

Denn in der Welt der Homelab-Hypervisoren sind es nie die katastrophalen Fehler, die einen erwischen. Es sind immer die stillen Fallen, die sich in den Befehlen verstecken, die man ausführt, ohne nachzudenken.