Im Katalog suchen

Linux - Wegweiser zur Installation & Konfiguration, 3. Auflage

Online-Version

Copyright © 2000 by O'Reilly Verlag GmbH & Co.KG

Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

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


vorheriges Kapitel Inhaltsverzeichnis Stichwortverzeichnis nächstes Kapitel

Einen neuen Kernel erstellen

Icon

Kapitel 6

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« in Kapitel 6, Verwalten von Dateisystemen, Swap-Bereichen und Geräten, 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 tigger 2.0.35 #4 Wed Sep 30 12:44:16 EST 1998 i586

Icon

uname(1)

In diesem Fall handelt es sich um einen Rechner mit der Version 2.0.35 des Kernels, der zuletzt am 30. September kompiliert wurde. Es werden noch weitere Informationen angezeigt, zum Beispiel der Name des Rechners, wie oft dieser Kernel kompiliert wurde (viermal) sowie die Angabe, daß es sich um einen Pentium- oder einen äquivalenten Prozessor (wie an i586 zu sehen ist) handelt. In der Manpage 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.Patch-Level

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 Patch-Level ist die Nummer des Patches (etwa: Ausbesserung) am aktuellen Kernel. Beispiele für Versionsnummern sind 2.0.36 (Patch-Level 36 der Kernel-Version 2.0) und 2.1.52 (Patch-Level 52 der Kernel-Version 2.1).

Es hat sich eingebürgert, »stabile« Versionen mit geraden Nummern zu bezeichnen (2.0, 2.2 usw.). Die Patches zu diesen Versionen enthalten nur Korrekturen (bug fixes), aber keinen neuen Code. Die Versionen mit ungeraden Nummern (2.1, 2.3 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 2.0 (der aktuellen stabilen Version) und 2.1 (der aktuellen Hacker-Version) gearbeitet wird. Die Patches zur Version 2.0 enthalten Bug-Fixes - damit sollen nur Fehler im bestehenden Code behoben werden. Die Patches zur Version 2.1 enthalten dagegen sowohl Korrekturen als auch neuen Programmcode - neue Gerätetreiber, neue Funktionen usw. Wenn die Kernel-Version 2.1 stabil genug erscheint, wird sie in 2.2 umbenannt, und eine Kopie davon wird zur Version 2.3. Anschließend werden die Versionen 2.2 und 2.3 weiterentwickelt; 2.2 ist dann der neue »stabile« Kernel, während 2.3 der Entwickler-Kernel für Erweiterungen des Codes ist. Während dieses Buch geschrieben wurde, ist genau dies inzwischen eingetreten; die aktuelle stabile Kernel-Reihe ist also 2.2, die aktuelle Entwickler-Reihe 2.3. Wenn Sie dies lesen, kann aber durchaus bereits ein weiterer Sprung vollzogen worden sein.

Diese Konvention der Versionsnumerierung gilt nur für die von Linus freigegebenen offiziellen Kernel-Versionen nach Version 1.0. Vor der Version 1.0 (das ist nun schon Geschichte) 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.

Wenn Sie sich dafür interessieren, wie sich die Kernelversionen entwickelt haben, können Sie das auf http://ps.cus.mist.ac.uk/~rhw/kernel.versions.html nachlesen.

Der Kernel-Quellcode Ihres Systems steht in /usr/src/linux (es sei denn, Sie verwenden Debian, dann stehen die Kernel-Quelle in /usr/src/kernel-source-versionsnummer). 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

Icon

Kapitel 14

Der offizielle Kernel wird als mit gzip komprimierte tar-Datei herausgegeben, die sowohl die Quelltexte als auch eine Reihe von Patches enthält - einen Patch pro Patch-Level. Die tar-Datei enthält die Quellen der »ungepatchten« Version; es existiert zum Beispiel eine tar-Datei mit den Quellen zur Kernel-Version 2.1 ohne Patches. Jeder Patch-Level 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 14 beschreiben wir die Benutzung von patch im Detail.

Icon

Nehmen wir an, Sie möchten auf die Kernel-Version 2.1, Patch-Level 35, »updaten«. Sie brauchen dazu die Quellen zu Version 2.1 (die Datei könnte den Namen v2.1.0.tar.gz haben) sowie die Dateien mit den Patch-Levels 1 bis 35. Diese Dateien heißen patch1, patch2 usw. (Sie brauchen alle Patch-Levels bis zu der Version, auf die Sie »updaten« wollen. Meistens sind diese Dateien ziemlich klein und in gepackter Form auf den Archiv-Servern vorhanden.) Sie finden alle diese Dateien im Verzeichnis kernel der Linux-FTP-Server; auf ftp://ftp.kernel.org zum Beispiel heißt das Verzeichnis mit den Kernel-Quellen der Version 2.2 und den Patches dazu /pub/Linux/kernel/v2.2. Sie finden die Kernel-Quellen hier als tar-Archive, sowohl mit gzip als auch mit bzip2 komprimiert.

Wenn Sie schon bei einem Patch-Level des Kernels angekommen sind (also zum Beispiel 2.1, Patch-Level 30) und auf einen Kernel umsteigen wollen, können Sie einfach die Patches von der Version, die Sie haben, zur Version, die Sie haben wollen, einspielen. Wenn Sie also beispielsweise von 2.1, Patch-Level 30, auf 2.1, Patch-Level 35, aktualisieren wollen, brauchen Sie die Patch-Dateien von 2.1.31 bis einschließlich 2.1.35.

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.1.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 patch35.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 einer Wildcard 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 auftreten, solange Sie die Patches nicht in der verkehrten Reihenfolge einspielen oder einen Patch mehrmals anwenden. Lesen Sie die Manpage 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 Grund nicht eingespielt werden konnten. Sehen 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 größere Schwierigkeiten 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. Sie können auch eine der komfortableren Varianten make menuconfig oder (nur wenn Sie das X Window System installiert haben) make xconfig verwenden.
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 an beliebiger Stelle 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 aktueller sein könnten als die Hinweise in diesem Buch. Befolgen Sie die Anweisungen in README, und nehmen Sie die Erläuterungen in diesem Buch zu Hilfe.

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. Wenn es mehrere Möglichkeiten gibt, wird der Default als Großbuchstabe wie in [Y/n] angezeigt. Ihre Antworten zu jeder der Fragen sind beim nächsten Erzeugen eines Kernels aus diesem Quellenbaum der Default.

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. Eine Reihe von Konfigurationsfragen erlauben auch die Antwort m neben y und n. Mit dieser Option wird die entsprechende Kernel-Funktion als ladbares Kernel-Modul kompiliert, anstatt direkt in das Kernel-Image gelinkt zu werden. Ladbare Module, die im folgenden Abschnitt »Ladbare Gerätetreiber« besprochen werden, ermöglichen es, Teile des Kernels (wie zum Beispiel Gerätetreiber) nach Bedarf im laufenden System zu laden und zu entladen. Wenn Sie sich bei einer Option nicht sicher sind, dann geben Sie ? ein; für die meisten Optionen bekommen Sie dann einen Informationstext zu sehen.

Eine Alternative zur Verwendung von make config ist make xconfig. Damit wird ein »X Window«-basiertes Kernel-Konfigurationsprogramm kompiliert und ausgeführt. Damit dies funktioniert, muß bei Ihnen das X Window System laufen, die dazugehörigen X11- und Tcl/Tk-Bibliotheken müssen vorhanden sein usw. Anstatt eine Reihe von Fragen zu stellen, können Sie mit diesem Utility Checkboxen verwenden, um die Kernel-Optionen auszuwählen, die Sie einschalten möchten. Das System merkt sich Ihre Konfigurationsoptionen jedes Mal, wenn Sie das Programm laufen lassen, so daß Sie nicht erneut alle Optionen eingeben müssen, wenn Sie nur einige Funktionen hinzufügen oder entfernen wollen.

Außerdem gibt es noch make menuconfig, das die textbasierte curses-Bibliothek verwendet und damit eine ähnliche dialogbasierte Kernel-Konfiguration ermöglicht, auch wenn Sie X nicht installiert haben. make menuconfig und make xconfig sind sehr viel komfortabler als make config, insbesondere da Sie zu einer Option zurückgehen und diese nachträglich ändern können, bis Sie Ihre Konfiguration abgespeichert haben.

Der folgende Auszug ist ein Teil einer Sitzung mit make config. Wenn Sie make menuconfig oder make xconfig verwenden, werden Sie den gleichen Optionen begegnen, die lediglich benutzerfreundlicher präsentiert werden.

* * Code maturity level options * Prompt for development and/or incomplete code/drivers\ (CONFIG_EXPERIMENTAL) [N/y/?] * * Processor type and features * Processor family (386, 486/Cx486, 586/K5/5x86/6x86, Pentium/K6/TSC,\ Ppro/&x86MX) [PPro/6x86MX] defined CONFIG_M686 Math emulation (CONFIG_MATH_EMULATION) [N/y/?] MTRR (Memory Type Range Register) support (CONFIG_MTRR) [N/y/?] Symmetric multi-processing support (CONFIG_SMP) [Y/n/?] * * Loadable module support * Enable loadable module support (CONFIG_MODULES) [Y/n/?] Set version information on all symbols for modules\ (CONFIG_MODVERSIONS) [N/y/?] Kernel module loader (CONFIG_KMOD) [N/y/?] * * General setup * Networking support (CONFIG_NET) [Y/n] ... usw. ... 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 2.2. Wenn Sie andere Patches eingespielt haben oder eine neuere Version des Kernels benutzen, kann es sein, daß weitere Fragen erscheinen. Beachten Sie, daß wir in der folgenden Liste nicht alle Konfigurationsoptionen zeigen; es gibt davon einfach zu viele, und die meisten sind selbsterklärend. Wir haben diejenigen herausgegriffen, bei denen Erklärungsbedarf besteht. Denken Sie daran, daß der Default oft die beste Antwort ist, wenn Sie sich nicht sicher sind, oder probieren Sie es mit ?.

Es sollte hier noch angemerkt werden, daß nicht alle Gerätetreiber in den Kernel gelinkt werden. Einige sind nur als ladbare Module verfügbar und werden getrennt vom Kernel verteilt. (Wie bereits erwähnt, können manche Treiber sowohl in den Kernel gelinkt als auch als Module übersetzt werden.) Ein bekannter Kernel-Treiber, der nur als Modul verfügbar ist, ist der »Floppy-Streamer«-Treiber für QIC-117-Bandlaufwerke, die am Floppy-Controller angeschlossen werden.

Wenn Sie in der von make config präsentierten Liste keinen Treiber für Ihr Lieblingsgerät finden, ist es möglich, daß der Treiber als Modul oder getrennter Kernel-Patch verfügbar ist. Durchsuchen Sie die FTP-Server und die Archiv-CD-ROMs, wenn Sie nicht finden, was Sie suchen. Im Abschnitt »Ladbare Gerätetreiber« später in diesem Kapitel gehen wir detailliert auf Kernel-Module ein.

Prompt for development and/or incomplete code/drivers
Antworten Sie mit Ja (y), wenn Sie neue Funktionen ausprobieren wollen, die von den Entwicklern noch nicht für stabil genug gehalten werden. Verwenden Sie diese Option nicht, wenn Sie nicht beim Testen neuer Funktionen mithelfen wollen.
Processor family(386, 486/Cx486, 586/K5x86/6x86, Pentium/K6/TSC, PPro/6x86MX)
Hier geben Sie an, welchen CPU-Typ Sie haben. Der Kernel wird dann mit speziellen Optimierungen für diesen Prozessortyp kompiliert. Beachten Sie, daß der Kernel eventuell nicht funktioniert, wenn Sie hier einen höheren Prozessortyp angeben, als Sie eigentlich haben. Der Pentium II MMX ist übrigens eine 686-CPU, keine 586-CPU.
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.
MTRR (Memory Type Range Register) support
Hiermit wird ein spezielles Feature eingeschaltet, das es nur auf Pentium II- und Pentium Pro-Systemen gibt. Wenn Sie keine dieser CPUs haben, dann brauchen Sie diese Option nicht (aber es schadet auch nicht, wenn Sie sie einschalten, es vergrößert nur den Kernel).
Symmetric multi-processing support
Hiermit wird die Kernel-Unterstützung für Systeme mit mehr als einer CPU eingeschaltet. Wenn Sie einen solchen Rechner haben, dann sagen Sie hier Ja (y), ansonsten Nein (n).
Enable loadable module support
Schaltet die Unterstützung für dynamisch ladbare Module ein. Sagen Sie hier auf jeden Fall Ja (y).
Set version information on all symbols for modules
Mit dieser Option ist es möglich, ein Modul, das für eine Kernel-Version kompiliert worden ist, mit einer anderen zu verwenden. Das bringt aber eine Reihe von Problemen mit sich, sagen Sie hier deswegen Nein (n), wenn Sie nicht genau wissen, was Sie tun.
Kernel module loader
Wenn Sie diese Option aktivieren, können Sie mit Hilfe des weiter unten beschriebenen Programms kerneld dynamische Module bei Bedarf automatisch laden und entladen.
Networking support
Antworten Sie mit Ja (y), wenn Sie irgendeine Form von Netzwerkunterstützung im Kernel haben wollen (einschließlich TCP/IP, SLIP, PPP, NFS usw.).
PCI support
Schalten Sie diese Option ein, wenn Ihre Hauptplatine einen PCI-Bus verwendet und Sie PCI-Karten in Ihrem Rechner installiert haben. Zur Erkennung und Aktivierung der PCI-Geräte wird das PCI-BIOS verwendet; eine Kernel-Unterstützung dafür ist für die Verwendung jedes PCI-Gerätes in Ihrem System notwendig.
System V IPC
Mit einem Ja auf diese Frage binden Sie die Unterstützung für die IPC-Funktionen (Inter-Process Communication) von System V ein. Dazu gehören zum Beispiel 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.
Sysctl support
Diese Option weist den Kernel an, das dynamische Ändern von Kernel-Parametern zu ermöglichen, ohne erneut zu booten. Sie sollten diese Option aktivieren, sofern Sie nicht sehr wenig Speicher haben, weil sie den Kernel 8 KB größer macht.
Kernel support for ELF binaries
Wenn Sie diese Option einschalten, können Sie Linux-Binärdateien im »Executable and Linking Format« (ELF) ausführen. ELF ist das Standardformat für ausführbare Dateien, Objektdateien und Systembibliotheken. Solche Standards sind für das Betriebssystem notwendig, um mit Werkzeugen wie Compilern und Linkern zu kooperieren. Die meisten aktuellen Linux-Systeme speichern ihre Binärdateien im ELF-Format, so daß Sie hier mit Ja (y) antworten sollten. Sehr alte Linux-Systeme verwenden das a.out-Format für Binärdateien.
Parallel port support
Schalten Sie diese Option ein, wenn Sie eine parallele Schnittstelle in Ihrem System haben und von Linux darauf zugreifen wollen. Linux kann die parallele Schnittstelle nicht nur für Drucker, sondern auch für PLIP (ein Netzwerkprotokoll für parallele Leitungen), ZIP-Laufwerke, Scanner und andere Geräte verwenden. In den meisten Fällen brauchen Sie noch einen weiteren Treiber.
Plug and Play support
Aktivieren Sie diese Option, wenn Sie eine ISA-Plug-and-Play-Karte in Ihrem System haben. Das betrifft keine PCI-Karten, die von Haus aus Plug-and-Play unterstützen.
Normal floppy disk support
Antworten Sie hier mit Ja (y), es sei denn, Sie wollen keine Unterstützung für Diskettenlaufwerke (das kann auf Rechnern, auf denen Disketten-Unterstützung nicht notwendig ist, ein bißchen Speicher sparen).
Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support
Antworten Sie hier mit Ja (y), es sei denn, Sie benötigen keine Unterstützung für MFM/RLL/IDE-Festplattenlaufwerke. Wenn Sie mit Ja geantwortet haben, werden Sie nach den Gerätetypen (Festplatten, CD-ROM-Laufwerke, Bandlaufwerke und Diskettenlaufwerke) gefragt, die über den IDE-Treiber angesprochen werden sollen. Wenn Sie keine IDE-Festplatten (nur SCSI) haben, ist es sicherer, diese Option abzuschalten.
XT harddisk support
Antworten Sie hier nur mit Ja, wenn Sie einen älteren XT-Festplatten-Controller haben (und ihn auch mit Ihrem Linux-System verwenden wollen).
Parallel port IDE device support
Diese Option schaltet die Unterstützung für IDE-Geräte ein, die an die parallele Schnittstelle angeschlossen werden. Dazu gehören beispielsweise portable CD-ROM-Laufwerke.
Networking options
Wenn Sie Netzwerkunterstützung (siehe oben) gewählt haben, wird Ihnen hier eine Reihe von Fragen über die gewünschten Netzwerkoptionen gestellt. Wenn Sie keine speziellen Bedürfnisse haben (in diesem Fall werden Sie ohnehin wissen, wie Sie die Fragen zu beantworten haben), verwenden Sie die Default-Antworten. Eine Reihe von Fragen sind etwas esoterisch (zum Beispiel IP: Disable Path MTU Discovery), und die Defaults sollten in fast allen Fällen verwendet werden.
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. All diese Fragen drehen sich um bestimmte SCSI-Controller-Chips und -Platinen. Wenn Sie sich nicht sicher sind, was für eine Art von SCSI-Controller Sie haben, lesen Sie in der Hardwaredokumentation nach oder befragen Sie die »Linux HOWTO«-Dokumente.
Sie werden auch gefragt, ob Sie Unterstützung für SCSI-Festplatten, -Bandlaufwerke, -CD-ROMs und andere Geräte haben wollen; geben Sie hier die richtigen Optionen für Ihre Hardware an.
Ohne SCSI-Hardware sollten Sie mit Nein antworten; dadurch wird der kompilierte Kernel erheblich kleiner.
Network device support
Hier kommt eine Reihe von Fragen über spezielle von Linux unterstützte Netzwerkkarten. Wenn Sie eine Ethernet-Karte (oder eine andere Netzwerkkarte) haben, schalten Sie die Optionen für Ihre Hardware ein. Wie bei den SCSI-Geräten sollten Sie Ihre Hardwaredokumentation oder die »Linux HOWTO«-Dokumente (wie zum Beispiel das Ethernet-HOWTO) lesen, um herauszufinden, welcher Treiber zu Ihrer Netzwerkkarte paßt.
Amateur Radio support
Diese Option schaltet die grundlegende Unterstützung für Netzwerkverbindungen über öffentliche Funkfrequenzen wie etwa CB ein. Wenn Sie die entsprechende Ausrüstung haben, dann aktivieren Sie diese Option und lesen Sie die AX25- und HAM-HOWTOs.
ISDN subsystem
Wenn Sie ISDN-Hardware in Ihrem System haben, dann aktivieren Sie diese Option und wählen den passenden Hardwaretreiber für Ihre Hardware aus. In den meisten Fällen sollten Sie dann auch Support synchronous PPP auswählen.(Siehe hierzu auch »PPP über ISDN-Leitungen« in Kapitel 15.)
Old CD-ROM drivers
Hier folgt eine Reihe von Fragen zu den speziellen CD-ROM-Laufwerken, die der Kernel unterstützt. Dazu gehören zum Beispiel das Sony-CDU31A/33A, Mitsumi, CD-ROM-Laufwerke von SoundBlaster Pro usw. Wenn Sie einen SCSI- oder IDE-CD-ROM-Controller haben (und die Unterstützung für diesen eingeschaltet ist), müssen Sie keine dieser Optionen aktivieren. Einige CD-ROM-Laufwerke haben eigene Schnittstellenkarten, für die mit diesen Optionen die Treiber aktiviert werden.
Character devices
Linux unterstützt eine Reihe von speziellen »Zeichen«-Geräten wie serielle und parallele Schnittstellen-Controller, QIC-02-Bandlaufwerke sowie Mäuse mit proprietären Schnittstellen (also keine Mäuse, die an die serielle Schnittstelle angeschlossen werden, wie etwa die Microsoft Serial Mouse). In diesem Abschnitt finden Sie auch die Unterstützung für Joysticks und die »Video for Linux«-Treiber, die Video- und Framegrabber-Hardware unterstützen. Aktivieren Sie die für Ihre Hardware passenden Optionen.
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 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).
Console drivers
Stellen Sie sicher, daß Sie hier zumindest VGA text console angewählt haben, ansonsten können Sie Ihr Linux-System nicht von der Konsole aus benutzen.
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 hacking
Dieser Abschnitt enthält Optionen, die nur dann nützlich sind, wenn Sie vorhaben, selbst am Linux-Kernel zu arbeiten. Wenn Sie das nicht vorhaben, sagen Sie hier Nein (n).

Icon

Kapitel 5

Nachdem Sie make config (oder eines der anderen Programme) 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, Compiler-Optionen für den Kernel oder die Voreinstellungen für das Root-Verzeichnis oder den Videomodus zu ändern, können Sie das Makefile entsprechend anpassen. Im Abschnitt »Von einer Diskette booten« in Kapitel 5, Grundlagen der Systemverwaltung, haben wir gezeigt, wie Sie die Einstellungen für das Root-Verzeichnis 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 bis 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 sicherzugehen.

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 Compiler-Lauf) 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 einigen Minuten und einigen Stunden betragen - das hängt von Ihrer Hardware ab. Der Kernel umfaßt eine ganze Menge Code - mehr als zehn MB -, seien Sie also nicht überrascht. Langsamere Systeme mit vier MB 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 Viertelstunde 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 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. 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.

Wenn Sie zu viele Funktionen ausgewählt haben, kann es passieren, daß Sie nach dem Kompilieren die Meldung kernel too big bekommen. Das passiert nur selten, weil Sie normalerweise auf einem Rechner nur sehr wenig Hardwaretreiber benötigen, aber es kann passieren. In diesem Fall haben Sie zwei Möglichkeiten: Kompilieren Sie einen Teil der Kernel-Funktionen als Module (siehe den nächsten Abschnitt »Ladbare Gerätetreiber«), oder Sie verwenden make bzImage anstelle von make zImage. Damit wird ein Kernel erzeugt, der sich selbst in den hohen Speicherbereich lädt, aber nur mit nicht ganz so alten Intel-Rechnern funktioniert. Machen Sie sich keine Sorgen, wenn das Kompilieren des Kernels vorher sehr lange gedauert hat. Die meiste Zeit wurde mit dem Erzeugen von Objektdateien verbracht, die sich immer noch auf Ihrem System befinden und weiterverwendet werden können. make bzImage wird also die meisten dieser Objektdateien wieder benutzen und daher sehr viel schneller ablaufen.

Icon

Kapitel 5

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« in Kapitel 5 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« in Kapitel 5 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 neu.



vorheriges Kapitel Inhaltsverzeichnis Stichwortverzeichnis nächstes Kapitel


Weitere Informationen zum Linux - Wegweiser zur Installation & Konfiguration

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center


O'Reilly Home | O'Reilly-Partnerbuchhandlungen | Bestellinformationen | Kontaktieren Sie uns
International | Über O'Reilly | Tochterfirmen

© 2000, O'Reilly Verlag