![]() |
|
Linux - Wegweiser zur Installation & Konfiguration, 3. AuflageOnline-VersionBitte 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.
|
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:
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 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.
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. |
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.
Als erstes müssen Sie die tar-Datei mit den Quelltexten von /usr/src aus entpacken. Geben Sie dazu folgende Befehle ein:
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.
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:
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.
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.
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):
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.
... 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
Processor family(386, 486/Cx486, 586/K5x86/6x86, Pentium/K6/TSC, PPro/6x86MX)
Math emulation
MTRR (Memory Type Range Register) support
Symmetric multi-processing support
Enable loadable module support
Set version information on all symbols for modules
Kernel module loader
Networking support
PCI support
System V IPC
Sysctl support
Kernel support for ELF binaries
Parallel port support
Plug and Play support
Normal floppy disk support
Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support
XT harddisk support
Parallel port IDE device support
Networking options
IP: Disable Path MTU Discovery
), und die Defaults sollten in fast allen Fällen verwendet werden.
SCSI support
Network device support
Amateur Radio support
ISDN subsystem
Support synchronous PPP
auswählen.(Siehe hierzu auch »PPP über ISDN-Leitungen« in Kapitel 15.)
Old CD-ROM drivers
Character devices
Filesystems
Console drivers
VGA text console
angewählt haben, ansonsten können Sie Ihr Linux-System nicht von der Konsole aus benutzen.
Sound card support
Kernel hacking
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.
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. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Weitere Informationen zum Linux - Wegweiser zur Installation & Konfiguration
Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center
© 2000, O'Reilly Verlag