Probleme mit vollen Boot-Partitionen

Auf immer mehr meiner Ubuntu-Server-Installationen mit automatischen täglichen Updates bin ich in letzter Zeit auf das Problem voller Boot-Partitionen gestoßen. Aus historischen Gründen richtet der Ubuntu-Installer standardmäßig eine eigene Boot-Partition für die Kernel-Dateien ein, obwohl dies in den meisten Fällen vollkommen überflüssig ist. Im Boot-Verzeichnis landet bei jedem Kernel-Update die gerade neueste Kernel-Version samt diverser Zusatzdateien.

Pro Kernel-Version beträgt der Platzbedarf unter Ubuntu 16.04 ca. 50 MByte, wobei die Initrd-Datei mit ca. 36 MByte der bei weitem wichtigste Faktor ist. Ubuntu 14.04 war hier noch sparsamer, dort fand man mit ca. 25 MByte pro Kernel das Auslangen (Initrd-Datei mit 20 MByte).

Ganz egal, wie groß die Boot-Partition ist: ohne Aufräumarbeiten läuft sie früher oder später voll. Das führt dazu, dass Kernel-Updates nicht mehr (richtig) installiert werden können. Mit etwas Pech hängt Ubuntu beim nächsten Reboot. Bei einer lokalen Maschine kann man dann im Grub-Menü einen älteren Kernel auswählen, damit booten und Aufräumarbeiten durchführen. Bei einem Server ist das aber viel schwieriger.

Analyse

df -h listet alle echten und virtuellen Dateisysteme auf. Die folgenden Daten stammen von einem Ubuntu-Server in einer virtuellen Maschine (KVM) mit einem nur 20 GByte großem Disk-Image. Spannend sind die Zeilen für das Root-Dateisystem (45% voll, d.h. alles OK) und für die Boot-Partition (100% voll, Vorsicht!):

df -h

Dateisystem             Größe Benutzt Verf. Verw% Eingehängt auf
udev                     477M       0  477M    0% /dev
tmpfs                    100M     11M   89M   11% /run
/dev/mapper/ub--vg-root   19G    7,8G  9,7G   45% /
tmpfs                    497M       0  497M    0% /dev/shm
tmpfs                    5,0M       0  5,0M    0% /run/lock
tmpfs                    497M       0  497M    0% /sys/fs/cgroup
/dev/vda1                236M    224M     0  100% /boot
tmpfs                    100M       0  100M    0% /run/user/1000

Die Boot-Partition wurde bei einem der letzten Kernel-Updates vollgeschrieben. Wenn Sie jetzt einen Reboot durchführen und ein wenig Pech haben, scheitert der Neustart!

Prävention

Es gibt viele Wege, dem Problem aus dem Weg zu gehen:

  • Keine automatisches Update: Wenn Sie Updates manuell durchführen, können Sie die Fehlermeldungen über eine volle /boot-Partition nicht übersehen. Aber je mehr Server Sie administrieren, desto nützlicher sind automatische Updates.

  • Eine ausreichend große Boot-Partition: Eine größere Boot-Partition mindert die Häufigkeit des Problems natürlich, wenn auch nicht dauerhaft. So wie die größte Festplatte irgendwann voll ist, gilt dies auch für die Boot-Partition 😉

  • Gar keine Boot-Partition: Bevor GRUB 2 sich durchgesetzt hat, war eine eigene Boot-Partitionen bei Server-Installationen eine Selbstverständlichkeit. GRUB 1 kam weder mit Software RAID noch mit LVM und (ohne Patches) nicht einmal mit ext4-Dateisystemen zurecht. Also speicherte man die Boot-Dateien in einer Partition ohne derartige Spezialitäten. GRUB 2 hat mit all dem überhaupt keine Probleme. Zwar gibt es auch heute noch Konfigurationsvarianten, bei denen eine eigene Boot-Partition notwendig oder zumindest empfehlenswert ist, bei typischen Server-Installation inkl. Software-RAID und LVM trifft dies aber nicht zu. Insofern spricht nichts dagegen, auf eine eigene Boot-Partition zu verzichten. Die Boot-Dateien landen dann einfach im /boot-Verzeichnis in der Systempartition. Da die Systempartition in aller Regel viel größer ist als die Boot-Partition, ist das Disk-full-Problem viel unwahrscheinlicher. Wie beim vorigen Tipp lässt sich auch dieser Ratschlag am einfachsten bei einer Neuinstallationen realisieren.

  • Monitoring: Mit einem vernünftigen Monitoring werden Sie rechtzeitig informiert, bevor die Boot-Partition voll läuft.

  • Remove-Unused-Dependencies: Die beste Lösung besteht darin, in der Datei /etc/apt/apt.conf.d/50unattended-upgrades die Option Remove-Unused-Dependencies auf true zu setzen. Dann kümmert sich unattended-upgrade selbst um apt-get autoremvoe und entfernt alle überflüssigen Pakete. Stellt sich nur die Frage, warum die Option nicht standardmäßig aktiv ist.

# in /etc/apt/apt.conf.d/50unattended-upgrades ändern
...
// Do automatic removal of new unused dependencies after the
// upgrade (equivalent to apt-get autoremove)
Unattended-Upgrade::Remove-Unused-Dependencies "true";

Krisenintervention

Wenn df -h /boot 100% liefert, die Boot-Partition also schon voll ist, ist Vorsicht angebracht. In diesem Fall sollten Sie zuerst einmal Aufräumarbeiten mit apt-get autoremove durchführen. Wenn dabei Fehler auftreten (filesystem full), wiederholen Sie das Kommando.

Selbst nachdem Sie nun wieder Platz in der Boot-Partition geschaffen haben, besteht weiterhin die Gefahr, dass der zuletzt installierte Kernel nicht korrekt bzw. nicht vollständig installiert wurde. Testen Sie zuerst, welche Kernel-Version aktuell läuft:

uname -r
4.4.0-47-generic

Die Pakete dieser Kernel-Version dürfen Sie auf keinen Fall anrühren!

Dann testen Sie, welche Kernel-Versionen sich aktuell in /boot befinden:

ls /boot/vmlinuz-4.4.0-*
  /boot/vmlinuz-4.4.0-47-generic  
  /boot/vmlinuz-4.4.0-57-generic  
  /boot/vmlinuz-4.4.0-59-generic

Alle Kernel-Versionen mit Ausnahme der aktuell laufenden Version (in diesem Beispiel 4.4.0-47) installieren Sie nun neu. Dabei wird die jeweilige Initrd-Datei neu generiert und die Grub-Konfigurationsdatei neu geschrieben.

apt-get install --reinstall linux-image-4.4.0-57-generic
  ...
  update-initramfs: Generating /boot/initrd.img-4.4.0-57-generic
  ...
  Grub-Konfigurationsdatei wird generiert
  ...

apt-get install --reinstall linux-image-4.4.0-59-generic
  ...
  update-initramfs: Generating /boot/initrd.img-4.4.0-59-generic
  ...
  Grub-Konfigurationsdatei wird generiert
  ...

Erst wenn das ohne Fehlermeldungen gelungen ist, können Sie mit reboot eine Neuinstallation wagen.

PS: Die ursprüngliche Version dieses Artikels habe ich auf kofler.info veröffentlicht. Dort wurde er auch mehrfach kommentiert.