26.4Kernel selbst konfigurieren und kompilieren
Der durchschnittliche Linux-Anwender muss seinen Kernel nicht selbst kompilieren. Bei allen aktuellen Distributionen werden ein brauchbarer Standardkernel und eine umfangreiche Sammlung von Modulen mitgeliefert. Dennoch kann es Gründe geben, den Kernel neu zu kompilieren:
-
Sie wollen Ihr System besser kennenlernen. Das Motto dieses Buchs ist es ja, Ihnen auch einen Blick hinter die Linux-Kulissen zu ermöglichen.
-
Sie brauchen besondere Funktionen, die weder in den mitgelieferten Kernel integriert sind noch als Modul vorliegen.
-
Sie möchten eine aktuellere Version des Kernels verwenden als die, die mit Ihrer Distribution mitgeliefert wurde.
-
Sie möchten selbst an der Kernelentwicklung teilnehmen und daher mit dem neuesten Entwicklerkernel experimentieren.
-
Sie wollen in Ihrem Bekanntenkreis mit Insider-Wissen auftrumpfen: »Ich habe den neuesten Linux-Kernel selbst kompiliert!«
Es gibt allerdings gewichtige Gründe, die gegen das Kompilieren eines eigenen Kernels sprechen:
-
Die meisten Distributionen verwenden nicht den Originalkernel, wie er von Linus Torvalds freigegeben wird, sondern eine gepatchte Version mit diversen Zusatzfunktionen, wobei natürlich jede Distribution andere Patches verwendet. An sich ist das eine feine Sache für den Anwender: Er bekommt auf diese Weise Zusatzfunktionen, von denen der Distributor glaubt, dass sie schon ausreichend stabil funktionieren. Wenn Sie sich nun aber selbst den Quellcode des Originalkernels herunterladen, fehlen diese Patches. Einzelne Funktionen Ihrer Distribution, die bisher einwandfrei gearbeitet haben, machen plötzlich Probleme oder funktionieren gar nicht mehr.
-
Das Kompilieren eines eigenen Kernels ist nicht schwierig. Schwierig ist aber die vorherige Konfiguration des Kompilationsprozesses. Dabei stehen Tausende von Optionen zur Auswahl. Sie können mit diesen Optionen beeinflussen, welche Funktionen direkt in den Kernel integriert werden, welche als Module und welche gar nicht zur Verfügung stehen sollen.
Wenn Sie sich – mangels Detailwissen – für die falschen Optionen entscheiden, ist das Ergebnis wie oben: Einzelne Funktionen verweigern den Dienst, und es ist relativ schwierig, die Ursache herauszufinden. Gerade für Linux-Einsteiger ist es praktisch unmöglich, die richtigen Einstellungen für alle Optionen richtig zu erraten.
Aus diesen Gründen verweigern die meisten Distributoren jeden Support, wenn Sie nicht den mit der Distribution mitgelieferten Kernel verwenden. Lassen Sie sich von diesen Warnungen aber nicht abschrecken, es einmal selbst zu versuchen. Wenn Sie nach der in diesem Abschnitt präsentierten Anleitung vorgehen, können Sie Ihren Rechner anschließend sowohl mit dem alten als auch mit dem neuen Kernel hochfahren – es kann also nichts passieren!
Zur Kompilierung des Kernels sind dieselben Entwicklungswerkzeuge wie zum Kompilieren eines einzelnen Moduls erforderlich (siehe Abschnitt 26.3).
Grundlagen
In der Vergangenheit gab es »stabile« Kernelversionen mit einer geraden Endnummer, also 2.0.n, 2.2.n, 2.4.n) etc. Dazwischen gab es die sogenannten Entwickler- bzw. Hacker-Kernel 2.3.n, 2.5.n etc. Die meisten Linux-Distributionen verwendeten stabile Kernelversionen, während die Entwicklerkernel für Programmierer gedacht waren, die sich an der Kernelentwicklung beteiligen. Neue Funktionen wurden zuerst im Hacker-Kernel getestet, bevor sie später in die nächste stabile Kernelgeneration Einzug hielten.
Mit Kernel 2.6 hat sich das Entwicklungsmodell geändert: Es gibt seither keine Hacker-Kernel mehr. Stattdessen erfolgt die Weiterentwicklung direkt in den 2.6.n-Versionen. Man könnte sagen, dass jede neue Kernelversion vorerst als Hacker-Kernel gilt; erst wenn Linus Torvalds entscheidet, dass die Version zuverlässig läuft, wird sie als stabile Version freigegeben. Der Hauptvorteil besteht darin, dass Neuerungen von wesentlich mehr Entwicklern getestet werden und viel schneller allgemein verfügbar werden.
Sollten in der jeweils letzten freigegebenen Kernelversion offensichtliche Fehler oder Sicherheitsmängel auftreten, werden diese in Zusatzversionen mit einer vierten Versionsnummer behoben. Daraus ergeben sich dann Kernelversionen wie 2.6.21.4.
Im Frühjahr 2011 hat Linus Torvalds etwas überraschend festgestellt, dass es Zeit für eine neue Kernelnummerierung sei. Deswegen folgte auf Kernel 2.6.39 die Version 3.0. Die weiteren Versionen bekamen die Nummern 3.1, 3.2, 3.3 etc. Mit den weiterhin erforderlichen Updates ergeben sich dadurch Versionsnummern in der Art 3.5.4. Das ist ein gewisser Fortschritt, weil die Versionsnummer nun nur noch aus drei Teilen besteht und nicht mehr wie bisher aus vier. Ansonsten gingen mit dem neuen Nummerierungschema keine grundlegenden Neuerungen einher – weder funktionell noch im Entwicklungsprozess.
Anfang 2014 gab es dann den nächsten Versionssprung auf 4.0, wobei das Nummerierungsschema aber gleich blieb. Es folgten also bis zur Fertigstellung dieses Manuskripts die Versionen 4.1 und 4.2; die Version 4.3 war gerade in Arbeit.
Die meisten Updates eines Linux-Systems können im laufenden Betrieb erfolgen. Aktualisierte Netzwerkdienste müssen zwar anschließend neu gestartet werden, aber es besteht keine Notwendigkeit, den ganzen Rechner neu zu starten. Eine Ausnahme von dieser Regel ist der Kernel: Damit Sicherheits-Updates im Kernel wirksam werden, müssen Sie einen neuen Kernel und neue Module installieren und den Rechner anschließend neu starten. Auf Desktop-Rechnern, die üblicherweise jeden Tag ein- und ausgeschaltet werden, ist das egal. Aber bei Servern, die möglichst ohne Unterbrechung ständig verfügbar sein sollen, ist ein Neustart immer unerwünscht.
Die erste Lösung für dieses Problem bot die Funktion Ksplice: Bei vielen Updates ist es möglich, die betreffende Kernelfunktion im laufenden Betrieb zu deaktivieren und durch neuen Code zu ersetzen. Die nicht eben trivialen technischen Hintergründe des Verfahrens sind auf den beiden folgenden Seiten beschrieben:
http://www.ksplice.com
http://lwn.net/Articles/340477
Mitte 2011 übernahm Oracle die Firma Ksplice. Kernel-Updates für Oracle Linux erfolgen seither zumeist durch Ksplice. Das war über mehrere Jahre ein durchaus gewichtiges Unterscheidungsmerkmal zu anderen Enterprise-Linux-Versionen, die keine vergleichbare Funktion anbieten konnten.
Red Hat und SUSE wollten in dieser Hinsicht natürlich nicht zurückstecken und entwickelten unter den Namen kPatch und kGraft vergleichbare Update-Mechanismen. Die beiden Mechanismen stehen seit 2014 in den Enterprise-Versionen von Red Hat und SUSE zur Verfügung und sind seit Version 4.0 (also Anfang 2015) auch offiziell im Kernel enthalten.
Der Kernel besteht zurzeit (Version 4.2) aus mehr als 20 Millionen Zeilen Code. Der Großteil davon ist in C geschrieben, ein kleiner Teil in Assembler. Wenn Sie wissen möchten, wer bzw. welche Firmen zur Kernelentwicklung beitragen, verfolgen Sie einfach die Linux-News-Site lwn.net. Dort finden Sie zu jedem Kernel-Release eine statistische Aufarbeitung, wer die meisten Änderungen durchgeführt hat. Auch auf http://heise.de gibt es regelmäßig exzellente Artikel über alle wichtigen Neuerungen im jeweils aktuellsten Kernel:
http://lwn.net/Articles/654633 (beide Links für Version 4.2)
http://heise.de/-2789351
Tipps zur Kompilierung des Kernels finden Sie auch auf den folgenden Seiten:
http://kernelnewbies.org/FAQ
http://www.tux.org/lkml
Wenn Sie sich für technische Interna interessieren, sind die Dokumentationsdateien des Kernelcodes sehr aufschlussreich. Gerade neue Funktionen des Kernels werden zuerst hier beschrieben, noch bevor die entsprechenden man-Seiten aktualisiert werden:
http://www.kernel.org/doc/Documentation
Kernelcode installieren
Der Quellcode für den Kernel befindet sich üblicherweise im Verzeichnis /usr/src/linux; nur bei Red Hat und Fedora gibt es abweichende Gepflogenheiten, die weiter unten behandelt werden. Falls dieses Verzeichnis leer ist, haben Sie den Kernelcode nicht installiert. Sie können nun wahlweise den Kernelquellcode Ihrer Distribution installieren oder den gerade aktuellen offiziellen Kernelcode herunterladen. Weniger Probleme bereitet zumeist die erste Variante, insbesondere für Einsteiger.
Ist genug Platz auf der Festplatte/SSD?
Beachten Sie, dass der Platzbedarf für den Kernelcode beachtlich ist: Die komprimierten Quellcodepakete sind mehr als 90 MByte groß. Nach dem Entpacken beträgt der Platzbedarf ca. weitere 700 MByte, und nach dem Kompilieren mit den dadurch resultierenden Binärdateien rund 10 GByte! Zuletzt können Sie mit make clean zahllose Objektdateien wieder löschen, aber zwischenzeitlich brauchen Sie eine Menge freien Speicherplatz.
Bei den meisten Distributionen gibt es ein eigenes Paket, das den Kernelquellcode enthält. Tabelle 26.3 gibt für einige gängige Distributionen an, in welchen Paketen sich der Kernelcode befindet. Dabei ist n.n ein Platzhalter für die installierte Kernelversion.
|
Distribution |
Paket |
|---|---|
|
Debian, Ubuntu |
linux-source-n.n |
|
Fedora, Red Hat |
kernel-n.n (Quellcodepaket!) |
|
SUSE |
kernel-source |
Tabelle 26.3Pakete mit dem Kernelquellcode
Bei Debian und Ubuntu wird der Kernelcode als tar-Archiv in das Verzeichnis /usr/src installiert. Sie müssen das Archiv selbst mit tar xJf linux-n.n.tar.xz auspacken. Die Kennung .xz deutet darauf hin, dass der Quellcode mit dem besonders effizienten XZ-Verfahren komprimiert wurde.
Für Fedora und Red Hat gelten einige Besonderheiten: Zum einen befindet sich der Kernelcode nicht in einem gewöhnlichen Paket, sondern in einem Quellcodepaket. Zum anderen empfehlen die Fedora-Richtlinien die Installation des Quellcodes nicht in /usr/src, sondern in das Unterverzeichnis rpmbuild des Heimatverzeichnisses. Das ermöglicht es, den Kernel ohne root-Rechte zu kompilieren.
Insgesamt ist die Vorgehensweise aber etwas umständlicher: Zuerst installieren Sie diverse Entwicklerpakete. rpmdev-setuptree erzeugt das Verzeichnis rpmbuild und darin wiederum diverse Unterverzeichnisse.
dnf download lädt das Quelltextpaket kernel-n.n.src.rpm zu der auf Ihrem Fedora-System gerade laufenden Kernelversion herunter. Im folgenden Beispiel ist das die Kernelversion 4.2.0-300. dnf builddep installiert nun alle Pakete, die zum Kompilieren des Kernels, also für den sogenannten »Build-Prozess«, erforderlich sind. Das rpm-Kommando extrahiert das *.src.rpm-Paket. Das Archiv des Kernelquellcodes (Datei linux-n.n.tar.xz) sowie alle Fedora-spezifischen Patches landen damit im Verzeichnis rpmbuild/SOURCES. Fehlermeldungen der Art Benutzer mockbuild existiert nicht - benutze Root können Sie dabei ignorieren.
Jetzt wechseln Sie in das Verzeichnis rpmbuild/SOURCES. rpmbuild packt die unzähligen Quellcodedateien aus, die bisher noch im Archiv linux-n.n.tar.xy zusammengefasst waren, und wendet alle Red-Hat- bzw. Fedora-spezifischen Patches an:
Anschließend finden Sie den Originalquellcode und den für Fedora gepatchten Quellcode in den folgenden Verzeichnissen:
Um den Platzbedarf zu minimieren, sind identische Dateien durch Hardlinks verknüpft und somit nur einmal physikalisch gespeichert. Weitere Fedora-spezifische Tipps zum Kompilieren eines eigenen Kernels finden Sie auf der folgenden Webseite. Dort sind auch diverse weitere Varianten beschrieben, z.B. wie Sie den neuen Kernel gleich in ein RPM-Paket verpacken oder wie Sie den Kernelcode direkt aus dem Git-Repository von Fedora herunterladen:
http://fedoraproject.org/wiki/Docs/CustomKernel
Der mit der Distribution mitgelieferte Kernel ist oft schon veraltet. Den aktuellen Kernelcode in Form von komprimierten tar-Archiven finden Sie z.B. hier:
http://www.kernel.org
ftp://ftp.kernel.org/pub/linux/kernel
Ein typischer Dateiname für das Kernelarchiv ist etwa linux-4.2.1.tar.xz (Größe ca. 90 MByte). Zur Installation wechseln Sie in das Verzeichnis /usr/src und führen das folgende Kommando aus:
Die Installation erfolgt in das Verzeichnis /usr/src/. Um den Zugriff auf dieses Verzeichnis zu vereinfachen, zeigt normalerweise der Link /usr/src/linux auf das aktuelle Quellcodeverzeichnis:
Kernelcode aktualisieren (patchen)
Mit sogenannten Patch-Dateien können Sie einen Versionswechsel von einer Version zu einer anderen durchführen. Patches sind komprimierte Textdateien, die angeben, in welchen Dateien welche Änderungen durchgeführt werden sollen. Patches sparen insbesondere bei kleinen Versionswechseln eine Menge Download-Volumen. Patches funktionieren allerdings nur dann, wenn sie auf die dafür gedachte (unveränderte!) Codebasis angewendet werden.
Nehmen wir an, Sie wollen den Code von 4.2.5 auf 4.2.6 aktualisieren: Naheliegend wäre es, einfach den Patch 4.2.6 anzuwenden. Das funktioniert so aber nicht, weil der Patch 4.2.6 als Basis den unveränderten Code 4.2 erwartet (nicht 4.2.5!). Daher müssen Sie auch den Patch 4.2.5 herunterladen und diesen invers anwenden (Option -R), um von 4.2.5 zurück zur Codebasis 4.2 zu gelangen. Erst jetzt funktioniert der Patch 4.2.6!
Das patch-Kommando wird normalerweise in Kombination mit bunzip2 eingesetzt. bunzip2 dekomprimiert den Patch, patch führt die Änderungen aus. Falls die Patch-Datei unkomprimiert vorliegt, lautet das Patch-Kommando patch -p1 < patchdatei.
Generell sollten Sie vor der Anwendung jedes Patches mit der Option --dry-run sicherstellen, dass dabei keine Probleme auftreten. Nichts ist ärgerlicher als ein fehlerhaft oder nur teilweise angewendeter Patch!
Die Patches verändern nur den Code, nicht aber den Namen des Verzeichnisses, in dem sich der Code befindet. Um Verwirrung zu vermeiden, sollten Sie anschließend auch das Codeverzeichnis umbenennen. Die tatsächliche Versionsnummer können Sie der Datei Makefile direkt im Quellcodeverzeichnis entnehmen.
Neben den gerade beschriebenen Update-Patches gibt es auch Patches mit inoffiziellen Zusatzfunktionen, die aus den verschiedensten Gründen noch nicht in den Standardkernel integriert sind (Funktions-Patches).
Grundsätzlich werden auch Funktions-Patches mit patch auf den Kernelcode angewendet. Allerdings müssen Sie darauf achten, dass Sie dieselbe Codebasis haben wie der Entwickler, der den Patch zur Verfügung gestellt hat. In der Regel ist als Codebasis nur der offizielle Kernelcode in der gerade aktuellen Version geeignet, nicht der oft schon gepatchte Kernelcode Ihrer Distribution.
Mitgelieferte Kernelkonfigurationsdateien verwenden
Der Kernel besteht aus Tausenden von Einzelfunktionen bzw. Komponenten. Bei nahezu allen Funktionen können Sie vor dem Kompilieren angeben, ob sie direkt in den Kernel integriert werden, als Modul kompiliert werden oder gar nicht verfügbar sein sollen. Dieser Vorgang heißt den »Kernel konfigurieren«.
Die Kernelkonfiguration wird durch die Datei .config im Verzeichnis /usr/src/linux-n.n bzw. /home/name/rpmbuild/BUILD/kernel-n.n/linux-n.n bestimmt. Dabei handelt es sich um eine rund 7000 Zeilen lange Textdatei, die angibt, ob eine Funktion direkt in den Kernel integriert (name=y) oder als Modul kompiliert werden soll (name=m). Nicht benötigte Funktionen erscheinen in der Konfigurationsdatei nicht bzw. nur in Kommentarzeilen. Die Datei kann auch zusätzliche Einstellungen enthalten (name=wert). Die folgenden Zeilen zeigen den Beginn einer .config-Datei:
Wenn Sie bei der manuellen Kernelkonfiguration (siehe den folgenden Abschnitt) keinen Ausgangspunkt haben, müssen Sie sich wirklich um alle Kerneloptionen kümmern. Gerade beim ersten Mal ist es so gut wie sicher, dass Sie irgendetwas übersehen werden. Sie sparen eine Menge Zeit und Mühe, wenn Sie die mit Ihrer Distribution mitgelieferte Kernelkonfigurationsdatei als Ausgangspunkt verwenden:
Dieses Verfahren hat leider einen Nachteil: Wenn der ursprüngliche Kernelcode andere Patches enthält als der neu zu kompilierende Code, enthält auch die ursprüngliche Konfigurationsdatei Optionen, die im neuen Code nicht vorgesehen sind. Das kann zu Problemen führen. Wie ich schon erwähnt habe, bauen viele Distributoren diverse Patches in ihren Kernel ein, die im Standardkernel nicht enthalten sind. Deswegen müssen Sie anschließend in das Quellcodeverzeichnis wechseln und dort das folgende Kommando ausführen:
make config wertet die vorhandene .config-Datei aus. Fehlen dort Optionen, die der aktuelle Kernelcode vorsieht, dann werden entsprechende Rückfragen angezeigt.
Jetzt bleibt noch die Frage offen, woher Sie die aktuelle Kernelkonfigurationsdatei für das Kommando cp old-config hernehmen. Bei nahezu allen Distributionen befindet sich im Verzeichnis /boot die zum laufenden Kernel passende Konfigurationsdatei, also z.B. /boot/config-n.n. Somit wird aus cp old-config beispielsweise:
Bei Red Hat bzw. Fedora finden Sie weitere Konfigurationsmuster für SMP-, Xen- und andere Kernelvariationen nach der Installation des Kernelquellcodepakets im folgenden Verzeichnis:
Der mit SUSE mitgelieferte Kernel verwendet die cloneconfig-Option (Gruppe General setup). Das bedeutet, dass /proc/config.gz den komprimierten Inhalt der .config-Datei enthält, mit der der gerade laufende Kernel kompiliert wurde. Mit make cloneconfig kopieren Sie die zuletzt verwendete Konfiguration in die Datei .config.
Kernel manuell konfigurieren
Prinzipiell müssen Sie sich zwischen zwei Kerneltypen entscheiden: monolithischen Kerneln oder modularisierten Kerneln. Monolithische Kernel enthalten alle benötigten Treiber direkt im Kernel und unterstützen keine Module. Modularisierte Kernel sind über die integrierten Treiber hinaus in der Lage, im laufenden Betrieb zusätzliche Module aufzunehmen. Ein modularisierter Kernel ist in fast allen Fällen die bessere Entscheidung.
Bei den meisten Komponenten haben Sie die Wahl zwischen drei Optionen: Yes, Module und No. Yes bedeutet, dass diese Komponente direkt in den Kernel integriert wird. Module bedeutet, dass diese Komponente als Modul kompiliert wird (nur sinnvoll bei einem modularisierten Kernel). No bedeutet, dass die Komponente überhaupt nicht kompiliert wird. Es gibt auch eine Reihe von Funktionen, die nicht als Module zur Verfügung gestellt werden können – dort reduziert sich die Auswahl auf Yes oder No.
Die übliche Vorgehensweise besteht darin, in den modularisierten Kernel nur relativ wenige elementare Funktionen zu integrieren und alle anderen Funktionen als Module verfügbar zu machen. Der Vorteil: Der Kernel an sich ist relativ klein, Module werden nur nach Bedarf nachgeladen.
Eine alternative Strategie besteht darin, einen monolithischen Kernel möglichst exakt für die eigenen Hard- und Software-Ansprüche zu optimieren. Alle Funktionen, die genutzt werden sollen, integrieren Sie direkt in den Kernel. Bei allen anderen Komponenten entscheiden Sie sich für No.
Generell wird ein monolithischer Kernel immer etwas größer als ein modularisierter Kernel. Dafür funktioniert er ohne die dynamische Modulverwaltung, und der Rechnerstart gelingt ohne Initrd-Datei. Der Nachteil ist auch offensichtlich: Wenn Sie eine bestimmte Funktion später doch brauchen, müssen Sie den Kernel neu kompilieren. Und nur echte Linux-Profis können abschätzen, welche Funktionen sie nutzen werden.
Werkzeuge zur manuellen Kernelkonfiguration
Um abweichend von der aktuellen Konfiguration einzelne Einstellungen zu verändern, können Sie .config manuell editieren. Das ist aber fehleranfällig und erfordert eine gute Kenntnis der Namen der diversen Optionen. Besser ist es, mit make xxxconfig ein spezielles Konfigurationsprogramm zu starten. Dabei stehen unterschiedliche Varianten zur Verfügung, die Sie mit einem der aufgelisteten make-Kommandos starten:
make config funktioniert immer, ist aber umständlich zu bedienen und nicht zu empfehlen. Sie müssen immer alle Optionen durchlaufen, auch wenn Sie nur eine einzige Option verändern möchten.
make menuconfig setzt voraus, dass Sie vorher das Paket ncurses-devel bzw. libncurses5-dev installiert haben. Die Konfiguration erfolgt ebenfalls im Textmodus. Der große Vorteil im Vergleich zu make config besteht darin, dass die Einstellung der unzähligen Optionen durch verschachtelte Dialoge strukturiert ist.
Auch mit make nconfig erfolgt die Konfiguration im Textmodus, und wie bei bei make menuconfig müssen Sie vorher das ncurses-Entwicklerpaket installieren. Der wesentliche Unterschied besteht in der Navigation: Während menuconfig verschachtelte Dialoge verwendet, navigieren Sie bei nconfig durch einen Baum, dessen Äste Sie ein- und ausklappen (siehe Abbildung 26.1).
Abbildung 26.1Kernelkonfiguration mit make nconfig
make localmodconfig ist eine interessante Kompiliervariante für alle, die es eilig haben. Dabei werden nur die Module kompiliert, die im gerade laufenden Kernel tatsächlich genutzt werden. Das hat Vor- und Nachteile: Der offensichtliche Vorteil besteht darin, dass wirklich nur der Teil des Kernelcodes übersetzt wird, der tatsächlich benötigt wird. Das kann die Übersetzungszeit auf ein Drittel senken! Allerdings läuft der so kompilierte Kernel auf einem anderen Rechner unter Umständen nicht, wenn für seine Hardware-Komponenten relevante Treiber fehlen. Auch das Nachladen eines Moduls, das zur Kompilierzeit nicht aktiv war, wird scheitern. Der Kernel ist also nur zu Testzwecken geeignet, nicht aber für eine längerfristige Nutzung. Detailinformationen zu dieser make-Variante können Sie hier nachlesen:
Wenn Sie nur einzelne Optionen an einer vorgegebenen Kernelkonfiguration ändern möchten, ist es am besten, auf make xxxconfig ganz zu verzichten. Stattdessen geben Sie die gewünschten Einstellungen in der getrennten Datei config-local an. Die hier gewählten Optionen haben Vorrang gegenüber .config.
Kernel kompilieren und installieren
Nachdem Sie mit der Konfiguration des Kernels vermutlich einige Zeit verbracht haben, muss jetzt der Rechner arbeiten. Die folgenden Kommandos beschäftigen einen schnellen Rechner circa eine halbe Stunde. Wenn Ihr Rechner mehrere CPUs oder Cores enthält, können Sie den Kompilierprozess durch make -j n all beschleunigen. make startet dann n Prozesse parallel und lastet so alle CPUs/Cores aus.
Das Ergebnis am Ende dieses Prozesses ist die Datei bzImage im Verzeichnis /pfad/zum/code/linux-n.n/arch/x86/boot. Die Größe der Datei liegt meist in der Größenordnung zwischen 4 und 7 MByte und hängt davon ab, wie viele Funktionen direkt in den Kernel inkludiert sind und wie viele als Module bzw. überhaupt nicht kompiliert wurden.
Fehler beim Kompilieren
Wenn beim Kompilieren ein Fehler auftritt, sollten Sie naturgemäß versuchen, ihm auf den Grund zu gehen. Wenn das Problem bei einer für Sie nicht wichtigen Funktion auftritt, können Sie die Konfiguration so ändern, dass die betroffene Funktion eben nicht kompiliert wird.
Hartgesottene Linux-Freaks können make einfach mit der zusätzlichen Option -k aufrufen, also z.B. make -k all. Diese Option bewirkt, dass Fehler ignoriert werden. make fährt also einfach mit der Kompilation der nächsten Datei fort. Wenn Sie Glück haben, betrifft das Kompilationsproblem ein für Sie unwichtiges Modul, das dann eben nicht zur Verfügung steht.
make modules_install kopiert die Moduldateien dorthin, wo die Kommandos zur Modulverwaltung (etwa insmod) diese erwarten: in das Verzeichnis /lib/modules/n. Dabei ist n die genaue Versionsnummer des soeben kompilierten Kernels.
Der frisch erzeugte neue Kernel ist natürlich noch nicht aktiv. Bisher wurden nur ein paar neue Dateien erstellt, sonst nichts! Der neue Kernel kann erst beim nächsten Start von Linux aktiviert werden und auch dann nur, wenn Sie Ihren Bootloader GRUB so konfigurieren, dass der neue Kernel berücksichtigt wird.
Dazu kopieren Sie als Erstes die neue Kerneldatei in das Verzeichnis /boot. Es ist üblich, der Datei den Namen vmlinuz-n.n zu geben. Gleichzeitig sollten Sie auch eine Kopie der Konfigurationsdatei erstellen:
Nun müssen Sie eine neue, zum Kernel passende Initrd-Datei erzeugen. Dazu verwenden Sie je nach Distribution die Kommandos dracut, mkinitrd, mkinitramfs oder update-initramfs. Außerdem müssen Sie die GRUB-Konfiguration aktualisieren, damit es im GRUB-Menü einen Eintrag für den neuen Kernel gibt. Das erforderliche Kommando lautet je nach Distribution update-grub oder grub2-mkconfig. Details zur Erzeugung von Initrd-Dateien und zur Aktualisierung der GRUB-Konfiguration können Sie in Kapitel 24, »GRUB«, nachlesen. Die folgenden Kommandos gelten für ein Fedora-System auf einem EFI-Rechner:
Ob alles funktioniert hat, merken Sie beim Neustart. Sollte der neue Kernel aus irgendeinem Grund nicht funktionieren, starten Sie den Rechner einfach mit dem bisherigen Kernel und unternehmen einen weiteren Versuch, den Kernel richtig zu konfigurieren und neu zu kompilieren. Läuft der neue Kernel dagegen zufriedenstellend, sollten Sie die nun nicht mehr benötigten Objekt-Dateien des Compilers aufräumen. Sie gewinnen auf diese Weise rund 9 GByte Platz auf der Festplatte!