prox03 hatte ein hartes Wochenende

Volles /boot am Morgen, kaputte APT-Repos am Nachmittag – prox03 hat sich dieses Wochenende ordentlich Aufmerksamkeit verdient.

Ausgangslage

Samstagmorgen der erste Warnschuss: prox03, einer meiner drei Proxmox-Cluster-Knoten, meldete eine volle /boot-Partition. Kaum war das erledigt, zeigte die Proxmox-Weboberfläche am Nachmittag Warnsymbole bei den APT-Repositories desselben Knotens. Zwei unabhängige Probleme, ein Server, ein Nachmittag.

Teil 1: /boot bei 100 %

Die /boot-Partition auf prox03 liegt auf NVMe-Storage (/dev/nvme0n1p2), gerade mal 456 MB gross – und war zu 100 %voll. Ursache: angesammelte Kernel-Versionen, ein Klassiker bei Proxmox mit seinem kleinen /boot.

Die Diagnose lief nach bewährtem Muster:

bash

dpkg -l | grep -E 'pve-kernel|proxmox-kernel'
uname -r

uname -r zeigte den laufenden Kernel als 7.0.14-6-pve. Damit war klar, welche Pakete bleiben mussten: die Meta-Pakete proxmox-kernel-6.17 und proxmox-kernel-7.0. Alles andere – konkret die alten versionierten, signierten Pakete proxmox-kernel-6.17.13-13-pve-signed, proxmox-kernel-7.0.6-2-pve-signed und proxmox-kernel-6.8.12-15-pve-signed – war Aufräum-Material.

Der Haken bei 100 % Belegung: apt purge allein hat oft keinen Platz mehr, um überhaupt zu arbeiten. Deshalb diesmal in dieser Reihenfolge:

1. Grosse initrd.img-Dateien der zu entfernenden Kernel manuell per rm -f löschen, um Platz zu schaffen
2. apt purge der alten Kernel-Pakete
3. apt --fix-broken install
4. apt autoremove
5. update-grub

Ergebnis: /boot ging von 100 % (444 MB belegt) auf 53 % (225 MB belegt, 206 MB frei) zurück. GRUB erkannte danach sauber nur noch die beiden verbliebenen Kernel (7.0.14-6-pve aktiv, 6.17.13-19-pve als Fallback).

Teil 2: APT-Repos in Konflikt

Kaum war /boot wieder im grünen Bereich, zeigte die Proxmox-Weboberfläche bei prox03 Warnsymbole im Bereich der APT-Quellen. Der Verdacht: veraltete oder doppelte Repository-Einträge.

Statt gleich loszulegen, erst mal die relevanten Dateien angeschaut:

• pve.list
• pve-enterprise.sources
• proxmox.sources

Das Bild dahinter: pve.list enthielt nur noch einen längst auskommentierten Bookworm-Ära-Eintrag – inaktiv, aber unnötiger Ballast. pve-enterprise.sources war dagegen aktiv, ohne ein explizites Enabled:-Feld – und damit faktisch scharf geschaltet, obwohl kein aktives Proxmox-Subscription-Abo besteht. proxmox.sources war die korrekte, aktive No-Subscription-Quelle für Trixie.

Das erklärte auch gleich einen bestehenden Fehler: 401 Unauthorized bei apt update, weil das System versuchte, die Enterprise-Quelle ohne gültiges Abo abzufragen.

Die Lösung in zwei Schritten:

bash

rm /etc/apt/sources.list.d/pve.list
sed -i '/^Components: pve-enterprise/a Enabled: false' /etc/apt/sources.list.d/pve-enterprise.sources

Damit war die alte Datei weg, und die Enterprise-Quelle sauber deaktiviert, statt nur „vergessen“ im System zu liegen. apt update lief danach ohne einen einzigen Fehler durch.

Bonus-Runde: die Cloud-Init-Passwort-Frage

Am Ende der Session kam noch eine altbekannte Frage zurück auf den Tisch: Warum fragen Debian-Cloud-Images manchmal nach einem Passwort, obwohl gar keines gesetzt wurde? Die Antwort dazu war bereits aus einer früheren Session bekannt und liess sich einfach wieder auffrischen: In der Regel liegt es nicht an einem versehentlich gesetzten Passwort, sondern daran, dass der SSH-Key via Cloud-Init nicht korrekt gelandet ist. Der dokumentierte Fix:

1. Temporäres Passwort im Cloud-Init-Tab setzen
2. Vollständigen Stop/Start-Zyklus auslösen (kein einfacher Reboot!)
3. Falls der Key danach immer noch fehlt: sudo cloud-init clean && sudo reboot, um einen kompletten frischen Cloud-Init-Durchlauf zu erzwingen

Lessons Learned

1. Ein volles /boot bei 100 % braucht zuerst manuellen Platz, bevor apt purge überhaupt greifen kann – grosse initrd.img-Dateien gezielt vorab löschen, dann erst purgen.
2. Meta-Pakete (proxmox-kernel-X.Y) bleiben, nur die alten versionierten, signierten Pakete fliegen raus. Diese Unterscheidung verhindert, dass man sich aus Versehen den aktuellen Kernel-Pfad kaputt macht.
3. Ein aktives pve-enterprise.sources ohne Enabled:-Feld ist scharf geschaltet – auch ohne Abo. Das führt direkt zu 401-Fehlern bei apt update, wenn keine gültige Subscription hinterlegt ist.
4. Alte .list-Dateien und neuere .sources-Dateien können nebeneinander existieren und sich widersprechen – beide Formate im Zweifel gegenprüfen, nicht nur eines der beiden.
5. Ein Cloud-Image, das nach einem Passwort fragt, hat fast immer ein SSH-Key-Problem, kein Passwort-Problem – ein Stop/Start-Zyklus (nicht Reboot!) reicht meistens, um Cloud-Init sauber neu greifen zu lassen.

Fazit

Zwei an sich unabhängige Probleme, aber beide am selben Knoten, am selben Nachmittag: erst ein zu kleines /boot, das mal wieder an seine Grenzen kam, dann veraltete APT-Quellen, die sich gegenseitig ins Gehege kamen. Nichts davon war kompliziert zu lösen – aber genau solche Häufungen erinnern daran, warum sich ein kurzer Blick in dpkg -l, apt-cache policyund die Repo-Dateien ab und zu lohnt, bevor die Weboberfläche einen mit Warnsymbolen überrascht.