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 besteht aus zwei Schritten. Ermitteln Sie, 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. Der laufende Kernel ist das Paket, das Sie nicht entfernen dürfen. Außerdem kann sich das System bereits in einem Zustand befinden, in dem apt überhaupt nicht mehr ausgeführt werden kann. Führen Sie daher zuerst eine Diagnose durch.

Das Fehlerbild

Eine Kernelversion installiert zwei große Dateien in /boot: den komprimierten Kernel (vmlinuz-<version>) und das initramfs (Initial-RAM-Dateisystem, initrd.img-<version>, das kleine Archiv, das der Kernel entpackt, bevor er das eigentliche root-Dateisystem einbindet). Das 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 Komprimierungsprogramms stammt aus COMPRESS= in /etc/initramfs-tools/initramfs.conf. Deshalb kann ein aktuelles Image zstd enthalten, während ein älteres gzip verwendet. Die beiden Zeilen, die dieses Problem erkennen lassen, sind No space left on device und die darunterstehende dpkg: error processing package-Zeile.

Danach bleibt das Paket teilweise 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 der über den Speicherplatz hinaus wichtige Teil: unattended-upgrades wird zeitgesteuert ausgeführt, trifft auf denselben Fehler und wird beendet. Der Server wirkt funktionsfähig und installiert Sicherheitsupdates stillschweigend nicht mehr. Außerdem schlägt jede von Ihnen gestartete, nicht zusammenhängende Installation mit derselben Zeile fehl. Die Ursache wird dann dem Paket zugeschrieben, das Sie gerade hinzufügen wollten. Deshalb lohnt es sich, eine unter Ubuntu fehlschlagende Tailscale-Installation zunächst als apt-Fehler zu betrachten. Wenn apt update bereits vorher fehlschlägt, handelt es sich um ein separates Problem, häufig um einen doppelten Eintrag nach der Migration der deb822-Quellen.

Prüfen, ob /boot eine separate Partition ist

Bevor Sie etwas löschen, ermitteln Sie, wie viel 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 benennt das Dateisystem, auf dem sich /boot tatsächlich befindet. 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 Platz. Der Befehl leert die heruntergeladenen .deb-Dateien unter /var/cache/apt/archives. Auf einem System mit einer echten /boot-Partition gibt apt clean dort überhaupt keinen Speicherplatz frei, weil sich der Cache auf einem anderen Dateisystem befindet.

Ermitteln Sie nun 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.

Laufenden Kernel ermitteln

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

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

Die zweite Datei ist nur vorhanden, wenn ein Paket einen Reboot angefordert hat. Eine linux-image-Zeile darin bedeutet, dass ein neuerer Kernel auf der Festplatte installiert, aber nicht verwendet wird, weil die Maschine seit der Installation nicht neu gestartet wurde. Starten Sie die Maschine vor der Bereinigung neu, sofern das möglich ist. apt schützt den laufenden Kernel und den neuesten Kernel. Wenn Sie mit einem alten Kernel arbeiten, bleibt dadurch eine weitere Version angepinnt, als erforderlich ist.

Kernel-Pakete auflisten und ihren Status prüfen

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

Das erste Feld ist der 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 fehlgeschlagene Upgrade oben. rc bedeutet, dass das Paket entfernt wurde, seine Konfiguration aber noch auf der Festplatte liegt. Das belegt in /boot keinen Speicherplatz und kann sicher mit purge entfernt werden.

Das zweite Feld zeigt, um welche Art von Paket es sich handelt. 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 dazu keine Warnung.

Die Pakete teilen sich wie folgt auf. 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. Wenn Sie die Header mit purge entfernen, wird daher Speicherplatz im Root-Dateisystem freigegeben, nicht jedoch Speicherplatz in /boot. Wenn Ihre Partition /boot voll ist, müssen Sie nach 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 betrachtet. Zu den geschützten Kerneln gehört der Kernel, den Sie aktuell ausführen. Die Aufbewahrungsrichtlinie hat sich zwischen den 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 anfasst. APT::VersionedKernelPackages ist die Liste der Namenspräfixe, die apt zunächst als versionierte Kernelpakete 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 Kernelpaket installiert wird. Eine manuelle Bearbeitung hat daher keinen dauerhaften Effekt: Bei der nächsten Kernelinstallation wird Ihre Änderung überschrieben. Bei Releases, bei denen die Datei fehlt, 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 richtige Antwort für Ihr Release.

Die Bereinigung, die Sie sicher ausführen können

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

--dry-run verändert nichts auf der Festplatte und gibt genau aus, was der tatsächliche Lauf entfernen würde. Lesen Sie die Liste. Zwei Dinge sollten Sie stoppen lassen. Ein Metapaket wie linux-generic oder linux-image-generic in der Entfernungsliste bedeutet, dass es als automatisch installiert markiert wurde. Wenn Sie es entfernen, enden Ihre Kernel-Updates. Die Zeichenfolge aus uname -r in der Entfernungsliste bedeutet, dass der laufende Kernel nicht geschützt ist. Das sollte nicht vorkommen. Sie müssen die Ursache untersuchen, bevor Sie fortfahren.

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

sudo apt autoremove --purge
df -h /boot

Die Option --purge 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. Das Menü sollte daher 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 stehen bleibt. Das ist eine mögliche Ursache für einen VPS, der nach einem Kernel-Update nicht bootet. Die Behebung über eine Rettungskonsole 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 unabhängig von seinem Alter nicht.

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

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

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 der vorgesehene Zustand, weil Sie diese Pakete selbst 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 notwendigen Schritte.

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

apt zeigt vor der Ausführung eine Liste der zu entfernenden Pakete an, weil linux-modules-extra-* vom Image-Paket abhängt und in derselben Transaktion entfernt werden muss. Diese Liste ist Ihre eigentliche Sicherheitsprüfung. Dort erkennen Sie, ob zusammen mit der gewünschten Version auch ein Meta-Paket entfernt werden soll. Antworten Sie mit n, wenn die Liste unerwartete Einträge enthält. 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 Speicher befindliche Kernel läuft weiter, nachdem seine Dateien gelöscht wurden. Deshalb scheint zunächst nichts auszufallen. Ausfallen kann alles, was der Kernel noch nicht geladen hat. Beim Bereinigen 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 Dateisystems, das dieser Kernel seit dem Booten noch nicht verwendet hat, schlägt dann fehl. Gleichzeitig ist /boot/vmlinuz-$(uname -r) nicht mehr vorhanden. Das Bootmenü bietet den laufenden Kernel daher nicht mehr an. Beim nächsten Reboot startet das System mit einer anderen Auswahl. Der Rechner verarbeitet weiterhin Netzwerkverkehr und ist bereits nicht mehr bootfähig. Prüfen Sie uname -r jedes Mal gegen die Liste der zu entfernenden Pakete.

Wenn /boot für die Ausführung von apt insgesamt zu voll ist

Das ist der Zustand, der dazu führt, dass Nutzer nach dieser Seite suchen. apt autoremove benötigt dpkg, um zuerst die Konfiguration des teilweise konfigurierten Kernelpakets abzuschließen. Dabei wird ein initramfs neu erstellt. Dafür wird Speicherplatz in einem /boot benötigt, der keinen freien Speicherplatz mehr hat. Durchbrechen Sie die Schleife einmalig 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 diese einzelne 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 absichtliche Ausnahme. Dadurch geht dpkg weiterhin davon aus, dass eine Datei vorhanden ist, obwohl sie nicht vorhanden ist. apt --fix-broken install schließt die fehlgeschlagene Konfiguration ab, sobald Speicherplatz für das initramfs verfügbar 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. In diesem Zeitraum kann das Menü noch auf die gerade gelöschte Datei verweisen. Wenn dpkg meldet, dass der Vorgang unterbrochen wurde, führt sudo dpkg --configure -a dieselbe Reparatur wie apt --fix-broken install aus.

Dieselbe Aufgabe 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.

Verhindern, dass das erneut passiert

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

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

Kommentieren Sie diese Zeilen ein, anstatt 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 übernommen hat, und überwachen Sie einen Lauf, bei dem nichts geändert wird:

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 fehlgeschlagen ist, wird dort daher lange angezeigt, bevor jemand bemerkt, dass auf dem System Patches fehlen. Die übrige Konfiguration wird unter automatischen Sicherheitsupdates auf Ubuntu behandelt.

Bevor der nächste Kernel installiert wird, 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 die Installation des nächsten Kernels genau wie oben beschrieben fehlschlagen. Beheben Sie das Problem daher jetzt und nicht erst während des Upgrades. Diese Prüfung ist neben Ihren anderen Prüfungen des Festplattenzustands auf einem VPS den kurzen Zeitaufwand wert. Besonders wichtig ist sie unmittelbar vor einem Release-Upgrade, weil das Upgrade von Ubuntu 24.04 auf 26.04 früh im Prozess einen neuen Kernel installiert. do-release-upgrade bricht ab, wenn /boot nicht über genügend freien Speicherplatz verfügt. Wenn Ihrem LTS-Server das Upgrade noch nicht angeboten wurde, liegt das am Zeitplan und nicht an einem Fehler. Ubuntu hält Upgrades von LTS auf LTS zurück, bis das Point-Release 26.04.1 veröffentlicht wird. Dadurch haben Sie ein bekanntes Zeitfenster, um /boot vorher in Ordnung zu bringen.

FAQ

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

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

Ist apt autoremove --purge auf einem Produktionsserver sicher?

Ja, sofern Sie zuerst den Dry Run prüfen. Führen Sie sudo apt autoremove --purge --dry-run aus. Dieser Befehl schreibt nichts, sondern zeigt die Liste an. Brechen Sie ab, wenn sie ein Meta-Paket wie linux-generic oder linux-image-generic enthält, da die künftigen Kernel-Updates nach der Entfernung eines solchen Pakets ausbleiben. Brechen Sie ebenfalls ab, wenn sie die Versionszeichenfolge enthält, die uname -r ausgibt. 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 fast sicher als manuell installiert markiert. autoremove betrifft nur Pakete, die als automatisch installiert markiert sind. Führen Sie apt-mark showmanual | grep -E '^linux-' aus. Jeder dort aufgeführte versionierte Kernel wurde irgendwann manuell installiert. Markieren Sie ihn mit sudo apt-mark auto linux-image-<version> als automatisch installiert und führen Sie den Dry Run erneut aus. Alternativ können Sie diese eine Version direkt mit sudo apt purge linux-image-<version> entfernen.

Kann ich Dateien manuell aus /boot löschen?

Nur als gezielte einmalige Maßnahme, wenn /boot so voll ist, dass apt das beschädigte Kernel-Paket nicht konfigurieren kann. Löschen Sie eine einzelne initrd.img-<version>-Datei, deren Version nicht der Ausgabe von uname -r 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 nachfolgenden Schritte löschen, verzeichnet dpkg weiterhin Pakete, deren Dateien nicht mehr vorhanden sind. Außerdem bleiben GRUB-Menüeinträge erhalten, die auf fehlende Dateien verweisen. Der Rechner fällt dann beim nächsten Reboot aus und nicht bereits in dem Moment, in dem der Fehler gemacht wurde.