Langes Warten bei Linux-Neustarts kann ziemlich lästig sein. Schuld sind die vielen Stufen des Bootprozesses. Der Kexec-Trick des Kernels umgeht sie und spart damit etwas Bootzeit ein. Als zusätzliches Schmankerl macht er Crash-Dumps möglich.

Zwei Anwendergruppen profitieren besonders von der Beschleunigung des Reboots: erstens Entwickler, die ihren neuen Kernel zum Testen booten, und zweitens jene Admins, die einen neuen Kernel installiert und mit möglichst kurzer Downtime gebootet haben wollen. Hierbei können rund 15 einsparbare Sekunden durchaus ein gewichtiges Argument sein, wenn jeder Stillstand des Servers eine Menge Geld kostet. Mit dem Kexec-Mechanismus [1] bietet Linux eine simple Möglichkeit an, einen Reboot schneller zu gestalten.

Restart im Kernel

Die Kexec-Patches gibt es bereits seit über drei Jahren. Mit Kernel 2.6.13 hat Linus Torvalds den Mechanismus endlich in den Standardkernel übernommen. Wurde ursprünglich nur die I-386-Architektur unterstützt, so beherrscht Linux diesen Mechanismus mittlerweile auch auf den AMD64- sowie PPC-, PPC64-, IA64- und S390-Architekturen.

Die hier vorgestellte Technik lässt sich außerdem nutzen, um im Fall eines Kernelabsturzes einen Crash-Dump zu schreiben. Diesen Speicherabzug erstellt ein im Speicher geparkter Kernel, der die Daten entweder auf die lokale Platte schreibt oder per Netzwerk auf einen anderen Rechner überträgt.

Mit Hilfe solcher Daten identifizieren die Linux-Entwickler die Ursache für den Absturz und steigern längerfristig die Stabilität des Kernels. Diese Technik firmiert in der Linux-Welt unter dem Namen Kdump (siehe Kasten “Crash-Dumps”).

Das Bios beim Booten übergehen spart bei jedem Neustart etwas Zeit. Die obere Hälfte der Abbildung 1 zeigt die Abläufe im Rechner beim normalen Boot- respektive Reboot-Vorgang. Dabei lädt das Bios den ersten Block eines bootbaren Mediums – meist den ersten Block der Festplatte – und startet das dort in den ersten 422 Bytes abgelegte Programm, den First Stage Bootloader. Der interpretiert die ebenfalls im ersten Block abgelegte Partitionstabelle.

Die Partitionstabelle enthält unter anderem die Information, in welcher Partition sich ein weiterer Bootloader befindet, nämlich jener, der das zu startende System lädt. Dieser so genannte Second Stage Bootloader lädt schließlich den Betriebssystemkern und übergibt ihm die Programmkontrolle.

Der untere Teil in Abbildung 1 skizziert den verkürzten Reboot-Vorgang. Das Bios sowie die beiden Bootloader sind nicht mehr beteiligt. Stattdessen parkt der Kexec-Mechanismus den zu ladenden Kernel an einem freien Speicherbereich im Hauptspeicher.

Kommando-Übergabe

Soll ein Reboot das geparkte Betriebssystem aktivieren, übernimmt Kexec das Kommando und überschreibt den Code des zuletzt aktiven Betriebssystemkerns mit dem geparkten Kernel. Ist dieser Vorgang abgeschlossen, übergibt Kexec ihm die Kontrolle: Das neue System bootet. Der Umweg über die Parkposition ist notwendig, weil der eigentlich für den Kernelcode vorgesehene Speicher vom gerade aktiven Kernel belegt ist.

Vor dem Genuss des schnellen Reboots muss der Admin zunächst das System für den schnellen Kernelwechsel vorbereiten. Ist dies erledigt, muss Kexec vor dem eigentlichen Reboot noch einen neuen Kernel im Speicher ablegen und danach aktivieren. Abbildung 2 zeigt die Vorbereitung des Systems.

Der beschleunigte Reboot setzt einen aktuellen Kernel voraus, der das Kexec-Feature unterstützt. Bei der Kernelkonfiguration sind die folgenden drei Optionen zu setzen:

• »CONFIG_KEXEC=y«: Diese Option integriert den
  Kexec-Systemcall in den Kernel. Sie findet sich in der
  Konfiguration unter dem Menüpunkt »Processor type and
  features« (siehe Abbildung 3).
• »CONFIG_PHYSICAL_START=0x100000« ist ebenfalls
  unter »Processor type and features« zu finden. Sie legt
  die Adresse fest, ab der der Kernel geladen wird.
  Üblicherweise ist die Option richtig konfiguriert (siehe
  Abbildung 3).
• »CONFIG_SYSFS=y«: Diese unter »Pseudo
  filesystems« befindliche Einstellung aktiviert das
  Gerätemodell und die Dateisystem-Schnittstelle (das
  Sys-Filesystem).

Nach der Kernelkonfiguration erfolgen das Generieren und das Installieren des Kernels. Wer sich dabei unsicher fühlt, findet die für Linux 2.6 passenden Informationen unter [4].

Nach der Installation des Kernels erfolgt im zweiten Schritt die Installation des Userspace-Programms »kexec« [5]. Eine Hilfe für die Generierung und Installation sucht man im Paket allerdings vergeblich, doch die bekannte Befehlsfolge »./configure && make && make install« führt auch hier zu dem gewünschten Ergebnis, das sich anschließend in »/usr/local/sbin/« findet.

Abbildung 1: Am gewöhnlichen Bootvorgang auf dem PC sind neben dem Bios zwei Bootloader beteiligt, bevor der Linux-Kernel die Kontrolle übernimmt. Kexec übergeht das Bios und die beiden Bootloader-Stages, indem es einen im Speicher geparkten Kernel umschichtet und dann startet.

Abbildung 2: Schritt für Schritt zum Kexec-Reboot. Vor dem eigentlichen Neustart steht die gründliche Vorbereitung.

Reboot-Skript anpassen

Der letzte Einrichtungsschritt ist notwendig, damit nach dem Herunterfahren des Systems statt des Bios der geparkte Kernel startet. Hierzu muss der Sysop das Init-System anpassen. Die Änderung ist minimal und betrifft allein das Skript »/etc/init.d/reboot«. Bei einer Ubuntu-Distribution beispielsweise baut er den Kexec-Aufruf folgendermaßen vor dem Kommando »reboot« ein:

log_begin_msg "Rebooting... "
/usr/local/sbin/kexec -e
reboot -d -f -i
log_end_msg $?

Kernel in Parkposition

Hatte Kexec vor dem Reboot einen Kernel geparkt, ruft es ihn vor dem sonst stattfindenden Übergang zum Bios auf. Liegt im Speicher kein nachzuladender Betriebssystemkern, kommt der bekannte Bootprozess über das Bios und die Bootloader zum Einsatz. Der Aufruf von »kexec -e« startet den geparkten Kernel. Der zum Beispiel mit dem Kommando »reboot« eingeleitete Neustart hat bis zum Aufruf des Programms seine Aufräumarbeiten abgeschlossen.

Nach Abschluss dieser Modifikationen steht dem Reboot nichts mehr im Weg. Hierzu ist als Erstes der neue Kernel inklusive der Bootparameter und einer eventuell notwendigen RAM-Disk zu parken. Auch bei dieser Arbeit hilft das Programm »kexec« mit dem Schalter »-l«. Der Parameter »–append« legt die Bootparameter fest, die Option »–initrd« die initiale RAM-Disk.

Wer sein System über den Bootloader »grub« startet, findet die Konfiguration bei den meisten Distributionen in der Datei »/boot/grub/menu.lst«. Dort stehen üblicherweise Zeilen wie etwa die folgenden für den Kernel und die initiale RAM-Disk:

kernel /boot/vmlinuz-2.6.13.2 U
root=/dev/sda2 ro
initrd /boot/initrd.img-2.6.13.2

Mit dem Kexec-Kommando wird daraus die Zeile:

kexec -l /boot/vmlinuz-2.6.13.2 U
--append="root=/dev/sda2 ro" U
--initrd=/boot/initrd.img-2.6.13.2

Wer den Reboot-Prozess im Detail verfolgen will, sollte auf eine Textkonsole wechseln. Nur auf diese Weise lassen sich die Ausgaben beim Bootprozess verfolgen. Das ist gerade beim ersten Reboot-Versuch wichtig, denn einzelne Treiber verlassen sich auf eine Hardware-Initialisierung durch das Bios.

So ließ sich beispielsweise ein Centrino-Notebook nicht hochfahren, solange der Kernel beim Start den Treiber »ipw2100.ko« benutzte. In solchen Fällen hilft nur noch ein harter Reset. Das System fährt dann wie gewohnt hoch. (ofr)

Abbildung 3: Der Kernel muss das Kexec-Feature unterstützen. Die Einstellung findet sich in der Kernelkonfiguration unter »Processor type and features«. Die Ladeadresse des Kernels liegt bei 0x100000.