Proxmox VE 9.2.22 bringt einen kleinen, aber betrieblich wichtigen Upgrade-Hinweis: Der pve8to9-Check warnt auf UEFI-Systemen vor einer nicht eingehängten EFI-Systempartition (ESP). Wer von PVE 8 auf PVE 9 wechselt, sollte deshalb nicht nur Pakete aktualisieren, sondern Bootpfad, Backup und Wiederanlauf vor dem Wartungsfenster prüfen.

Stand: 19.10.2026. Der Anlass ist konkret: Im offiziellen Quellcode wurde am 15.10.2026 die Version 9.2.22 gesetzt und der Upgrade-Checker um diese Warnung ergänzt. Laut Änderung kann ein UEFI-System nach einem Upgrade von PVE 8 auf PVE 9 nicht mehr starten, wenn die ESP während des GRUB-Updates nicht unter /boot/efi eingehängt war. Das ist kein Grund, jedes Upgrade aufzuschieben – aber ein guter Grund, es als Betriebsänderung statt als Routinebefehl zu behandeln.

Auf einen Blick

  • Proxmox VE 9.2.22 ergänzt den Upgrade-Check für PVE 8 nach PVE 9 um eine UEFI-/ESP-Warnung.
  • Eine fehlende Einhängung unter /boot/efi kann beim GRUB-Update zu einem Startproblem führen.
  • Betroffen ist der dokumentierte Sonderfall von UEFI-Systemen; Systeme mit proxmox-boot-tool behandelt der Check laut Änderung gesondert.
  • Vor dem Upgrade gehören Bootprüfung, getestetes Backup, Cluster-Status und ein Wartungsfenster zusammen.
  • Ein Update ist erst dann sauber abgeschlossen, wenn Workloads und Wiederanlauf geprüft sind.

Was ist der aktuelle Aufhänger?

Der offizielle pve-manager-Commit vom 15.10.2026 setzt die Version auf 9.2.22. Im selben aktuellen Entwicklungsstand wurde der pve8to9-Check erweitert: Auf einem UEFI-System soll er künftig warnen, wenn /boot/efi nicht eingehängt ist. Die Begründung im Commit ist eindeutig: Beim Upgrade von PVE 8 auf PVE 9 kann ein System nach einem GRUB-Update andernfalls nicht booten.

Wichtig ist die Einordnung: Ein Commit ist noch keine pauschale Aussage über jede Installation und ersetzt weder die offiziellen Release Notes noch einen Blick auf die eigene Hardware. Für Betriebsteams ist die Änderung dennoch wertvoll. Sie macht sichtbar, dass die Bootkette ein eigener Prüfpunkt ist – und nicht bloß ein Detail, das nach einem scheinbar erfolgreichen Paketlauf auffällt.

Warum ist die ESP vor dem Upgrade so wichtig?

Auf UEFI-Systemen liegt die Startinformation auf einer EFI-Systempartition. Ist diese beim Aktualisieren des Bootloaders nicht erreichbar, können Dateien an der falschen Stelle landen oder die erwartete Aktualisierung ausbleiben. Der Server kann dann zwar während des Wartungsfensters noch laufen, nach einem Neustart aber nicht wie geplant wiederkommen.

Für ein einzelnes Lab-System ist das ärgerlich. Für ein KMU-Cluster betrifft es schnell mehr: virtuelle Maschinen starten nicht automatisch, interne Dienste bleiben weg oder ein geplanter Knotenwechsel wird zum Incident. Deshalb gehört der Check nicht an das Ende einer Upgrade-Checkliste, sondern vor die Freigabe des Wartungsfensters.

Proxmox-Umgebungen sollten ohnehin als Verbindung aus Virtualisierung, Storage, Netzwerk, Monitoring und Dokumentation betrieben werden. Genau dabei unterstützt eine Proxmox-Betreuung mit Backup, Härtung und Runbooks: Nicht der einzelne Befehl steht im Mittelpunkt, sondern ein reproduzierbarer Ablauf für Änderungen und Störungen.

Die praktische Checkliste vor dem PVE-8-zu-PVE-9-Upgrade

Die folgenden Punkte sind keine Ersatzdokumentation. Sie helfen, die Herstelleranleitung in einen belastbaren Betriebsablauf zu übersetzen.

  1. Release Notes und Upgrade-Anleitung für den eigenen Ausgangsstand lesen. Die offizielle Upgrade-Anleitung von PVE 8 auf PVE 9 ist die maßgebliche Reihenfolge. Versionssprünge, Repositorys und Abhängigkeiten nicht aus alten Blogposts ableiten.
  2. Den Upgrade-Checker ausführen und jeden Hinweis bewerten. Die neue ESP-Warnung ist ein Beispiel dafür, warum ein sauberer Check mehr leistet als ein schneller Paketbefehl. Warnungen dokumentieren, Ursache klären und erst dann fortsetzen.
  3. Bootmodus und ESP kontrollieren. Bei UEFI prüfen, ob die erwartete EFI-Systempartition vorhanden, unter /boot/efi eingehängt und beim Start dauerhaft eingebunden ist. Wer unsicher ist, sollte diesen Punkt vor dem Wartungsfenster nachvollziehbar dokumentieren.
  4. Backup nicht nur als Jobstatus akzeptieren. Für kritische VMs oder Container einen Restore-Test einplanen. Ein grüner Backup-Job beantwortet nicht automatisch, ob Daten, Konfiguration und Startreihenfolge im Ernstfall wiederherstellbar sind. IT-Security und Betriebssicherheit beginnen genau bei solchen überprüfbaren Recovery-Schritten.
  5. Cluster und Abhängigkeiten prüfen. Quorum, Replikation, Storage-Zustand, Netzpfade und Reihenfolge der Knotenwartung gehören in den Plan. Bei einem Einzelknoten ist der Rückweg besonders wichtig; bei einem Cluster darf Hochverfügbarkeit nicht mit einem ungeprüften Upgrade verwechselt werden.
  6. Wartungsfenster und Rückfallplan festlegen. Verantwortliche, Kommunikationsweg, erwartete Dauer und Abbruchkriterium vorab definieren. Dazu gehört auch, wie ein physischer Konsolenzugang oder Out-of-Band-Management erreichbar ist, falls der Bootvorgang nicht durchläuft.

Was nach dem Upgrade verifiziert werden sollte

Ein erfolgreiches Paketende ist nur ein Zwischenergebnis. Nach dem Neustart sollte der Host erreichbar sein, die erwartete Proxmox-Version zeigen und Storage sowie Netzwerk sauber eingebunden haben. Danach folgen die Workloads: Starten die priorisierten VMs und Container? Sind Monitoring, Backup-Jobs und Benachrichtigungen wieder aktiv? Funktioniert ein gezielter Test der wichtigsten Anwendung?

Diese Prüfung sollte kurz im Runbook festgehalten werden. Sie spart beim nächsten Wartungsfenster Zeit und trennt belastbaren Betrieb von Wissen, das nur in einzelnen Köpfen steckt. Gerade für KMU ist das oft wirkungsvoller als zusätzliche Komplexität: ein schlanker Ablauf, der Boot, Backup, Monitoring und Rückfallweg verbindlich abdeckt.

Fazit

Die ESP-Warnung in Proxmox VE 9.2.22 ist ein konkreter Hinweis, dass Upgrades an der Bootkette scheitern können – auch wenn der Rest der Plattform modern und gut gepflegt ist. Wer von PVE 8 auf PVE 9 wechselt, sollte den pve8to9-Check ernst nehmen, UEFI und /boot/efi vorab prüfen und die Änderung mit getesteten Backups sowie einem klaren Rückfallplan durchführen. So wird aus einem Versionswechsel eine kontrollierte Wartung statt ein ungeplantes Recovery.

Quellen