© Konstantin Trubavin, 123RF

Ob aus reinem Interesse oder um beim Testen des Kernels zu helfen: Es gibt immer gute Gründe, zumindest auf einem System eigene Linux-Kernel zu kompilieren. Ein Erfahrungsbericht zeigt, wie das möglichst einfach klappt.

Schon seit Jahren probiert der Autor des Artikels neue Kernel-Builds auf dem eigenen Laptop aus. Geschah dies früher aus reiner Neugier und Freude daran, hat er seit geraumer Zeit auch ein berufliches Interesse, die Kernel-Entwicklung zeitnah zu verfolgen.

Natürlich gibt es Abkürzungen, wie den Einsatz vorgefertigter Kernel-Pakete etwa für Ubuntu [1]. Auch Debian “Sid” oder dedizierte Rolling-Release-Distributionen liefern neue Kernel-Pakete relativ früh aus. Dieser Weg erlaubt es allerdings nicht, die beim Durchlauf von »make oldconfig« neu hinzu gekommenen Konfigurationsoptionen einzeln zu studieren. Vielmehr muss der Paketnutzer LinuxChanges [2] oder ähnliche Quellen heranziehen, um von den Neuerungen der jeweils aktuellen Kernel zu erfahren.

Zudem kommt es insbesondere beim Berichten von Fehlern im Kernel vor, dass Kernel-Entwickler die Bug-Melder dazu auffordern, einen bestimmten Patch oder eine bestimmte alternative Version des Kernels aus einem anderen Git-Repository zu testen. Spätestens dann ist es an der Zeit, seinen eigenen Kernel zu übersetzen. Daneben ist es auch für größere Cloud-Umgebungen mitunter sinnvoll, speziell optimierte Kernel zu bauen. Das ist jedoch nicht der Fokus des Artikels.

Aus den Quellen

Früher war ein heruntergeladener Tarball, mitunter auf eine neuere Version gepatcht, die Quelle des Kernel-Sourcecodes. Heute verwendet der Autor schon länger nur noch Git dafür. Es bietet Kernel-Enthusiasten gleich mehrere entscheidende Vorteile:

• Man kann den Quelltext inkrementell aktualisieren, ohne ihn manuell patchen zu müssen.
• Es ist erlaubt, in einem lokalen Repository mehrere Remote-Repositories zu konfigurieren und nach Belieben zwischen ihnen zu wechseln.
• Es ist möglich, in die Vergangenheit zu gehen und beispielsweise eine bestimmte Version anzuspringen.
• Mit »git bisect« gibt es ein essenzielles Werkzeug, um über eine binäre Suche die genaue Ursache eines neu eingeführten Fehlers zu finden.

Wer selbst einen eigenen Kernel kompilieren möchte, und sei es nur für den eigenen Laptop oder eine bestimmte virtuelle Maschine, sollte erst einmal den kompletten Quelltext aus einem Git-Repository klonen. Wer gleich ganz vorn mitschwimmen will, der greift dabei zum Mainline-Repository von Linus Torvalds (Listing 1)

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Wem das noch nicht riskant genug erscheint, der wagt sich an das von Stephen Rothwell betreute Linux-Next-Repository [3]. Anwender, die zunächst auf Nummer sicher gehen möchten, wählen stattdessen Linux Stable [4]. In diesem Repository pflegt Greg Kroah-Hartman ältere Versionen des Linux-Kernels für längere Zeit.

Daneben gibt es noch weitere Linux-Stable-Repositories von anderen Kernel-Entwicklern, Integrations-Repositories diverser Subsystembetreuer sowie Repositories, in denen einzelne Kernel-Entwickler neue Funktionen oder Bugfixes ausprobieren. Einen Überblick gibt Git.kernel.org: Jedes dort aufgelistete Repository lässt sich anklicken. Am Ende der daraufhin erscheinenden Zusammenfassungsseite stehen verschiedene Klon-URLs für das Repository zur Auswahl.

Da der Autor für seinen Produktiv-Laptop eigene Kernel kompiliert, wartet er in der Regel mindestens bis zum Release Candidate 2 einer neuen Kernel-Version. In der Zeit zwischen Release und der Eröffnung des Merge Windows bis zum Release Candidate 2 aktualisiert er auf Stable-Versionen des aktuellen Release-Kernels. Das gelingt, indem er das Linux-Stable-Repository in das Verzeichnis mit dem bereits geklonten Repository (Abbildung 1) integriert (Listing 2).

$ git remote add linux-stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
$ git fetch linux-stable

Abbildung 1: So lässt sich das Linux-Stable-Repository in das lokale Git-Repository integrieren.

Der Befehl »git tag« liefert einen Überblick über die verfügbaren Kernel-Versionen der lokal vorhandenen Repositories. Das Kommando »git checkout v5.7.2« passt den lokalen Verzeichnisbaum beispielsweise auf die Version 5.7.2 des Linux-Kernels an.

Bei einem solchen Setup wechselt »git checkout master« (sofern die Kernel-Entwickler für eine neutralere und genauere Sprache nicht auch auf die von Github eingeführte Bezeichnung »main« [5] umsteigen) wieder auf die aktuelle Version in der lokalen Kopie im Repository von Linus Torvalds. Das bringt ein »git pull« dann auf den aktuellen Stand, während »git fetch linux-stable« das zusätzlich als Remote-Quelle hinzugefügte Linux-Stable-Repository lokal aktualisiert.

Für einen tieferen Einstieg in Git sei das online kostenlos verfügbare Buch “Pro Git” [6] empfohlen, das auch gedruckt zum Kauf steht.

Werkzeugkasten holen

Das Konfigurieren und Bauen des Kernels erfordert einige Werkzeuge und Bibliotheken. Zudem ist es sinnvoll, die Ncurses-Bibliothek zu installieren. Zum Übersetzen braucht der Linux-Installateur dann im Wesentlichen Make und einen Compiler. Für Debian und Ubuntu installiert der Befehl aus der zweiten Zeile von Listing 3 sämtliche erforderlichen Pakete. Bei Fedora und CentOS gelingt dies mit den Befehlen aus Zeile 4 und 5. Bei Open Suse Leap und SLES muss der Entwickler unter Umständen das Modul Development-Tools aktivieren. Dann installieren die Befehl aus Zeile 7 und 8 die erforderlichen Pakete zum Übersetzen des Kernels.

### Debian, Ubuntu
$ sudo apt install build-essential bison flex libelf-dev libssl-dev libncurses-dev
### Fedora, CentOS
$ sudo dnf groupinstall 'Development Tools'
$ sudo dnf install bc flex bison ncurses-devel openssl-devel elfutils-libelf-devel
### OpenSuse Leap / SLES
# zypper install -t pattern devel_basis devel_kernel
# zypper install ncurses-devel

Falls noch ein Werkzeug fehlt, gibt Make oft eine klare Fehlermeldung aus. Sie enthält Paketnamen für unterschiedliche Distributionen und verrät so, welches Paket das System noch vermisst. Um einen brandneuen Kernel zu übersetzen, benötigte Debian im Test zum Beispiel Rsync, Fedora verlangte zusätzlich nach dem Paket rpm-build. Lässt sich ein bestimmter Befehl nicht ausführen, ist auch meist schnell klar, in welchem Paket er steckt.

Schlägt ein Make-Versuch fehl, gibt es die Möglichkeit, die in diesem Prozess erzeugten Dateien wieder zu löschen, um neu anzufangen. Dabei helfen wahlweise die Befehle »make clean« oder »make mrproper«, wobei Letzterer neben den nicht mehr nötigen Objektdateien auch die ».config« entfernt.

Vorsicht, Baustelle!

Danach konfiguriert und baut der Admin bereits den Kernel. Auch hier machen ihm einige Kniffe das Leben leichter. Einer der einfachsten Wege, an eine Konfiguration für einen lauffähigen Kernel zu kommen, besteht darin, die Konfiguration des aktuellen Kernels zur Grundlage für den neuen zu machen.

Ein Durchlauf von »make oldconfig« fragt dabei nur die neu hinzugekommenen Konfigurationsoptionen ab (Abbildung 2). Für jede Option gibt es einen Hilfstext und in der Regel auch eine Empfehlung, die weiterhilft, wenn dem Admin nicht klar ist, welche Einstellung für diese Option Sinn ergibt. Oft stimmt die Empfehlung auch mit dem überein, was »make oldconfig« als Standardoption anbietet.

Abbildung 2: Ein Durchlauf von »make oldconfig« für Linux 5.8-rc2 offenbart eine neue Option für die Gerätedatei, um das System über Userspace-Werkzeuge in den Ruhezustand zu versetzen. Auch ohne diese Gerätedatei funktioniert der rein Kernel-basierte Weg dafür jedoch.

Der Autor des Artikels behauptet nicht, den Sinn und Zweck auch nur ansatzweise jeder Kernel-Option zu kennen. Ungeduldige kommen in der Regel auch damit durch, einfach so lange die Eingabetaste zu drücken, bis keine Frage mehr auftaucht. Zumindest hat dies im Rahmen einer Aufgabe für Teilnehmer von Linux-Kursen des Autors immer wieder funktioniert. Auch in den Tests zu diesem Artikel ließen sich größere Kernel-Updates so realisieren.

Als Alternative dazu erstellt der Admin mit »make localmodconfig« eine Minimalkonfiguration. Dieses Make-Target entfernt alle derzeit nicht geladenen Module aus der Konfiguration. Für einen Laptop oder einen Desktop-PC ist es empfehlenswert, vorher alle gewünschten externen Geräte anzuschließen, um eine möglichst vollständige Konfiguration zu erhalten.

Eine Garantie für ein lauffähiges System liefert dieser Befehl allerdings nicht. So kann es zu Schwierigkeiten kommen, falls die Entwickler zwischen der aktuell laufenden und der neu zu kompilierenden Kernel-Version Konfigurationsoptionen umbenennen.

Henne-Ei-Problem

In vielen Distributionen stellt der Distributor die Kernel-Konfiguration bereit. Daher kommt meist eine Konfiguration zum Einsatz, die unterschiedlichste Hardware abdeckt. Die Distribution stellt in der Regel möglichst viele Treiber, Dateisysteme und Funktionen als nachladbare Module bereit. Darunter befinden sich auch die Treiber und das Dateisystemmodul für den Zugriff auf das Dateisystem mit dem Verzeichnis »/lib/modules/«. Dort liegen, nach Kernel-Version sortiert, die Moduldateien.

Diese Konstellation führt beim Booten jedoch zu einem Henne-Ei-Problem, das eine Initial Ramdisk löst. In ihr laden Udev – und gegebenenfalls einige Skripte – die für den Zugriff auf das Root-Dateisystem erforderlichen Kernel-Module. Der Bootloader wiederum lädt diese komprimierte Ramdisk in den Hauptspeicher und übergibt dem Kernel deren Hauptspeicheradresse.

Ohne Ramdisk?

Mit »make nconfig« passt der Kernel-Bauer die Konfiguration in einem teilweise recht tief verschachtelten Menü an die eigenen Bedürfnisse an. Er entfernt wahlweise nicht erforderliche Module oder kompiliert als Modul übersetzte Funktionen fest ein. Das macht es auch möglich, auf eine Initial Ramdisk zu verzichten.

Der Autor des Artikels macht sich schon seit geraumer Zeit nicht mehr die Mühe herauszufinden, welche Optionen er dafür auf jeden Fall fest einkompilieren muss – Initial Ramdisks funktionieren bei gängigen Distributionen mittlerweile sehr zuverlässig.

Während Debian, Ubuntu und deren Ableger in der Standardkonfiguration eine sehr umfangreiche Initial Ramdisk mit fast allen Modulen bauen, lassen OpenSuse, Fedora und verwandte Distributionen standardmäßig alles weg, was die aktuelle (virtuelle) Hardware nicht benötigt. Der Maximal-Ansatz hat den Vorteil, dass bei einer entsprechenden Kernel-Konfiguration mit vielen Modulen der Kernel auch auf anderer Hardware bootet, was den Umzug auf neue Hardware erleichtert.

Bei weiteren grundsätzlichen Fragen zum Kernel-Bau lohnt sich ein Blick in das Buch “Linux Kernel in a Nutshell” von Greg Kroah-Hartman [7], das sich online herunterladen oder bei O’Reilly und anderen Buchhändlern käuflich erwerben lässt. Allerdings ist das Buch auf dem Stand von 2006. Aktuellere Hinweise zu interessanten Informationsquellen für Kernel-Bauer und angehende Kernel-Entwickler liefert Kroah-Hartman im Interview ab Seite 30 in dieser Ausgabe.

Schnellbau

Eine weitere wichtige Voraussetzung vor dem Bau eines Kernels ist, dass ausreichend Festplattenplatz zur Verfügung steht. In den Tests genügten 30 GByte gerade so für den kompletten Build-Prozess.

Zum Bau des Kernels eignen sich ansonsten die Make-Targets für das Erzeugen von Debian- oder RPM-Paketen hervorragend. Sie erleichtern das Installieren und Entfernen selbst gebauter Kernel erheblich. Sobald der Kernel konfiguriert ist, erledigt dabei ein Make-Aufruf den kompletten Rest. Am Ende fällt ein Debian- oder RPM-Paket heraus, das der Nutzer über »dpkg -i« oder »rpm -i« installiert. Beim Einrichten der Pakete erstellen Distributionsskripte zudem in der Regel automatisch einen passenden Eintrag für den Bootloader (Abbildung 3).

Abbildung 3: Auch OpenSuse legt für einen neuen Kernel automatisch einen Bootloader-Eintrag an.

Das kleine Werkzeug Eatmydata steckt bei Debian und Ubuntu im gleichnamigen Paket. Es entsorgt weitgehend jegliche »fsync()«- und ähnliche Aufrufe beim Kompilieren, was den Prozess beschleunigt. Der Autor verwendet dabei auf einem Thinkpad T520 mit Dualcore-“Sandybridge”-CPU mit Hyperthreading im Verzeichnis mit dem Linux-Quelltext folgenden Aufruf:

$ eatmydata make -j4 bindeb-pkg LOCALVERSION=-tp520

Hinter der Option »-j« steht die Anzahl der CPU-Kerne, wie sie der Befehl »lscpu« ausgibt. Die fertigen Pakete landen bei Debian-basierten Distributionen direkt im übergeordneten Verzeichnis. Für Suse und Red Hat lautet der Befehl dagegen:

$ make -j2 binrpm-pkg LOCALVERSION=-vm

Bei RPM-basierten Distributionen findet sich das fertige Paket in einem Verzeichnis wie »rpmbuild/RPMS/x86_64/« im übergeordneten oder im Home-Verzeichnis (Abbildung 4). Die Variable »LOCALVERSION« enthält ein Anhängsel für die mit »uname -r« oder »cat /proc/version« ausgegebene Kernel-Version.

Abbildung 4: Dank des passenden Make-Targets (in diesem Fall »binrpm-pkg«), landet der neue Kernel auf Fedora 32 am Ende als RPM-Paket im Home-Verzeichnis.

Die gezeigten Verfahren funktionieren nur auf Distributionen, die auf DEB- oder RPM-Paketen basieren. Einen üblichen, allgemeineren Ansatz schildert ein Artikel im Arch-Wiki im Detail [8]. Statt den Kernel-Quelltext als Tarball herunterzuladen, lässt er sich auch via Git beziehen. Ein weiterer Artikel beschreibt den Arch-spezifischen Ansatz, sich eigene Kernel zu bauen [9].

Es gibt noch weitere Make-Targets, über die Kernel-Bauer wahlweise ein Verzeichnis (»dir-pkg«), einen komprimierten Tarball (»tar-pkg«, »targz-pkg«, »tarbz2-pkg«, »tarxz-pkg«) oder gar ein Snap-Paket (»snap-pkg«) erzeugen. Einen Überblick über die Möglichkeiten gibt »make help«.

Es existierte im Übrigen noch ein weiterer Ansatz für Debian, den der Autor lange Zeit verwendet hat: der Befehl »make-kpkg« aus dem Debian-Paket »kernel-package«. Diesen Weg bieten aktuelle Versionen von Debian und Ubuntu jedoch nicht mehr an.

Erfahrungen

Einen eigenen Kernel für den produktiv genutzten Laptop zu bauen, hat Vor- und Nachteile. Einerseits ist es ein guter Test für einen relativ großen Teil der Kernel-Funktionalität. Für eine Desktop-Sitzung auf einem Laptop oder PC müssen Prozess-Scheduler, Blocklayer und eine ganze Reihe von Hardware-Treibern gut funktionieren.

Andererseits ist bei einem neuen Fehler – auch Regression genannt – die Motivation stark, auf den letzten Kernel zu wechseln, der dieses Problem nicht hatte. Das ist insbesondere der Fall, wenn es sich um einen schwerwiegenden Fehler handelt. Der häufig als Stoßseufzer geäußerte Wunsch “Ich will doch nur arbeiten!” spielt hier durchaus eine Rolle. Zudem bleiben für Server- oder Cloud-Umgebungen erforderliche Funktionen mitunter ungetestet.

Wer indes auf einer nur gelegentlich genutzten Hardware oder einer virtuellen Maschine testet, löst die Bedingungen für das Auftreten eines Fehlers womöglich gar nicht aus. Auch ein automatisches Testen, auf das Kernel-Entwickler zurückgreifen, spürt nicht alle Fehler auf.

Es gelang auf den vom Autor genutzten Laptop durchaus, den ein oder anderen neuen Fehler zu finden und einzugrenzen, zuletzt beim Kernel 5.8-rc3 (Abbildung 5). Oft genug wiesen die Fehler aber auch zwei Eigenschaften auf, die die Motivation zur Aufklärung sinken lassen: Sie sorgen zum einen dafür, dass beim Arbeiten plötzlich der Mauszeiger stehen bleibt. Zum anderen passiert das nicht reproduzierbar und auch nicht sofort.

Abbildung 5: Auch beim zu Redaktionsschluss aktuellen Kernel 5.8-rc3 stieß der Autor beim Testen auf ein Problem.

Auf einem Laptop sind die Möglichkeiten zur Aufklärung in diesem Fall begrenzt. Bei einem harten Crash des Kernels gibt es in der Regel keinerlei Spuren in Systemprotokollen wie »/var/log/syslog« oder »/var/log/kern.log«. Der interessante Teil eines etwaigen Backtrace auf TTY1 war hingegen häufiger bereits aus dem sichtbaren Bereich des Bildschirms hinausgescrollt – wenn der Zugriff auf TTY1 überhaupt gelang.

Fehlerberichte ohne vollständige Rückverfolgung zur Stelle im Kernel, an der der Fehler auftritt, lassen Kernel-Entwickler regelmäßig im Dunkeln tappen. Selbst mit einem vollständigen Backtrace kann man einen Fehler nicht immer aufklären. Fehler dieser Art traten auf einem Thinkpad T520 über die Jahre vor allem beim Intel-Grafiktreiber und anderen Treibern auf. Zudem kann es vorkommen, dass ein Crash mit einem Release Candidate auftritt [10] und mit einem der folgenden wieder verschwindet (Abbildung 6).

Abbildung 6: Der Backtrace-Teil eines Crashs beim Booten mit Kernel 4.4-rc3. Die Version 4.4-rc5 ließ sich wieder einwandfrei hochfahren.

Für Fehler, die sich anders schwer aufklären lassen, gibt das Bisecting Entwicklern einen sehr guten Prozess an die Hand, um der genauen Ursache auf die Spur zu kommen. Voraussetzung ist, dass sie die letzte fehlerfreie und die erste fehlerhafte Version kennen. In diesem Fall ermittelt eine binäre Suche oft den exakten Commit, ab dem das Problem auftritt, also die genaue Änderung am Kernel. Das ist nicht immer auch die eigentliche Ursache, hilft jedoch den Entwicklern meist enorm weiter, um ihr auf die Spur zu kommen.

Beim Bisecting wählt Git zunächst einen Commit zwischen der fehlerfreien und der fehlerhaften Version. Er sollte idealerweise einigermaßen in der Mitte liegen, daher der Name Binärsuche. Der Tester kompiliert einen neuen Kernel auf dem Stand dieses Commits und testet ihn. Dann teilt er Git mit, ob dieser Kernel gut oder schlecht war, und Git wählt auf Basis dieser Information den nächsten Commit. Die binäre Suche braucht in der Regel nicht allzu viele Durchläufe, um den exakten Commit aufzuspüren.

Befindet sich die Regression jedoch zwischen zwei Release-Versionen wie 5.6 und 5.7, kommt es durchaus vor, dass Git auch Commits zwischen der letzten Release-Version und dem Release Candidate 1 wählt. Das birgt ein gewisses Risiko, dass der resultierende Kernel nicht läuft. So bootete ein solcher Kernel des Autors vor längerer Zeit gar nicht erst. Handelt es sich zudem um einen nicht reproduzierbaren Fehler, der erst nach einer gewissen Zeit auftritt, wird ein solches Bisecting sehr schnell sehr zeitaufwendig.

Für den Autor ist dies aktuell ein Grund, einen Fehler auch mal Fehler sein zu lassen. So flackerte bei seinem Thinkpad T42, das die Stereoanlage über eine USB-Soundkarte mit Musik füttert, mit den Linux-Kerneln 5.4 und 5.5 von Debian die Grafikanzeige (Mobility Radeon 9600). Daher behält diese alte Hardware erst einmal den 5.3er-Kernel. Gelegentliche Tests verraten, ob die Anzeige mit einem aktuelleren Kernel wieder funktioniert.

Zudem treten manche Fehler nur in ungewöhnlichen Konfigurationen auf. So lief der selbst kompilierte Kernel auf dem Laptop des Autors lange Zeit mit der Option »threadirqs«. Diese brachten Entwickler aus dem Realtime-Patchset für Linux in den Mainline-Kernel; sie macht Interrupts als Threads sichtbar.

Das erwies sich beim Unterrichten im Schulungscenter als nützlich: Plötzlich klappte der Netzwerkzugriff nicht mehr, und der Thread für den Ethernet-Interrupt fiel mit 100 Prozent CPU-Last auf. Im Gespräch mit einem Dozenten-Kollegen kam heraus, dass die Teilnehmer eines Netzwerkkurses eine Schleife gesteckt hatten. Auf die Idee, dass dank der Option »threadirqs« das Linux-System beim Einstecken eines USB-Sticks hart einfriert, kam der Autor zunächst nicht. Bisecting zeigte jedoch einen Zusammenhang mit Interrupts [11].

Andererseits fanden Kernel-Entwickler in der Vergangenheit hier und da die Ursache eines Problems auch ohne Bisecting sehr schnell – vielleicht weil jemand anderes den Fehler ebenfalls berichtet und einen vollständigen Bisect angefertigt hatte oder weil der Fehler aufgrund seiner Art leicht aufzuklären war. So zeigte Btrfs mit Kernel 5.5 bei der Ausgabe von Df unter bestimmten Umständen falsche Werte. Der Autor meldete dies Ende Januar 2020 [12]. Josek Bacik lieferte nach nur zwei Tagen einen Patch, der das Problem behob [13]. Greg Kroah-Hartman baute den Patch auch in die Stable Trees bis hin zur Version 4.9 ein.

Wie in vielen anderen Open-Source-Projekten blieb manch anderer im Bugtracker des Kernels berichtete Fehler hingegen lange Zeit unbeachtet. Besser funktioniert es oft, eine E-Mail an die Verantwortlichen des betreffenden Subsystems (»MAINTAINERS«-Datei) und an die passende Mailing-Liste zu schicken [14].

Fazit

Die Tests von Entwicklungsversionen des Linux Kernels ist mit einigem Aufwand verbunden. Während sich manche Fehler im Handumdrehen aufklären lassen, gehen bei anderen mehrere Stunden ins Land.

Eine besondere Hürde entsteht, wenn ein Fehler zu einem harten Einfrieren des Systems führt. Auch die Ursache eines nur gelegentlich auftretenden Fehlers lässt sich mit Bisecting nur schwer aufklären. In solchen Fällen kann der Prozess Tage dauern.

Allerdings macht es auch immer wieder Spaß, durch das Berichten und Aufklären von Fehlern zur Kernel-Entwicklung beizutragen. Für angehende Kernel-Entwickler ist es also ein wichtiger erster Schritt, den eigenen Kernel aus Git zu übersetzen und laufen zu lassen. (kki)