Selbstgebacken: Kernel kompilieren nach Rezept
Kompilieren
Das Kompilieren läuft im Grunde automatisch ab. make übernimmt den Löwenanteil der Arbeit, indem es aus der oben erstellten Konfiguration und über Makefiles, die jede Komponente des Kernels mitbringt, die zu bauenden Teile des Kernels bestimmt und Abhängigkeiten auflöst. Prinzipiell kann man sich make als Küchenmaschine vorstellen, in die man den kompletten Vorratsraum hineinkippt und die dann aufgrund eines dazugeworfenen Rezepts nicht benötigte Zutaten aussortiert, den Rest entsprechend in der richtigen Reihenfolge verarbeitet und zum Schluss den Kuchen backt. Ganz perfekt ist die Analogie jedoch nicht, solange Hühner ihren Eiern kein Makefile beilegen.
Voraussetzung ist natürlich, dass die für das Bauen des Kernels notwendigen Programme vorhanden sind, also Compiler, Linker und Co. In der GNU Compiler Collection (GCC) ist alles dabei.
Der folgende Befehl baut den oben konfigurierten Kernel und die zugehörigen Module zusammen:
$ make -j8 bzImage modules
Mit »make« kann man seinem System richtig einheizen – im wahrsten Sinne. Die Option -j gibt an, wie viele Jobs gleichzeitig laufen sollen, denn »make« ist ein unbarmherziger Antreiber. Ohne Widerrede schickt es auf Anforderung 64 Compiler- und Linker-Prozesse oder noch mehr gleichzeitig an den Start, was jedoch nur bei entsprechend gut dimensionierten Mehrprozessor-Systemen wirklich sinnvoll ist. Ein durchschnittliches Zwei-Prozessor-System ist mit vier bis acht Jobs gut bedient. Die Faustregel lautet hier generell, dass doppelt so viele Jobs antreten sollen, wie Prozessoren oder Kerne im System vorhanden sind, so z.B. acht Jobs für vier Kerne. In keinem Fall sollte -j ohne darauf folgende Zahl auftreten; »make« versteht dies als Anweisung, keine Grenzen für die Zahl möglicher Prozesse zu setzen, und startet für jedes Unterverzeichnis im Kernel-Baum nun einen eigenen Job. Dies führt fast immer zu einer vollständigen Auslastung des Systems, das dann auch kaum noch auf Benutzereingaben reagiert.
Der Gang zur Kaffeemaschine ist als nächstes eine gute Wahl, ebenso das gemütliche Aufbrühen eines Tees. Ein Build-Vorgang kann gerne mal eine gute Stunde (oder auch zwei) in Anspruch nehmen, je nach Leistungsfähigkeit der Hardware. [Ed.: Bei einer auf das Nötige reduzierten Konfiguration können es auch 10 Minuten sein.] Da das Bauen des Kernels auch eine sehr aufwendige Angelegenheit ist, sollte man vom Abspielen von HD-Videos auf dem gleichen System absehen, selbst wenn es seit Linux 2.6.38 dank der dort eingeführten Prozess-Gruppen prinzipiell möglich, wenn auch nicht schön ist.
Installieren
Das Installieren des Kernels und der Module muss als Superuser (ggfs. mittels sudo) erfolgen. Hierbei werden das Kernel-Abbild (vmlinuz), eine Sicherung der verwendeten Konfiguration (config), eine Datei mit Debug-Informationen (System.map) und das Startabbild (initrd.img), das den Kernel und ein kleines Dateisystem für den Start des Systems beinhaltet, in das Verzeichnis /boot kopiert und im Bootloader registriert. Die Module wandern in dem Fall nach /lib/modules/3.3.2, bei anderen Kernel-Versionen eben in ein entsprechend benanntes Verzeichnis.
# make modules_install install
Damit wäre der eigene Kernel gebaut und installiert und wartet nur noch darauf, durch einen Neustart gestestet zu werden.
Kurzer Einwurf
Der Bootloader Grub2 blendet je nach Konfiguration das Bootmenu beim Start aus, was die Auswahl eines alternativen Kernels erheblich erschweren kann. Um dem vorzubeugen, sollte man in der Datei /etc/default/grub kontrollieren, ob die Option GRUB_HIDDEN_TIMEOUT gesetzt ist, und sie gegebenenfalls auskommentieren. Musste die Datei bearbeitet werden, ist es notwendig, dass Grub seine Konfiguration neu schreibt, erst dann sollte ein Neustart mit dem neuen Kernel erfolgen.
# update-grub
Feuerprobe
Ob alles gut gegangen ist, wird nach einem Neustart mit dem eigenen Kernel offensichtlich. Im besten Fall bootet das System – das kann beim ersten Mal etwas länger dauern als gewohnt – und präsentiert einem die Anmeldemaske. Nach der Anmeldung kann man erst einmal prüfen, ob der neue Kernel auch tatsächlich geladen wurde:
# uname -a
Es sollte nun eine Ausgabe erfolgen, die irgendwo die Versionsnummer 3.3.2 aufführt. Erscheint wider Erwarten die alte Version, so wurde der neue Kernel nicht in Grub registriert; update-grub, als Superuser ausgeführt, schafft hier Abhilfe.
Probleme können auftreten, wenn Kernel-Module zum Einsatz kommen, die nicht aus den Kernel-Quellen stammen – ein Beispiel ist hier VirtualBox, es kann aber auch proprietäre Grafiktreiber betreffen. Diese externen Module werden natürlich nicht mitkompiliert, selbst wenn sie aus der Paketverwaltung des Linux-Systems stammen. Im Falle von VirtualBox muss hier gegebenenfalls unter dem neuen Kernel das zugehörige Modul erneut gebaut werden:
# /etc/init.d/vboxdrv setup
Dieses Problem ist nicht neu, deshalb bieten aktuelle Distributionen bereits Abhilfe: DKMS (Dynamic Kernel Module Support) ist in der Lage, ihm bekannte Module neu zu kompilieren, sobald ein neuer Kernel installiert wird. VirtualBox nutzt dies bereits seit längerem, weshalb die Installation von »dkms« zu empfehlen ist.
Wie werde ich ihn wieder los?
Nicht immer ist alles Gold was glänzt, und nicht alles, was bootet, taugt auch für den täglichen Gebrauch. Treten Probleme auf, ist es vielleicht notwendig, den Kernel wieder loszuwerden. Auch das ist vom Prinzip her einfach; man löscht die erzeugten Kernel-Dateien und wirft den entsprechenden Eintrag aus dem Bootloader. Dazu startet man am besten mit einem anderen Kernel, indem man diesen beim Systemstart im Menü des Bootloaders auswählt. Ist das System gestartet, kann eine kurze Kontrolle mit uname -r nicht schaden, ob man auch den richtigen Kernel geladen hat:
Zu Löschen sind im Verzeichnis /boot alle Dateien mit der entsprechenden Versionsnummer, zum Beispiel config-3.3.2, initrd.img-3.3.2, System.map-3.3.2 und vmlinuz-3.3.2. Außerdem sollte das Verzeichnis mit den Modulen entfernt werden (hier wieder /lib/modules/3.3.2):
# rm /boot/*-3.3.2 # rm -rf /lib/modules/3.3.2/
Einige Distributionen, darunter SUSE, fügen der Versionsnummer auch beim Selbstkompilieren noch ein Anhängsel an, entsprechend müssen die beiden rm-Befehle korrigiert werden.
Nun muss Grub wieder seine Konfiguration mit update-grub aktualisieren. Damit ist man den selbstgebackenen Kernel wieder los, sowohl im Bootloader als auch auf der Festplatte.
Die Kernel-Quellen braucht man im Übrigen nicht unbedingt aufzuräumen, solange man genug Platz auf der Festplatte hat.
