Alte Kernel entfernen und /boot unter Ubuntu freigeben

Warum apt nicht mehr funktioniert, wenn /boot mit alten Kerneln voll läuft

Unter Ubuntu schreibt jedes Kernel-Update einen neuen Satz von Dateien nach /boot und lässt die vorherigen Dateien dort liegen. Dadurch läuft eine kleine /boot-Partition voll, und apt kann eine Installation nicht mehr abschließen. Die Reparatur erfolgt in zwei Schritten. Ermitteln Sie zunächst, welche Pakete auf dem System Kernel sind und mit welchem Kernel das System gestartet wurde. Entfernen Sie anschließend die übrigen Pakete mit apt autoremove --purge.

Die Reihenfolge ist wichtig. Den laufenden Kernel dürfen Sie nicht entfernen. Außerdem kann sich das System bereits in einem Zustand befinden, in dem apt überhaupt nicht mehr ausgeführt werden kann. Führen Sie zuerst eine Diagnose durch.

Wie der Fehler tatsächlich aussieht

Eine Kernelversion installiert zwei große Dateien in /boot: den komprimierten Kernel (vmlinuz-<version>) und die initramfs (Initial-RAM-Dateisystem, initrd.img-<version>, das kleine Archiv, das der Kernel entpackt, bevor er das eigentliche Root-Dateisystem einbindet). Die initramfs wird zum Installationszeitpunkt auf Ihrem Rechner erstellt. Deshalb benötigt die Installation freien Speicherplatz und nicht nur Bandbreite für den Download. Wenn kein Speicherplatz mehr vorhanden ist, schlägt der Build fehl und reißt das Paket mit sich.

update-initramfs: Generating /boot/initrd.img-6.8.0-64-generic
gzip: stdout: No space left on device
E: mkinitramfs failure gzip 1
update-initramfs: failed for /boot/initrd.img-6.8.0-64-generic with 1.
dpkg: error processing package linux-image-6.8.0-64-generic (--configure):
 installed linux-image-6.8.0-64-generic package post-installation script subprocess returned error exit status 1

Die Versionszeichenfolge ist bei Ihnen eine andere. Der Name des Komprimierers stammt aus COMPRESS= in /etc/initramfs-tools/initramfs.conf. Deshalb kann ein aktuelles Image zstd nennen, während ein älteres gzip nennt. Die beiden Zeilen, die dieses Problem kennzeichnen, sind No space left on device und die darunterstehende dpkg: error processing package-Zeile.

Danach bleibt das Paket halb konfiguriert. Jeder spätere apt-Aufruf versucht erneut, es zu konfigurieren, schlägt auf dieselbe Weise fehl und endet mit E: Sub-process /usr/bin/dpkg returned an error code (1). Das ist über den fehlenden Speicherplatz hinaus der entscheidende Punkt: unattended-upgrades wird nach seinem Zeitplan ausgeführt, stößt auf denselben Fehler und beendet sich. Der Server wirkt weiterhin funktionsfähig und installiert stillschweigend keine Sicherheitsupdates mehr. Außerdem schlägt jede unabhängige Installation, die Sie versuchen, mit derselben Zeile fehl. Die Ursache wird dann dem Paket zugeschrieben, das Sie gerade hinzufügen wollten. Deshalb lohnt es sich, eine an einem apt-Fehler scheiternde Tailscale-Installation unter Ubuntu zuerst als apt-Fehler zu lesen. Wenn apt update bereits vorher fehlschlägt, handelt es sich um ein separates Problem, häufig um einen doppelten Eintrag nach der Migration zu den deb822-Quellen.

Prüfen, ob /boot eine eigene Partition ist

Ermitteln Sie vor dem Löschen, welchen Speicherplatz Sie tatsächlich freigeben.

findmnt /boot
findmnt -T /boot
df -h /boot /

Der erste Befehl gibt nur dann eine Zeile aus, wenn /boot ein eigener Mountpoint ist. Der zweite gibt immer eine Zeile aus und nennt das Dateisystem, auf dem /boot tatsächlich liegt. Wenn beide dasselbe Dateisystem wie / nennen, ist /boot lediglich ein Verzeichnis im Root-Dateisystem und kann nicht eigenständig voll laufen: Ihr Root-Dateisystem ist voll, und alte Kernel sind nur eine von mehreren Ursachen. In diesem Fall schafft sudo apt clean, das die heruntergeladenen .deb-Dateien unter /var/cache/apt/archives leert, wieder freien Speicherplatz. Auf einem Rechner mit einer echten /boot-Partition gibt apt clean dort überhaupt keinen Speicherplatz frei, weil sich der Cache auf einem anderen Dateisystem befindet.

Ermitteln Sie jetzt den Wert, mit dem Sie weiterarbeiten.

df -h /boot
ls -lh /boot/vmlinuz-$(uname -r) /boot/initrd.img-$(uname -r)

Vergleichen Sie die Spalte Avail mit der Größe dieser beiden Dateien. Die Initrd ist die größere Datei. Das nächste Kernel-Update benötigt Platz für ein weiteres Paar von ungefähr dieser Größe. Wenn Avail kleiner als die aktuelle Initrd ist, wird das nächste Update bereits fehlschlagen.

Ermitteln Sie den laufenden Kernel

uname -r
cat /var/run/reboot-required.pkgs

uname -r gibt den Release-String des aktuell im Speicher geladenen Kernels aus. Kopieren Sie diesen String an einen sicheren Ort. Diese Version dürfen Sie keinesfalls entfernen.

Die zweite Datei existiert nur, wenn ein Paket einen Neustart angefordert hat. Eine linux-image-Zeile darin bedeutet, dass ein neuerer Kernel auf dem Datenträger installiert, aber nicht verwendet wird, weil die Maschine seit der Installation nicht neu gestartet wurde. Starten Sie die Maschine nach Möglichkeit neu, bevor Sie die Bereinigung durchführen. apt schützt den laufenden Kernel und den neuesten Kernel. Wenn Sie also einen alten Kernel ausführen, bleibt dadurch eine zusätzliche Version festgehalten.

Kernel-Pakete auflisten und ihren Status prüfen

dpkg --list | grep -E 'linux-(image|modules|headers|tools)' | awk '{print $1, $2}'

Das erste Feld enthält den Statuscode von dpkg. ii bedeutet, dass das Paket installiert und konfiguriert ist. iF bedeutet, dass es installiert, aber nur teilweise konfiguriert ist. Genau diesen Zustand hinterlässt das oben fehlgeschlagene Upgrade. rc bedeutet, dass das Paket entfernt wurde, seine Konfiguration aber noch auf der Festplatte liegt. Es belegt keinen Speicherplatz in /boot und kann gefahrlos mit purge entfernt werden.

Das zweite Feld gibt den Pakettyp an. Ein Name mit einer Versionsnummer, beispielsweise linux-image-6.8.0-64-generic, bezeichnet einen bestimmten Kernel. Ein Name ohne Versionsnummer, beispielsweise linux-image-generic, linux-headers-generic oder linux-generic, bezeichnet ein Meta-Paket. Es enthält keinen Kernel. Seine einzige Aufgabe besteht darin, vom neuesten versionierten Kernel abzuhängen, damit apt upgrade neue Kernel installiert. Wenn Sie ein Meta-Paket entfernen, erhält der Rechner keine Kernel-Updates mehr. Danach gibt es keine Warnung.

Die Paketgruppen sind wie folgt aufgeteilt. linux-image-* enthält das komprimierte Kernel-Image in /boot. linux-modules-* und linux-modules-extra-* enthalten die Treiber unter /lib/modules. linux-headers-* enthält Build-Header unter /usr/src. Beim Entfernen der Header wird daher Speicherplatz im Root-Dateisystem frei, nicht in /boot. Wenn Ihre /boot-Partition voll ist, müssen Sie nach den Image-Paketen suchen.

ls -1 /boot/vmlinuz-*
ls -1 /lib/modules/

Diese beiden Auflistungen sollten untereinander und mit der Ausgabe von dpkg --list übereinstimmen. Ein Verzeichnis in /lib/modules ohne passendes installiertes Paket ist ein Überbleibsel davon, dass jemand Dateien manuell gelöscht hat.

Wie apt entscheidet, welche Kernel behalten werden

apt autoremove entfernt keinen Kernel, den es als geschützt einstuft. Zur geschützten Menge gehört auch der aktuell ausgeführte Kernel. Die Aufbewahrungsrichtlinie hat sich zwischen Ubuntu-Releases geändert. Lesen Sie sie daher auf Ihrem eigenen System aus, statt einer irgendwo notierten Zahl zu vertrauen.

apt-config dump | grep -i -e neverautoremove -e versionedkernel
ls -l /etc/apt/apt.conf.d/01autoremove /etc/apt/apt.conf.d/01autoremove-kernels

APT::NeverAutoRemove ist die Liste der Paketnamensmuster, die apt autoremove nicht verändert. APT::VersionedKernelPackages ist die Liste der Namenspräfixe, die apt zunächst als versionsgebundene Kernel-Pakete behandelt. Bei Releases, die /etc/apt/apt.conf.d/01autoremove-kernels erzeugen, wird diese Datei von /etc/kernel/postinst.d/apt-auto-removal jedes Mal neu geschrieben, wenn ein Kernel-Paket installiert wird. Eine manuelle Bearbeitung hat daher keinen dauerhaften Effekt: Bei der nächsten Kernel-Installation wird Ihre Änderung überschrieben. Bei Releases ohne diese Datei wendet apt denselben Schutz intern an. In beiden Fällen zeigt apt-config dump die auf Ihrem System geltenden Regeln an. Diese Ausgabe ist die maßgebliche Antwort für Ihr Release.

Die gefahrlos ausführbare Bereinigung

sudo apt update
sudo apt autoremove --purge --dry-run

--dry-run ändert nichts auf der Festplatte und gibt genau aus, was der echte Lauf entfernen würde. Lesen Sie die Liste. Zwei Dinge sollten Sie anhalten lassen. Ein Metapaket wie linux-generic oder linux-image-generic in der Entfernungsliste bedeutet, dass es als automatisch installiert markiert wurde. Seine Entfernung beendet Ihre Kernel-Updates. Die Zeichenfolge aus uname -r in der Entfernungsliste bedeutet, dass der laufende Kernel nicht geschützt ist. Das sollte nicht vorkommen und muss untersucht werden, bevor Sie fortfahren.

Wenn die Liste korrekt aussieht, führen Sie den Befehl tatsächlich aus.

sudo apt autoremove --purge
df -h /boot

Die --purge-Variante entfernt neben dem Paket auch die verbliebene Konfiguration. Sie gibt nur wenig zusätzlichen Speicherplatz frei. Außerdem verhindert sie, dass sich in dpkg --list immer mehr rc-Zeilen ansammeln. Dadurch bleibt das nächste Audit lesbar.

Prüfen Sie anschließend, ob das Bootmenü neu erstellt wurde. Beim Entfernen eines Kernelpakets wird update-grub automatisch ausgeführt. Daher sollte das Menü nur auf Dateien verweisen, die noch vorhanden sind.

sudo grep -o 'vmlinuz-[^ ]*' /boot/grub/grub.cfg | sort -u
ls -1 /boot/vmlinuz-*

Jede Version aus der ersten Ausgabe muss in der zweiten Ausgabe erscheinen. Ein Menüeintrag, der auf eine nicht mehr vorhandene Datei verweist, kann aus einem funktionierenden Server einen Server machen, der an der GRUB-Eingabeaufforderung anhält. Das ist ein möglicher Weg zu einem VPS, der nach einem Kernel-Update nicht bootet. Eine Behebung über eine Rescue-Konsole ist deutlich schwieriger, als das Problem hier zu vermeiden.

Warum apt autoremove manchmal nichts entfernt

apt autoremove entfernt nur Pakete, die als automatisch installiert markiert sind. Das sind Pakete, die als Abhängigkeit eines anderen Pakets installiert wurden. Einen Kernel, den Sie selbst mit apt install linux-image-6.8.0-40-generic installiert haben, markiert apt als manuell installiert. autoremove entfernt ihn daher nie, unabhängig davon, wie alt er ist.

apt-mark showmanual | grep -E '^linux-'

Jeder versionierte Kernel in dieser Ausgabe ist für autoremove unsichtbar. Übergeben Sie ihn erneut und verwenden Sie die Versionszeichenfolgen aus Ihrer eigenen Auflistung:

sudo apt-mark auto linux-image-6.8.0-40-generic linux-modules-6.8.0-40-generic
sudo apt autoremove --purge --dry-run

Lassen Sie die Meta-Pakete als manuell installiert markiert. Das ist beabsichtigt, weil Sie diese Pakete ausdrücklich angefordert haben.

Einen bestimmten Kernel gezielt entfernen

Manchmal soll eine bestimmte Version sofort entfernt werden, statt erst dann, wenn die Richtlinie dies zulässt. Geben Sie das Image-Paket an. apt ermittelt die übrigen erforderlichen Schritte.

sudo apt purge linux-image-6.8.0-40-generic

apt gibt vor der Ausführung eine Entfernungsliste aus. linux-modules-extra-* hängt vom Image-Paket ab und muss daher in derselben Transaktion entfernt werden. Diese Liste ist Ihre eigentliche Sicherheitsprüfung. Hier erkennen Sie, ob zusammen mit der vorgesehenen Version auch ein Meta-Paket entfernt werden soll. Beantworten Sie die Abfrage mit n, wenn etwas Unerwartetes in der Liste steht. Führen Sie anschließend sudo apt autoremove --purge aus, um die Modul- und Header-Pakete zu ermitteln, die nun nicht mehr benötigt werden.

Warum Sie den laufenden Kernel niemals entfernen

Der bereits im Arbeitsspeicher geladene Kernel läuft weiter, nachdem seine Dateien gelöscht wurden. Deshalb scheint zunächst nichts auszufallen. Betroffen ist jedoch alles, was der Kernel noch nicht geladen hat. Durch das Entfernen von linux-modules-$(uname -r) wird /lib/modules/$(uname -r)/ gelöscht. Der nächste Ladevorgang eines Moduls schlägt daher fehl:

modprobe: FATAL: Module nf_tables not found in directory /lib/modules/6.8.0-64-generic

Ab diesem Zeitpunkt schlägt das Neuladen der Firewall fehl. Auch das Einhängen eines Dateisystemtyps, den dieser Kernel seit dem Booten noch nicht verwendet hat, schlägt fehl. Gleichzeitig ist /boot/vmlinuz-$(uname -r) nicht mehr vorhanden. Das Bootmenü bietet den aktuell laufenden Kernel daher nicht mehr an. Beim nächsten Reboot startet das System mit einem anderen Kernel. Der Rechner verarbeitet weiterhin Netzwerkverkehr und ist bereits nicht mehr bootfähig. Vergleichen Sie uname -r jedes Mal mit der Liste der zu entfernenden Pakete.

Wenn /boot für die Ausführung von apt vollständig belegt ist

Das ist der Zustand, der Nutzer auf diese Seite führt. apt autoremove benötigt dpkg, um zuerst die Konfiguration des teilweise konfigurierten Kernel-Pakets abzuschließen. Dieser Schritt erstellt ein initramfs und benötigt dafür Speicherplatz in einem /boot, in dem kein Platz mehr vorhanden ist. Durchbrechen Sie die Schleife einmal manuell.

uname -r
ls -1 /boot/initrd.img-*

Wählen Sie ein initrd aus, dessen Version nicht der von uname -r ausgegebenen Zeichenfolge entspricht, und löschen Sie nur diese eine Datei.

sudo rm /boot/initrd.img-6.8.0-40-generic
sudo apt --fix-broken install
sudo apt autoremove --purge
sudo update-grub

Jede Zeile hat einen bestimmten Zweck. rm ist eine bewusste Ausnahme. Dadurch geht dpkg davon aus, dass eine Datei vorhanden ist, obwohl sie fehlt. apt --fix-broken install schließt die fehlgeschlagene Konfiguration ab, sobald wieder Platz für das initramfs vorhanden ist. autoremove --purge entfernt anschließend das Paket, zu dem die gelöschte Datei gehört, zusammen mit den anderen alten Versionen. Dadurch stimmt dpkg wieder mit dem Inhalt des Datenträgers überein. update-grub erstellt das Menü anhand der tatsächlich vorhandenen Dateien neu. Starten Sie zwischen rm und update-grub keinen Reboot, weil das Menü in diesem Zeitraum noch auf die gerade gelöschte Datei verweisen kann. Wenn dpkg meldet, dass der Vorgang unterbrochen wurde, führt sudo dpkg --configure -a dieselbe Reparatur wie apt --fix-broken install durch.

Der gleiche Vorgang auf dnf-Systemen

Wenn Ihr VPS Fedora oder eine der RHEL-Neuimplementierungen wie Rocky Linux verwendet, ist der Mechanismus umgekehrt. Debian und Ubuntu schützen Kernel mit apt-Autoremove-Regeln und überlassen die Bereinigung Ihnen oder unattended-upgrades, während dnf eine Anzahl namens installonly_limit erzwingt und den ältesten Kernel automatisch entfernt, sobald eine neue Installation diesen Wert überschreiten würde. Lesen Sie den aktuell geltenden Wert mit grep installonly_limit /etc/dnf/dnf.conf und man 5 dnf.conf aus und löschen Sie einen vorhandenen Rückstand mit sudo dnf remove --oldinstallonly. Auch dort ist der laufende Kernel geschützt. Eine umfassendere Zuordnung zwischen den beiden Paketmanagern finden Sie unter den Entsprechungen der dnf- und apt-Befehle.

Wiederholungen verhindern

Eine Bereinigung, die davon abhängt, dass Sie sich daran erinnern, schlägt irgendwann fehl. Konfigurieren Sie sie daher dort, wo die Kernel installiert werden. Öffnen Sie /etc/apt/apt.conf.d/50unattended-upgrades und suchen Sie nach diesen Schlüsseln. Die ausgelieferte Datei enthält sie bereits als auskommentierte Zeilen:

Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

Entfernen Sie die Kommentarzeichen, statt am Ende eine zweite Kopie anzuhängen. In der apt-Konfiguration gilt die letzte Zuweisung eines Schlüssels. Ein Duplikat führt daher zu widersprüchlichen Angaben und macht unklar, welcher Wert tatsächlich verwendet wird. Prüfen Sie, welchen Wert der Parser ermittelt hat, und beobachten Sie einen Lauf, der nichts ändert:

apt-config dump | grep -i 'Unattended-Upgrade::Remove'
sudo unattended-upgrade --dry-run --debug
sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log

Das Log liefert den Nachweis. Es zeichnet jeden Lauf auf. Ein Upgrade, das wegen fehlenden Speicherplatzes fehlschlägt, wird dort daher erfasst, lange bevor jemand bemerkt, dass auf dem Rechner Patches fehlen. Der übrige Teil dieser Konfiguration wird unter automatische Sicherheitsupdates unter Ubuntu behandelt.

Vor der Installation des nächsten Kernels müssen Sie eine Zahl prüfen. Dafür verwenden Sie dasselbe Befehlspaar wie am Anfang dieser Anleitung:

df -h /boot
ls -lh /boot/initrd.img-$(uname -r)

Wenn Avail nicht deutlich größer als diese Datei ist, wird der nächste Kernel genau wie oben beschrieben fehlschlagen. Beheben Sie das Problem daher jetzt und nicht während des Upgrades. Diese Prüfung dauert neben Ihren anderen Prüfungen des Festplattenzustands auf einem VPS nur eine Minute. Besonders wichtig ist sie unmittelbar vor einem Release-Upgrade. Der Wechsel von Ubuntu 24.04 auf 26.04 installiert früh im Ablauf einen neuen Kernel, und do-release-upgrade bricht ab, wenn in /boot nicht genügend Speicherplatz verfügbar ist.

FAQ

Warum behält Ubuntu alte Kernel, statt sie zu löschen?

Weil ein Kernel, der nicht bootet, keine andere Auswahlmöglichkeit lässt. Wenn die vorherige Version erhalten bleibt, kann ein fehlerhaftes Update über das GRUB-Menü statt über die Rescue-Konsole des Providers behoben werden. apt schützt daher eine Gruppe von Kernelpaketen vor der automatischen Entfernung und schließt immer den aktuell ausgeführten Kernel ein. Führen Sie apt-config dump | grep -i neverautoremove aus, um die genauen Muster anzuzeigen, die Ihre Version schützt, da sich diese Richtlinie zwischen den Versionen geändert hat.

Ist apt autoremove --purge auf einem Produktionsserver sicher?

Ja, sofern Sie zuerst den Probelauf prüfen. Führen Sie sudo apt autoremove --purge --dry-run aus. Dieser Befehl schreibt nichts, sondern zeigt die geplante Paketliste an. Brechen Sie ab, wenn darin ein Meta-Paket wie linux-generic oder linux-image-generic enthalten ist, da die zukünftige Kernelaktualisierung endet, wenn eines dieser Pakete entfernt wird. Brechen Sie ebenfalls ab, wenn die von uname -r ausgegebene Versionszeichenfolge enthalten ist. Wenn keines von beiden vorkommt, handelt es sich bei den zu entfernenden Paketen um alte Kernel und verwaiste Abhängigkeiten.

apt autoremove hat nichts entfernt, und /boot ist weiterhin voll. Was nun?

Die alten Kernel sind mit hoher Wahrscheinlichkeit als manuell installiert markiert. autoremove bearbeitet nur Pakete, die als automatisch installiert markiert sind. Führen Sie apt-mark showmanual | grep -E '^linux-' aus. Jede dort aufgeführte versionierte Kernelversion wurde irgendwann manuell installiert. Markieren Sie sie mit sudo apt-mark auto linux-image-<version> als automatisch installiert und führen Sie den Probelauf erneut aus. Alternativ können Sie diese Version direkt mit sudo apt purge linux-image-<version> vollständig entfernen.

Kann ich Dateien manuell aus /boot löschen?

Nur als gezielte einmalige Maßnahme, wenn /boot so voll ist, dass apt das fehlerhafte Kernelpaket nicht konfigurieren kann. Löschen Sie genau eine initrd.img-<version>-Datei, deren Version nicht der von uname -r ausgegebenen Version entspricht. Führen Sie anschließend sofort sudo apt --fix-broken install, sudo apt autoremove --purge und sudo update-grub aus. Wenn Sie Dateien ohne diese Folgeschritte löschen, verzeichnet dpkg weiterhin Pakete, deren Dateien fehlen. Außerdem bleiben GRUB-Menüeinträge bestehen, die auf nicht vorhandene Dateien verweisen. Der Rechner fällt dann beim nächsten Reboot aus und nicht bereits in dem Moment, in dem Sie den Fehler gemacht haben.