  Linux Kernel HOWTO
  Brian Ward (bri@blah.math.tu-graz.ac.at) und         
  Peter Stterlin (pit@uni-sw.gwdg.de)
  v0.80-3, 1. Juli 1998

  Dieser Text gibt eine detaillierte Anleitung zu Konfiguration, Kompi
  lation und Upgrades des Linux-Kernels fr ix86-basierte Systeme.


  1.  Einleitung


  Dies ist die Version 0.80 des Kernel HOWTO. Diese deutsche Version
  basiert auf der englischen Version 0.80 vom 26. Mai 1997 von Brian
  Ward (bri@blah.math.tu-graz.ac.at).


  1.1.  Fr wen ist dieser Text?


  Fr alle, die einen neuen Kernel kompilieren und installieren wollen
  und/oder mssen, weil sie


    Hardware besitzen, die von ihrem derzeitigen Kernel nicht
     untersttzt wird, wohl aber von neueren;

    ein bestimmtes Softwarepaket installieren wollen, das eine hhere
     Kernelversion voraussetzt,

    neugierig sind auf die Fhigkeiten eines neuen Kernels

    oder einfach nur wissen wollen, wie das alles im Prinzip
     funktioniert.


  1.2.  Copyright

  Dieses Dokument ist urheberrechtlich geschtzt. Das Copyright fr die
  englische Kernel HOWTO, auf der dieses Dokument basiert, liegt bei
  Brian Ward. Das Copyright fr die deutsche Version liegt bei Peter
  Stterlin und Marco Budde.

  Das Dokument darf gem der GNU General Public License verbreitet
  werden. Insbesondere bedeutet dieses, da der Text sowohl ber
  elektronische wie auch physikalische Medien ohne die Zahlung von
  Lizenzgebhren verbreitet werden darf, solange dieser Copyright-
  Hinweis nicht entfernt wird. Eine kommerzielle Verbreitung ist erlaubt
  und ausdrcklich erwnscht. Bei einer Publikation in Papierform ist
  das Deutsche Linux HOWTO Projekt hierber zu informieren.



  1.3.  Einige wichtige Vorbemerkungen


  Einige der in diesem Text aufgefhrten Beispiele gehen davon aus, da
  die GNU-Versionen einiger Hilfsprogramme wie tar, find und xargs
  installiert sind. Dies ist zwar unter Linux Standard, sollte aber
  dennoch nicht unerwhnt bleiben.

  Der Leser sollte weiterhin auch ber die Struktur des Dateisystems auf
  dem Rechner Bescheid wissen. Wer sich darber nicht ganz sicher ist,
  sollte auf jeden Fall die Ausgabe des mount Kommandos irgendwo
  aufschreiben, oder auch den Inhalt der Datei /etc/fstab. Dies kann
  einem mancherlei Unannehmlichkeiten ersparen, wenn man das System
  durch eine Unachtsamkeit in einen nicht bootfhigen Zustand versetzt
  hat.

  Der gegenwrtig aktuelle stabile Kernel hat die Versionsnummer 2.0.30.
  Die angegebenen Beispiele beziehen sich auf diese Version. Obwohl
  dieser Text soweit wie mglich versionsunabhngig geschrieben wurde,
  kann es bei der schnellen Entwicklung von Linux nicht ausbleiben, da
  Theorie (dieser Text) und Wirklichkeit (der allerneueste Kernel) etwas
  auseinanderwandern.  Dies sollte keine greren Probleme verursachen,
  kann aber den einen oder anderen vielleicht etwas verwirren.


  Es gibt zwei unterschiedliche Versionen der Linux-Kernels, die
  stabilen und die Entwickler-Versionen. Man kann sie anhand ihrer
  Versionsnummer voneinander unterscheiden: Die stabilen Kernels haben
  eine gerade Versionsnummer; der erste stabile Kernel war 1.0.x, danach
  kam 1.2.x und die derzeit aktuelle stabile Kernelversion ist 2.0.x.
  Diese Versionen werden auch gerne als Production Release angesehen.
  Sie sind im Normalfall extrem stabil und fehlerfrei. Oder wie soll man
  eine Laufzeit von mehreren hundert Tagen ohne Absturz sonst nennen?

  Die dazwischenliegenden, ungeraden Versionen wie 1.1.x, 1.3.x und der
  sicher bald kommende 2.1.x sind Testversionen, in denen neue Treiber
  in den Kernel aufgenommen werden, neue Konzepte oder Protokolle
  integriert werden. Kurzum, eine Spielwiese fr die Kernel-Hacker.
  Kernels dieser Versionen knnen durchaus manchmal instabil sein und zu
  Abstrzen fhren. Wer also auf einen absturzfreien Rechner angewiesen
  ist, sollte immer bei den stabilen Versionen bleiben. Wer aber gerne
  ein wenig experimentiert, sollte durchaus auch die Entwickler-Kernels
  ausprobieren, denn nur so knnen Fehler in diesen Versionen entdeckt
  werden, und nur so kann der nchste stabile Kernel auch wirklich
  stabil werden.

  Dies war wohl ein Problem mit den derzeitigen 2.0.x Kernels, deren
  Vorversionen nicht intensiv genug getestet wurden, so da einige
  dieser Kernels ein paar unentdeckte Fehler enthielten.



  2.  Wichtige Fragen und ihre Antworten





  2.1.  Was macht der Kernel berhaupt?


  Der Unix-Kernel stellt eine Art Vermittler zwischen den
  Anwenderprogrammen und der Hardware des Computers dar. Er verwaltet
  den Arbeitsspeicher des Rechners und sorgt dafr, da jedes laufende
  Programm (Proze) angemessene Anteile der Prozessor-Arbeitszyklen
  zugewiesen bekommt. Der Kernel stellt eine von der speziellen Hardware
  unabhngige Schnittstelle zum Zugriff auf diese Hardware zur
  Verfgung.

  Es gibt zwar noch eine Menge weiterer Dinge, fr die der Kernel
  zustndig ist, doch sind dies die wichtigsten, ber die jeder Bescheid
  wissen sollte.


  2.2.  Warum sollte ich auf eine neuere Kernelversion umsteigen?


  Zunchst untersttzen neuere Kernels praktisch immer mehr Hardware als
  die lteren, d.h. sie besitzen zustzliche Treiber. Sie haben auch oft
  eine bessere Prozeverwaltung und arbeiten dadurch manchmal deutlich
  schneller. Sie knnen einfach stabiler sein als die alten Versionen
  und dumme Fehler beheben, die sich in diesen noch versteckt hatten.
  Der hufigste Grund fr einen Kernel-Upgrade sind wohl die Treiber und
  die korrigierten Fehler.


  2.3.  Welche Hardware wird von den neuen Kernels untersttzt?


  Die Anzahl der untersttzten Hardware ist inzwischen sehr gro und
  wchst laufend weiter. Das Hardware HOWTO befat sich speziell mit
  diesem Thema. Alternativ kann man sich auch die Datei
  /usr/src/linux/config.in der Kernel-Quellen ansehen oder einfach bei
  einem make config schauen, was alles angeboten wird. Dabei wird
  allerdings nur aufgefhrt, was die Standard-Kerneldistribution
  untersttzt. Darber hinaus gibt es aber noch eine Unmenge an
  zustzlichen Treibern, die unabhngig vom eigentlichen Kernel
  entwickelt und verwaltet werden. Die PCMCIA-Treiber, die als Module in
  den Kernel eingebunden werden, sind hierfr ein Beispiel.


  2.4.  Welche Versionen von gcc und libc bentige ich?


  Linus empfiehlt im README der Kernel-Quellen eine Version, mit der
  dieser Kernel kompiliert werden sollte. Ist diese Version des gcc auf
  dem eigenen System noch nicht vorhanden, so sollte man sie
  installieren.  Welche Version der libc man fr eine bestimmte Version
  des gcc-Kompilers bentigt, kann man der Dokumentation des Kompilers
  entnehmen. Dies ist keine sehr schwierige Prozedur, man mu sich nur
  genau an die Anweisungen halten.


  2.5.

  Was ist ein (ladbares) Modul?


  Das sind Teile des Kernels, die nicht direkt in den Kernel eingebunden
  (linked) sind. Man kompiliert sie separat und kann sie nach Belieben
  in den laufenden Kernel einbinden und wieder entfernen.  Aufgrund
  dieser extremen Flexibilitt ist das inzwischen der bevorzugte Weg, um
  bestimmte Dinge im Kernel zu programmieren. Viele verbreitete Treiber,
  wie z.B. die PCMCIA- oder QIC-80/40-Treiber, sind solche ladbaren
  Module.



  2.6.  Wieviel Platz auf der Festplatte wird bentigt?


  Das hngt etwas von der jeweiligen Systemkonfiguration ab. Die
  komprimierten Quellen des Kernels der Version 2.0.10 sind bereits fast
  6 Megabytes gro, unkomprimiert belegen sie dann etwa 24 MB. Doch das
  ist noch nicht alles - man will den Kernel ja schlielich auch
  kompilieren.  Fr ein typisches System (Netzwerk, SCSI, drei oder
  vier verschiedene Dateisysteme, Untersttzung der seriellen und
  parallelen Schnittstellen) mu man etwa 30 MB einkalkulieren.  Will
  man die eigentlichen Kernelquellen auch noch in ihrer komprimierten
  Form aufbewahren, kommen so 36 MB zusammen. Fr Systeme, die weit mehr
  Treiber bentigen, kann es auch mehr sein. Weiterhin sollte man
  bedenken, da neuere Kernels mit Sicherheit noch mehr Platz
  verbrauchen werden. Man sollte also mit Blick in die Zukunft nicht zu
  knapp kalkulieren. Andererseits ist es bei den heutigen Preisen fr
  Festplatten auch kein allzu groes Problem mehr, bei Platzmangel
  einfach eine weitere Platte zu kaufen.


  2.7.  Wie lange dauert der Kernelbau?


  Fr die meisten Leute lautet die Antwort: Ziemlich lang. Die
  Leistungsfhigkeit des jeweiligen Systems sowie der zur Verfgung
  stehende Arbeitsspeicher geben hier den Ausschlag, ein wenig kann man
  diese Zeit auch durch die Anzahl der Treiber beeinflussen, die man
  einbinden will. Auf einem 486DX4/100 mit 16 MB RAM dauert die
  Kompilierung eines Kernels der Version 1.2 mit fnf Dateisystemen,
  Netzwerk- und Soundkartenuntersttzung etwa 20 Minuten. Ein 386DX/40
  mit 8 MB bentigt fr dieselbe Konfiguration etwa 1,5 Stunden. Es
  empfiehlt sich also je nach Ausstattung, in der Zwischenzeit einen
  Kaffee zu kochen oder zu lesen. Eine andere Mglichkeit besteht darin,
  den Kernel von einem Bekannten mit einem schnelleren Rechner
  kompilieren zu lassen. Auf einem Pentium Pro Multiprozessorrechner
  dauert es nur ein paar Minuten :-).


  3.  Die Kernelkonfiguration



  3.1.  Download der Quellen


  Die Quelldateien des Linux-Kernels knnen ber Anonymous-FTP von
  ftp.funet.fi bezogen werden; sie befinden sich dort unterhalb des
  Verzeichnisses /pub/Linux/PEOPLE/Linus. Dieser Server wird an vielen
  Stellen gespiegelt, es lohnt sich also, zunchst mal auf dem lokalen
  Server nachzusehen. Einige nationale und internationale Mirrors sind:


     USA

       metalab.unc.edu:/pub/Linux/kernel

       tsx-11.mit.edu:/pub/linux/sources/system


     UK


       sunsite.doc.ic.ac.uk:/pub/unix/Linux/sunsite.unc-mirror/kernel


     sterreich

       ftp.univie.ac.at:/systems/linux/sunsite/kernel


     Deutschland

       ftp.Germany.EU.net:/pub/os/Linux/Local.EUnet/Kernel/Linus

       sunsite.informatik.rwth-aachen.de:/pub/Linux/PEOPLE/Linus


     Frankreich

       ftp.ibp.fr:/pub/linux/sources/system/patches


     Australien

       sunsite.anu.edu.au:/pub/linux/kernel

  Generell ist auch eine Spiegelung von metalab.unc.edu ein guter
  Startpunkt. Die Datei /pub/Linux/MIRRORS enthlt eine Liste mit den
  bekannten Spiegelungen.

  Im angegebenen Verzeichnis befinden sich Unterverzeichnisse mit Namen
  wie v1.3, v2.0 usw. Die hchste Versionsnummer stellt den aktuellsten
  Kernel dar, wobei ungerade Versionsnummern wie v1.3 die Beta-Versionen
  sind. Wer also auf einen stabilen Kernel Wert legt, sollte bei den
  geraden Versionsnummern bleiben.

  In den jeweiligen Verzeichnissen stehen dann die Linux-Quellen in
  Dateien mit den Namen linux-x.y.z.tar.gz; x.y.z ist dabei die
  Versionsnummer. Die Datei mit der hchsten Versionsnummer stellt den
  neuesten Kernel dar. In der Regel sollte dieses auch die beste Version
  sein.


  Ebenfalls in diesem Verzeichnis befinden sich Dateien mit den Namen
  patch-x.y.z.gz. Dabei handelt es sich um sogenannte Patch-Dateien, mit
  denen man bereits vorhandene Kernel-Quellen einer lteren Version auf
  den neuesten Stand bringen kann. Nheres dazu steht im Abschnitt
  ``Patchen des Kernels''.

  Eine weitere Mglichkeit, die Kernel-Quellen zu bekommen, stellen
  Mailbox-Systeme dar. Eine Liste von Mailboxen, die die Linux-Quellen
  anbieten, wird regelmig in der Newsgruppe comp.os.linux.announce
  gepostet.

  Wenn Sie auf der Suche nach allgemeinen Informationen zu Linux und
  unterschiedlichen Distributionen sind, werfen Sie einen Blick auf
  diesen Server:

       http://www.linux.org



  3.2.  Auspacken der Quellen


  Die Installation der Quellen verlangt root-Rechte, so da man sich
  entweder als root einloggen oder durch su die Identitt wechseln mu.
  Der Kernel-Verzeichnisbaum residiert normalerweise im Verzeichnis
  /usr/src:


       # cd /usr/src




  Wer - wie die meisten - bereits bei der ersten Installation seines
  Linux-Systems die Kernel-Quellen mitinstalliert hat, wird hier ein
  Verzeichnis mit dem Namen linux finden. Wer genug Platz auf der Fest
  platte hat und auf Nummer Sicher gehen will, kann dieses Verzeichnis
  beibehalten. Eine gute Idee ist es, die Versionsnummer des Kernels in
  diesem Verzeichnisbaum herauszufinden und das gesamte Verzeichnis
  umzubenennen. Hierfr gibt es zwei Mglichkeiten:


  1. Es luft noch der ursprngliche Kernel, dann sind die
     Versionsnummern von Quellen und laufendem Kernel identisch. Die
     Versionsnummer des laufenden Kernels erfhrt man durch den Befehl:



       # uname -r
       1.2.13





  2. Wer sich nicht sicher ist: Die Versionsnummer fr den
     Verzeichnisbaum steht im obersten Makefile /usr/src/linux/Makefile
     ganz am Anfang:



       VERSION = 1
       PATCHLEVEL = 2
       SUBLEVEL = 13





  Hier handelt es sich also um einen Kernel 1.2.13.

  Der gesamte Verzeichnisbaum wird nun einfach umbenannt:


       # mv linux linux-1.2.13




  Eine weitere, sehr viel platzsparendere Mglichkeit ist es, den alten
  Verzeichnisbaum als gepacktes TAR-Archiv aufzuheben:


       # tar cvfz linux-1.2.13.tgz linux
       # rm -rf linux




  Wer sicher ist, da er die alten Quellen nicht mehr bentigt, oder
  einfach nicht genug Platz fr zwei Versionen hat, kann auch einfach
  den vorhandenen Verzeichnisbaum lschen:


       # rm -rf linux




  In jedem Fall mu aber sichergestellt sein, da es in /usr/src kein
  Verzeichnis mit dem Namen linux gibt, bevor man die neuen Quellen aus
  packt!

  Dieses Auspacken geschieht mit dem Befehl


       # tar xpvfz linux-x.y.z.tar.gz




  oder, wenn die Datei bereits entkomprimiert ist, mit


       # tar xpvf linux-x.y.z.tar




  Wer das TAR-Archiv nicht im aktuellen Verzeichnis stehen hat, mu
  natrlich den vollen Pfad zu dieser Datei angeben, also etwa:


       # tar xpvfz /home/ftp/incoming/linux-x.y.z.tar.gz




  In jedem Fall wird whrend des Auspackens der Inhalt des Archives am
  Bildschirm angezeigt (durch die Option v bei tar), und am Ende steht
  dann ein neues Verzeichnis linux in /usr/src.  In dieses sollte man
  nun wechseln und als erstes die Datei README lesen. Darin gibt es
  einen Abschnitt INSTALLING the kernel, in dem insbesondere einige
  symbolische Links aufgefhrt sind, deren Existenz berprft werden
  mu.


  3.3.  Konfiguration des Kernels


  Hinweis: Der folgende Abschnitt wiederholt in Teilen den
  entsprechenden Abschnitt der Datei README.

  Im Verzeichnis /usr/src/linux startet der Befehl



       # make config





  ein Konfigurationsskript, das eine ganze Menge Fragen stellt. Da
  dieses Skript zu seiner Abarbeitung zwingend die Shell bash bentigt,
  mu sichergestellt sein, da diese Shell zur Verfgung steht: Entweder
  als /bin/bash, als /bin/sh oder aber unter dem in der Variablen $BASH
  angegebenen Pfad.

  Mittlerweile gibt es einige Alternativen zu make config, die von den
  meisten als komfortabler angesehen werden. Wer mit dem X Window System
  arbeitet, sollte



       # make xconfig





  ausprobieren, sofern auch Tk installiert ist. Wer (n)curses
  installiert hat, und ein textbasiertes Men bevorzugt, sollte



       # make menuconfig




  verwenden. Der groe Vorteil beider Varianten ist, da man bei einer
  Fehleingabe problemlos zum entspechenden Punkt zurckgehen und den
  Fehler korrigieren kann.

  Die Fragen knnen im Normalfall mit y (Ja) oder n (Nein) beantwortet
  werden. Viele Treiber bieten auerdem die Option m an, dies steht fr
  Modul. Dadurch wird der Treiber zwar kompiliert, aber nicht direkt in
  den endgltigen Kernel eingebunden, sondern als ladbares Modul
  bereitgestellt.

  Seit der Version 2.0 des Kernels gibt es weiterhin zu fast allen
  Fragen die Antwortmglichkeit ?. Dadurch wird ein kurzer Hilfetext der
  jeweiligen Konfigurationsmglichkeit angezeigt. Die dort gegebene
  Information ist in jedem Fall die aktuellste.

  Im folgenden werden einige der wichtigeren Optionen genauer erlutert.
  Weniger wichtige oder offensichtliche Optionen sind weiter unten im
  Abschnitt ``Weitere Konfigurationsmglichkeiten'' zusammengestellt.


  3.3.1.

  Kernel math emulation


  Wer keinen mathematischen Koprozessor hat, weil er noch einen
  einfachen 386 oder einen 486SX benutzt, mu hier mit y antworten. Wer
  einen Koprozessor hat, kann trotzdem mit y antworten, denn der Kernel
  erkennt selbstndig, wenn ein Koprozessor vorhanden ist und ignoriert
  dann den Emulator. Lediglich der Kernel wird dadurch etwa 45 kB grer
  und verbraucht unntig RAM.

  Angeblich ist die Emulation des Koprozessors relativ langsam. Dies mag
  mit ein Grund sein, warum das X Window System auf Rechnern ohne
  Koprozessor extrem langsam ist. Aber das gehrt eigentlich nicht
  hierher.


  3.3.2.



  Normal (MFM/RLL) disk and IDE disk/cdrom support


  Die meisten werden hier mit y antworten, denn dadurch wird die
  Untersttzung fr die normalen Festplatten der PCs aktiviert.
  Lediglich Besitzer von reinen SCSI-Systemen knnen hier n antworten.

  Bei einer positiven Antwort kann man weiterhin zwischen dem alten
  disk-only und dem neueren IDE-Treiber auswhlen. Der alte Treiber
  untersttzt maximal zwei Festplatten an einem einzigen Host-Adapter,
  der neue erlaubt eine weitere Schnittstelle und untersttzt auch
  IDE-/ATAPI-CD-ROMs. Der neue Treiber ist etwa 4 kB grer und
  sicherlich auch verbessert, d.h. auer einer anderen Anzahl an Fehlern
  kann er auch die Leistung der Festplatte erhhen. Dies gilt vor allem
  fr die neueren EIDE-Gerte.


  3.3.3.

  Networking support


  Normalerweise wird man hier nur dann mit y antworten, wenn der Rechner
  an ein Netzwerk wie das Internet angeschlossen ist, oder wenn man
  SLIP, PPP, TERM oder etwas hnliches verwenden will, um sich ber ein
  Modem in ein Netzwerk einzuklinken. Da aber viele Pakete wie z.B. das
  X Window System Netzwerkuntersttzung bentigen, selbst wenn der
  Rechner gar nicht wirklich an ein Netz angeschlossen ist, sollte man
  hier y antworten. Gleiches gilt fr die etwas spter kommende Frage
  nach TCP/IP networking. Wer sich nicht ganz sicher ist, sollte y
  sagen.


  3.3.4.  Limit memory to low 16MB


  Es gibt einige fehlerhafte 386er DMA-Controller, die RAM-Bereiche
  oberhalb von 16 MB nicht fehlerfrei adressieren knnen. In den
  seltenen Fllen, da man einen solchen besitzt, sollte man hier mit y
  antworten.


  3.3.5.

  System V IPC


  Eine der besten Definitionen, was IPC (Inter Process Communication)
  ist, findet sich im Glossar von Bchern ber Perl. Kein Wunder, denn
  gerade Perl-Programmierer verwenden es, um verschiedenen Prozesse
  miteinander kommunizieren zu lassen. Auch viele andere Programmpakete
  (z.B. DOOM) verwenden IPC, es ist also keine gute Idee, es zu
  deaktivieren, auer man wei genau was man tut.


  3.3.6.

  Processor type (386, 486, Pentium, PPro)


  In lteren Kernels lautete die Frage: Use -m486 flag for 486-specific
  optimizations. Frher wurden dadurch bestimmte Optimierungen fr
  einen speziellen Prozessortyp aktiviert. Die Kernels wurden dadurch
  etwas in der Gre verndert, liefen aber auch auf anderen
  Prozessortypen. Dies gilt aber inzwischen nicht mehr, man sollte
  unbedingt den Prozessortyp angeben, fr den der Kernel gedacht ist.
  Lediglich ein 386er Kernel arbeitet auf allen Rechnern.


  3.3.7.

  SCSI support


  Wer einen SCSI-Adapter und -Gerte besitzt, antwortet hier mit y. Es
  werden dann weitere Fragen zu Untersttzung unterschiedlicher Hardware
  (CD-ROM, Bandlaufwerk) gestellt. Das SCSI HOWTO gibt hier nhere
  Hilfestellungen.


  3.3.8.  Network device support


  Wer eine Netzwerk-Karte besitzt, oder SLIP/PPP verwenden will, sagt
  hier y. Das Konfigurationsskript fragt dann nach der genauen Art der
  Hardware und welche Protokolle verwendet werden sollen.


  3.3.9.

  Dateisysteme


  Das Konfigurationsskript erfragt die Untersttzung fr folgende
  Dateisysteme:

     Standard (minix)
        Die neueren Distributionen legen kaum noch minix-Dateisysteme
        an, und nur noch wenige Leute benutzen es. Dennoch kann es nicht
        schaden, dieses Dateisystem zu untersttzen. Einige
        Rettungsdisketten verwenden es, und auch sehr viele Floppies,
        die unter Unix verwendet werden, verwenden es, da es auf diesen
        viel einfacher zu benutzen ist.


     Extended fs
        Dies war die erste Version des erweiterten Dateisystem extfs,
        sie ist aber kaum noch in Gebrauch. Wer es bentigt, wei das;
        alle anderen knnen ohne Gefahr mit n antworten.


     Second extended
        Dies ist das am weitesten verbreitete Dateisystem, praktisch
        alle neueren Distributionen verwenden es. Ziemlich sicher wird
        man hier also mit y antworten.


     xiafs filesystem
        Dieses Dateisystem - eine Alternative zu extfs - war einmal
        recht verbreitet, heute arbeitet aber kaum noch jemand damit.


     msdos
        Wer auf seine DOS-Partition unter Linux zugreifen will oder
        Disketten im DOS-Format mounten will, antwortet hier y.


     vfat
        Das Dateisystem von Win95, das endlich auch lange Dateinamen
        erlaubt.  Wer Zugriff auf seine Win95-Partition haben will, sagt
        y.

     umsdos
        Dieses Dateisystem benutzt das einfache DOS System, um darauf
        ein Unix-Dateisystem mit allen Vorzgen (lange Dateinamen etc.)
        anzulegen.  Ganz nett, wenn man Linux nur mal probieren will und
        seine DOS-Partition nicht neu formatieren will. Aber es ist
        relativ langsam und nicht sehr sinnvoll fr diejenigen, die kein
        DOS verwenden.


     /proc
        Eine der grten Ideen seit der Erfindung des Milchpulvers; die
        Idee ist wohl von den Bell Labs abgeschaut. Man legt nicht
        wirklich ein Verzeichnis /proc auf der Festplatte an, dies ist
        vielmehr eine Schnittstelle zum Kernel und den laufenden
        Prozessen in Form eines Dateisystems. Sehr viele Hilfsprogramme
        wie z.B. ps benutzen es; auch einige Shells, insbesondere rc,
        verwenden /proc/self/fd, das auf anderen Systemen als /dev/fd
        bekannt ist, fr den I/O. Diese Frage sollte unbedingt mit y
        beantwortet werden, da sehr viele wichtige Dinge und Programme
        unter Linux darauf angewiesen sind.


     NFS
        Wer seinen Rechner an ein Netzwerk angeschlossen hat und
        Verzeichnisse von anderen Rechnern in das eigene Dateisystem
        einklinken will, sagt hier y.


     ISO9660
        Das ist das Dateisystem der meisten CD-ROMs. Wer ein CD-Laufwerk
        besitzt und es unter Linux benutzen will, sagt auch hier y.


     HPFS
        Das ist das Dateisystem von OS/2. Im Moment kann es nur gelesen,
        aber nicht geschrieben werden.


     System V und Coherent
        System V und Coherent sind andere Varianten von Unix fr PCs.
        Sie verwenden ein eigenes Dateisystem, das Linux natrlich auch
        untersttzt.


     UFS
        UFS wird von Sun und FreeBSD verwendet. Wer entsprechende
        Systeme hat, wird hier mit y antworten und kann dann - bislang
        allerdings nur lesend - auf deren Partitionen zugreifen.


     Amiga FFS
        Dies ist ein experimenteller Treiber fr das Amiga Dateisystem.


  3.3.9.1.  Welche Dateisysteme brauche ich denn?


  Auf jeden Fall diejenigen, die im alten System auch bentigt werden.
  Dies erfhrt man, indem man den mount Befehl ohne Parameter benutzt:







  $ mount
  /dev/hda1 on / type ext2 (defaults)
  /dev/hda3 on /usr type ext2 (defaults)
  none on /proc type proc (defaults)
  /dev/fd0 on /mnt type msdos (defaults)




  In jeder einzelnen Zeile gibt das Wort nach type das jeweilige
  Dateisystem an. In diesem Beispiel sind / und /usr vom Typ ext2, also
  Second Extended. Das /proc System wird untersttzt, auerdem ist eine
  Diskette unter /dev/fd0 mit dem DOS-FAT gemounted.

  Eine andere Mglichkeit, die derzeit untersttzten Dateisysteme
  herauszubekommen, stellt das /proc-Verzeichnis dar, vorausgesetzt
  natrlich, es ist im laufenden Kernel aktiviert. Hier ein Beispiel:


       $ cat /proc/filesystems
               ext2
       nodev   proc
               msdos
       nodev   nfs




  Nur sehr selten genutzte Dateisysteme in den Kernel einzubinden fhrt
  schnell zu einem unntig groen Kernel; gleiches gilt natrlich auch
  fr selten genutzte Hardware-Treiber. Eine sehr elegante Methode, dies
  zu umgehen, stellen die Module dar. Dies wird in einem spteren
  Abschnitt beschrieben. Warum ein groer Kernel generell von Nachteil
  ist, wird im Abschnitt ``Einige Fuangeln'' erlutert.


  3.3.10.  Character Devices


  Hier kann man die Treiber fr den Drucker bzw. den Parallelport, Bus-
  Muse, PS/2-Muse (das PS/2 Protokoll wird bei vielen Notebooks fr
  den Trackball verwendet) sowie einige Bandlaufwerke aktivieren.


  3.3.11.

  Sound card


  Wer sein biff unbedingt bellen lassen will ;-), sollte hier mit y
  antworten. Dann wir etwas spter ein weiteres Konfigurationsprogramm
  kompiliert und ausgefhrt, das alles ber die Konfiguration der
  Soundkarte abfragt. Dazu ein Hinweis: Bei der Frage, ob der komplette
  Sound-Treiber installiert werden soll, kann man mit n antworten und im
  darauffolgenden Dialog nur die gewnschten Komponenten aktivieren, das
  spart etwas Platz im Kernel.  Das Sound HOWTO gibt hier weitere
  Informationen.


  3.3.12.  Weitere Konfigurationsmglichkeiten


  Hier sind bei weitem nicht alle auftretenden Optionen aufgefhrt. Zum
  einen ndert sich das Konfigurationsskript mit jedem neu
  hinzugekommenen Treiber (was recht hufig geschieht), auerdem sind
  viele der Fragen selbsterklrend: Untersttzung fr die Netzwerk-Karte
  3Com 3C509 braucht man genau dann, wenn man diese Karte auch besitzt,
  usw.  Im Zweifel gibt die Online-Hilfe durch Eingabe von ? einen
  kurzen Hinweis.


  3.3.13.  Kernel hacking


  Hierzu ein Zitat aus dem README von Linus:


       Die Aktivierung der Kernel hacking Option fhrt im Normal
       fall zu einem greren oder langsameren Kernel (oder sogar
       beides). Dadurch kann der Kernel sogar definitiv instabiler
       werden, da manche Routinen dann etwas unterschiedlich kom
       piliert werden, um gezielt schlechte Routinen zum Absturz zu
       bringen und dadurch Fehler im Kernel aufzudecken (kmal
       loc()). Soll der Kernel ganz normal verwendet werden, sollte
       man deshalb hier mit n antworten.



  3.4.  Das Makefile


  Wird make config ordnungsgem beendet, teilt eine kurze Meldung mit,
  da der Kernel nun konfiguriert ist und man das Top-Level Makefile
  auf zustzliche Konfigurationsoptionen hin untersuchen soll.

  Derzeit ist die einzige Option, die im Makefile direkt eingestellt
  wird, die Untersttzung von SMP (Symmetric Multi-Processing) fr
  Mainboards mit mehr als einem Prozessor. Wer ein solches Board
  besitzt, sollte unbedingt auch die Datei
  /usr/src/linux/Documentation/SMP.txt lesen.


  4.  Die Kompilierung

  4.1.


  clean und depend


  Am Ende der Konfiguration weist das Skript ebenfalls darauf hin, man
  solle ein make dep sowie ein make clean durchfhren.  Dies sollte man
  in jedem Fall tun, damit die wechselseitigen Abhngigkeiten der Quell-
  und Include-Dateien richtig zusammengestellt werden. Dies dauert nicht
  sehr lange; auf meinem DX/2-80 aber fast lnger als die komplette
  Kompilierung des Kernels. Danach lscht man mit make clean alle alten
  Objekt-Dateien und stellt so sicher, das sie wirklich neu bersetzt
  werden. Dieser Schritt ist wirklich wichtig, und einige
  fehlgeschlagene Kompilierungsversuche beruhten nur auf einem
  vergessenen:



       # make dep
       # make clean







  4.2.

  make


  Nun kommt der zeitraubende Teil.



       # make zImage





  kompiliert den gesamten Kernel und hinterlt die Datei zImage im
  Verzeichnis arch/i386/boot. Dies ist der neue, komprimierte Kernel.



       # make zdisk





  macht dasselbe, installiert aber diesen neuen Kernel gleich auf eine
  Diskette, die man hoffentlich rechtzeitig in das Laufwerk A: geschoben
  hat.  Die letztere Methode ist ziemlich praktisch, um neue Kernels
  relativ gefahrlos zu testen. Wenn er aus irgendeinem Grund nicht
  richtig funktioniert oder gar abstrzt, nimmt man einfach die Diskette
  aus dem Laufwerk und bootet den alten Kernel. Generell ist es immer
  eine gute Idee, eine solche bootfhige Diskette mit einem
  funktionierenden Kernel zur Hand zu haben. Denn irgendwann kommt immer
  der Tag, an dem man aus Versehen den Kernel von der Festplatte lscht
  oder eine hnliche Dummheit begeht.

  Alle halbwegs aktuellen Kernels sind komprimiert, daher das z am
  Anfang der Namen. Ein solcher komprimierter Kernel entpackt sich
  automatisch selber, wenn er bootet.


  4.3.



  Andere Optionen (Targets) fr make


  make mrproper macht etwas hnliches wie clean, aber sehr viel
  umfassender. Manchmal ist das notwendig, um ein wirklich sauberen
  Verzeichnisbaum zu generieren.  Dabei werden aber auch die alten
  Einstellungen der Konfiguration gelscht; eventuell sollte man sich
  deshalb eine Sicherungskopie der Datei .config aufheben, um bei Bedarf
  die alten Einstellungen nachsehen zu knnen.

  make oldconfig versucht, die Kernel-Konfiguration automatisch anhand
  einer alten Konfigurationsdatei durchzufhren. Wer noch nie einen
  Kernel kompiliert hat, sollte diese Option besser nicht benutzen, da
  sicherlich die eine oder andere Einstellung verndert werden mu.

  make modules wird in einem eigenen Abschnitt beschrieben.




  4.4.

  Installation des neuen Kernels


  Jetzt, nachdem der Kernel erfolgreich den eigenen Wnschen
  entsprechend kompiliert wurde, ist es an der Zeit, ihn zu
  installieren. Die meisten Leute benutzen LILO, den Linux Loader, um
  Linux und eventuell auch einige weitere Betriebssysteme zu booten. Fr
  diesen Fall gengt meist ein einfaches make zlilo. Dabei wird der
  Kernel kompiliert, installiert und lilo aufgerufen. Danach sollte
  alles fr einen Reboot des neuen Kernels bereit sein.

  Das funktioniert aber nur dann, wenn lilo folgendermaen eingestellt
  und installiert ist: Der Kernel ist /vmlinuz, lilo befindet sich in
  /sbin und die Konfigurationsdatei fr lilo (/etc/lilo.conf) stimmt mit
  dieser Einstellung berein. Ist dies nicht der Fall, mu man lilo
  selber aufrufen, nachdem der neue Kernel an die richtige Stelle
  kopiert wurde.

  Eigentlich ist lilo ein Paket, das sehr einfach zu installieren und
  auch zu benutzen ist. Dennoch lassen sich manche von der
  Konfigurationsdatei (/etc/lilo.conf oder, bei lteren Versionen,
  /etc/lilo/config) verwirren. Ein typischer Eintrag in dieser Datei
  sieht so aus:



       image = /vmlinuz
           label = Linux
           root = /dev/hda1
           ...




  Der Eintrag image = gibt den vollen Pfad des gegenwrtig installierten
  Kernels an; die meisten verwenden /vmlinuz.  label gibt einen Namen,
  unter dem man diesen Eintrag, wenn mehrere Eintrge vorhanden sind,
  ansprechen kann, und root gibt diejenige Partition der Festplatte an,
  die als / gemountet werden soll. Um fr das hier beschriebene System
  den neuen Kernel zu installieren, sollte man also vom alten Kernel
  eine Sicherheitskopie machen, den neuen Kernel an die angegebene
  Stelle kopieren und lilo aufrufen:



       # mv /vmlinuz /Old_Kernel
       # mv /usr/src/linux/arch/i386/boot/zImage /vmlinuz
       # lilo




  Bei lteren Versionen von lilo mu die letzte Zeile eventuell


       # /etc/lilo/install



  oder sogar


       # /etc/lilo/lilo -C /etc/lilo/config

  lauten.


  4.4.1.  Beispiel fr eine LILO-Konfiguration


  LILO kann im Prinzip beliebig viele verschiedene Systeme booten,
  deshalb kann man es auch sehr gut dazu verwenden, neuen und alten
  Kernel gleichzeitig bootfhig zu machen. Hierzu ein Beispiel, wobei
  Zeilen, die mit einem # beginnen, als Kommentare verstanden werden:



       # LILO Konfigurationsdatei
       #            von Peter Stterlin, September 1996
       #
       # Start des globalen Abschnittes

       boot = /dev/hda
       message=/etc/lilo.bootmenue
       compact
       prompt
       timeout = 100
       image = /vmlinuz
               label = 1
               root = /dev/hda2
       image = /vmlinuz_old
               label = 2
               root = /dev/hda2
       other = /dev/hda1
               label = 3
               table = /dev/hda




  Der erste Eintrag gibt an, wo LILO installiert werden soll; hier auf
  der ersten Festplatte. In der zweiten Zeile wird eine Datei angegeben,
  deren Inhalt LILO beim Laden am Bildschirm ausgibt.  In dieser Datei
  steht etwa folgendes:



       ^LBitte eine der angegebenen Konfigurationen auswaehlen:

       Def. --> 1  Linux (neuer Kernel)

                2  Linux (alter Kernel)

                3  MSDOS 6.0




  Das ^L (CONTROL-L) am Anfang bewirkt dabei, da der Bildschirm
  gelscht wird. Der dritte Eintrag (compact) optimiert den Ladevorgang.
  Das prompt in der nchsten Zeile bewirkt, da LILO auf eine Eingabe
  des Benutzers wartet, der nun auswhlen kann, welche der drei
  Konfigurationen er starten will. Auf diese Eingabe wartet LILO 10
  Sekunden (timeout = 100) und ldt dann automatisch den ersten Eintrag
  der folgenden Liste.  Diese Liste enthlt hier drei Eintrge. Die
  ersten beiden beginnen mit image = und weisen damit auf Linux-Systeme
  hin. Der dritte Eintrag (other = /dev/hda1) betrifft ein nicht nher
  spezifiziertes Betriebssystem, dessen Boot-Partition /dev/hda1 ist; in
  diesem Fall ist es eine DOS-Partition.

  Aus diesen drei Mglichkeiten kann man nun, wie in der Meldung
  angegeben, durch Drcken der Tasten 1, 2 oder 3, entsprechend den
  Eintrgen label= in den einzelnen Abschnitten, eine auswhlen.

  Dies beschreibt nur uerst knapp die unzhligen Mglichkeiten, die
  LILO bietet. Wer sich nher darber informieren will, sollte die sehr
  ausfhrliche Dokumentation, die mit LILO mitgeliefert wird, studieren.


  5.


  Patchen des Kernels


  Die Quelldateien des Linux-Kernels sind mittlerweile mit immerhin 6 MB
  sehr umfangreich  und es wre unbequem, sich mit jeder neuen
  Kernelversion die kompletten Dateien erneut zu besorgen. Stattdessen
  werden nur diejenigen Teile, die sich verndert haben, in Form eines
  inkrementellen Patches verbreitet. Wer also z.B. die vollstndigen
  Kernel-Quellen der Version 2.0.0 besitzt und sich die Datei
  patch-2.0.1.gz besorgt, kann damit seinen Verzeichnisbaum auf die
  Version 2.0.1 upgraden, indem er diese Patch-Datei einspielt.


  5.1.  Einspielen eines Patches


  Wer der Sache noch nicht so recht traut, kann zunchst mit


       # cd /usr/src
       # tar cvfz linux_old.tgz linux




  eine Sicherungskopie der alten Version anlegen, bevor er den neuen
  Patch einspielt. Vorher empfiehlt es sich aber in jedem Fall, ein make
  clean durchzufhren.

  Das eigentliche Patchen geschieht nun durch folgende Befehle:



       # cd /usr/src
       # zcat patch-2.0.1.gz | patch -p0 2>&1 | tee patch.out




  Jetzt werden jede Menge Meldungen ber den Bildschirm rasen ber
  hunks, die eingespielt werden, und ob das erfolgreich war. Da es
  recht schwierig ist, in diesem vorbeirasenden Wirrwarr Fehlermeldungen
  zu entdecken, wurden im Beispiel die gesamten Meldungen zustzlich in
  der Datei patch.out mitprotokolliert. Diese kann man nun nach der
  Zeichenkette fail durchsuchen, um festzustellen, ob alles glatt
  gegangen ist. Eine noch einfachere Mglichkeit ist es, patch mit der
  Option -s zu starten. Dadurch wird patch veranlat, nur noch bei
  Fehlern Meldungen am Bildschirm auszugeben.

  Auer durch die Ausgabe von patch lassen sich gescheiterte Patch-
  Versuche auch folgendermaen auffinden: Schlgt ein Patch-Versuch
  fehl, so werden die beanstandeten Abschnitte der zu patchenden Datei
  mit der Endung .rej versehen abgespeichert. Um diese Reject-Dateien
  (zurckgewiesenen Dateien) zu finden, kann man sich des Programmes
  find bedienen:


       # find .  -name '*.rej' -print




  Dieses listet alle Dateien mit der Endung .rej auf, die sich im
  aktuellen Verzeichnis und dessen Unterverzeichnissen befinden.

  Sind keine Fehler aufgetreten, kann man die neue Kernelversion wie
  gewohnt kompilieren.

  Wem das zu kompliziert ist - bitte, Linux wre nicht Linux, wenn es
  dafr nicht auch eine Lsung gbe. Im Verzeichnis
  /usr/src/linux/scripts steht ein Shell-Skript mit dem Namen patch-
  kernel, welches einem fast alle Arbeit abnimmt. Es erkennt automatisch
  die Versionsnummer der momentan installierten Kernel-Quellen und sucht
  dann im aktuellen Verzeichnis nach Patch-Dateien mit hheren
  Versionsnummern als der installierte Kernel.  Diese werden dann
  automatisch eine nach der anderen eingespielt. Tritt ein Fehler auf,
  bricht das Skript selbstverstndlich ab.


  5.2.  Was tun bei Fehlern?


  Wer niemals selber in den Kernel-Quellen herumeditiert, fr den
  sollten die Patches eigentlich immer ohne Probleme einspielbar sein.
  Lediglich in alten Kernel-Versionen gab es ein Problem, wenn eine
  Datei mit dem Namen config.in gepatcht werden sollte. Wurde diese aber
  verndert, um der eigenen Rechnerkonfiguration Rechnung zu tragen, so
  fand patch sich in dieser Datei nicht mehr zurecht und konnte den
  Patch nicht einspielen. Diese Probleme sind aber inzwischen
  bercksichtigt und sollten nicht mehr auftreten.

  Kommt es dennoch einmal soweit, sollte man als erstes die
  Reject-Datei ansehen und sie dann mit der zu patchenden Datei
  vergleichen. Oft weicht die Originaldatei nur geringfgig von der Form
  ab, die die Patch-Datei erwartet. Da patch jeweils zeichenweise
  vergleicht, kann bereits ein fehlendes Leerzeichen oder eine Leerzeile
  zuviel ein erfolgreiches Einspielen des Patches verhindern.

  Eine letzte mgliche Fehlerquelle besteht darin, da man einen Patch
  auerhalb der Reihe einspielen will, also z.B. einen mit einer
  geringeren Versionsnummer als die bereits vorhandenen Kernel-Quellen.
  Dann hlt patch zumeist mit folgender Meldung an:

       previously applied patch detected: Assume -R?

  Antwortet man darauf mit y, so versucht patch, die vorhandenen Quellen
  wieder auf den alten Stand zurckzusetzen, wird dabei aber ziemlich
  sicher scheitern. Dann wird man kaum umhinkommen, sich die vollstndi
  gen Kernel-Quellen neu zu besorgen. Ein Grund mehr also, das Skript
  patch-kernel zu verwenden, denn dieser Fehler tritt damit sicherlich
  nicht auf.

  Hat man einen Patch versehentlich eingespielt, so kann er mit dem
  Befehl patch -R wieder rckgngig gemacht werden.


  5.3.  Diese lstigen .orig Dateien...



  patch legt von allen vernderten Dateien Sicherungskopien mit der
  Endung .orig an. Diese nehmen bereits nach einigen eingespielten
  Patches einen nicht unerheblichen Platz ein; von 1.1.48 bis 1.1.51
  waren es ber ein halbes MB.

  Auch hier hilft der find-Befehl, all diese Dateien auf einmal zu
  lschen:



       # find .  -name '*.orig' -exec rm -f {} ';'




  Alternativ kann auch das  GNU-Programm xargs verwendet werden:



       # find .  -name '*.orig' | xargs rm




  Die Benutzer von patch-kernel sind wiederum im Vorteil, denn dieses
  Skript lscht automatisch alle .orig-Dateien.



  5.4.  Andere Patches


  Es gibt auer den von Linus verwalteten Patches auch noch andere,
  nicht zur Standard-Kerneldistribution zugehrige Patches. Diese sind
  meist fr spezielle Hardware und befinden sich oft noch im
  experimentellen Stadium. Viele dieser Patches werden vielleicht in
  spteren Kernel-Versionen in die Standard-Distribution aufgenommen.
  Quota und Untersttzung fr den Iomega ZIP-Drive sind diesen Weg
  gegangen.  Solange sie aber noch exotisch sind, knnen diese Patches
  dazu fhren, da die Standard-Patches von Linus nicht mehr fehlerfrei
  eingespielt werden knnen. In diesem Fall hat man dann nur die
  Mglichkeit, den Patch vor dem Kernel-Upgrade rckgngig zu machen,
  sich komplett neue Kernel-Quellen zu besorgen oder zu versuchen, die
  fehlgeschlagenen Patches von Hand zu korrigieren. Dies kann auf Dauer
  recht frustrierend sein. Wer nicht mit jedem neuen Kernel in den
  Quellen herumsuchen will, der sollte den externen Patch rckgngig
  machen (patch -R) bevor er den offiziellen Patch einspielt, oder
  gleich die volle Kernel-Version neu installieren. Erst danach kann man
  sehen, ob sich der inoffizielle Patch in die neuen Kernel-Quellen
  einspielen lt. Ist dies nicht der Fall, kann man entweder mit dem
  alten Kernel weiterarbeiten und auf ein Upgrade verzichten, bis jemand
  anders diesen Patch an die neue Kernelversion angepat hat, oder aber
  selber in den Quellen und dem Patch herumsuchen und selber versuchen,
  ihn zum Laufen zu bekommen.

  Wie viele dieser inoffiziellen Patches gibt es? Nun, es tauchen immer
  wieder welche auf, und wer die Newsgroups verfolgt, wird bald ber sie
  stolpern. Auf der anderen Seite bieten die neuen Kernels durch die
  ladbaren Module eine viel elegantere Methode, um neue Treiber und
  hnliches in den Kernel einzubinden, ohne da dabei die
  Originalquellen verndert werden mten. Aus diesem Grund wird die
  Anzahl der wirklichen Patches mit der Zeit zurckgehen.




  6.  Zustzliche Pakete


  Der Linux-Kernel besitzt eine Vielzahl an Merkmalen, die in den
  eigentlichen Quelldateien kaum erwhnt werden. Sie werden
  typischerweise durch externe Hilfsprogramme angesprochen und
  ausgenutzt. Einige der am weitesten verbreiteten sind hier aufgefhrt.


  6.1.  kbd


  Die Linux Console besitzt eine Unmenge an Besonderheiten, vielleicht
  sogar zu viele. Darunter sind die Mglichkeiten den Zeichensatz zu
  wechseln, die Tastatur umzudefinieren, den Videomodus umzuschalten (in
  neueren Kernelversionen) usw. Das kbd Paket stellt Programme zur
  Verfgung, mit denen der Benutzer all dies machen kann, zustzlich
  jede Menge Zeichenstze und Tastaturlayouts fr fast jede denkbare
  Tastatur. Dieses Paket findet man auf denselben Servern, auf denen
  auch die Kernel-Quellen liegen. Die derzeit aktuelle Version ist
  kbd-0.91.tar.gz.


  6.2.



  util-linux


  Rik Faith (faith@cs.unc.edu) hat eine Kollektion von Hilfsprogrammen
  zusammengestellt, die durch einen dummen Zufall den Namen util-linux
  bekommen habe.  Inzwischen wird das Paket von Nicolai Langfeldt (util-
  linux@math.uio.no) betreut; man findet es z.B. auf:

       metalab.unc.edu:/pub/Linux/system/misc

  Darin enthalten sind Programme wie setterm, rdev oder ctrlaltdel, die
  fr die Funktion des Kernels relevant sind.  Darber hinaus sind aber
  noch jede Menge andere Programme enthalten, die nicht unbedingt alle
  installiert werden sollten. Wie Rik im README angibt: Nie ohne zu
  berlegen installieren, es knnte sonst durchaus etwas nachhaltig
  durcheinander geraten.


  6.3.

  hdparm


  Dieses Programm erlaubt es, die Kommunikation mit der Festplatte zu
  beeinflussen und zu optimieren. Wie viele andere Programme war hdparm
  zunchst einer der inoffiziellen Kernel-Patches zusammen mit einigen
  Hilfsprogrammen. Die Patches wurden inzwischen in den Standard-Kernel
  bernommen, die Programme werden aber immer noch separat betreut und
  verteilt.


  6.4.

  gpm


  gpm steht als Abkrzung fr General Purpose Mouse, also Vielzweck-
  Maus. Mit diesem Programm knnen Textstcke mit Cut-and-Paste zwischen
  den verschiedenen virtuellen Konsolen ausgetauscht werden.
  7.

  Einige Fuangeln



  7.1.  make clean


  Wenn sich der neu installierte Kernel seltsam verhlt, stehen die
  Chancen recht hoch, da vergessen wurde, vor der Kompilation ein make
  clean durchzufhren. Die typischen Symptome reichen von einem totalen
  Systemabsturz ber unerklrliche I/O-Probleme bis hin zu einer
  Verlangsamung des Systems. make dep sollte man auch nie vergessen.


  7.2.


  Sehr groe und/oder langsame Kernel


  Belegt der Kernel zu viel des wertvollen Hauptspeichers, oder dauert
  die Kompilierung trotz des nagelneuen 786DX/6-440 viel zu lange, sind
  mglicherweise einige gar nicht bentigte Dinge (Gertetreiber,
  Dateisysteme usw.) in den Kernel integriert. Ein typisches Anzeichen
  fr einen solchen berfrachteten Kernel ist eine berhhte Swap-
  Aktivitt.  Dabei werden die jeweils gerade nicht bentigten
  Speicherbereiche auf die Festplatte ausgelagert und bei Bedarf wieder
  zurckgeladen. Ein zu groer Kernel lt weniger physikalischen
  Hauptspeicher fr die Anwendungen brig, so da das Swappen frher
  einsetzt. Erkennbar ist es an einer dauernden Festplattenaktivitt.

  Einen solchen Monster-Kernel kann man aber oft vermeiden. Generell
  gilt: Was man nicht bentigt, wird nicht konfiguriert; was man nur
  selten bentigt, sollte nach Mglichkeit als ladbares Modul kompiliert
  werden.

  Den tatschlich vom Kernel belegten Anteil des Hauptspeichers findet
  man folgendermaen heraus: Durch den Befehl cat /proc/meminfo oder
  free erfhrt man den Betrag des gesamt zur Verfgung stehenden
  Hauptspeichers (Mem: total bzw. MemTotal). Diesen Wert subtrahiert man
  einfach vom insgesamt installierten Speicher.  Eine andere Mglichkeit
  bietet der Befehl dmesg, mit dem man sich die Boot-Meldungen des
  Kernels ansehen kann. Ziemlich am Anfang steht dort eine Zeile:


       Memory: 15124k/16384k available (552k kernel code, 384k reserved, 324k
       data)


  Wer nun aber dennoch auf einen groen Kernel angewiesen ist, kann
  folgendes versuchen:




       # make bzimage




  In diesem Fall ist es vermutlich ebenfalls notwendig, eine neuere
  Version des Linux Loaders LILO zu installieren.


  7.3.  Die Kernel-Kompilierung schlgt fehl


  Eine milungene Kernel-Kompilierung kann vielerlei Ursachen haben. Die
  einfachste ist wieder ein vergessenes make dep ; make clean.
  Ebenfalls kann ein fehlgeschlagener Patch (man suche nach .rej
  Dateien) oder ein anderweitig durcheinandergeratener Quell-
  Verzeichnisbaum die Kompilierung verhindern. In diesem Fall ist es oft
  die schnellste Lsung, sich einen kompletten neuen Kernel-Quellcode zu
  besorgen und zu installieren.

  Die neuen Kernels der 2.0.x Generation bieten die Mglichkeit, die
  Konfiguration mengesteuert entweder mit make menuconfig oder make
  xconfig durchzufhren. Diese sehr komfortablen Programme hatten
  zeitweise kleinere Probleme mit dem Soundtreiber. Wer eine dieser
  Konfigurationshilfen verwendet und den Kernel nicht ordnungsgem
  kompilieren kann, sollte mal versuchen, ein normales make config
  durchzufhren, das hat manchmal geholfen.

  Weiterhin kann es sein, da man versucht, einen Kernel der Version
  1.2.x mit einem neueren ELF-Compiler (gcc 2.6.3 und hher) zu
  bersetzen.  Typischerweise bekommt man dabei haufenweise
  Fehlermeldungen der Art ****** undefined. Normalerweise ist dieser
  Fehler schnell behoben: Am Anfang der Datei arch/i386/Makefile mssen
  die folgenden Zeilen eingefgt werden:



       AS=/usr/i486-linuxaout/bin/as
       LD=/usr/i486-linuxaout/bin/ld -m i386linux
       CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include




  Danach sollte sich der Kernel mit



       # make dep
       # make clean
       # make zImage




  bersetzen lassen.

  Etwas schwieriger aufzudecken sind falsche oder falsch installierte
  Versionen des Compilers gcc. Das README von Linus gibt Hinweise dazu
  und auch auf einige symbolische Links, deren Korrektheit man
  berprfen sollte.


  In wirklich sehr seltenen Fllen kann gcc auch aufgrund von Hardware-
  Problemen abstrzen. Die Fehlermeldung lautet dann in etwa xxx got
  fatal signal 11 und man hat keinerlei Ahnung, was das bedeutet.
  Insbesondere diese Signal 11 Abstrze deuten immer auf Probleme mit
  der Speicher-Hardware hin. Dies knnen fehlerhafte SIMMs oder Cache-
  Bausteine sein, oder einfach nur zu knapp eingestellte Timings im BIOS
  des Mainboards. Oft hilft es z.B., in einem solchen Fall die Anzahl
  der Waitstates im Advanced Chipset Setup zu erhhen.

  Es gibt einen eigenen Hilfetext, der sich speziell mit dieser Art von
  Problemen beschftigt:

  http://www.bitwizard.nl/sig11/



  7.4.  Der neu installierte Kernel bootet nicht


  lilo wurde nach der Installation nicht ausgefhrt. Wurde z.B. der alte
  Kernel nur umbenannt, so bootet LILO in diesem Fall trotzdem noch die
  alte Version, da es den Kernel nur ber seine Position auf der
  Festplatte ldt, nicht ber seinen Namen. Erst bei einem erneuten Lauf
  von lilo wird dieser Positionszeiger auf den neu installierten Kernel
  gesetzt.

  Eventuell ist auch die Konfigurationsdatei fehlerhaft. Ein oft
  auftretender Fehler, den man nur zu leicht bersieht, ist z.B. wenn
  man anstelle von boot = /dev/hda die Zeile boot = /dev/hda1
  eingetragen hat.

  Ein weiterer Grund fr Probleme mit LILO knnen groe Festplatten mit
  mehr als 1024 Zylindern sein. Das LILO mini-HOWTO oder die
  Dokumentation von LILO selber geben dazu nhere Informationen.


  7.5.  LILO vergessen: Das System bootet nicht mehr


  Wohl dem, der sich beizeiten eine Rettungsdiskette oder zumindest eine
  Bootdiskette (make zdisk) erstellt hat. Mit einer Bootdiskette kann
  man einfach das System von der Floppy starten und dann lilo aufrufen.

  Besitzt man nur eine Rettungsdiskette, wird es etwas komplizierter;
  man mu den neuen Kernel von der Festplatte auf eine weitere Diskette
  bertragen. Dazu mu man einiges ber sein System wissen:

    Auf welcher Partition befindet sich das Root-Verzeichnis (/) des
     Systems?

    Auf welcher Partition steht der kompilierte Kernel? Dies kann
     entweder ebenfalls das Root-Verzeichnis sein, wenn man den Kernel
     bereits dorthin kopiert hat, oder aber die Partition, auf der sich
     das Verzeichnis /usr/src/linux befindet.

    Den Typ des Dateisystems, auf dem sich der Kernel befindet, also
     z.B. ext2 oder minix.

  Im folgenden Beispiel ist / auf /dev/hda1, und das gesamte /usr-
  Verzeichnis - also auch /usr/src/linux - befindet sich auf der
  Partition /dev/hda3 und ist vom Typ ext2.

  Zunchst bootet man also die Rettungsdiskette. Dann mu das
  Dateisystem, welches den Kernel enthlt, gemounted werden. Hierfr
  bentigt man einen Mount Point, meist wird dafr /mnt verwendet. Falls
  dieses Verzeichnis auf der Rettungsdiskette bereits existiert - was
  sehr wahrscheinlich ist - wird der erste Befehl eine Fehlermeldung
  verursachen, die aber ignoriert werden kann:



       # mkdir /mnt
       # mount -t ext2 /dev/hda3 /mnt





  Nun wechselt man in das Verzeichnis mit dem neuen Kernel. Dabei mu im
  angegebenen Fall bercksichtigt werden, da das Verzeichnis nicht wie
  gewohnt unter /usr gemounted wurde. Fr den Pfadnamen gilt also
  folgendes:


       /mnt + /usr/src/linux/arch/i386/boot - /usr =
       /mnt/src/linux/arch/i386/boot


  Man legt eine formatierte Diskette (nicht die Boot-/Root-Diskette der
  Rettungsdiskette!) in das erste Laufwerk (DOS A:), bertrgt den
  Kernel auf diese Diskette und konfiguriert ihn fr das richtige Root-
  Dateisystem:



       # cd /mnt/src/linux/arch/i386/boot
       # dd if=zImage of=/dev/fd0
       # rdev /dev/fd0 /dev/hda1




  Nachdem man in das Hauptverzeichnis zurckgewechselt ist und die
  Festplattenpartition wieder ent-mounted ist, kann das System mit der
  so erstellten Bootdiskette neu gestartet werden:



       # cd /
       # umount /mnt
       # shutdown -r now




  Nach dem Reboot sollte in jedem Fall die erste Aktion ein Lauf von
  lilo sein!


  7.6.

  warning: bdflush not running


  Dies ist nur noch fr sehr alte Installationen ein Problem, dort aber
  ein schwerwiegendes. Dieses Programm schreibt in regelmigen
  Abstnden die Dateisystem-Buffer auf die Festplatte zurck. Mit dem
  Release der Kernelversion 1.0 (April 1994) wurde das Programm durch
  eine neue Version ersetzt. Man mu sich die aktuelle Version von
  bdflush besorgen; man sollte sie von derselben Quelle bekommen, von
  der auch die Kernel-Quellen stammen. Diese Version installiert sich
  dann unter dem Namen update. Nach einem Reboot sollten die
  Fehlermeldungen verschwinden.


  7.7.  Mein IDE-/ATAPI-CD-ROM-Laufwerk wird nicht erkannt


  Obwohl mit der Einfhrung des ATAPI-Standards der Anschlu von CD-ROM-
  Laufwerken stark vereinheitlicht wurde, treten noch recht hufig
  Probleme auf, da immer noch einige Dinge beachtet werden mssen.

  Ist das CD-ROM-Laufwerk das einzige Gert am jeweiligen IDE-Interface,
  so mu es als master oder single konfiguriert sein.  Dies ist ein sehr
  oft vorkommender Fehler.

  Viele Hersteller von Soundkarten (z.B. Creative Labs) haben heutzutage
  eine IDE-Schnittstelle auf der Karte integriert. Dieses kann unter
  Umstnden zu Problemen fhren. Denn auf einigen Mainboards sind
  bereits zwei IDE-Schnittstellen vorhanden (die zweite meist auf IRQ
  15), so da diejenige auf der Soundkarte als dritte IDE-Schnittstelle
  konfiguriert wird (oft ber IRQ 11). Die 1.2.x Versionen des Linux-
  Kernels untersttzen jedoch nur maximal zwei IDE-Schnittstellen. Wer
  noch diesen alten Kernel verwendet, hat mehrere Mglichkeiten zur
  Auswahl:

  Nur in den seltensten Fllen sind an beiden IDE-Schnittstellen auf dem
  Mainboard bereits zwei Gerte angeschlossen. In diesem Fall kann man
  das ATAPI-CD-ROM dort anschlieen und die Schnittstelle auf der
  Soundkarte ausschalten. Dies hat auerdem den positiven Nebeneffekt,
  das ein IRQ frei wird.

  Wer sowieso nur eine IDE-Schnittstelle auf dem Mainboard besitzt, kann
  die auf der Soundkarte als Nummer zwei (IRQ 15) umkonfigurieren; sie
  sollte dann von Linux korrekt erkannt werden.

  Die Kernel der neuen 2.0 Generation (genauer bereits seit der frhen
  1.3.x Phase) haben solche Probleme nicht mehr. Ihr neuer IDE-Treiber
  untersttzt bis zu vier IDE-Schnittstellen. Wer also wirklich drei
  IDE-Schnittstellen verwenden will oder mu, sollte auf diese Version
  umsteigen, was sowieso eine gute Idee ist.


  7.8.  obsolete routing requests


  Wer nach einem Kernel-Upgrade derartige seltsame Meldungen bekommt,
  wenn er sein Netzwerk konfiguriert, hat eine zu alte Version des route
  Programmes und einiger damit zusammenhngender Routinen.  Die Include-
  Datei /usr/include/linux/route.h hat sich in neueren Versionen des
  Kernels verndert. Man sollte eine neuere Version dieser Programme
  installieren. route ist Bestandteil des NetKit-A Paketes, das man
  ebenfalls von derselben Quelle wie den Kernel beziehen kann:


       ftp.funet.fi:/pub/OS/Linux/PEOPLE/Linus/net-source/base




  7.9.  Not a compressed kernel Image file


  Wer beim Booten diese Meldung bekommt, hat den falschen Kernel
  installiert. Der richtige Kernel ist nicht vmlinux in /usr/src/linux
  sondern arch/i386/boot/zImage.


  7.10.  Console-Probleme nach dem Upgrade auf 1.3.x oder spter


  Die neuen Versionen verwenden eine andere Kennung fr die Konsole. In
  der Datei /etc/termcap sollte entweder im termcap-Eintrag fr console
  das Wort dumb durch linux ersetzt werden oder aber ein kompletter
  neuer Eintrag fr linux erstellt werden. Siehe dazu auch das Keyboard
  HOWTO.




  7.11.  Seit dem Kernel-Upgrade kann ich nichts mehr kompilieren


  Manche Programme bentigen gewisse Informationen und Definitionen aus
  dem Linux-Kernel. Diese bekommen sie, indem in den Include-Dateien,
  das sind die Dateien mit der Endung .h, die entsprechenden Dateien aus
  den Kernel-Quellen eingebunden werden:

       #include <linux/xyzzy.h>


  Die Datei xyzzy.h wird dann in dem Verzeichnis /usr/include/linux
  gesucht. Dieses Verzeichnis ist aber nur ein symbolischer Link auf das
  include-Verzeichnis der Kernel-Quellen; normalerweise lautet der Name
  des Verzeichnisses /usr/src/linux/include/linux.  Es gibt mehrere
  Mglichkeiten, warum der Compiler die gesuchten Dateien nicht findet:


  1. Der Link existiert nicht. Dies lt sich einfach beheben:



       # ln -s /usr/src/linux/include/linux /usr/include/linux





  2. Der Link zeigt an eine falsche Stelle. Dies kann geschehen, wenn
     der Kernel-Verzeichnisbaum nicht an der Standard-Stelle befindet.
     In diesem Fall mu er entsprechend umgebogen werden, also z.B.
     fr den Fall, da der Kernel im Verzeichnis /opt/Sources ausgepackt
     wurde:



       # cd /usr/include
       # rm -f linux
       # ln -s /opt/Sources/linux/include/linux linux





  3. Die Kernel-Quellen sind nicht installiert. Oft wird aus Platzmangel
     der gesamte Kernel-Verzeichnisbaum gelscht. Hier hilft es nur, die
     include-Dateien wieder zu installieren:



       # tar zxvpf linux.x.y.z.tar.gz linux/include





  4. Die Rechte der Dateien sind falsch gesetzt.  Wer z.B. als root eine
     umask verwendet, die anderen Benutzern den Lesezugriff auf Dateien
     verwehrt, mu beim Auspacken des Kernels unbedingt die Option p fr
     tar verwenden oder zumindest fr das include-Verzeichnis den
     lesenden Zugriff fr alle ermglichen, da sonst nur root den
     Compiler benutzen kann. Dieses geschieht nachtrglich mit dem
     Befehl:



  # cd /usr/src/linux
  # chmod -R go+r include






  7.12.  Erhhung von Systembeschrnkungen


  Die folgenden Beispiele sind vielleicht ein Hinweis fr all
  diejenigen, die sich fragen, wie man die diversen vernderbaren
  Schrankenwerte (Soft Limits) im Kernel verndern kann:



       # echo 4096 > /proc/sys/kernel/file-max
       # echo 12288 > /proc/sys/kernel/inode-max
       # echo 300 400 500 > /proc/sys/vm/freepages






  8.  Hinweise zum Upgrade auf Version 2.0


  Mit der Version 2.0 des Linux-Kernels wurden eine ganze Menge an
  Neuerungen und Vernderungen eingefhrt. Die Datei
  Documentation/Changes im Verzeichnisbaum der 2.0.x Kernel-Quellen
  enthlt alle Informationen, die man bei einem Upgrade auf diese
  Version bentigt. Insbesondere kann es notwendig sein, diverse andere
  Systemkomponenten auf den neuesten Stand zu bringen, so etwa gcc, libc
  oder SysVInit. Manche Systemdateien mssen eventuell ebenfalls
  editiert und dem neuen Kernel angepat werden.  Aber keine Panik, das
  ist einfacher, als es klingt.


  9.

  Module


  Ladbare Kernel-Module knnen Hauptspeicher sparen und vereinfachen
  meist die Konfiguration eines Systems. Die neue Red Hat-Distribution
  hat z.B.  nur noch eine einzige Bootdiskette fr alle Konfigurationen.
  Inzwischen knnen fast alle optionalen Kernel-Teile als Module
  konfiguriert werden: Dateisysteme, Netzwerk-Karten, serielle und
  parallele Schnittstellen, Bandlaufwerke, Drucker usw.


  9.1.


  Installation der Hilfsprogramme


  Das Hinzufgen und Entfernen der Module zum Kernel wird von einigen
  externen Programmen erledigt. Diese gehren nicht zur Standard-
  Kerneldistribution und mssen extra installiert werden. Man bekommt
  sie von denselben Servern wie auch den Kernel unter dem Namen modules-
  x.y.z.tar.gz. Man sollte dabei dasjenige Paket mit derselben oder,
  falls es das nicht gibt, mit der nchstkleineren Versionsnummer wie
  der verwendete Kernel benutzen. Nach dem Auspacken des Paketes mit
       # tar zxvf modules-x.y.z.tar.gz




  findet man in dem neu angelegten Verzeichnis modules-x.y.z eine
  README-Datei, die man aufmerksam lesen sollte. Darin werden auch
  Anweisungen zur Installation gegeben; dies beschrnkt sich aber
  eigentlich immer auf ein einfaches make install. Dabei sollten die
  folgenden Programme im Verzeichnis sbin installiert werden: insmod,
  rmmod, ksyms, lsmod, genksyms, modprobe und depmod.

  Im Unterverzeichnis insmod des Modul-Paketes ist auch ein kleines
  Beispiel fr einen ladbaren Treiber enthalten (/dev/hw).  Wer Lust
  hat, kann damit ein wenig herumspielen, die Datei INSTALL gibt dazu
  ein paar Hinweise.

  insmod dient dazu, ein Modul in den laufenden Kernel einzufgen.
  Normalerweise handelt es sich bei den Modulen um Binrdateien mit der
  Endung .o. Der Beispieltreiber heit z.B.  drv_hello.o. Um diesen
  einzufgen, lautete der Befehl also:



       # insmod drv_hello.o





  Um zu sehen, welche Module gerade im Kernel geladen sind, dient der
  Befehl lsmod:



       # lsmod
       Module:        #pages:  Used by:
       drv_hello          1




  drv_hello ist der Name des Modules; es belegt eine Page (Seite,
  entspricht 4 kB) im Speicher. Keine weiteren Module des Kernels sind
  von ihm abhngig.

  Um das Modul wieder zu entfernen, wird folgender Befehl verwendet:



       # rmmod drv_hello




  Wichtig ist hierbei, da rmmod den Namen des Modules, so wie er von
  lsmod angezeigt wird, und nicht den Dateinamen als Argument bentigt.

  Die Manual Pages der Modul-Programme geben weitere Informationen ber
  deren Zweck und Optionen.


  9.2.  Die Module der Standard-Kerneldistribution



  Zum gegenwrtigen Zeitpunkt (2.0.30) knnen folgende Bestandteile des
  Kernels als Modul kompiliert werden:

    alle Dateisysteme (auer /proc)

    die meisten Treiber fr Ethernet sowie ISDN-Karten

    Untersttzung fr SCSI-Gerte (Festplatten, CD-ROM, Tape)

    alle untersttzten SCSI-Karten auer AM53C974

    der Sound-Treiber

    alle untersttzten IDE-CD-ROMs

    Disketten, Drucker, Loopback und RAM-Disk

    serielle und parallele Schnittstelle (Drucker), BUS- und PS/2 Muse

     Um diese zu benutzen, darf man sie nicht in den eigentlichen Kernel
     einbinden, d.h. whrend des make config darf man die entsprechenden
     Fragen nicht mit y beantworten, sondern mit m fr Modul. Nachdem
     der Kernel wie bereits beschrieben kompiliert und installiert
     wurde, mssen die Module dann extra mit dem Befehl



       # make modules




  bersetzt werden. Mit



       # make install




  werden die bersetzten Module dann im Verzeichnis /lib/modules/x.y.z
  installiert, wobei x.y.z die verwendete Kernel-Version ist. Von dort
  knnen sie dann mit dem Befehl lsmod oder modprobe geladen werden. Der
  Vorteil von modprobe gegenber lsmod ist dabei, da der volle Pfad des
  Modules nicht angegeben werden mu. modprobe sucht automatisch in
  /lib/modules/x.y.z. Auerdem wird immer die richtige Version des
  Moduls, passend zum gerade laufenden Kernel, gelesen. Wer gerne mit
  verschiedenen Kernels experimentiert, wird das schnell zu schtzen
  wissen.

  Ladbare Module sind ganz besonders fr nur selten benutzte Dinge
  praktisch, ein gutes Beispiel sind Dateisysteme. Wer nur ab und zu mal
  eine Diskette mit dem MSDOS FAT-Dateisystem mounten mu, kann das
  entsprechende Modul (msdos.o) nur bei Bedarf laden und so unter
  Normalbedingungen etwa 50 kB an RAM einsparen. Noch komfortabler wird
  das Ganze, wenn man kerneld verwendet. Dies ist ein automatischer
  Modul-Lader, der bentigte Module selbstttig in den Kernel ldt,
  sobald das entsprechende Gert oder Protokoll bentigt wird, und es,
  wenn es nicht mehr in Benutzung ist, auch wieder entfernt.

  Diese und viele weitere Feinheiten im Umgang mit den Modulen werden im
  Module-HOWTO beschrieben.



  10.  Andere Konfigurationsoptionen


  In diesem Abschnitt werden einige weitere Optionen der Kernel-
  Konfiguration mit make config nher erlutert.


  10.1.  General setup



     Normal floppy disk support
        Modulfhig (spart auch 50 kB). Besitzer eines IBM Thinkpad
        sollten aber unbedingt drivers/block/README.fd lesen. Auch
        anderen kann das nicht schaden.


     XT harddisk support
        Hat noch jemand einen alten, verstaubten 8 Bit XT
        Festplattencontroller?  Dann kann er hier mit y antworten und
        ihn auch unter Linux verwenden.


     PCI bios support
        Wer ein PCI-Mainboard hat, kann das mal ausprobieren. Aber
        Vorsicht, einige ltere Mainboards knnen dadurch abstrzen.
        Weitere Informationen enthlt das PCI HOWTO.


     Kernel support for ELF binaries
        ELF (Executable Link Format) ist das bevorzugte Binrformat der
        neueren Linux-Distributionen; man wird hier also wohl meist y
        antworten.


     Kernel support for a.out binaries
        Das alte Binrformat. Kann als Modul kompiliert werden. Da noch
        einige Programme im a.out Format im Umlauf sind, ist es eine
        gute Idee, dieses Format zu untersttzen.


     Set version information on all symbols for modules
        Bislang muten Module explizit fr jede Kernelversion neu
        kompiliert werden. Wenn man hier mit y antwortet, kann man auch
        Module von anderen Kernel-Versionen benutzen. In diesem Fall
        sollte man aber unbedingt die Datei
        /usr/src/linux/Documentation/modules.txt lesen.


     Networking options
        Siehe dazu das NET-3 HOWTO.


  11.  Tips und Tricks



  11.1.  Umlenken der Ausgabe von make oder patch


  Gerade diese beiden Programme produzieren oft eine Unmenge von
  Meldungen, die ber den Bildschirm huschen, ohne da man sie lesen
  kann. Der Trick, diesen Text zustzlich in eine Datei zu schreiben,
  wurde weiter oben bereits angewandt, man verwendet dazu das Programm
  tee. Die genaue Syntax hngt aber von der verwendeten Shell ab,
  deshalb sollte man zunchst feststellen, welche Shell man benutzt.
  Wer es nicht sowieso wei, kann das leicht mit dem Befehl finger
  herausfinden:


       % finger root
       Login: root                             Name: root
       Directory: /root                        Shell: /bin/bash




  finger wertet brigens die Datei /etc/passwd aus, in der die Login-
  Shell eingetragen ist; man kann also auch dort nachsehen.  Der
  gesuchte Befehl lautet dann fr

     bash
        (Befehl) 2>&1 | tee (Datei)


     csh/tcsh
        (Befehl) |& tee (Datei)


     rc (Befehl) >[2=1] | tee (Datei)


  11.2.  Kernel updates


  Die nderungen des Linux-Kernels von Version zu Version werden von
  Michael Chastain (mec@treflan.shout.net) zusammengefat und werden von
  Russell Nelson (nelson@crynwr.com) archiviert:

       http://www.crynwr.com/kchanges

  .


  12.  Andere ntzliche Dokumente



    Sound HOWTO: Soundkarten und Hilfsprogramme.

    SCSI HOWTO: Alles ber SCSI, Controller und Gerte.

    NET-3 HOWTO: Netzwerk.

    PPP HOWTO: Netzwerkverbindungen ber PPP.

    PCMCIA HOWTO: PCMCIA-Karten fr Notebooks.

    ELF HOWTO: ELF: Was es ist; wie man umsteigen kann.

    Hardware HOWTO: Was wird von Linux untersttzt?

    Module HOWTO: mehr zu den Kernel-Modulen.

    Kerneld mini-HOWTO: ber die Verwendung von kerneld.

    BogoMips mini-HOWTO: Falls Sie sich fragen, was das ist.





