Linux Kernel HOWTO: Einige Fußangeln

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

7.2 Sehr große 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 möglicherweise einige gar nicht benötigte Dinge (Gerätetreiber, Dateisysteme usw.) in den Kernel integriert. Ein typisches Anzeichen für einen solchen überfrachteten Kernel ist eine überhöhte Swap-Aktivität. Dabei werden die jeweils gerade nicht benötigten Speicherbereiche auf die Festplatte ausgelagert und bei Bedarf wieder zurückgeladen. Ein zu großer Kernel läßt weniger physikalischen Hauptspeicher für die Anwendungen übrig, so daß das Swappen früher einsetzt. Erkennbar ist es an einer dauernden Festplattenaktivität.

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

Den tatsächlich vom Kernel belegten Anteil des Hauptspeichers findet man folgendermaßen heraus: Durch den Befehl cat /proc/meminfo oder free erfährt man den Betrag des gesamt zur Verfügung stehenden Hauptspeichers (Mem: total bzw. MemTotal). Diesen Wert subtrahiert man einfach vom insgesamt installierten Speicher. Eine andere Möglichkeit 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 großen 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 schlägt fehl

Eine mißlungene 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 Lösung, sich einen kompletten neuen Kernel-Quellcode zu besorgen und zu installieren.

Die neuen Kernels der 2.0.x Generation bieten die Möglichkeit, die Konfiguration menügesteuert entweder mit make menuconfig oder make xconfig durchzuführen. 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 durchzuführen, 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 höher) zu übersetzen. Typischerweise bekommt man dabei haufenweise Fehlermeldungen der Art ****** undefined. Normalerweise ist dieser Fehler schnell behoben: Am Anfang der Datei arch/i386/Makefile müssen die folgenden Zeilen eingefügt 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 überprüfen sollte.

In wirklich sehr seltenen Fällen kann gcc auch aufgrund von Hardware-Problemen abstürzen. Die Fehlermeldung lautet dann in etwa xxx got fatal signal 11 und man hat keinerlei Ahnung, was das bedeutet. Insbesondere diese Signal 11 Abstürze deuten immer auf Probleme mit der Speicher-Hardware hin. Dies können 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 erhöhen.

Es gibt einen eigenen Hilfetext, der sich speziell mit dieser Art von Problemen beschäftigt:

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

7.4 Der neu installierte Kernel bootet nicht

lilo wurde nach der Installation nicht ausgeführt. 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 lädt, 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 für Probleme mit LILO können große Festplatten mit mehr als 1024 Zylindern sein. Das LILO mini-HOWTO oder die Dokumentation von LILO selber geben dazu nähere 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.

Zunächst bootet man also die Rettungsdiskette. Dann muß das Dateisystem, welches den Kernel enthält, gemounted werden. Hierfür benötigt man einen Mount Point, meist wird dafür /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 berücksichtigt werden, daß das Verzeichnis nicht wie gewohnt unter /usr gemounted wurde. Für 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:), überträgt den Kernel auf diese Diskette und konfiguriert ihn für 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 zurückgewechselt 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 für sehr alte Installationen ein Problem, dort aber ein schwerwiegendes. Dieses Programm schreibt in regelmäßigen Abständen die Dateisystem-Buffer auf die Festplatte zurück. 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 Einführung des ATAPI-Standards der Anschluß von CD-ROM-Laufwerken stark vereinheitlicht wurde, treten noch recht häufig Probleme auf, da immer noch einige Dinge beachtet werden müssen.

Ist das CD-ROM-Laufwerk das einzige Gerät 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 Umständen zu Problemen führen. 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 unterstützen jedoch nur maximal zwei IDE-Schnittstellen. Wer noch diesen alten Kernel verwendet, hat mehrere Möglichkeiten zur Auswahl:

Nur in den seltensten Fällen sind an beiden IDE-Schnittstellen auf dem Mainboard bereits zwei Geräte angeschlossen. In diesem Fall kann man das ATAPI-CD-ROM dort anschließen und die Schnittstelle auf der Soundkarte ausschalten. Dies hat außerdem 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 frühen 1.3.x Phase) haben solche Probleme nicht mehr. Ihr neuer IDE-Treiber unterstützt 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 zusammenhängender Routinen. Die Include-Datei /usr/include/linux/route.h hat sich in neueren Versionen des Kernels verändert. 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 später

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

7.11 Seit dem Kernel-Upgrade kann ich nichts mehr kompilieren

Manche Programme benötigen 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 Möglichkeiten, warum der Compiler die gesuchten Dateien nicht findet:

Der Link existiert nicht. Dies läßt sich einfach beheben:
# ln -s /usr/src/linux/include/linux /usr/include/linux
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. für 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
Die Kernel-Quellen sind nicht installiert. Oft wird aus Platzmangel der gesamte Kernel-Verzeichnisbaum gelöscht. Hier hilft es nur, die include-Dateien wieder zu installieren:
# tar zxvpf linux.x.y.z.tar.gz linux/include
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 für tar verwenden oder zumindest für das include-Verzeichnis den lesenden Zugriff für alle ermöglichen, da sonst nur root den Compiler benutzen kann. Dieses geschieht nachträglich mit dem Befehl:
# cd /usr/src/linux # chmod -R go+r include

7.12 Erhöhung von Systembeschränkungen

Die folgenden Beispiele sind vielleicht ein Hinweis für all diejenigen, die sich fragen, wie man die diversen veränderbaren Schrankenwerte (»Soft Limits«) im Kernel verändern kann:


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

Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 17:56:57

7. Einige Fußangeln

7.1 make clean