Unattended-Upgrades auf Proxmox und Debian: die Paketliste, die nicht automatisch darf

unattended-upgrades bricht jede Änderung ab, bei der ein Paket entfernt werden müsste. Die eingebaute Plausibilitätsprüfung verwirft den Vorgang, sobald ein Paket zum Löschen vorgemerkt ist; das Paket, das die Entfernung gebraucht hätte, bleibt still liegen. Das ist genau das Verhalten von apt upgrade — und über diesen Modus wird die Proxmox-Administrationsanleitung deutlich: „performing an apt upgrade may result in a partially upgraded or broken package state“. Ein unbeaufsichtigter Lauf kann nicht auf full-upgrade umschalten; die Weigerung steckt im Programm, nicht in der Konfigurationsdatei.

Die Frage lautet deshalb nicht, ob man Proxmox automatisch aktualisieren darf, sondern: welchen Teil gibt man einem Werkzeug, das niemals ein Paket entfernt. Zurückgehaltene Pakete melden sich nicht — sie landen als Zeile in /var/log/unattended-upgrades/unattended-upgrades.log.

Zwei Herkünfte, zwei Entscheidungen

Die Quellen auf einem PVE-Host weisen sich unterschiedlich aus. Debian-Security veröffentlicht als Origin: Debian, Label: Debian-Security; das Proxmox-Repositorium als Origin: Proxmox, Label: Proxmox Debian Repository; und Ceph trägt ein eigenes Label, derzeit Proxmox Ceph 19 Squid Debian Repository. Ein Muster, das auf das Proxmox-Label zielt, erfasst Ceph also nicht, und umgekehrt. Nur Sicherheitsaktualisierungen, sonst nichts, sieht so aus:

Unattended-Upgrade::Origins-Pattern {
  "origin=Debian,codename=${distro_codename},label=Debian-Security";
  "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};

In der Vorlage, die das Paket mitbringt, ist eine dritte Zeile aktiv, die leicht übersehen wird: Sie endet auf label=Debian statt auf label=Debian-Security. Das ist das reguläre Stable-Archiv, nicht das Sicherheitsarchiv — wer sie stehen lässt, bekommt jede Debian-Zwischenversion über Nacht in einem Rutsch auf den Hypervisor. Diese eine Zeile ist der Unterschied zwischen reiner Sicherheitspflege und allem.

Die Sperrliste — und warum die naheliegende daneben liegt

Naheliegend ist eine Liste aus proxmox-ve, pve-kernel, pve-manager, qemu-server, pve-qemu-kvm und pve-container. Sie hat zwei Fehler. Erstens gibt es pve-kernel auf Proxmox VE 9 nicht mehr — dieser Zweig liefert proxmox-kernel-6.14, die signierten Einzelversionen und das Sammelpaket proxmox-default-kernel. Zweitens könnte keines dieser Pakete ohnehin angefasst werden, wenn dein Muster nur Debian-Security erlaubt: Sie stammen alle aus der Proxmox-Herkunft, genau wie zfsutils-linux, corosync, ifupdown2 und ceph-common. Auf einem PVE-Host sind das Proxmox-Pakete, keine Debian-Pakete. Eine Sperrliste verdient ihren Platz erst, wenn du origin=Proxmox bewusst erlaubst — und dann braucht jeder Eintrag eine Begründung:

Die Einträge sind reguläre Ausdrücke, die nur am Namensanfang greifen: libc6 nimmt auch libc6-dev mit, solange du nicht libc6$ schreibst. Für alles, was sich nie bewegen soll, ist apt-mark hold das robustere Mittel — es hält auch das full-upgrade auf, das du um zwei Uhr nachts selbst tippst.

Der Fehler vor dem ersten nächtlichen Neustart

Automatic-Reboot steht in der Vorgabe auf false, und wer es einschaltet, hat Automatic-Reboot-WithUsers in der Vorgabe auf true — die eigene offene Sitzung hält ihn nicht auf. Ausgelöst wird er von der Datei /var/run/reboot-required, und die schreibt unter Debian ein Kernel-Hook, den das Paket unattended-upgrades selbst mitbringt. Vor der Installation gab es sie nie; dass sie fehlt, belegt also nichts.

Und dann der Teil, der wirklich wehtut. Die Option onboot steht in der qm.conf wie in der pct.conf in der Vorgabe auf 0 — ein Gast startet beim Systemstart nur, wenn du es angeordnet hast. Ein Host, der um 02:00 neu startet, kommt mit jeder VM und jedem Container zurück, die jemand von Hand gestartet hatte: aus. Vorher prüfen, nicht nachher — grep -L '^onboot: 1' /etc/pve/qemu-server/*.conf /etc/pve/lxc/*.conf listet genau die Gäste, die nicht wiederkommen.

Auch die Uhrzeit führt in die Irre. Ausgelöst wird der Lauf vom apt-daily-upgrade.timer um 06:00, mit einer zufälligen Verzögerung von bis zu 60 Minuten; unattended-upgrades ruft danach shutdown mit deiner Automatic-Reboot-Time auf. Trägst du dort 02:00 ein, planst du den nächsten 02:00-Termin — neunzehn bis zwanzig Stunden mit installiertem neuem und laufendem altem Kernel.

needrestart läuft mit und tut nichts

Dienste starten nicht neu, wenn nur eine ihrer Abhängigkeiten aktualisiert wurde — dafür gibt es needrestart. Die mitgelieferte Konfiguration schreibt das Problem selbst hin: „If needrestart is configured to run in interactive mode but is run non-interactive (i.e. unattended-upgrades) it will fallback to list only mode.“ Die Vorgabe ist der interaktive Modus; auf einer unangetasteten Installation listet der automatische Lauf also die Dienste auf, die noch auf alten Bibliotheken sitzen, und startet keinen davon neu. $nrconf{restart} = 'a'; bringt ihn zum Handeln — auf einem Hypervisor eine bewusste Entscheidung, denn ein Speicher- oder Cluster-Dienst ist kein Webserver.

Ohne apt: dnf-automatic

Auf RHEL, Rocky und Alma heißt das Gegenstück dnf-automatic, konfiguriert in /etc/dnf/automatic.conf und eingeschaltet über dnf-automatic.timer (auf dnf5-Systemen dnf5-automatic.timer). Drei Schalter entscheiden: upgrade_type mit default oder security, apply_updates und reboot mit never, when-changed oder when-needed. Ein direktes Gegenstück zur Paketsperre gibt es nicht — excludepkgs ist in dnf eine Option je Repositorium, nichts, was in der automatic.conf steht. Sauberer Entwurf, stumpferes Werkzeug.

Was von Hand übrig bleibt

So eingerichtet hält der Host seine Debian-Hälfte selbst aktuell und rührt die Proxmox-Hälfte nicht an. Diese Trennung ist richtig — und sie bedeutet, dass die Proxmox-Hälfte jetzt daran hängt, dass jemand mitbekommt, dass es eine neue Version gibt. Proxmox betreibt dafür keine Ankündigungs-Mailingliste. Hak Proxmox VE und Debian im Katalog an, und du bekommst eine Mail, sobald eine neue Version erscheint — kostenlos, ohne Konto, Abmeldung mit einem Klick. Stand 19.08.2026 sind die neuesten erfassten Versionen Proxmox VE 9.2 (Herstellerdatum 21.05.2026) und Debian 13.6 (11.07.2026); derselbe Bestand führt für Proxmox VE 8 den 31.08.2026 als Support-Ende, und was sonst noch ausläuft, steht auf der End-of-Life-Seite. Der Katalog deckt auch die Klasse mit ab, die gar kein apt hat — Appliances und Firmware, wo es nichts zu konfigurieren gibt.

Die ehrliche Einschränkung

Das alles setzt voraus, dass das Sicherheitsarchiv für deine Ausgabe überhaupt noch liefert. Für Debian 12 — die Basis von Proxmox VE 8 — ist die reguläre Sicherheitspflege ausgelaufen, LTS trägt vom 11.06.2026 bis zum 30.06.2028, mit dem Vorbehalt, den das LTS-Team selbst ausspricht: Wie viele Pakete ordentlich betreut werden, hängt davon ab, wie viel Unterstützung das Team bekommt. Dein Origins-Pattern ändert sich dadurch nicht; was durch dieses Muster ankommt, schon. Und Automatisierung ohne Hinsehen ist eine Gewohnheit, keine Absicherung — lass vor der ersten scharfen Nacht einmal unattended-upgrade --dry-run --debug laufen und lies danach das Protokoll oder setze Unattended-Upgrade::Mail.

Optionsnamen, Vorgabewerte und die Plausibilitätsprüfung aus unattended-upgrades 2.12 in der Fassung von Debian 13; needrestart 3.11-1; Timer-Werte aus apt 3.0.3. Origin und Label aus den Release-Dateien von security.debian.org und download.proxmox.com, abgerufen am 19.08.2026, Proxmox-Paketnamen aus dem trixie-Zweig von pve-no-subscription am selben Tag. onboot-Vorgaben aus den Proxmox-VE-Handbuchseiten zu qm.conf und pct.conf. patchletter-Zahlen aus dem eigenen Bestand, Stand: 19.08.2026.