Om din nya kärna gör riktigt knasiga saker, efter en rutin-uppgradering av
kärnan, så finns det en möjlighet att du glömt att make clean,
innan du kompilerade den nya kärnan. Symptomen kan vara allt från att ditt
system helt enkelt kraschar och konstiga in/ut-problem, till dålig
prestanda. Se till att du gör en make dep också.
Om din kärna suger åt sig en massa minne, är för stor och/eller bara tar en evighet att kompilera, även när du har fått din nya 786DX6/440 att fungera med den, så har du antagligen konfigurerat in en massa onödiga saker (drivrutiner, filsystem osv.). Det du inte använder ska du inte ta med, för det tar upp minne. De mest uppenbara symptomen på för stora kärnor är extrem swappning till och från hårddisken; om din hårddisk för en massa oväsen, och den inte är en sådan där gammal Fujitsu Eagle, som lät som en jumbo-jet som var på väg att landa när du slog av dem, så ta en titt på din kärn-konfigurering.
Du kan ta reda på hur mycket minne kärnan använder genom att ta den totala
mängden minne i din maskin och subtrahera summan av "total mem" i
/proc/meminfo, eller utdatan från kommandot `free'. Du kan
också ta reda på det genom att köra `dmesg' (eller genom att titta
på kärnans log-fil, var den nu finns på ditt system). Där finns en rad som
ser ut någonting i stil med detta:
Memory: 15124k/16384k available (552k kernel code, 384k reserved, 324k data)
Min 386 (vilken har en aning mindre skräp in-konfigurerat) säger:
Memory: 7000k/8192k available (496k kernel code, 384k reserved, 312k data)
Om du bara `måste' ha en stor kärna, men systemet inte låter dig ha det, så
kan du testa `make bzimage'. Du kan mycket väl bli tvungen att
installera en ny version av LILO för att få detta att fungera.
Om den inte kompilerar så är det troligt att en patch misslyckades, eller
att din källkod är korrupt på något sätt. Det kan också vara något fel på
din version av gcc, eller den kan vara korrupt (det kan t.ex. vara något fel
på include-filerna). Se till att de symboliska länkar, som Linus beskriver
i README-filen ser ut som de ska. Rent generellt kan man säga, att
om en standard-kärna inte kompilerar, så är det något stort fel på ditt
system, och en ominstallering av vissa saker är antagligen nödvändig.
Eller du kanske kompilerar en 1.2.x-kärna med en ELF-kompilator (gcc 2.6.3
eller högre). Om du får en hög det-och-det undefined-meddelanden
under kompileringen, så finns det vissa möjligheter att det är detta som är
ditt problem. Lösningen är i de flesta fall väldigt enkel. Lägg till
följande rader i början av arch/i386/Makefile:
AS=/usr/i486-linuxaout/bin/as LD=/usr/i486-linuxaout/bin/ld -m i386linux CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/includeKör sedan
make dep och zImage igen.
I sällsynta fall kan gcc krascha p.g.a. hårdvaru-problem. Fel-meddelandet kommer vara något i stil med "xxx exited with signal 15", och det kommer oftast se mystiskt ut. Jag skulle antagligen inte nämna detta, om det inte hade hänt mig en gång - jag hade dåligt cache-minne, och kompilatorn kunde begå slumpmässiga fel. Pröva först med att ominstallera gcc, om du får problem. Du bör endast börja bli misstänksam om din kärna kompilerar bra med "external cache" avslaget, en mindre mängd RAM osv.
Det brukar irritera folk, när det sägs att det kan vara något problem med
deras hårdvara. Tja, jag sitter inte och hittar på det här. Det finns en
FAQ om detta -- den finns på
http://www.bitwizard.nl/sig11/.
Du körde inte LILO, eller konfigurerade det inte korrekt. En sak som "fick"
mig en gång, var ett problem med konfigurerings-filen; den sa `boot =
/dev/hda1', istället för `boot = /dev/hda'. (Detta kan först
vara väldigt irriterande, men så fort du har en fungerande konfigurerings-fil
så behöver du inte göra några ändringar i den.)
Hoppsan! Det bästa du kan göra här är att starta upp med en diskett och
preparera en till start-diskett (som `make zdisk' skulle göra).
Du måste veta var ditt rot-filsystem (/) finns, och vilken sort
det är (t.ex. second extended, minix). I exemplet nedan måste du också veta
vilket filsystem ditt /usr/src/linux-källkodsträd finns på, dess
typ och var det vanligtvis monteras.
I det följande exemplet är / /dev/hda1, och filsystemet
som innehåller /usr/src/linux är /dev/hda3, och monteras
vanligtvis på /usr. Båda filsystemen är second extended. Den
fungerande kärnan i /usr/src/linux/arch/i386/boot heter
zImage.
Idén är, att om det finns en fungerande zImage, så är det möjligt
att använda den till en ny diskett. Ett annat alternativ, vilket kan fungera
bättre eller sämre (det beror på metoden du använde när du stökade till i
filsystemet), diskuteras efter detta exempel.
Först och främst, starta från en start/rot-diskett-kombination eller en räddnings-diskett och montera filsystemet vilket innehåller den fungerande kärnan:
mkdir /mnt
mount -t ext2 /dev/hda3 /mnt
Om mkdir säger åt dig att katalogen redan existerar, ignorera det
bara. cd-a nu till stället där den fungerande kärnan finns.
Observera att
/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/bootSätt i en formatterad diskett i diskett-station "A:" (inte din start- eller rot-diskett!), dumpa kärnan på disketten och konfigurera den för ditt rot-filsystem:
cd /mnt/src/linux/arch/i386/boot
dd if=zImage of=/dev/fd0
rdev /dev/fd0 /dev/hda1
cd-a till / och avmontera det vanliga
/usr-filsystemet:
cd /
umount /mnt
Du ska nu kunna starta om ditt system som vanligt från denna diskett. Glöm inte att köra lilo (eller vad det nu var som gick snett) efter att du startat om!
Som nämndes ovan, så finns det ett annat vanligt alternativ. Om du
råkade ha en fungerande kärna i / (/vmlinuz t.ex.), så
kan du använda den till en start-diskett. Om vi förutsätter alla de
ovannämnda omständigheterna, och att kärnan är /vmlinuz, gör bara
följande ändringar i exemplet ovan: ändra
/dev/hda3 till /dev/hda1 (/-filsystemet),
/mnt/src/linux till
/mnt, och if=zImage till if=vmlinuz. Anmärkningen
som förklarar hur du tar reda på /mnt/src/linux kan du hoppa över.
Att använda LILO med stora hårddiskar (mer än 1024 cylindrar) kan leda till problem. See LILO mini-HOWTO eller dokumentationen för hjälp om det.
Det här kan vara ett allvarligt problem. Från och med en kärn-utgåva efter
1.0 (runt 20 april 1994), uppgraderas/utbyttes ett program som heter
`update', vilket regelbundet spolar ur (flushes) filsystemets
buffrar. Skaffa källkoden till `bdflush' (du kan hitta det där
du hittade källkoden till kärnan), och installera det (det är bäst att köra
systemet med den gamla kärnan, då du gör detta). Det installerar sig självt
som `update', och efter att du startat om ska den nya kärnan inte
längre klaga.
Du har antagligen en ELF-kompilator (gcc 2.6.3 eller senare) och källkoden
till kärna 1.2.x (eller tidigare). Den vanliga lösningen är att lägga till
följande tre rader i början av arch/i386/Makefile:
AS=/usr/i486-linuxaout/bin/as LD=/usr/i486-linuxaout/bin/ld -m i386linux CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
Detta kommer kompilera en 1.2.x-kärna med a.out-bibliotek.
Konstigt nog så är det många som inte kan få sina ATAPI-spelare att fungera, antagligen för att det finns ett antal saker som kan gå snett.
Om din CD-ROM-spelalre är den enda enheten på ett visst IDE-gränssnitt så måste de jumpras som "master" eller "single". Detta påstås vara det vanligaste felet.
Creative Labs (som ett exempel) har satt IDE-gränssnitt på sina ljudkort nu. Detta leder dock till det intressanta problemet att, medan vissa bara har ett gränssnitt från början, så har många IDE-gränssnitt inbyggda i sina moderkort (vanligen på IRQ15), så en vanlig praxis är att göra soundblaster-gränssnittet till en tredje IDE-port (IRQ11, åtminstone är det vad jag har hört).
Detta skapar problem med Linux, genom att version 1.2.x inte stödjer ett tredje IDE-gränssnitt (stödet dyker upp någonstans i 1.3.x-serien, men det är en utvecklings-serie och den auto-söker inte). För att komma runt detta, kan du välja mellan några olika metoder.
Om du redan har en andra IDE-port, så finns det risk att du inte använder den, eller att den redan inte har två enheter. Ta ATAPI-spelaren från ljudkortet och sätt det på det andra gränssnittet. Sedan kan du stänga av ljudkortets gränssnitt, vilket i alla fall sparar in en IRQ.
Om du inte har ett andra gränssnitt, jumpra ljudkortets gränssnitt (inte ljudkortets ljud-delar) som IRQ15, det andra gränssnittet. Detta bör fungera.
Om den, av någon anledning, absolut måste vara på ett så kallat "tredje"
gränssnitt, eller om det finns andra problem, skaffa en 1.3.x-kärna
(1.3.57 har det, t.ex.) och läs igenom drivers/block/README.ide.
Det finns mycket mer information där.
Skaffa nya versioner av route-programmet och alla andra program som
sysslar med route-manipulering. /usr/include/linux/route.h (vilken
faktiskt är en fil i /usr/src/linux) har ändrats.
Uppgradera till åtminstone version 1.2.1.
Använd inte vmlinux-filen, vilken skapas i /usr/src/linux
som kärna; [..]/arch/i386/boot/zImage är den rätta.
Ändra ordet dumb till linux i konsollens termcap-rad i
/etc/termcap. Du kan också bli tvungen att skapa en
terminfo-avdelning.
Källkoden till Linux-kärnan innehåller ett antal include-filer (sakerna som
slutar med .h), vilka hänvisas till av standard-versionerna i
/usr/include. De hänvisas vanligtvis till på detta sätt (där
xyzzy.h skulle vara något i /usr/include/linux):
#include <linux/xyzzy.h>
Vanligtvis finns det en länk, som heter linux i
/usr/include till include/linux-katalogen i din kärn-källkod
(/usr/src/linux/include/linux i ett vanligt system). Om denna länk
inte finns där, eller pekar till fel ställe, så kommer det mesta att vägra
kompilera. Om du bestämmer dig för att källkoden till kärnan tar upp för
mycket plats på hårddisken, och tar bort den, så är detta uppenbarligen ett
problem. Ett annat sätt det kan gå fel på är med fil-rättigheter; om din
root har en umask, som inte tillåter andra användare att se dess
filer som standard, och du packade upp kärn-källkoden med
p-parametern (bevara fil-lägen), så kommer de andra användarna inte
att kunna använda C-kompilatorn. Även om du skulle kunna använda
chmod-kommandot för att fixa detta, så är det antagligen enklare
att packa upp include-filerna igen. Du kan göra detta på samma sätt som du
packade upp hela källkoden från början, men med en ytterligare parameter:
blah# tar zxvpf linux.x.y.z.tar.gz linux/include
Observera: "make config" kommer återskapa
/usr/src/linux-länken, om den inte finns där.
De följande få exempel-kommandona kan vara hjälpsamma för de som undrar hur man kan utöka vissa "mjuka" gränser, som sätts av kärnan:
echo 4096 > /proc/sys/kernel/file-max echo 12288 > /proc/sys/kernel/inode-max echo 300 400 500 > /proc/sys/vm/freepages