Home
Über die LugBE | Mailing List | Treff & Events | Projekte | lost+found | Support

Kernel Kompilieren

Vortrag von Cedric Bösiger (mit tatkräftiger Unterstützung von Mathias Gygax)

16. Januar 2003

Wohl die meisten Linux-Anwender sind schon einmal vor der Frage gestanden, ob sie wohl für ihr System einen neuen Kernel kompilieren müssen.

Und der grösste Teil wird diese Aufgabe schon - mehr oder weniger erfolgreich - hinter sich gebracht haben. Der Vortrag richtete sich daher explizit an diejenigen, die noch nie einen Kernel kompiliert oder ein Kernel-Upgrade gemacht hatten, oder daran gescheitert waren. Überraschenderweise fand das Thema trotz der kurzen Ankündigungsfrist von nur zwei Tagen reichlich Anklang, so dass der kleine Saal im Beaulieu mit rund 20 Besuchern mehr als nur gut belegt war. Dieser Andrang überforderte denn auch prompt das Servicepersonal, so dass zwischen Bestellung und Lieferung der notwendigen Verpflegung der Beginn des Vortrags selbst immer weiter hinausgeschoben werden musste - gegen 21.00 Uhr waren dann schliesslich alle soweit.

Die heute gängigen Distributionen installieren bei der Erstinstallation meist einen speziell angepassten Kernel und stellen weitere als vorkonfigurierte Pakete (im jeweiligen Paketmanagement-Format, etwa .deb oder .rpm) zur Verfügung. Diese Pakete können von den jeweils bekannten Download-Servern der Distributoren bezogen werden. Aber darum ging es an diesem ersten Off-Event im neuen Jahr 2003 nicht. Stattdessen wollten wir einen Blick darauf werfen, wie man einen Kernel selbst konfiguriert, kompiliert und installiert, was es mit den Modulen auf sich hat und worauf man besonders achten muss.

Zu den Themen gibt es natürlich reichlich Literatur im Netz (etwa beim Linux Documentation Project, die Howto-Quelle schlechthin, wo es beinahe für alles eine detaillierte Anleitung gibt, was irgendwie unter Linux läuft). Doch auch der Kernel-Source selbst ist umfassend dokumentiert: Das Verzeichnis /usr/src/linux/documentation ist bei Problemen meist die erste Anlaufstelle. Es macht daher wohl keinen Sinn, wenn wir hier den ganzen Vorgang im Detail noch einmal beschreiben.

Der Linux-Kernel steht gänzlich unter der GPL, und daher ist auch der Sourcecode dazu auf www.kernel.org frei verfügbar. Erster Schritt also: Den Kernel-Source herunterladen. Sollte man noch zusätzliche Features oder Treiber brauchen, die im Hauptzweig des Kernels nicht enthalten sind, braucht man noch die entsprechenden "Patches". (Ein Patch ist ergänzender Sourcecode, der vor dem Kompilieren in den Kernel-Sourcecode integriert wird, meistens mit Hilfe des patch-Befehls.)

Der Kernel-Source muss unter /usr/src/linux entpackt werden. Achtung: Besteht dieses Verzeichnis schon (oder ist als Link auf ein anderes vorhanden), wird es überschrieben! Es zahlt sich aus, ein bestehendes Verzeichnis umzubenennen oder den entsprechenden Link zu löschen, bevor der neue Kernel-Source entpackt wird.

Der Vortrag entwickelte sich bald zu einer Parallel-Konferenz: Während Cedric die einzelnen Schritte der Kernel-Konfiguration im Überblick erklärte, fielen Mathias zu jedem Punkt noch interessante Details ein (als "Randnotizen" getarnt), die er den Zuhörern nicht vorenthielt (etwa, dass um einen CD-Brenner oder eine USB-Digitalkamera zu betreiben, die SCSI-Unterstützung im Kernel vorhanden sein muss, oder dass auf Servern, die höchsten Sicherheitsansprüchen genügen müssen, das dynamische Laden von Kernel-Modulen nicht möglich sein sollte, und noch viele wertvolle Tipps mehr). Ermuntert von dem lebhaften, nicht geplanten Doppelvortrag meldeten sich bald auch andere, erfahrenere Linuxer zu Wort, und zwischen den Fragen aus dem Publikum, den entsprechenden Antworten und den weiteren Punkten des Vortrags entwickelte sich eine angeregte Diskussion über "anything 'kernel'".

Hier nur zwei Themen, die dabei angesprochen wurden:

Was gewinne ich durch die Verwendung von Modulen?

Module sind Kernel-Teile, die Unterstützung für bestimmte Features oder Hardware bereitstellen. Beinahe jede Kernel-Funktion kann entweder fix im Kernel einkompiliert oder als Modul separat kompiliert werden. Bei Bedarf (gesteuert über Major- und Minor-Device-Numbers des Devices und die Dateien /etc/modules.conf und /lib/modules/<kernel-version>/modules.dep) lädt der laufende Kernel das benötigte Modul nach.

Vorteile dieses Vorgehens:
- Bessere Performance, da nur das im Speicher geladen ist, was wirklich benötigt wird
- Kürzere Boot-Zeiten
- Weniger Gefahrenquellen für Fehler im Code (Stabilität)
- Flexibilität: Neue Hardware kann einfach eingebunden werden, ohne dass jedesmal der ganze Kernel neu kompiliert werden muss.

Mögliche Nachteile:
- Treiber, die schon beim Booten benötigt werden, stehen dort noch nicht zur Verfügung (fix einkompilieren!)
- Wird ein Rechner gehackt, kann der Eindringling Kernel-Module laden, die seine Aktivitäten verschleiern

Warum muss man überhaupt selber einen Kernel kompilieren, wo doch von der Distribution schon einer installiert wurde?

Der Zweck des Kernel-Kompilierens ist in erster Linie, den Kernel an die Hardware des Rechners und an den Verwendungszweck des Systems anzupassen. Der von den Distributionen installierte Kernel muss natürlich sehr generisch ausgelegt sein, da er ja alle mögliche Hardware von vornherein unterstützen muss und auch für jeden Zweck verwendbar sein muss. Daher enthalten diese Kernel meist wesentlich mehr, als für den Betrieb wirklich benötigt wird, angefangen von zehn verschiedenen Dateisystemtypen über IPX und Appletalk bis hin zu Mainframe-Erweiterungen. Während das für Workstations noch angehen mag, ist es bei einem Server oder Router sicherlich angebracht, einen speziellen, extra für diesen Anwendungszweck optimierten Kernel zu erstellen. Aber auch bei Workstations macht sich eine Anpassung an die eigene Hardware angenehm in der Performance bemerkbar.
Unumgänglich wird das selbst Kompilieren, wenn man Hardware hat, die vom bereits installierten Kernel nicht unterstützt wird.

Cedric versuchte, uns am laufenden System einen Upgrade von Kernel 2.2.201 auf 2.5.58 vorzuführen, und wie zur Warnung, dass man - bei allem Komfort, den die Konfigurationstools make menuconfig oder make xconfig inzwischen bieten - sich doch noch konzentrieren muss dabei (leicht gesagt bei einem Saal mit 20 neugierigen Fragestellern;-), verweigerte der neue Kernel dann auch prompt den Dienst. Glücklich diejenigen, die den vorherigen Kernel noch nicht gelöscht oder überschrieben und im Bootloader-Menü noch eingetragen haben.

Und zum Schluss doch noch im Schnelldurchlauf die Schritte zum Kernel:

Kernel Source herunterladen (www.kernel.org)
Nach /usr/src/linux entpacken
cd /usr/src/linux
make menuconfig
(Konfigurationstool)
make dep
make bzImage
make modules
make modules_install
Kernel-Image (bzImage) und Symboltabelle (System.map) von Hand nach /boot kopieren
oder
make install
(Backup nicht vergessen!!!)
Bootloader konfigurieren (/etc/lilo.conf bzw. /boot/grub/menu.lst)
reboot

Wenn alles gut gelaufen ist: Glückwunsch zum neuen Linux-System!

Was vom Abend noch übrig blieb, wurde u.a. dazu verwendet, eine Knoppix-CD für die Schweiz anzupassen (Jäggi-Stand am 22. Februar) und zu überlegen, wie die weibliche Komponente in der LugBE gefördert werden könnte. Spät, aber doch warf man uns schliesslich höflich hinaus an die frische Nachtluft.
Bis zum nächsten Mal.

Markus


Webmaster at lugbe.ch

Die Artikel dieser Seite stehen unter Copyleft ihrer jeweiligen Autor*innen. Ihre Nutzung, Wiedergabe etc. untersteht den Bedingungen der GNU Free Documentation License (http://www.gnu.org/copyleft/fdl.html), wo nicht explizit anders vermerkt.