Copyright © 1995 by O'Reilly/International Thomson Verlag

Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen.

Wünschen Sie mehr Informationen zu der gedruckten Version des Buches "Linux - Wegweiser zur Installation & Konfiguration", dann klicken Sie hier.


Kapitel 4

Einen neuen Kernel erstellen

Das Neukompilieren des Kernels scheint des Hackers Steckenpferd zu sein, aber es ist eine wichtige Aufgabe für jeden Systemverwalter. Zunächst einmal werden Sie wahrscheinlich einen neuen Kernel für Ihr System erstellen, um nicht benötigte Treiber zu entfernen. Dadurch verringern Sie den Speicherbedarf für den Kernel selbst -- wir haben schon im Abschnitt » Swap-Space benutzen « darauf hingewiesen, daß der Kernel ständig im Arbeitsspeicher residiert, und daß der vom Kernel belegte Speicher bei Bedarf nicht mehr von anderen Programmen benutzt werden kann.

Gelegentlich werden Sie eine neue Version des Kernels einspielen müssen. Auch für den Kernel gilt, ebenso wie für andere Teile Ihres Systems, daß Sie sicherlich auf dem aktuellen Stand bleiben wollen, wenn wichtige Fehler behoben oder neue Bestandteile in den Kernel integriert werden. Die Leute, die aktiv an der Entwicklung des Kernels teilhaben, werden ihren Kernel für den Fall aktualisieren müssen, daß es Änderungen an dem Code gegeben hat, an dem Sie arbeiten. Manchmal wird ein neuer Kernel benötigt, damit eine neue Version des Compilers oder der Libraries benutzt werden kann. Einige Anwendungen (etwa das X Window System) laufen erst ab einer bestimmten Kernel-Version.

Der Befehl uname -a zeigt Ihnen an, mit welcher Version des Kernels Sie arbeiten. Die Ausgabe sollte etwa so aussehen:

rutabaga% uname -a 
Linux rutabaga 1.1.37 #6 Wed Nov 16 17:50:50 EST 1994 i486

In diesem Fall handelt es sich um einen Rechner mit der Version 1.1.37 des Kernels, der zuletzt am 16. November kompiliert wurde. Es werden noch weitere Informationen angezeigt, z.B. der Name des Rechners, wie oft dieser Kernel kompiliert wurde (sechs mal) sowie die Angabe, daß es sich um einen 486er handelt. In der Man-Page zu uname erfahren Sie mehr hierzu.

Der Linux-Kernel ist ein Ungeheuer mit vielen Fangarmen. Etliche Gruppen von Leuten arbeiten an verschiedenen Teilen des Kernels, und Teile des Codes wirken wie ein Flickenteppich aus den unterschiedlichsten Ideen. Insgesamt gesehen ist der Kernel-Code trotzdem brauchbar und einheitlich und wer Lust hat, sein Innenleben zu erkunden, wird dabei kaum auf Probleme stoßen. Allerdings werden aufgrund der intensiven Entwicklungsarbeiten neue Versionen in rascher Folge freigegeben -- manchmal täglich. Der Hauptgrund dafür ist, daß fast alle Gerätetreiber im Kernel-Code enthalten sind; mit jeder Aktualisierung eines Treibers wird also auch eine neue Kernel-Version fällig. Mit der Einführung von ladbaren Gerätetreibern sind die Entwickler allerdings in der Lage, die Treiber unabhängig vom eigentlichen Kernel herauszugeben, wodurch auch die Notwendigkeit für solche schnellen Versionswechsel entfällt.

Derzeit pflegt Linus Torvalds die »offizielle« Version des Kernels. Obwohl die General Public License es jedermann freistellt, den Kernel zu ändern und unter demselben Copyright wieder zu veröffentlichen, ist es doch sehr hilfreich, daß Linus einen »offiziellen« Kernel pflegt. Dadurch ist sichergestellt, daß die Versionsnummern einheitlich bleiben und daß alle dasselbe meinen, wenn von Kernel-Revisionen die Rede ist. Wer einen Fehler beheben oder neuen Code einfügen möchte, muß das Ganze nur an Linus schicken, der solche Änderungen meistens aufnimmt, solange andere Teile des Systems nicht beeinträchtigt werden.

Die Versionsnummern des Kernels sind folgendermaßen aufgebaut:

major.minor.patchlevel
Major ist die Major Number (etwa: Haupt-Versionsnummer), die sich nur selten ändert. Minor ist die Minor Number (etwa: Neben-Versionsnummer), die die »Entwicklungslinie« der aktuellen Kernel-Version angibt, und Patchlevel ist die Nummer des Patches (etwa: Ausbesserung) am aktuellen Kernel. Beispiele für Versionsnummern sind 1.0.5 (Patchlevel 5 der Kernel-Version 1.0) und 1.1.52 (Patchlevel 52 der Kernel-Version 1.1).

Es hat sich eingebürgert, »stabile« Versionen mit geraden Nummern zu bezeichnen (1.0, 1.2, 1.4 usw.). Die Patches zu diesen Versionen enthalten nur Korrekturen (bug fixes), aber keinen neuen Code. Die Versionen mit ungeraden Nummern (1.1, 1.3, 1.5 usw.) sind »Entwickler«-Versionen (development releases), deren Patches sowohl Korrekturen (bug fixes) enthalten als auch neuen Code, den die Entwickler beigesteuert haben. Wenn ein Entwickler-Kernel so weit gereift ist, daß er für den allgemeinen Einsatz stabil genug läuft, wird er umbenannt und erhält die nächsthöhere (gerade) Minor Number; danach beginnt der Entwicklungskreislauf von vorne.

Ein Beispiel: Nehmen wir an, daß derzeit an den Kernel-Versionen 1.2 (der aktuellen stabilen Version) und 1.3 (der aktuellen Hacker-Version) gearbeitet wird. Die Patches zur Version 1.2 enthalten Bug-fixes -- damit sollen nur Fehler im bestehenden Code behoben werden. Die Patches zur Version 1.3 enthalten sowohl Korrekturen als auch eine ganze Menge neuen Programmcodes -- neue Gerätetreiber, neue Funktionen usw. Wenn die Kernel-Version 1.3 stabil genug erscheint (etwa mit der Revision 1.3.65), wird sie in 1.4 umbenannt, und eine Kopie davon wird zur Version 1.5 Anschließend werden die Versionen 1.4 und 1.5 weiterentwickelt; 1.4 ist dann der neue »stabile« Kernel, während 1.5 der Entwickler-Kernel für Erweiterungen des Codes ist.

Diese Konvention der Versionsnumerierung gilt nur für die von Linus freigegebenen offiziellen Kernel-Versionen nach Version 1.0. Vor der Version 1.0 (wenn Sie dieses Buch lesen, wird das schon Geschichte sein) gab es nur einen aktuellen Kernel, der ständig gepatcht wurde. In der Entwicklergemeinde hat man festgestellt, daß der Entwickler-Kernel für experimentierfreudige Benutzer geeignet ist, während der stabile Kernel für die Benutzer gedacht ist, die ein zuverlässiges System brauchen. Auf diese Weise erleiden die Benutzer des stabilen Kernels keinen Schaden, wenn der Entwickler-Kernel durch neuen Code einmal unbrauchbar wird.

Im allgemeinen sollten Sie den Entwickler-Kernel nur dann benutzen, wenn Sie Wert darauf legen, stets die neuesten Möglichkeiten des Kernels zu nutzen und bereit sind, Probleme mit Ihrem System zu akzeptieren. Die Benutzung des Entwickler-Kernels geschieht auf eigene Gefahr.

Der Kernel-Quellcode Ihres Systems steht in /usr/src/linux . Wenn Sie den Kernel mit den vorhandenen Quelltexten neu kompilieren möchten, brauchen Sie keine Dateien zu besorgen oder Patches einzuspielen. Wenn Sie auf eine neue Version des Kernels umsteigen möchten, sollten Sie der Anleitung im folgenden Abschnitt folgen.

Kernel-Quelltexte besorgen

Der offizielle Kernel wird als gzip-te tar-Datei herausgegeben, die sowohl die Quelltexte als auch eine Reihe von Patches enthält -- einen pro Patchlevel. Die tar-Datei enthält die Quellen der ungepatchten Version; es existiert z.B. eine tar-Datei mit den Quellen zur Kernel-Version 1.3 ohne Patches. Jeder Patchlevel wird in Form einer Datei veröffentlicht, die mit dem Befehl patch eingespielt wird (die Datei selbst wird mit dem Befehl diff erstellt.)

Im Abschnitt » Dateien patchen « in Kapitel 6 beschreiben wir die Benutzung von patch im Detail.

Nehmen wir an, Sie möchten auf die Kernel-Version 1.3 Patchlevel 15 updaten. Sie brauchen dazu die Quellen zu Version 1.3 (die Datei könnte den Namen v1.3.0.tar.gz haben) sowie die Dateien mit den Patchlevels 1 bis 15. Diese Dateien heißen patch1 , patch2 usw. (Sie brauchen alle Patchlevels bis zu der Version, auf die Sie aufsteigen wollen. Meistens sind diese Dateien ziemlich klein und in gepackter Form auf den Archivservern vorhanden.) Sie finden alle diese Dateien im Verzeichnis kernel der Linux-FTP-Server; auf sunsite.unc.edu z.B. heißt das Verzeichnis mit den Kernel-Quellen der Version 1.3 und den Patches dazu /pub/Linux/kernel/v1.3 .

Die Quelltexte entpacken

Als erstes müssen Sie die tar-Datei mit den Quelltexten von /usr/src aus entpacken. Geben Sie dazu folgende Befehle ein:

rutabaga# cd /usr/src 
rutabaga# mv linux linux.old 
rutabaga# tar xzf v1.3.0.tar.gz

Damit sichern Sie die alten Kernel-Quellverzeichnisse nach /usr/src/linux.old und legen /usr/src/linux an, in dem die neuen Quellen stehen. Beachten Sie, daß die tar-Datei mit den Quelltexten das Unterverzeichnis linux bereits enthält .

Sie sollten die Quelltexte des aktuellen Kernels im Verzeichnis /usr/src/linux stehenlassen. Dies hängt damit zusammen, daß es zwei symbolische Links gibt -- /usr/include/linux und /usr/include/asm -- , die auf den Verzeichnisbaum des aktuellen Kernels verweisen, um beim Kompilieren von Programmen bestimmte Header-Dateien bereitzustellen. (Sie sollten die Kernel-Quellen immer im Zugriff haben, damit Programme, die diese Include-Dateien benutzen, kompiliert werden können.) Falls Sie mehrere Kernel-Verzeichnisbäume im System behalten wollen, müssen Sie sicherstellen, daß /usr/src/linux auf den jeweils aktuellen verweist.

Die Patches einspielen

Wenn Sie irgendwelche Patches einspielen möchten, benutzen Sie dazu das Programm patch . Nehmen wir an, daß Sie die gepackten Dateien patch1.gz bis patch15.gz vorliegen haben. Diese Patches sollten von /usr/src aus eingespielt werden. Das heißt nicht, daß die Dateien selbst dort stehen sollen, sondern daß Sie patch von /usr/src aus aufrufen sollten. Für jede der Dateien können Sie folgenden Aufruf von /usr/src aus starten:

gunzip -c patchdatei | patch -p0

Die Option -p0 weist patch an, von den Dateinamen innerhalb der Patch-Dateien keine Namensteile zu entfernen.

Die Patches müssen einer nach dem anderen in numerischer Reihenfolge eingespielt werden. Dies ist sehr wichtig. Bedenken Sie, daß die Benutzung eines Wildcards wie patch* nicht funktioniert -- das liegt daran, daß der * die ASCII-Sortierung benutzt und nicht die numerische Reihenfolge einhält. (Sie würden sonst nach patch1 die Dateien patch10 und patch11 statt patch2 und patch3 eingespielt bekommen.) Es ist wirklich das beste, diesen Befehl für jede der Patch-Dateien einzeln von Hand aufzurufen. Auf diese Weise stellen Sie sicher, daß die Dinge in der richtigen Reihenfolge ablaufen.

Mit dieser Vorgehensweise sollten beim Patchen Ihrer Quellen keine Probleme auftauchen, solange Sie die Patches nicht in der verkehrten Reihenfolge einspielen oder einen Patch mehrmals applizieren. Lesen Sie die Man-Page zu patch , falls Sie doch Schwierigkeiten haben. Wenn Sie gar nicht weiterkommen, sollten Sie das neue Kernel-Verzeichnis löschen und mit der Original-tar-Datei von vorne anfangen.

Mit den Befehlen:

find /usr/src/linux -follow -name "*.rej" -print 
find /usr/src/linux -follow -name "*#" -print

können Sie überprüfen, ob die Patches korrekt eingespielt wurden. Damit erhalten Sie eine Liste aller Dateien, die »zurückgewiesenen« Code aus dem Patch-Vorgang enthalten. Wenn solche Dateien existieren, befinden sich darin Teile der Patch-Dateien, die aus irgendeinem Grunde nicht eingespielt werden konnten. Schauen Sie sich diese Dateien an; wenn das nicht weiterhilft, fangen Sie noch einmal von vorne an. Sie können nicht davon ausgehen, daß Ihr Kernel kompiliert wird und korrekt funktioniert, solange das Patchen nicht ohne Zurückweisungen beendet wurde.

Den Kernel kompilieren

Sie können einen neuen Kernel unabhängig davon erstellen, ob Sie die Kernel-Quellen aktualisiert haben oder nicht. Der wichtigste Grund für die Neukompilierung ist entweder ein Update oder der Wunsch, den vorhandenen Kernel zu verkleinern, indem nicht benötigte Treiber entfernt werden.

Sechs Schritte führen Sie zu einem neuen Kernel, und diese sollten ohne Stolpern durchführbar sein (all diese Schritte werden auf den nächsten Seiten detaillierter beschrieben):

  1. Rufen Sie make config auf und beantworten Sie eine Reihe von Fragen nach den benötigten Treibern.

  2. Rufen Sie make dep auf, um Abhängigkeiten der Quelldateien festzustellen und in die verschiedenen Makefiles einzutragen.

  3. Wenn Sie vorher schon von diesem Verzeichnisbaum aus einen Kernel erstellt haben, rufen Sie make clean auf, damit alte Objektdateien entfernt werden und eine komplette Neukompilierung stattfindet.

  4. Starten Sie die Kompilierung des Kernels mit make zImage .

  5. Gehen Sie einen Kaffee trinken (oder zwei; das hängt von der Geschwindigkeit Ihres Rechners und dem verfügbaren Arbeitsspeicher ab).

  6. Installieren Sie die neue Kopie des Kernels entweder auf einer Diskette oder mittels LILO.

Alle diese Befehle werden von /usr/src/linux aus aufgerufen -- außer Schritt 5, den Sie sonstwo durchführen können.

Zu den Kernel-Quelltexten gehört eine README -Datei, die auf Ihrem System unter /usr/src/linux/README stehen sollte. Lesen Sie diese Datei. Sie finden dort aktuelle Hinweise zur Kompilierung des Kernels, die neuer sein könnten als die Hinweise in diesem Buch. Befolgen Sie die Anweisungen im README und nehmen Sie die Erläuterungen in diesem Buch zuhilfe.

Der erste Schritt ist der Aufruf von make config . Damit wird ein Skript gestartet, das Ihnen eine Reihe von Ja/Nein-Fragen nach den benötigten Treibern stellt. Zu jeder Frage gibt es eine voreingestellte Antwort, aber seien Sie vorsichtig -- diese Voreinstellungen entsprechen nicht unbedingt dem, was Sie wollen. Der Aufruf von make config bringt einige Prompts auf den Bildschirm, die wir weiter unten zeigen.

Beantworten Sie einfach die Fragen, indem Sie entweder mit ENTER die Vorgabe bestätigen oder y bzw. n (und dann ENTER) eingeben. Nicht alle Fragen akzeptieren eine Ja/Nein-Antwort; eventuell müssen Sie eine Zahl oder einen anderen Wert eingeben. Mit den Eingaben, die Sie hier machen, wird bei der nächsten Kompilierung in diesem Verzeichnisbaum der Kernel erstellt.

/bin/sh Configure 
*
* General setup
*
Kernel math emulation (CONFIG_MATH_EMULATION) [n] 
Normal harddisk support (CONFIG_BLK_DEV_HD) [y] 
XT harddisk support (CONFIG_BLK_DEV_XD) [n] 
Networking support (CONFIG_NET) [n] 
Limit memory to low 16MB (CONFIG_MAX_16M) [n] 
System V IPC (CONFIG_SYSVIPC) [y] 
Use -m486 flag for 486-specific optimizations (CONFIG_M486) [y] 
 ... und so weiter ...  
The linux kernel is now hopefully configured for your setup.
Check the top-level Makefile for additional configuration,
and do a 'make dep ; make clean' if you want to be sure all
the files are correctly re-made

Wenn Sie sich mit der Hardware Ihres Systems auskennen, sollten die Fragen leicht zu beantworten sein. Die folgenden Fragen stammen aus der Kernel-Konfiguration der Version 1.1. Wenn Sie andere Patches eingespielt haben oder eine neuere Version des Kernels benutzen, kann es sein, daß weitere Fragen erscheinen.

Kernel math emulation
Antworten Sie mit Ja (y), wenn Sie keinen mathematischen Koprozessor in Ihrem Rechner haben. Dies ist notwendig, damit der Kernel einen Koprozessor emulieren kann.

Normal harddisk support
Hier sollten fast alle Benutzer mit Ja antworten; damit werden die Treiber für die gängigen Festplattentypen aktiviert.

XT-Festplatte
Antworten Sie hier nur dann mit Ja, wenn Sie einen alten XT-Festplattencontroller benutzen. Die meisten Leute brauchen diesen Treiber nicht.

Networking support
Antworten Sie mit Ja, wenn Sie Unterstützung entweder für TCP/IP, Ethernet, Loopback oder SLIP im Kernel benötigen. In Kapitel 7 gehen wir im Detail auf diesen Punkt ein.

Limit memory to low 16MB
Wahrscheinlich werden Sie hier mit Nein antworten, auch wenn Sie weniger als 16 Megabytes an Speicher haben. Diese Option behebt die Probleme, die einige Systeme mit dem Zugriff auf Speicher oberhalb von 16 MBytes haben.

System V IPC
Mit einem Ja auf diese Frage binden Sie die Unterstützung für die IPC-Funktionen (interprocess communication) von System V ein. Dazu gehören z.B. msgrcv und msgsnd . Einige Programme, die von System V portiert wurden, brauchen die IPC; Sie können mit Ja antworten -- es sei denn, Sie haben eine starke Aversion gegen IPC.

Use -m486 flag for 486-specific optimizations
Wenn in Ihrem System ein 486er oder Pentium-Prozessor steckt, sollten Sie hier mit Ja antworten. Auch bei einem 386er kann das Ja nicht schaden. Hiermit wird lediglich an einigen Stellen die Kompilierung des Kernel-Codes für die 486er und Pentium-Prozessoren optimiert.

SCSI support
Wenn Sie irgendeinen SCSI-Controller in Ihrem System haben, antworten Sie mit Ja. Sie werden eine Reihe von Fragen zu den SCSI-Geräten in Ihrem System gestellt bekommen; klären Sie vorab, welche Hardware Sie installiert haben. Ohne SCSI-Hardware sollten Sie mit Nein antworten; dadurch wird der kompilierte Kernel erheblich kleiner.

CD-ROM drivers
Hier folgt eine Reihe von Fragen zu den Nicht-SCSI-CD-ROM-Laufwerken, die der Kernel unterstützt. Dazu gehören z.B. das Sony CDU31A/33A, Mitsumi, das SoundBlaster Pro CD-ROM usw.

Filesystems
Es folgt eine Reihe von Fragen zu den Dateisystemen, die der Kernel unterstützt. Im Abschnitt » Mit Dateisystemen arbeiten « werden wir auf die Dateisysteme eingehen, die Linux unterstützen kann. Hier können Sie bestimmen, für welche Dateisysteme Sie die Unterstützung einbinden möchten. Die meisten Systeme sollten die Dateisysteme Minix, Second Extended und /proc unterstützen. Wenn Sie direkt von Linux aus auf Ihre DOS-Daten zugreifen wollen, sollten Sie die Unterstützung für das DOS-Dateisystem einbinden. Für den Zugriff auf CD-ROM-Daten brauchen Sie das ISO-9660-Dateisystem (das die meisten CD-ROMs benutzen).

Parallel printer support
Dies beinhaltet die Unterstützung einiger Routinen für die parallelen Schnittstellen, an die Drucker angeschlossen werden. Falls Sie mit Ihrem System einen Drucker benutzen möchten, antworten Sie mit Ja.

Mouse support
Verschiedene Maustypen (insbesondere »Busmäuse«, welche nicht die serielle Schnittstelle benutzen) benötigen einen eigenen Kernel-Treiber. Einige Maustypen werden abgefragt, darunter Logitech, PS/2 und die Busmaus von Microsoft. Beantworten Sie die entsprechende Frage mit Ja, wenn bei Ihnen eines dieser käsefressenden, haarigen Tiere herumläuft.

Selection (cut and paste for virtual consoles)
selection ist ein nettes Maus-Tool, mit dem Sie Texte zwischen virtuellen Konsolen hin- und herkopieren können -- so ähnlich, wie das unter xterm geschieht. Dies kann sehr hilfreich sein, wenn Sie nur mit der textorientierten Bedienoberfläche arbeiten. Auf Ihrem System sollte eine Man-Page zu selection existieren; es ist in den meisten Distributionen enthalten. selection selbst läuft als Dämon, der die Mausunterstützung überwacht, aber es braucht auch Unterstützung im Kernel für den Zugriff auf die Puffer der virtuellen Konsolen. Antworten Sie mit Ja, wenn Sie die Maus auf diese Weise einsetzen wollen.

Tape support
Der Kernel unterstützt verschiedene Typen von Treibern für Streamer, und zu jedem Treiber werden Ihnen Fragen gestellt. Enthalten sind u.a. Treiber für QIC-02- und QIC-117-Laufwerke; letzterer wird für »Floppy«-Streamer benutzt. Der primäre Treiber für diese Laufwerke ist ein ladbares Modul. Im Abschnitt » Die ladbaren Gerätetreiber « und in der HOWTO-Datei zum Linux-Ftape finden Sie weitere Details.

Sound card support
Wenn Sie auf diese Frage mit Ja antworten, werden Ihnen mehrere Fragen zu Ihrer Soundkarte gestellt; zu den Treibern, die Sie installieren möchten sowie zum IRQ und zur Adresse Ihrer Soundkarte.

Kernel profiling support
Wenn Sie diese Option aktivieren, wird in den Kernel Programmcode eingebunden, der die Leistung des Kernels überwacht sowie andere nützliche Debugging-Informationen anzeigt. Diese Programme erfordern einiges an Systemzeit und können den Rechner verlangsamen. Solange Sie nicht an einem ganz bestimmten Kernel-Problem arbeiten, sollten Sie diese Option mit Nein beantworten.

Nachdem Sie make config beendet haben, werden Sie aufgefordert, das »Top-level-Makefile«, also /usr/src/linux/Makefile , zu editieren. In den meisten Fällen wird das gar nicht notwendig sein. Wenn Sie vorhaben, Compileroptionen für den Kernel oder die Voreinstellungen für Root oder den Videomodus zu ändern, können Sie das Makefile entsprechend anpassen. Im Abschnitt » Von einer Diskette booten « haben wir gezeigt, wie Sie die Einstellung für Root und den Videomodus problemlos auch mit rdev in einer fertig kompilierten Kopie des Kernels vornehmen können.

Der nächste Schritt ist der Aufruf von make dep . Damit wird eine Reihe von Befehlen aufgerufen, die den Verzeichnisbaum durchsuchen und Abhängigkeiten der Quelldateien feststellen. Gleichzeitig werden zusätzliche Informationen in die verschiedenen Makefiles eingetragen. (Falls Sie wirklich wissen möchten, was hier passiert: Die Makefiles werden um Regeln ergänzt, die dafür sorgen, daß Programmcode neu kompiliert wird, wenn beispielsweise eine Header-Datei geändert wurde, die in einer Quelldatei eingebunden war.) Dieser Schritt sollte nicht länger als etwa fünf oder zehn Minuten dauern.

Wenn Sie eine komplette Neukompilierung des Kernels erzwingen möchten, sollten Sie an dieser Stelle make clean aufrufen. Damit werden alle Objektdateien aus diesem Verzeichnisbaum entfernt, die bei einer früheren Kompilierung erzeugt wurden. Wenn Sie von diesem Verzeichnisbaum aus noch nie einen Kernel erstellt haben, können Sie sich diesen Schritt wohl ersparen (obwohl damit kein Schaden angerichtet wird). Falls Sie den Kernel nur an wenigen Stellen geändert haben, sollten Sie diesen Schritt vielleicht auslassen, damit nur die geänderten Dateien neu kompiliert werden. Auf jeden Fall stellen Sie mit dem Aufruf von make clean einfach sicher, daß der ganze Kernel »von Grund auf« neu kompiliert wird. Falls Sie irgendwelche Zweifel haben, geben Sie diesen Befehl ein, um auf der sicheren Seite zu bleiben.

Jetzt sind Sie soweit, daß Sie den Kernel kompilieren können. Rufen Sie dazu make zImage auf. Es empfiehlt sich, den Kernel zu erstellen, wenn die Systemlast nur gering ist, so daß der größte Teil des Arbeitsspeichers für die Kompilierung genutzt wird. Falls weitere Benutzer auf dem System arbeiten oder Sie eine große Anwendung (wie das X Window System oder einen anderen Compilerlauf) starten, kann die Kernel-Kompilierung bis zum Kriechgang abgebremst werden. Das Zauberwort hier heißt Arbeitsspeicher. Eine langsame CPU kann die Kompilierung ebenso schnell erledigen wie eine schnellere CPU, wenn Sie nur genug RAM zur Verfügung hat.

Die Zeit für die Kernel-Kompilierung kann irgendwo zwischen zehn Minuten und einigen Stunden betragen -- das hängt von Ihrer Hardware ab. Der Kernel umfaßt eine ganze Menge Code -- deutlich mehr als ein Megabyte -- seien Sie also nicht überrascht. Langsamere Systeme mit vier Megabytes an RAM (oder weniger) müssen mehrere Stunden für die komplette Kompilierung ansetzen; schnellere Rechner mit mehr Speicher können nach weniger als einer halben Stunde fertig sein. Hier zeigen sich die Unterschiede zwischen den Systemen.

Wenn während der Kompilierung Fehler oder Warnungen auftreten, können Sie nicht davon ausgehen, daß der kompilierte Kernel korrekt funktioniert. In den meisten Fällen (allerdings nicht immer) wird die Kompilierung beim Auftreten eines Fehlers abgebrochen. Fehler können nach verkehrt eingespielten Patches, bei Problemen mit make config und make dep oder aufgrund von echten Fehlern im Code auftreten. In den »sicheren« Versionen des Kernels treten Programmierfehler nur äußerst selten auf, während die Entwickler-Kernel und neue Treiber im Teststadium durchaus fehlerhaft sein können. Im Zweifelsfall sollten Sie den Kernel-Verzeichnisbaum komplett löschen und noch einmal von vorne beginnen.

Nach der Kompilierung finden Sie die Datei zImage im Verzeichnis /usr/src/linux /arch/i386/boot vor. Diese Kopie des Kernels wird so benannt, weil sie ein ausführbares Abbild des Kernels ist, das intern mit gzip komprimiert wurde. Beim Booten wird der Kernel sich selbst in den Arbeitsspeicher entpacken -- versuchen Sie nicht, gzip oder gunzip von Hand anzuwenden! Auf diese Weise belegt der Kernel erheblich weniger Speicherplatz und Kopien davon passen auf eine Diskette.

Anschließend sollten Sie mit dem neuen Kernel rdev aufrufen um sicherzustellen, daß die Einstellungen für das Root-Dateisystem, den Videomodus und andere Parameter korrekt sind. Wir haben dies im Abschnitt » Von einer Diskette booten « weiter oben in diesem Kapitel beschrieben.

Wenn der neue Kernel erstellt ist, können Sie ihn zum Booten vorbereiten. Dazu müssen Sie entweder das Kernel-Abbild auf eine Boot-Diskette kopieren oder LILO so einrichten, daß der Kernel von der Festplatte bootet. Im Abschnitt » Das System booten « besprechen wir diese Themen. Machen Sie den Kernel mit einer dieser beiden Methoden bootfähig, wenn Sie damit arbeiten wollen, und starten Sie das System erneut.


Inhaltsverzeichnis Vorherige Abschnitt Nächste Abschnitt