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.
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.
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/
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.
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:
/) des Systems?
/usr/src/linux befindet.
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!
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.
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.
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
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.
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.
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>
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:
# ln -s /usr/src/linux/include/linux /usr/include/linux
/opt/Sources ausgepackt wurde:
# cd /usr/include
# rm -f linux
# ln -s /opt/Sources/linux/include/linux linux
include-Dateien wieder zu installieren:
# tar zxvpf linux.x.y.z.tar.gz linux/include
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
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