Einen eigenen Kernel zu kompilieren gilt als schwierig – mehrere hundert Konfigurationsoptionen schrecken ab. Doch Sie müssen nicht alle verstehen, um einen neuen Kernel selbst zu übersetzen.

Eigentlich kommt der Nutzer nicht oft auf Tuchfühlung mit dem Kernel: Sie starten Programme unter X-Window oder auf der Konsole, Sie stöbern im Dateisystem – doch hinter allem steckt der Kernel: Er teilt den Anwendungen Arbeitsspeicher zu, steuert den Zugriff aufs Dateisystem und vieles mehr. Doch zwischen dem Kernel und Ihnen liegt (zumindest) eine Shell oder grafische Oberfläche.

Dabei ist der Kernel auf Linux-Systemen leicht auszumachen – er verbirgt sich hinter der Datei /boot/vmlinuz-Kernelversion. Je nach Distribution ist er ein bis zwei MByte groß. Kann das alles sein? Ja und nein – obwohl der Kernel selbst nur einen geringen Bruchteil des Speichers eines laufenden Linux-Systems belegt, gehören die Dateien unter /lib/modules/[Kernelversion] ebenfalls zum ihm. Allerdings beansprucht längst nicht der ganze Inhalt dieses unter Suse 10.0 immerhin etwa 70 MByte großen Verzeichnis auch Platz im Arbeitsspeicher: Die Module aus diesem Verzeichnis werden nur bei Bedarf (on demand) geladen.

Fast jede Distribution liefert Kernel und Module fertig in binärer Form mit, doch der Kernel lässt sich wie ein normales Programme übersetzen – Sie benötigen dazu den Kernel-Quelltext sowie den GNU-C-Compiler.

Zeit für was Neues

Normalerweise laufen die distributionseigenen Kernel ohne Fehl und Tadel. Dennoch gibt es einige Szenarien, in denen das Kompilieren eines neuer Kernel sinvoll sein kann:

• In sicherheitskritischen Anwendungen sollte der Kernel nach Bekanntwerden von Sicherheitslücken erneuert werden.
• Die Unterstützung neuer Hardware wie DVB-, WLAN-Karten oder Webcams verbessert sich häufig in neueren Kernelversionen.
• Über Patches integrieren Sie bei Bedarf neue Funktionen in den Kernel. Ein Beispiel ist Software-Suspend2 [1]: Dieser Patch ist besonders für Notebook-Nutzer interessant. Er bringt Suspend auf manchen Systemen zum Laufen, auf denen dies mit dem Standard-Kernel nicht klappt.

Es ist nicht ganz einfach, sich einen Überlick über die Entwicklung des Kernels zu verschaffen: Zu zahlreich sind die Änderungen von Version zu Version. Eine Zusammenfassung bietet das Changelog auf Kernelnewbies.org [2]. Normalerweise finden Sie die Information, dass eine neue Kernelversion bei Hardware-Problemen Abhilfe schaffen könnte, jedoch eher im Kontext des fraglichen Hardware-Geräts: Wenn Sie in einem DVB-Forum lesen, dass Ihre Karte mit Kernel 2.6.13 funktioniert, auf Ihrem System jedoch 2.6.12 läuft, dann wird es Zeit, den Kompiler in die Hand zu nehmen.

Einen neuen Kernel zu kompilieren stellt kein Risiko dar: Der Bootloader lässt sich so konfigurieren, dass Sie nicht nur zwischen unterschiedlichen Linux-Systemen wählen können. Auch verschiedene Kernel für ein System lassen sich im Bootloader eintragen. Auch nach der Installation eines neuen Kernels lässt sich das System auf jeden Fall wie bisher booten. Abbildung 1 zeigt die Schritte, die erforderlich sind, um einen selbstkompilierten Kernel auf Ihrem System zum Laufen zu bringen.

Abbildung 1: Schritt für Schritt zum neuen Kernel: Der vorgestellte Weg ist nicht nur für Experten gangbar.

Quell des Kernel-Lebens

Zuerst benötigen Sie die Kernel-Quellen. Möglicherweise stellt Ihre Distribution ein Paket mit aktualisierten Kernquellen bereit. Den neuesten verfügbaren Kernel erhalten Sie jedoch stets bei Kernel.org. Da die Site häufig überlastet ist, sollten Sie stets einen Mirror [3] benutzen. Laden Sie den Kernel mit der höchsten Versionsnummer herunter. Entpacken Sie dieses Archiv nach /usr/src.

Dieser oft “Plain Vanilla” genannte Kernel unterscheidet sich allerdings grundlegend von Distributionskerneln: Meist pflegen die Distributionen eine Vielzahl von Patches ein, die die Funktion und den Treiber-Bestand des Kernels erweitern und bekannte Fehler korrigieren.

Ob nun der Original-Kernel von Kernel.org oder die Adaption der Distributionen die bessere Basis für ein stabiles System abgeben, ist weitgehend eine Glaubensfrage. Mit beiden kommt es selten zu Problemen. Meist stehen die Quellen für den jeweils aktuellen Kernel allerdings nur in der offiziellen Variante zur Verfügung.

In der Praxis bemerken Sie aber normalerweise keinen Unterschied. Eine Ausnahme bildeten frühe Versionen von Suse 9: Hier fügte ein Patch dem Standard-Dateisystem von Suse (ReiserFS) sogenannte extended Attributes hinzu. Der damalige Standard-Kernel verstand diese noch nicht, so dass das Booten aus einer mit Suse erstellen ReiserFS-Partionen misslang. Die extended Attributes sind seit einiger Zeit in den Standard-Kernel integriert.

Sie können nun bereits mit der Konfiguration Ihres neuen Kernels beginnen. Sie arbeiten dann mit dem offiziell vom Kernel-Entwicklerteam freigegebenen Kernel. Alternativ bietet sich der so genannten mm-Tree des Kernels an, der bereits Verbesserungen des laufenden Kernel-Entwicklunsprozesses enthält. Dabei handelt es sich sowohl um Bugfixes als auch um Erweiterungen, die vor der Übernahme in den Standard-Kernel noch einen letzten Test hinter sich bringen müssen. Andrew Morton veröffentlicht den mm-Tree als Patch gegen den Standard-Kernel. Wie Sie diesen und andere Patches anwenden, beschreibt der Kasten “Kernel patchen”.

$ cd linux-2.6.[Version]
$ patch -p1 <../[Patchdatei]

Qual der Wahl

Der Linux-Kernel ist modular aufgebaut: Verschiedene Funktionen (zum Beispiel die Unterstützung für ein bestimmtes Dateisystem oder eine bestimmte Soundkarte) lassen sich beim Neubau aktivieren oder deaktivieren. Je mehr Funktionen aktiviert sind, desto größer wird der Kernel – theoretisch. In der Praxis dauert nur der Kompiliervorgang länger, sofern Sie die on-demand-load-Funktion des Kernels nutzen.

Die meisten Kernel-Features lassen sich sowohl als Modul in den Kernel integrieren als auch fest einkompilieren. Nur die fest einkompilierten Bestandteile bleiben stets im Arbeitsspeicher. Kernel-Module lädt Linux nur bei Bedarf. Deshalb spielt es es in der Praxis – bis auf einen Platzverbrauch in der Größenordnung von 50 MByte auf der Festplatte – keine Rolle, wenn nicht benötigte Kernel-Funktionen als Modul aktiviert sind (vgl. Abbildung 2).

Vorarbeit

Da Linux-Distribution auf möglichst jeder Hardware laufen sollten, ist es gängige Praxis, bei den mitgelieferten Kerneln so gut wie alle Funktionen als Modul einzubauen – ausgenommen extrem selten benötige Bestandteile oder solche, die Probleme verursachen. Diese Vorkonfiguration sollten Sie übernehmen: Die Kernelkonfiguration in allen Details zu verstehen, erfordert viel Hintergrundwissen.

Die meisten Distributionen legen die Standard-Konfiguration des Kernels in der Datei /boot/config-Kernelversion ab. Die Version des laufenden Kernels erfahren Sie als Root über uname -r. Suse-Anwender finden die Kernelkonfiguration nicht im Verzeichnis /boot, dafür generiert der laufende Kernel dynamisch im /proc-Verzeichnis eine Datei config.gz. Kopieren Sie diese in das Kernel-Verzeichnis, entpacken Sie sie mit gunzip config.gz und benennen Sie sie in .config um.

Alle make-Befehle führen Sie stets als Root und aus dem Verzeichnis /usr/src/linux-Kernelversion heraus aus. Reinigen Sie einen neu entpackten Kernelbaum zunächst mit make mrproper von eventuellen Resten aus dem Entwicklungsprozess. Kopieren Sie die nun die Konfigurationsdatei mit cp /boot/config-Kernelversion /usr/src/linux-Kernelversion/.config in den Kernelbaum.

Der Kernel bringt ein Qt-, ein Gtk-, sowie ein konsolenbasiertes Frontend zur Konfiguration mit. Damit wählen Sie aus, welche Funktionen Ihr selbstkompilierter Kernel beherrschen soll. In diesem Konfigurationsmenü, das bei allen Frontends die gleichen Einträge enthält, finden sich mehrere hundert Einstellungen – was zunächst abschreckt.

Doch dank der kopierten Konfigurationsdateien ist der Kernel zum Glück bereits vorkonfiguriert, wenn Sie nun das Konfigurationswerkzeug mit make menuconfig (Konsolen-Version), make gconfig (Gtk-Version) oder make xconfig (Qt-Version) starten (Abbildung 2). Die Konsolen-Version benötigt ncurses-devel, gilt jedoch als das zuverlässigste Werkzeug.

Wenn Sie eine .config-Datei aus einer älteren Kernelversion in ihren Quellbaum kopiert haben, müssen Sie Menuconfig oder ein anderes Konfigurationstool einmal aufzurufen, bevor Sie mit dem Kompilieren beginnen: Dies ergänzt die Konfigurationsoptionen, die bei der neuen Kernelversion hinzugekommen sind, mit der Standardeinstellung.

Sie sollten die Konfiguration nun jedoch beenden, ohne Einstellungen zu verändern: Wählen Sie in Menuconfig respektive Xconfig so lange die Option Exit, bis das Tool Sie fragt, ob Sie die Konfiguration speichern möchten. Bejahen Sie dies. In Gconfig dagegen müssen Sie für das Speichern selbst Sorge tragen, anderenfalls gehen die Einstellungen verloren.

Erst wenn Sie den neuen Kernel erstellt und einmal erfolgreich gebootet haben, rufen Sie das Konfigurationswerkzeug erneut auf und verändern die Kernelkonfiguration bei Bedarf weiter.

.config-Dateien älterer Kernel-Versionen um fehlende Einstellungen.” width=”300″ height=”211″ /> Abbildung 3: Ein Aufruf des Konfigurationstools ergänzt .config-Dateien älterer Kernel-Versionen um fehlende Einstellungen.

Zielgerade

Nun trennt Sie, wenn alles glatt geht, nur noch ein make (und eine Wartezeit von etwa 5-30 Minuten) von einem fertigen Kernel. Beim Kompilieren erscheinen viele Meldungen auf der Konsole; Warnungen (Abbildung 4) sind dabei kein Grund zur Besorgnis. Für Debian- und Ubuntu-User ergeben sich einige Abweichungen (siehe Kasten).

Läuft die Kompilation durch, ohne dass Sie das Wort error zu sehen bekommen, finden Sie den neuen Kernel innerhalb des Kernel-Quellbaumes im Verzeichnis /arch/Prozessor-Architektur/boot als Datei bzImage. Bei einem PC ist das /arch/i386/boot, was auch für amd_64-Kernel gilt. Kopieren Sie das bzImage in das Verzeichnis /boot. Benennen Sie die Datei dort in vmlinuz-Kernelversion um. Kopieren Sie außerdem die Datei system.map nach /boot/system.map-Kernelversion. make modules_install installiert schließlich die als Modul konfigurierten Teile des Kernels.

Abbildung 4: Warnungen beim Kompilieren sind, je nach Einstellung des Kompilers, normal. Das Wort “error” weist hingegen darauf hin, das Übersetzen des Kernels fehlgeschlagen ist.

Nun müssen Sie den neuen Kernel noch in das Startmenü des Bootloaders eintragen. Beim Bootloader Grub, den inzwischen fast alle Distributionen nutzen, editieren Sie dazu die Datei /boot/grub/menu.lst. Für Lilo stehen die entsprechenden Einstellungen in /etc/lilo.conf.

In die Gänge kommen

Beim Booten stellt sich leider ein klassisches Henne-Ei-Problem ein: Um Dateisysteme lesen zu können, benötigt der Kernel Module, die in einem Dateisystem auf der Festplatte liegen. Als Lösung setzen die meisten Distributionen eine sogennanten Initial Ramdisk ein. Der Kernel mountet die Initial Ramdisk, deren Inhalt der Bootloader dem Kernel zur Verfügung stellt, vorübergehend als Root-Dateisystem. Der Kernel findet darin die benötigten Module. Alternativ lassen sich die Dateisystem- und Festplattentreiber auch fest in den Kernel einkompilieren.

Normalerweise reicht mkinitrd ohne Parameter als Root aus, um für alle Kernel-Images in /boot neue Initial-Ramdisk-Images zu generieren. Im Details unterscheidet sich mkinitrd von Distribution zu Distribution, so dass ein Blick in die Manpage nicht schaden kann. Wenn alles glatt geht, liegt danach ein neues Initrd-Image initrd-[Kernelversion] im Verzeichnis /boot.

Listing 1 zeigt eine menu.lst, die Einträge für ein Ubuntu- und ein Suse-System enthält. Die root-Zeile legt die Partion fest, in der das Kernel-Image liegt. Die Sytax hd(0,0) steht für: 1. Festplatte, erste Partion, also hda. Die nächsten zwei Zeilen bezeichnen das Kernel-Image und das Initial-Ramdisk-Image. Beim Kernel-Image folgen hinter dem Dateinamen noch die Parameter, die dem Kernel beim Start übergeben werden sollen.

Auch wenn die menu.lst recht kompliziert aussieht, ist es in der Praxis einfach, einen Grub-Menüeintrag für Ihren neuen Kernel zu erstellen: Dupizieren Sie den Standard-Eintrag für Ihre Distribution und passen Sie dann die Dateinamen für Kernel und Initial Ramdisk sowie den title an. Entfernen Sie in dieser Phase keine bestehenden Einträge.

title Ubuntu, kernel 2.6.12-9-386
root       (hd0,0)
kernel    /boot/vmlinuz-2.6.12-9-386 root=/dev/hdc1 ro quiet splash
initrd     /boot/initrd.img-2.6.12-9-386
title SUSE LINUX 10.0
root    (hd0,8)
kernel /boot/vmlinuz root=/dev/hdc9 vga=0x31a selinux=0 resume=/dev/hdc3  splash=silent showopts
          initrd /boot/initrd

Booten Sie nun Ihr System neu, wählen Sie im Bootprompt den neuen Kernel und achten Sie auf Fehlermeldungen. Auf gewohnte grafische Bootscreens müssen Sie mit dem Plain-Vanilla-Kernel verzichten, diese Funktion fügt erst der Bootsplash-Patch [4] hinzu.

Feineinstellung

Falls der neue Kernel mit den vom laufenden Kernel übernommenen Einstellung bootet, können Sie die Einstellungen anpassen (zum Beispiel in der neuen Kernversion hinzugekommene Treiber aktivieren). Kompilieren Sie den Kernel neu, so werden nur von der Veränderungen betroffene Teile des Quellcodes neu übersetzt.

Die Tabelle “Hauptmenü Kernel-Konfiguration” bietet einen Überblick über wichtige Einträge der erste Menüebene der Kernelkonfiguration. Die in der Tabelle fehlenden Menüpunkte sind meist nur für Experten interessant. So sollten Sie den Networking Support nur anpassen, wenn Sie der Netzwerk-Unterstützung des Kernels wirklich vertraut sind. Treiber zu entfernen, die Sie nicht benötigen, sollte in 2.6-Kerneln nicht mehr zu Problemen führen. Im Version 2.4 brach der Kompiliervorgang dagegen relativ häufig ab, wenn verschiedene Treiber sich gegenseitig voraussetzten und die Abhängigkeit im Konfigurationswerkzeug nicht richtig aufgelöst war.

Aktivieren Sie nie Debug-Optionen, da diese oft die Systemgeschwindigkeit stark beeinträchtigen. Legen sie außerdem stets Backups der Datei .config an, bevor Sie eine funktionierende Kernelkonfiguration weiter verändern.

Wenn das System wie gewünscht läuft, können Sie in der menu.lst noch den Wert des default-Eintrags anpassen, um den neuen Kernel als Standard-Bootoption festzulegen. Weiter Informationen auf Englisch finden Sie im Kernel-Build-HOWTO [5], Hintergrundinformationen rund um den Kernel bietet die schon erwähnte Site Kernelnewbies.org [6].