1. Ausgangslage

1.1 Notebookdaten

Mein HP Omnibook XE3 (F2307) hat die folgenden Leistungsdaten:

• Intel PIII 650/800 MHz CPU
• 256 MB RAM
• S3 Savage 8MB SVGA
• 20 GB Harddisk
• 14.1" TFT-Display
• OnBoard 10/100 MBit Ethernet und Modem
• ESS Allegro 1989 Soundkarte

1.2 Neuerung im Kernel 2.4.5

Im neun Kernel 2.4.5 ist nun der Tulip Patch nicht mehr nötig, er ist in den Kernel eingeflossen. Ich habe die folgenden Tipps mit den folgenden Distributionen ausprobiert: Red Hat 7.1, SuSE 7.1 und Debian Potato.

2. Installation

2.1 Start der Installation

Zur Installation ist eigendlich nicht viel zu sagen, CD 1 rein, starten, auswählen ob grafische- oder textbasierende Installation. Hier noch ein kleiner Tipp, nimm die benutzerdefinierte Installation, da kannst du alles schön selber auswählen und deinen Bedürfnissen anpassen!

Partitionieren

Ich habe meine 20 GB Festplatte wie folgt partitioniert:

hda1    /boot           ext2    20MB
hda2    Windows98       fat     3GB
hda5    /home           ext2    4GB
hda6    /               ext2    2GB (Im nachhinein würden hier 200 MB völlig reichen)
hda7    /usr            ext2    2GB 
hda8    /opt            ext2    2GB
hda9    <swap>               swap    256MB
hda10   /stuff          ext2    4GB
hda11   /public         ext2    1.7GB

2.2 Grafikkarte

Die Grafikkarte ist nun kein Problem mehr, sie wird automatisch erkannt wenn du das willst! Bei Red Hat 7.0 und älter musste noch von Hand die Grafikkarte eingerichtet werden. Wie das geht findest du auf der Hompage von Philippe Depouilly

2.3 Netzwerkkarte

Im Konfigurationsmenu des Kernels kann man unter Network device support -> Ethernet (10 or 100Mbit) -> DECchip Tulip (dc21x4x) PCI support anwählen. Ich habe ihn direkt in den Kernel kompiliert, andere nehmen es als Modul, dann muss noch folgendes gemacht werden:

Das Modul modproben ($ modprobe tulip), und die Zeile “alias eth0 tulip” in File /etc/modutils/aliases hinzufügen, dann $ update-modules und es läuft!

Jetzt kann man mit $ ifconfig das Device eth0 einrichten.

Achtung wenn der Kernel 2.4.4 und jünger ist:

Nun wenn du das erste Mal startest, ist schon alles recht schön, nur die Netzwerkkarte funktioniert noch nicht. Mit dem 2.2er Kernel ist dies recht mühsam, am besten du bersorgst dier den 2.4 Kernel. Der ist um einiges einfacher. Du kannst ihn bei http://www.kernel.org downloaden.Ich habe ihn auf eine CD gebrannt, zusammen mit dem Tulip-Patch.

Bei der Netzwerkkarte handelt es sich um ein Accton EN2224 Chipset, dieser wird nicht direkt vom Kernel unterstützt. Aber Philippe Depouilly hat auf seiner Homepage einen Patch, danke nochmals an dieser Stelle!

Bevor man den Kernel compiliert, muss man das File drivers/net/tulip/tulip_core.c im Kernelsource mit den folgenden Zeilen ergänzen:

153,156d152 < /* Added for HP Omnibook XE3 */
< { "EN2242 tulip work-alike", 128, 0x0801fbff,
< HAS_MII | HAS_MEDIA_TABLE | ALWAYS_CHECK_MII | HAS_ACPI |HAS_NWAY,
< t21142_timer },
184,186c180
< /* Added for HP Omnibook XE3 */
< { 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
< {0, }
---
> {0, }

Man kann sich natürlich das Leben auch unnötig schwer machen, hier kann der Patch heruntergeladen werden. tulip_core.c

Nun kann man im Konfigurationsmenu des Kernels unter Network device support -> Ethernet (10 or 100Mbit) -> DECchip Tulip (dc21x4x) PCI support anwählen. Ich habe ihn direkt in den Kernel kompiliert, andere nehmen es als Modul, dann muss noch folgendes gemacht werden:

Das Modul modproben ($ modprobe tulip), und die Zeile “alias eth0 tulip” in File /etc/modutils/aliases hinzufügen, dann $ update-modules und es läuft!

Jetzt kann man mit $ netcfg das Device eth0 einrichten.

2.4 Soundkarte

Mit dem Kernel 2.4 kein Problem mehr, einfach am Anfang des Konfiguratonsmenus für den Kernel Yes sagen zu "Prompt for development and/or incomplete code/drivers" und dann in der Sound-Sektion -> Maestro3 anwählen (Modul oder direkt in den Kernel kompilieren). Wenn man das Modul direkt in den Kernel kompiliert hat, enjoy. Als Modul muss noch in /etc/modules.conf die Zeile "alias sound maestro3" hinzugefügt werden.

2.6 DMA Modus der Festplatte

Um den DMA Modus zu aktiviert, müssen die folgenden Zeilen im Konfigurationsfile /etc/rc.d/rc.local hizugefügt werden:

/sbin/hdparm -d 1 -c 1 -k 1 /dev/hda # to improve Hard Disk performance
/sbin/hdparm -d 1 -c 1 -k 1 /dev/hdc # to improve CD-ROM performance

2.7 Framebuffer

Um in den Genuss von 1024x768 im Terminal zu kommen, musst du im Kernelkonfigurationsmenu Framebuffer -> VESA VGA graphics console support anwäheln und dann die Zeile “vga=792” zu deinem /etc/lilo.conf hinzufügen. Danach $ sbin/lilo/ und rebooten. Dein Terminal läuft jetzt mit einer Auflösung von 1024x768!

2.8 USB

USB ist kein Problem, ich betreibe eine Philips Vesta Pro und eine Logitech Optical Maus an meinem PC. SuSE hat da ein schönes Programm names USBManager, dieses als Source kompilieren oder wenn man SuSE hat als Package anwählen. Danach noch im Kernel USB in den Kernel Kompilieren und die einzelnen Devices als Module hinzufügen. Jetzt nur noch den USBMangaer starten und schon kann man die Maus und diverse andere Geräte benützen.

3. Referenzen

• Slackware auf einem HP Omnibook XE3
• Debian Linux on a HP Omnibook XE3
• Philippe Depouilly mit seien Ausführungen zu Red Hat 6.2/7.

Bevor man die Sache näher anschauen, sollten man sich erst einmal überlegen, ob man wirklich einen neuen Kernel zum Betrieb des Linux-Systems benötigt. In den älternen Linux-Versionen war das Erzeugen eines neuen Kernels zwingend notwendig, wenn zusätzliche Hardware, wie beispielsweise eine Soundkarte, verwendet werden wollte. Es musste die entsprechende Option gesetzt werden, damit diese Hardwaresetzt werden, damit diese Hardware überhaupt angesprochen wurde. In den neueren Kernel-Versionen seit 2.0 ist dieses aber nicht mehr unbedingt erforderlich, da sich dort die Hardware auch über sogenannte Module ansprechen lässt. Mit Hilfe dieser Module wird dann auf die Hardware zugegriffen, wobei die hierfür notwendige Parameter an die Module übergeben werden. Damit ist der Kernel universell einsetzbar, dann er ruft nun nur bei Bedarf die zuständigen Module auf, um die Hardware anzusprechen.

Dies hat ausserdem noch den Vorteil, dass die Funktionen zum Zugriff auf eine spezielle Hardwarekomponente nicht mehr in den Kernel eingebunden werden müssen, sondern hier sind nur noch Funktionen zum Laden und Starten der Module notwendig. Diese sind meist wesentlich kleiner und auch mehrfach verwendbar, sodass der erzeugte Kernel insgesamt kleiner wird und nicht mehr soviel Speicherplatz benötigt.

Bindet man hingegen alle benötigten Funktionen in den Kernel ein, so sind diese zwar immer verfügbar, aber sie belegen Platz, auch wenn sie nicht benötigt werden. Lagert man hingegen bestimmte Funktionen in Module aus, so benötigt der Hauptkeer Hauptkernel weniger Speicherplatz und die Module werden nur bei Bedarf nachgeladen, sodass sie auch nur dann Speicherplatz verwenden. Werden die Module nicht mehr benötigt, wird der von ihnen belegte Speicherplatz wieder freigegeben.

Auf diese Weise könnte man einen Kernel generieren, der nur noch wenige Funktionen enthält und der zum Zugriff auf weitere Hardware nur noch Module aufruft. Aber hierbei ist Vorsicht geboten, da natürlich die elementaren Funktionen zum Zugriff auf die Festplatte enthalten sein müssen. Wäre dies nicht der Fall, liessen siech die Module zum Zugriff auf die Platte ja nicht von der Festplatte laden. Gleiches gilt übrigens im Prinzip auch für die Unterstützung der Tastatur und der Grafikkarte, damit man von Beginn an ein Bild sehen und eventuell auch in den Bootvorgang eingreifen kann.

Zu den elementaren Funktionen gehören beispielsweise diejenigen zu Zugriff auf DIE-Platten oder auch die SCSI-Treiber, sofern eine entsprechende Karte verwendet wird. Ausserdem darf der Treiber für das Linux-Dateisystem ext2fs nicht vergessen werden, da sonst zwar auf die Platte zugegriffen werden kann, werden kann, die Daten aber nicht passend interprediert würden.

Das Konzept mit den Modulen hat zusätzlich den Vorteil, dass es wesentlich flexibler ist, wenn man häufig die Hardware wechselt. In diesem Fall entfällt das ständige generieren eines neuen Kernels; lediglich den für die neue Hardware passender Treiber muss in die entsprechende Module eingetragen werden. Wird dann versucht, auf die Hardware zuzugreifen, erfolgt eine Auswertung der Datei und das entsprechende Modul wird dynamisch geladen.

Aus all diesen Gründen sollte man sehr genau überlegen, ob wirklich ein neuer Kernel generiert werden soll oder nicht. Dies könnten beispielsweise dann sinnvoll sein, wenn möglichst ein kleiner Kernel erforderlich ist, oder wenn die Treiber für die eingesetzte spezielle Hardware noch nicht als Module vorliegen. Was man dabei aber bedenken sollte, ist die Tatsache, dass es keine Garantie gibt, dass der neue Kernel auch tatsächlich so funktioniert, wie man sich das vorstellt beziehungsweise wünscht. Dieses kann letztlich sogar dazu führen, dass das System gar nicht mehr startet. Daher sollte man also immer noch die Möglichke noch die Möglichkeit vorsehen, den alten Kernel zu starten, sodass zumindest wieder an die Daten erreichbar sind. Nicht schaden kann in solch einem Fall die beispielsweise während der Installation erzeugte Boot-Diskette zum Starten des Systems sowie das Anlegen eines Backups.

Wenn man sich dazu entschlossen hat, einen neuen Kernel zu erzeugen, muss natürlich die entsprechende Software und die Quellen installiert sein. Ausserdem sollte man sich mit Administrator-Rechten, also als "root" oder unter Verwendung von "su", eingeloggt haben, damit man vollen Zugriff auf die Dateien des Systems hat. Ist dies erfolgt, wechselt man in einem Terminalfenster in das Verzeichnis "/usr/src/linux" und beginnt dort, die notwendigen Schritte auszuführen.

Dabei müssen als erstes angegeben werden, welche Optionen beziehungsweise Treiber in den Kernel eingebunden und welche als Module gestaltet werden sollen. Dazu hat man nachfolgende Möglichkeiten:

• "make config" eingeben. Danach wird man gefragt, welche Optionen vom Kernel unterstützt werstützt werden sollen. Dabei kann man die Fragen entweder mit [y], mit [n] oder gegebenenfalls auch mit [m] beantworten, wenn dieser Treiber als Modul verwendet werden soll. Wird eine falsche Taste gedrückt, wird eine kurze Hilfe ausgegeben.
• "make menuconfig" verwenden. Dabei sieht man eine textbasierte Menüstruktur, in der alle Optionen in Gruppen geordnet sind. Dadurch hat man den Vorteil, dass bei einer erneuten Übersetzung nicht mehr alle Fragen beantworten werden müssen.
• "make xconfig" verwenden. Damit sieht man erneut eine Art Menüstruktur, nur ist dies als X-Anwendung ausgeführt. Allerdings müssen hierfür zwingend die Pakete "tcl" und "tk" installiert sein, damit man das entsprechende Fenster auf dem Desktop sieht. Ausserdem sollten X-Window als "root" gestartet sein. Zusätzlich kann eine Hilfe zu den jeweiligen Optionen aufgerufen werden.

Unabhängig davon, wie man sich entscheidet, bewirken alle drei Möglichkeiten jetztendlich das selch das selbe. Dabei muss man sich natürlich entscheiden, ob man einen Treiber dauerhaft in den Kernel einbinden oder diesen als Modul ausführen möchte. Ausserdem muss man beachten, dass die Optionen nicht unbedingt so eingestellt sind wie beim aktuellen verwendeten Kernel, sodass man zu Anfang immer erst einmal alle durchsehen sollte. Dieses ist sehr wichtig. Allerdings wäre es ratsam, sich dafür etwas Zeit zunehmen, da es sich doch um eine beträchtliche Anzahl von Möglichkeiten handelt, die sich einstellen lassen. Dabei wird man dann sicherlich auch einige finden, von denen man nicht weiss, was sich damit einstellen lässt. Ist man sich nicht sicher, sollte man es einfach beim Vorgabewert belassen.

Beendet man das Konfigurationswerkzeug, wird mit den einstellbaren Optionen eine Text-Konfigurationsdatei (.config) geschrieben, die anschliessend ausgewertet wird. Diese befindet sich im Verzeichnis "/usr/src/linux". Ausserdem wird beim Verlassen des Konfigurationswerkzeuges gleich angezeigt, welches die nächsten Schritte sind. Hierfür muss man dann das Kommando "make dep" eingeben, um die Abhängigkeiten der einzelnen Optionen untereinander zu erzeugen. Funktioniert dieses Kommando übrigens nicht wie erwartet, sollte erwartet, sollte man es einmal ausgeschrieben versuchen, also "make depend" eingeben.

Die Abhängigkeiten werden in die Dateien ".depend" und ".hdepend" geschrieben, wobei es sich ebenfalls wieder um Textdateien handelt, sodass man sie sich mit einem Editor anschauen kann. Allerdings sollten die Datei nicht geändert werden, da dies das Generieren des Kernels stark beeinflussen könnte.Anschliessend müssen die alten Objektdateien gelöscht werden, wozu der Befehl "make clean" eingegeben wird. Würde dies nicht durchgeführt, könnte es passieren, dass einige Quelltexte nicht übersetzt würden, was eventuell zu einer Fehlerfunktion des Kernels führen kann. Daher sollte dieser Befehl auch immer dann ausgeführt werden, wenn man einen Kernel mehrmals nacheinander übersetzt, um verschiedene Einstellungen auszuprobieren. Danach kann man endlich daran gehen, einen neuen Kernel zu erzeugen. Dafür hat man vier Möglichkeiten, wobei auf die Gross- und Kleinschreibung zu achten ist.

Verwenden von "make zImage". Dadurch wird ein normaler Kernel generiert. Hat man allerdings zu viele Treiber eingebunden, wird der Kernel zu gross und man sieht eine entsprechende Feh entsprechende Fehlermeldung. In diesem Fall sollte man lieber die nächste Möglichkeit einsetzten.

• Verwenden von "make bzImage". Dadurch wird ein grosser Kernel erzeugt, der auch dann möglich ist, wenn alle Treiber eingebunden wären. Aus diesem Grund sollte eigentlich nur diese Option ausgewählt werden, um auf jeden Fall auf der sicheren Seite zu sein.
• Verwenden von "make zdisk". Wenn man eine Boot-Diskette erzeugen möchte, so geschieht dies mit diesem Befehl. In diesem Fall wird wieder ein Kernel erzeugt, der direkt auf eine Bootdiskette geschrieben wird.
• Verwenden von "make bzdisk". In diesem Fall wird ein grosser Kernel erzeugt, der direkt auf eine Bootdiskette geschrieben wird.

Dabei deutet der Buchstabe z bei den Befehlen an, dass es sich um komprimierte Kernel handelt, dass heisst der Kernel wird nach der Erzeugung mit "gzip" behandelt, sodass er insgesamt weniger Platz auf der Platte benötigt. Die Neuübersetzung des Kernels dauert einige Zeit, wobei es nage Zeit, wobei es natürlich auf die Geschwindigkeit des Rechnes ankommt. Bei den neuesten Rechnermodellen werden sicherlich nur einige Minuten in Anspruch genommen, es könnte aber auch mehrere Stunden dauern, wenn nur ein Rechmer mit einem 386er Prozesser dazu verwendet wird. Verzweiflung ist hier nicht angebracht, auch wenn es gegen zehn Minuten dauert. Aber da man Linux alsGrundsystem verwendet, hat man immer noch die Möglichkeit, auf eine andere Konsole oder in eine andres Terminalfenster zu wechseln, um dort weiter arbeiten zu können.Rauschen die Meldungen übrigens auf dem Monitor zu schnell vorbei, hat man auch die Möglichkeit, sie in einer Datei zu protokollieren. Dazu muss nur die Ausgabe in eine Datei umgeleitet werden. Hierzu kann einfach das Umleitungssymbol verwendet werden, wie im nachfolgenden Beispiel:

make bzImage > Dateiname

Hierbei bezeichnet dann "Dateiname" den Namen der Protokolldatei. Allerdings hat dies Lösung den Nachteil, dass auf dem Bildschirm nun nichts mehr zu sehen ist und man weiss nicht, wie lange es noch dauert. Besser ist dagegen die Lösung, wie sie im SuSE-Handbuch zu finden ist. Verwendet man beispiewendet man beispielsweise die "Bash" als Login-Shell, kann folgendes Kommando eingegeben werden:

Make bzImage 2>&1 | tee Dateiname

Dadurch ist die Ausgabe auch im Terminalfenster ersichtlich.Nachdem der Kernel also übersetzt worden ist, befindet sich dieser im Verzeichnis "/usr/src/linux/arch/i386/boot". Abhängig davon, welche Option (1 oder 2) man gewählt hat, besitzt der neue Kernel entweder den Namen "zimage" oder "bzimage". Wenn man den neuen Kernel nun starten möchte, muss dieser in das Verzeichnis "/boot" kopiert werden. Doch bevor man dies tut, sollten erst noch einige Module generiert werden. Dazu dient das Kommando "make modules". Dieser Schritt entfällt natürlich, wenn keine Treiber als Module ausgeführt und alle benötigten direkt in den Kernel eingebunden sind. Danach kopiert man den Kernel ins Verzeichnis "/boot". Doch zuvor wäre es ratsam, den alten Kernel zu sichern, wozu der folgende Befehl dient:

cp /boot/vmlinuz /boot/vmlinuz.old<

Damit wird der alte Kernel in die Datei "vmlinuz.old" kopiert. Anschliessend überschriebt man den aktuellen Kernel mit dem neuen, indem nachfolgendes Kommando eingegeben wird:

cp /usr/src/linux/arch/i386/boot/zImage /boot/vmlinuz

oder

cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz

Dabmit ist zwar der neue Kernel im Startverzeichnis plaziert, aber bei Versuch das System neu zu starten, würde dies nicht gelingen. Statt dessen müss man zusätzlich noch das Kommando "lilo" aufrufen, um diesen neuen Kernel sozusagen beim System anzumelden. Alternativen könnten die vorigen drei Schritte auch durch ein einziges Kommante ersetzt werden, indem beispielsweise "make bzlilo" aufgerufen wird. Allerdings ist dieses Kommando nicht bei allen Distributionen verfügbar. Beispielsweise ist er in den SuSE-Makefils vorhanden, in denen von Caldera nicht.Hat man den alten Kernel gesichert und sollte dieser alternativ noch gestartet werden können, damit im Zweifelsfall üen, damit im Zweifelsfall überhaupt eine Möglichkeit existiert, an das System heranzukommen, muss die Konfigurationsdatei "/etc/lilo.conf" entsprechend angepasst werden. Hier trägt man die passende Daten ein, wobei der Name das neuen Kernels und eine andere Bootkennung verwendet werden müssen. Ist dieses erfolgt, ruft man erneut das Kommando "lilo" auf, damit der alte Kernel auch tatsächlich gestartet werden kann.Es kann natürlich auch das Administrationswerkzeug der Distribution, also beispielsweise "yast" bei SuSE, "coas" bei Caldera, "dldadmin" bei DLD oder "linusconf" bei RedHat. In die entsprechenden Masken sind die passenden Werte einzutragen und alles andere wird automatisch erledigt, inklusive des Aufrufs des "lilo".Alternativ kann der neue Kernel auch gleich im Verzeichnis "/boot" ausgeben werden, wenn im Haupt-Makefile eine Änderung vorgenommen wird. In diesem Fall muss man in der Datei "/usr/src/linux/Makefile" die Auskommentierung der Zeile "INSTALL_PATH=/boot" löschen. Dadurch würde der neue Kernel gleich im Verzeichnis "/boot" landen, sodass Umkopieren entfällt.

Um das System mit dem neuen Kernel auf diese Weise zu starten, trägt man den Namen in die lilo-Konfigurationsdatei ein. Allerdings darf der natürlich nach d natürlich nach der Erzeugung des Kernels nicht vergessen werden, das Kommando "lilo" einzugeben, um diesen beim System anzumelden.

Der Rechner kann nun neu gestartet werden. Falls es nicht so funktionierten sollte, kann man auch wieder mit dem alten Kernel booten und somit erneut einen neuen Kernel generieren, der dann hoffentlich auch funktioniert.

Doch damit ist es noch nicht getan, sofern auch Module verwendet werden. Ähnlich wie der Kernel installiert wurde, muss dies auch mit den Modulen getan werden. Allerdings existiert hierfür ein spezielles Kommando, das bei allen Distributionen gleich ist. Ist man übrigens nicht sicher, ob die neuen Module auch wirklich funktionieren, so hat man die Möglichkeit, die alten zu sichern. Zu diesem Zweck wechselt man in das Verzeichnis "/lib/modules/", wobei dort ein weiteres Unterverzeichnis mit der Versionsnumer des Kernels als Name ist. Dieses kopieret man mit seinem Inhalt einfach in ein anderes Verzeichnis, also beispielsweise von "/lib/modules/2.2.5" nach "/lib/modules/2.2.5.old", sodass im Falle eines Falles ein Zugriff möglich ist.

Ist dieser Schritt erfolgt, wechselt man in das Verzeichnis "/usr/src/linux/", um dort den Befehl "make modules_install" für die Installation der Module einzugeben. Dardurch werden die neuen Module in die für jeweilige Distribution passende Verzeichnisse kopiert, um danach vom neuen Kernel verwendent werden zu können.

Damit hätte man eigentlich fast alles erledigt, aber bei einigen Distributionen (beispielsweise SuSE) müssen noch zusätzlich die Datei "System.map" in das Verzeichnis "/boot" kopiert werden. Diese Datei enthält die Kernelsymbole, die von den Modulen benötigt werden und diese müssen natürlich zu den aktuellen erzeugten Modulen passen. Hat man dieses nicht ausgeführt, könnte es vorkommen, dass eine sich entsprechende Fehlermeldung beim Hochfahren des Rechners bemerkbar macht. Bei anderen Distributionen wird unter "/boot/System.map" ein Link auf die Datei im Verzeichnis "/usr/scr/linux", beziehungsweise auf das spezielle Verzeichnis der jeweiligen Distribution, gesetzt, sodass automatisch immer die jeweils aktuelle Version verwendet wird. Dabei kann es allerdings auch vorkommen, dass die Datei im Verzeichnis "/boot" einen etwas anderen Namen hat, sodass man unter Umständen ein bir Umständen ein bisschen suchen muss.

Andererseits kann es aber auch vorkommen, dass der Link auf eine spezielle Datei im selben Verzeichnis weist, die im Namen noch die Versionsnummer des Kernels enthält. In diesem Fall muss dann wieder die neu erzeugte Datei umkopiert werden, damit beim Starten keine Fehlermeldung erscheint.

Hat man alle besprochenen Schritte befolgt, sollte man in der Lage sein, einen neuen Kernel zu erzeugen und diesen dann auch zu installieren. Ausserdem hat man nun immern och die Möglichkeit, auf den alten Kernel auszuweichen, wenn sich der neue doch als fehlerhaft erweist. Dabei ist der Vorgang im Wesentlichen unabhängig von der gewählten Distribution gleich, wobei aber im Detail doch diverse Unterschiedee bestehen, wie man bei der Datei "System.map" gesehen hat.

Schnellanleitung zum Übersetzten eines neuen Kernels: