Garten
Eden

Woohoo! Ist es normal, so euphorisch zu sein, wenn man erfolgreich seinen ersten eigenen Kernel kompiliert hat? Egal, ich bin es.

$ uname -r

2.6.37.1-candela

Das meldet mir die Konsole seit gestern Abend. Und der Kernel läuft einwandfrei.
Es folgt eine kleine Erfolgsgeschichte bzw. wie ich vorgegangen bin.

Ist ja schön und gut – aber warum?

Natürlich darf man sich zurecht fragen, warum man sich überhaupt an die Arbeit machen sollte, sich einen Kernel zu backen, wenn es doch so viele fertige, auch aktuelle, gibt. Kurzum: Man soll/muss nicht. Trotzdem kann es gerechtfertigt sein. Das ubuntuusers-Wiki gibt die wichtigsten Gründe dafür ganz treffsicher wieder. Zitat:

• Man ist ein Kernel-Entwickler oder -Tester,
• man möchte den Kernel auf eine spezielle Art kompilieren (z.B. um experimentelle Funktionen zu nutzen),
• man besitzt Hardware, die der offizielle Ubuntu-Kernel nicht unterstützt
• oder man ist einfach nur neugierig.

Ich bin dann wohl ein Repräsentant des letzten Falles.

Und wie?

Zu meiner Vorgehensweise: Schaut man ins Internet, erschlagen einen die Informationen, die es zum Thema Kernel-Kompilierung gibt und mir ging es so, dass ich nicht wusste, welcher Quelle ich den Vorzug geben soll. Nachdem ich aber ein Werkzeug gefunden hatte, das einem den Großteil der Arbeit abnimmt, waren die meisten How-Tos und Tutorials überflüssig. Dieses magische Tool heißt KernelCheck (Debian-Paket-Download auf der Projektseite/Sourceforge).
KernelCheck lädt die Informationen zu den aktuell erhältlichen Kerneln von kernel.org und kann jeden davon automatisch herunterladen. Anschließend bietet es an, einige empfohlene Einstellungen vom Tool vornehmen zu lassen, wie z. B. die Vorkonfiguration von ALSA und Grafiktreibern. Wählt man dazu noch die benutzerdefinierte Installation, kann man über eine Konsole Patches einspielen. Für ein funktionierendes ureadahead benötigte ich z. B. einen Patch, der im ubuntuusers-Forum veröffentlicht wurde. Im Anschluss kann man die Kernelkonfiguration vornehmen und der Kompiliervorgang startet.

Und was stelle ich ein?

Ja, die Kernelkonfiguration. Damit steht und fällt die Aktion. Mit über 3600 Wahlmöglichkeiten zwischen einkompilieren oder nicht und manchmal auch noch als Modul kompilieren verliert man da schnell den Überblick – so man denn je einen hatte. Ich habe mir nach anfänglichem Schock über ihren Umfang doch die Kernel-Seeds zu Gemüte geführt, eine gut strukturierte Informationsseite über (fast) alle Kerneloptionen. Wobei ich zugeben muss, dass diese Art, jede Stellschraube einzeln abzuklappern, sehr mühsam ist. Trotzdem kann ich es allen Interessenten nur ans Herz legen – schließlich soll die gesamte Aktion ja nicht an der Faulheit scheitern. Ohne die nötige Ausdauer kann man es IMHO auch gleich sein lassen.

Wie lange dauert so eine Kernelkompilierung?

Das Kompilieren selbst dauerte auf meinem 2,3 GHz-Mobilprozessor mit 4 GB RAM ziemlich genau 30 Minuten 15 Minuten. Neben der Systemleistung ist dies aber auch vor allem von den gewählten Einstellungen abhängig – Faustregel: je mehr, desto länger. Ich habe sehr viel abgewählt, weil ich weder Funkmasten noch Netzwerk-Backbones oder 20 Jahre alte Hardware betreibe.
Deutlich mehr Zeit in Anspruch nimmt hingegen das Durchgehen der einzelnen Konfigurationen. Aber wie gesagt: Für einen gut angepassten, minimalistischen Kernel lohnt sich die Arbeit.

Trivia

• Mein erster Versuch war übrigens schon vorletzte Woche. Da hatte ich allerdings die kleine, aber feine Option CONFIG_RFKILL nicht gesetzt, was dazu führte, dass mein WLAN inklusive Bluetooth nur aktiviert wurde, wenn ich den Hardware-Schalter dafür vor dem Systemstart umlegte bzw. im laufenden Betrieb die WLAN-Module rund um iwlagn neulud. Daraufhin dachte ich mir, dass ich nun auch warten kann, bis das erste Update zum neuen 2.6.37-er Kernel erscheint. Wie das Leben so spielt, hat dieses Minor-Release historisch lange auf sich warten lassen.
• Image und Headers haben bei mir nun einen Umfang von zusammen 23 MB 16 MB. Zum Vergleich: Der Mainline-Kernel wiegt 44 MB.
• Es existiert ein Video, das eine Beispielkompilierung zeigt. Das ist vielleicht ganz praktisch zum Verständnis des Patchens.
• Ich sage es vielleicht noch einmal ausdrücklich: Einen eigenen Kernel zu kompilieren kann Spaß machen und sinnvoll sein. Trotzdem bringt es nicht immer etwas und man kann damit auch Schaden anrichten, weswegen man es sich eventuell zweimal überlegen sollte.

Fazit

Was will ich mit diesem Beitrag sagen? Vielleicht, dass es Spaß machen kann, so tief in ein System einzugreifen. Dass es in Linux mehr Stellschrauben gibt, als man sieht. Dass auf dieser Ebene eine ungeheure, selten geschätzte Arbeit liegt.
Vielleicht auch, dass Linux-Nutzer zu sein so vieles heißen kann. Wenn man will, benutzt man es wie andere (Multimedia-)Betriebssysteme auch. Möchte man aber mehr, so steht einem auch das frei.
Zu viel erwarten darf man allerdings nicht. Wenn man nicht gerade auf Bleeding-Edge-Treiber aus dem neusten Kernel angewiesen ist, wird sich das erlebte System nicht deutlich von einem mit vorkompiliertem Kernel unterscheiden.

Also: Man kann sich einen eigenen Kernel backen. Man kann es aber auch sein lassen.

Update am 11.03.2011 18:21