Als je nieuwe kernel echt vreemde dingen doet na een routine kernel-upgrade,
bestaat de kans dan je vergat
make clean
uit te voeren voordat je de nieuwe kernel compileerde.
De symptomen kunnen van alles zijn, van je systeem dat ineens crasht,
vreemde I/O problemen, te lage performance. Wees er zeker van dat je
ook een make dep
doet.
Als je kernel een boel geheugen opslurpt, te groot is, en/of het compileren eeuwig duurt, ook al heb je een nieuwe Quadbazillium-III/4400 die eraan werkt, dan heb je waarschijnlijk erg veel onnodig spul (device drivers, bestandssystemen, enz) geconfigureerd. Als je het niet gebruikt, configureer het dan niet, want het neemt geheugen in beslag. Het meest opvallende van kernel bload is het extreme in en uitswappen van geheugen naar de disk; als je disk een heleboel lawaai maakt en het niet één van die oude Fujitsu Eagles is, die klinken alsof er een straalvliegtuig landt als je je computer uitzet, kijk dan nog eens naar je kernelconfiguratie.
Je kunt erachter komen hoeveel geheugen je kernel gebruikt door de
totale hoeveelheid geheugen in je machine af te trekken van de hoeveeelheid
van ``total mem'' in /proc/meminfo
of de uitvoer van het
commando `free
'.
Configuratie-opties voor PC's zijn: Selecteer als eerste, onder de categorie `General Setup', `Parallel port support' en `PC-style hardware'. Selecteer dan onder `Character devices', `Parallel printer support'.
En dan zijn er nog de namen. Linux 2.2 noemt de printerdevices anders dan
in voorgaande releases.
Het komt hierop neer dat, als je onder je oude kernel een lp1
had, het onder je nieuwe kernel waarschijnlijk een lp0
is.
Gebruik `dmesg
' of doorzoek de logs in /var/log
om erachter
te komen.
Als het niet compileert, dan is het waarschijnlijk dat er een patch
mislukte, of je source is op énén of andere manier verknoeid.
Het kan ook zijn dat je niet de juiste versie van gcc hebt, of deze kan
ook verknoeid zijn (de include bestanden kunnen bijvoorbeeld fout zijn).
Zorg ervoor dat de symbolische links, die Linux in de
README
beschrijft, juist zijn ingesteld.
In het algemeen geldt, dat als een standaardkernel niet compileert, er
iets ernstig mis is met het systeem, en opnieuw installeren van bepaalde
tools is waarschijnlijk noodzakelijk.
In een aantal gevallen kan gcc door hardwareproblemen crashen. De foutmelding zal iets zijn als ``xxx exited with signal 15'' en het zal er gewoonlijk zeer mysterieus uitzien. Ik zou dit waarschijnlijk niet ter sprake hebben gebracht, behalve dat het me een keer overkwam - Ik had wat slecht cache geheugen, en de compiler kon nu en dan willekeurig weigeren. Probeer als eerste gcc opnieuw te installeren als je problemen ervaart. Je zou alleen achterdochtig moeten zijn, als je kernel goed compileert met externe cache uitgezet, een verminderde hoeveelheid RAM, enz.
Het schijnt mensen te storen wanneer er wordt gesuggereerd, dat er problemen
met hun hardware zijn. Ik verzin dit niet. Er is een FAQ voor -- het is te
vinden bij http://www.bitwizard.nl/sig11/
.
Je hebt LILO niet gedraaid of het is niet juist geconfigureerd.
Één ding dat me eens ``overkwam'', was een probleem in het
configuratiebestand; het gaf aan `boot = /dev/hda1
'
in plaats van `boot = /dev/hda
' (Dit kan in het begin echt
hinderlijk zijn, maar zodra je een werkend configuratiebestand hebt, zou
je het niet meer hoeven te wijzigen).
Oeps! Het beste wat je hier kunt doen is met een diskette of CDROM te
booten en een andere opstartbare diskette aan te maken
(zoals `make zdisk
' zou doen).
Je zult moeten weten waar je root (/
) bestandssysteem zich bevindt
en van welk type het is
(b.v. second extended, minix). In het voorbeeld hieronder zul je ook moeten
weten op welk bestandssysteem je
/usr/src/linux
source-tree zich bevindt, het type,
en waar het normaal gesproken wordt gemount.
In het volgende voorbeeld, is /
/dev/hda1
, en het
bestandssysteem met /usr/src/linux
is /dev/hda3
, normaal gesproken gemount onder /usr
.
Het zijn allebei second extended bestandssystemen. De werkende kernel image in
/usr/src/linux/arch/i386/boot
wordt bzImage
genoemd.
De bedoeling is, dat als er een functionerend
bzImage
is, het mogelijk is om dat voor de nieuwe diskette te
gebruiken. Een ander alternatief, welke wel of niet beter kan werken,
(dit hangt af van de speciale methode waarin je je systeem hebt verknoeid)
wordt na het voorbeeld besproken.
Boot om te beginnen vanaf een boot/root diskset of rescuedisk, en mount het bestandssysteem waarin zich de werkende kernel-image bevindt:
mkdir /mnt mount -t ext2 /dev/hda3 /mnt
Als mkdir
je de melding geeft dat de directory al bestaat, negeer
het dan gewoon.
cd
nu naar de plaats waar de werkende kernel-image stond. Merk
op dat
/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/boot
Plaats een geformatteerde disk in drive ``A:'' (niet je boot- of rootdisk!), dump de image naar de disk, en configureer het voor je root bestandssysteem:
cd /mnt/src/linux/arch/i386/boot dd if=bzImage of=/dev/fd0 rdev /dev/fd0 /dev/hda1
cd
naar /
en unmount het normale /usr
bestandssysteem:
cd / umount /mnt
Je zou je systeem nu zoals gewoonlijk vanaf deze diskette op moeten kunnen starten. Vergeet na het opstarten, lilo niet te draaien (of wat je ook verkeerd deed)!
Zoals hierboven genoemd, is er nog een ander alternatief. Als je
een werkende kernel-image in /
hebt, (bijvoorbeeld
/vmlinuz
), kun je dat voor een bootdisk gebruiken.
Uitgaande van alle bovenstaande condities, en dat mijn kernel-image
/vmlinuz
is, maak je gewoon deze wijzigingen aan, in het
voorbeeld hierboven:
verander
/dev/hda3
in /dev/hda1
(het /
bestandssysteem),
/mnt/src/linux
in
/mnt
, en if=bzImage
in if=vmlinuz
. De
opmerking die uitleg geeft hoe /mnt/src/linux
kan worden afgeleid,
kan worden genegeerd.
LILO met grote drives gebruiken, (meer dan 1024 cylinders) kan problemen veroorzaken. Zie de LILO mini-HOWTO of documentatie hierover voor hulp.
Dit kan een ernstig probleem zijn. Beginnend met kernelrelease
na 1.0 (rond 20 Apr 1994), werd een programma met de naam
`update
' bijgewerkt, welke periodiek de buffers van het
bestandssysteem opschoont.
Haal de sources van `bdflush
' op
(je zou het moeten kunnen vinden daar waar je je kernelsource vandaan hebt
gehaald), en installeer het (je wilt je systeem waarschijnlijk
onder de oude kernel draaien als je hiermee bezig bent). Het
installeert zichzelf als `update
' en na een reboot, zou de nieuwe
kernel er niet langer problemen mee moeten hebben.
Vreemd genoeg krijgen een heleboel mensen hun ATAPI drives niet werkend, waarschijnlijk omdat er een aantal dingen verkeerd kan gaan.
Als je CD-ROM drive het enige apparaat op een bepaalde IDE interface is, moet het als ``master'' of ``slave'' zijn gejumperd. Dit is vermoedelijk de meest voorkomende fout.
Creative Labs heeft nu IDE-interfaces op hun geluidskaarten gezet. Dit leidt echter tot het interessante probleem dat terwijl een aantal mensen slechts één interface heeft , hebben velen twee IDE-interfaces op hun moederborden ingebouwd (meestal op IRQ15), dus het is een algemene gewoonte om van de soundblaster interface een derde IDE poort te maken (IRQ11, is me verteld).
Dit veroorzaakt problemen met linux gezien versies 1.2.x geen derde IDE-interface ondersteunen (er is ondersteuning te beginnen ergens in 1.3.x series maar dat is development, denk daaraan, en het doet geen auto-probe). Om dit te omzeilen, heb je een paar keuzes.
Als je al een tweede IDE-poort hebt, bestaat de kans dat je het niet gebruikt, of er zich nog geen twee devices op bevinden. Haal de ATAPI-drive van de geluidskaart af en bevestig het aan de tweede interface. Je kunt de interface van de geluidskaart vervolgens de-activeren, wat je hoe dan ook een IRQ bespaart.
Als je geen tweede interface hebt, jumper de interface van de geluidskaart (niet het geluidsdeel van de geluidskaart) dan als IRQ15, de tweede interface. Het zou moeten werken.
Haal nieuwe versies op van het route
programma en enige andere
programma's die er zijn voor route manipulatie.
/usr/include/linux/route.h
(dat eigenlijk een bestand in
/usr/src/linux
is), is gewijzigd.
Upgrade naar tenminste versie 1.2.1.
Gebruik het bestand vmlinux
die je in /usr/src/linux
hebt aangemaakt, niet als je boot-image; het juiste bestand is
[..]/arch/i386/boot/bzImage
.
Wijzig het woord dumb
in linux
in de console termcap
entry in /etc/termcap
. Het kan ook zijn dat je een terminfo
entry moet maken.
De linux kernelsource bevat een aantal include bestanden (die met
een .h
eindigen), waarnaar wordt verwezen door de standaard
include bestanden in /usr/include
.
Er wordt als volgt naar verwezen (waar
xyzzy.h
iets in /usr/include/linux
zou zijn):
#include <linux/xyzzy.h>
Normaal gesproken, is er een link met de naam linux
in
/usr/include
naar de directory
include/linux
van je kernelsource
(/usr/src/linux/include/linux
op het systeem). Als deze link
niet voorkomt, of naar de verkeerde plaats verwijst, zal het meeste helemaal
niet worden gecompileerd.
Als je besloot de kernelsource te verwijderen, omdat het te veel
ruimte op de disk in beslag nam, zal dit uiteraard een probleem zijn.
Een andere manier waarop het fout kan gaan is door bestandspermissies;
als je root
een umask heeft, die andere gebruikers niet toestaat,
standaard de bestanden te zien, en je pakte de kernelsource uit met de
p
(preserve filemodes)
optie, dan zullen die gebruikers ook niet in staat zijn om de C compiler
te gebruiken. Alhoewel je het
chmod
commando zou kunnen gebruiken om dit te herstellen,
is het waarschijnlijk makkelijker om de include bestanden opnieuw uit te
pakken. Je kunt dit op dezelfde manier doen zoals
je in het begin met de hele source deed, alleen met een aanvullend argument:
blah# tar zxvpf linux.x.y.z.tar.gz linux/includeOpmerking: ``
make config
'' zal de /usr/src/linux
opnieuw aanmaken als het er niet is.
De volgende paar voorbeeldcommando's kunnen handig zijn voor degenen die zich afvragen hoe ze bepaalde software-limieten kunnen verhogen die door de kernel worden opgelegd:
echo 4096 > /proc/sys/kernel/file-max echo 12288 > /proc/sys/kernel/inode-max echo 300 400 500 > /proc/sys/vm/freepages