Skip to content

LILO makes the difference

Dieser Tage war mal wieder ein Kernelupdate einzuspielen. Normalerweise mache ich das Maschine für Maschine, um bei möglicherweise auftretenden Problemen nur ein System bis zur Lösung lahmzulegen, und eigentlich nie abend, wenn ich eigentlich nur noch ins Bett gehen sollte. Dieses Mal dachte ich mir, das könne ich "noch eben schnell" erledigen - famous last words. Und weil es schnell gehen sollte, habe ich den Update-Prozess mehr oder weniger gleichzeitig gestartet und die ersten beiden Maschinen dann auch parallel rebootet. Während ich dann darauf wartete, daß sie ordnungsgemäß wieder hochkommen, hatte ich die übrigen Updates durchlaufen lassen.

Nur … kamen die beiden rebooteten Maschinen nicht wieder hoch. Nada. Und natürlich handelte es sich dabei um gehostete Server, und natürlich um ältere solche, die über keine remote console verfügen. Nicht, daß mir das zwingend geholfen hätte.

Also hilft nur fluchen und ein Reboot in das sog. Rettungssystem, ein Minimal-Linux, das eine Untersuchung des Systems erlaubt. Und während ich noch grübelte und in den Logs nach möglichen Ursachen suchte, kam mir auch schon ein Gedanke - beides waren Altsysteme, die als Bootloader noch mit LILO, nicht grub, ausgestattet sind. Und ich konnte mich jedenfalls nicht bewußt erinnern, beim Upgrade irgendwelchen Output von LILO gesehen zu haben … Also die Partitionen ins Rettungssystem mounten, in das Echtsystem chrooten, lilo ausführen, unmounten, das Echtsystem rebooten und das beste hoffen.

Und, siehe da: das war die Lösung.

Jetzt frage ich mich nur: War das immer schon so, daß man bei einem Debian nach dem Kernelupdate von Hand lilo ausführen mußte? Oder wurde das früher - unter Sarge oder Lenny - nicht automatisch von einem postinstall-Script gemacht? *kopfkratz* Und wenn letzteres: wie stelle ich dieses Verhalten wieder her?

Aufräumen schafft Platz

/ lief voll.

Aufräumen hilft.

Nach dem - inzwischen auf allen Rechnern abgeschlossenen - Upgrade auf Debian Lenny beklagte ich unter anderem ein Volllaufen des Root-Filesystems auf einer Maschine, das ich damals bei der Einrichtung etwas arg knapp bemessen hatte. Mittlerweile stellte sich heraus, dass der verbliebene Platz noch nicht einmal mehr für das Einspielen von Kernel-Updates ausreichte; so geht das natürlich auf Dauer nicht.

Auf der Suche nach einer Lösung stellte ich dann - glücklicherweise - fest, dass der große Platzverbrauch seine Ursache vor allem darin hatte, dass von allen jemals aktiv gewesen Kernel noch die zugehörigen Module auf der Platte lagen, insgesamt vier Verzeichnisse voll. Nach Beseitigung eines dieser Modul-Verzeichnisse (zugehörig zu einem schon weggeputzten Kernel - sah es mit dem Platz dann schon viel, viel besser aus, und auch das Kernel-Update ließ sich brav installieren.

So soll es sein. :-)