<!-- This is the Linux Kernel HOWTO, SGML source -- >

<!doctype linuxdoc system>

<article>

<title>The Linux Kernel HOWTO
<author>Brian Ward, <tt>bri@blah.math.tu-graz.ac.at</tt>, svensk översättning:
Linus Åkerlund, uxm165t@tninet.se
<date>v0.80, 26 May 1997, svensk översättning 21 juni 1998

<abstract>
Detta är en detaljerad guide till kärn-konfigurering, kompilering,
uppgraderingar och problem-lösning för ix86-baserade system.
</abstract>

<toc>

<sect> Inledning <p>

Borde du läsa det här dokumentet? Tja, se efter om du har något av följande
problem:
<p>

<itemize>
<item> "Arg! Det här wizzo-46.5.6-paketet säger att det behöver
kärn-version 1.8.193 och jag har fortfarande version 1.0.9!"
<item> Det finns en enhets-drivrutin i en av de nyare kärnorna som
du bara måste ha
<item> Du har verkligen inte en aning om hur man kompilerar en kärna
<item> "Är de här grejerna i READMEn <it>verkligen</it> allt?"
<item> Du kom, du försökte, det fungerade inte
<item> Du behöver något att ge till folk som insisterar på att be dig
att installera deras kärnor åt dem
</itemize>

<sect1> Läs det här först! (Jag menar det)<p>
Några av exemplen i det här dokumentet förutsätter att du har GNU <tt>tar</tt>,
<tt>find</tt> och <tt>xargs</tt>. De är ganska standard; detta ska inte skapa
några problem. Det förutsätts också att du känner till ditt systems
filsystems-struktur; om du inte gör det så är det viktigt att du har en
avskrift av <tt>mount</tt>-kommandots utdata, under normala förhållanden
(eller en listning av <tt>/etc/fstab</tt>, om du förstår den). Denna 
information är viktig och ändras inte, förutsatt att du inte partitionerar om
din hårddisk, lägger till en ny, installerar om ditt system eller något
liknande.

<p>
Den senaste "production"-versionen av kärnan, när detta skrivs, var 2.0.30,
vilket innebär att referenserna och exemplen korresponderar till den
utgåvan. Även om jag försöker göra det här dokumentet så 
versions-oberoende som möjligt, så är kärnan ständigt under utveckling, så
om du har en ny utgåva, så kommer där oundvikligen att finnas skillnader.
Återigen, detta borde inte skapa några problem, men det skulle kunna ge
upphov till viss förvirring.

<p>
Det finns två versioner av källkoden till Linux-kärnan, "production" och
"development" (stabil respektive utvecklings-version. övers.anm.). 
Production-utgåvor börjar med 1.0.x är för tillfället versionerna med jämna
nummer; 1.0.x var production, 1.2.x var production, precis som 2.0.x. Dessa
kärnor anses vara de mest stabila, bugg-fria versionerna tillgängliga, då
de ges ut. Utvecklings-versionerna av kärnan (1.1.x, 1.3.x osv) är menade
som test-kärnor, för folk som har lust att prova på nya och ibland ganska
buggiga kärnor. Du har blivit varnad.
<p>

<sect1>Några ord om stilen

<p>

<tt>Text som ser ut så här</tt> är antingen något som uppträder på din
skärm, ett filnamn, eller något som kan skrivas in direkt, såsom ett
kommando, eller parametrar till ett kommando (om du läser detta dokument
i rent text-format, så ser det inte annorlunda ut). Kommandon och andra
indata citeras ofta (med ` '), vilket skapar följande klassiska
kommaterings-problem: om en sådan sak uppträder i slutet av en mening, inom
citationstecken, så skriver folk ofta en `.' tillsammans med kommandot,
eftersom det amerikanska sättet att citera säger att man ska sätta punkten
innanför citationstecknen. Även om det sunda förnuftet (och tyvärr så
förutsätter detta att den som har sunt förnuft är van vid den så kallade
amerikanska citations-stilen) borde säga åt en att ta bort punkten först,
så är det många som helt enkelt inte kommer ihåg det, så jag kommer placera
punkten utanför citations-tecknen i sådana fall. Med andra ord, om jag 
säger år dig att skriva "<tt>make config</tt>", så skriver jag
`<tt>make config</tt>', inte `<tt>make config</tt>.'
<p>
<sect1> Översättarens anmärkningar
<p>
Uppdaterade dokumentet 13/11-98, genom att byta ut översättningen av
&quot;permissions&quot; till &quot;rättigheter&quot;, istället för det
sämre &quot;tillåtelser&quot;
<p>

<sect>Viktiga frågor och svar på dessa <p>

<sect1>Vad är det kärnan gör, förresten? <p>

Unix-kärnan fungerar som en medlare mellan dina program och din
hårdvara. Först och främst så utför den (eller ser till så att det blir
utfört) minneshantering för alla program (processer) som körs, och ser
till så att alla får sin rättvisa (eller orättvisa, det beror på hur man
ser på saken) tilldelning av processor-cykler. Vidare så tillhandahåller
den ett trevligt, ganska portabelt gränssnitt, som gör att programmen kan
prata med din hårdvara.

<p>
Kärnan gör visserligen mer än så, men dessa grundläggande funktioner är
de viktigaste att känna till.

<p>

<sect1>Varför skulle jag vilja uppgradera min kärna?

<p>

Nyare kärnor erbjuder generellt möjligheter att prata med flera typer
av hårdvara (de har alltså fler enhets-drivrutiner), de kan ha bättre
process-hantering, de kan arbeta snabbare än äldre versioner, de kan
vara mer stabila än äldre versioner och de kan rätta till fjantiga
buggar i äldre versioner. De flesta uppgraderar sina kärnor för att de
vill ha drivrutinerna och bugg-fixarna.

<p>

<sect1>Vilken slags hårdvara stödjer de nyare kärnorna?

<p>

Se Hardware-HOWTOn. Eller så kan du ta en titt på `<tt>config.in</tt>'-filen
i Linux-källkoden, eller helt enkelt få reda på det när du kör
`<tt>make config</tt>'. Detta visar dig all hårdvara som stöds av
standard-distributionen av kärnan, men inte allt som Linux stödjer; många
vanliga enhets-drivrutiner (såsom PCMCIA-drivrutinerna och 
band-drivrutinerna) är laddningsbara moduler, vilka utvecklas och 
distribueras separat.

<p>

<sect1>Vilka versioner av gcc och libc behöver jag?

<p>

Linus rekommenderar en viss version av gcc i <tt>README</tt>-filen, som
kommer med Linux-källkoden. Om du inte har denna version, så talar
gcc-dokumentationen i den rekommenderade versionen av gcc om ifall du
behöver uppgradera libc. Detta är inte en svår procedur, men det är viktigt
att du följer instruktionerna. 

<p>

<sect1>Vad är en laddningsbar modul?
<p>

Dessa är delar av kärn-koden, vilka inte länkas (inkluderas) direkt till
kärnan. Man kompilerar dem separat, och kan sätta in dem och ta bort dem
från kärnan som körs, nästan när som helst. P.g.a. deras flexibilitet, så
är de nu det mest populära sättet att koda vissa kärn-funktioner. Många
populära enhets-drivrutiner, såsom PCMCIA-drivrutinerna och 
QIC-80/40 band-drivrutinerna, är laddningsbara moduler.

<p>

<sect1>Hur mycket hårddisk-utrymme behöver jag?
<p>

Det beror på just din system-konfiguration. Den komprimerade källkoden är
nästan 6 megabytes stor, vid version 2.0.10. De flesta behåller denna även
efter uppackningen. Uppackad tar den upp 24 MB. Men det räcker inte med
det -- du behöver mer för att faktiskt kompilera den. Detta beror på hur
mycket stoppar in i din kärna. På en specifik maskin, t.ex., så har jag
nätverk, 3com 3C509-drivrutinen och tre filsystem konfigurerade, till
vilket det går åt 30 MB. Om vi lägger till den packade Linux-källkoden, 
så behöver du runt 36 MB för just denna konfiguration. På ett annat system,
utan nätverks-enhets-stöd (men fortfarande med nätverks-stöd) och 
ljudkorts-stöd, tar den upp ännu mera utrymme. En nyare kärna har dessutom
med stor säkerhet ett större källkods-träd än en äldre, så rent generellt,
om du har en massa hårdvara, så måste du se till att du har en tillräckligt
stor hårddisk i röran (och med dagens prisläge kan jag inte låta bli att
rekommendera dig att skaffa en till hårddisk, som ett svar på dina
utrymmes-problem).

<p>

<sect1>Hur lång tid tar det?
<p>

För de flesta är svaret "ganska lång tid". Ditt systems hastighet och
mängden minne du har bestämmer, i sista instans, tiden, men det har även
en del att göra med mängden grejer du konfigurerar in i kärnan. På en
486DX4/100, med 16 MB RAM, tar det, för en v1.2-kärna med fem filsystem,
nätverks-stöd och ljudkorts-drivrutiner runt 20 minuter. På en 386DX/40
(8 MB RAM), med en liknande konfiguration, tar kompileringen nästan en och
en halv timme. Det är generellt sett en bra rekommendation att ta en kopp
kaffe, se på TV, sticka, eller vad du nu brukar göra för skojs skull, när
din maskin kompilerar en kärna. Du kan även be någon med en snabbare
maskin kompilera en kärna åt dig, om du har en långsam maskin.

<p>

<sect>Hur den faktiska konfigureringen av kärnan går till
<p>

<sect1>Skaffa källkoden
<p>

Du kan skaffa källkoden via anonym ftp från <tt>ftp.funet.fi</tt>, i
<tt>/pub/Linux/PEOPLE/Linus</tt>, en spegel eller någon annan sajt. Den
heter i typfallet <tt>linux-x.y.z.tar.gz</tt>, där <tt>x.y.z</tt> är 
versionsnumret. Nyare (bättre?) versioner och patcharna finns vanligtvis
i underkataloger som `<tt>v1.1</tt>'och `<tt>v1.2</tt>'. Det högsta
numret är den senaste versionen, och är vanligtvis en "test-utgåva", vilket
innebär att du inte ska ta hem den, om du känner dig osäker på beta- och
alfa-utgåvor. Håll dig i så fall till den stabila utgåvan.
<p>

Det rekommenderas <it>starkt</it> att du använder en spegel-sajt, istället
för ftp.funet.fi. Här kommer en kort lista på speglar och andra sajter:
<p>
<verb>
USA:         sunsite.unc.edu:/pub/Linux/kernel
USA:         tsx-11.mit.edu:/pub/linux/sources/system
UK:          sunsite.doc.ic.ac.uk:/pub/unix/Linux/sunsite.unc-mirror/kernel
Austria:     ftp.univie.ac.at:/systems/linux/sunsite/kernel
Germany:     ftp.Germany.EU.net:/pub/os/Linux/Local.EUnet/Kernel/Linus
Germany:     sunsite.informatik.rwth-aachen.de:/pub/Linux/PEOPLE/Linus
France:      ftp.ibp.fr:/pub/linux/sources/system/patches
Australia:   sunsite.anu.edu.au:/pub/linux/kernel
</verb>

Rent generellt så är en spegel-sajt till <tt>sunsite.unc.edu</tt> ett bra
ställe att leta på. Filen <tt>/pub/Linux/MIRRORS</tt> innehåller en lista
på kända speglar. Om du inte har tillgång till ftp, så postas en lista på
BBS-system med Linux regelbundet till comp.os.linux.announce; försök få
tag på den. 
<p>

Om du är ute efter generell information om Linux och distributioner, ta en
titt på <tt>http://www.linux.org</tt>.

<p>

<sect1>Packa upp källkoden
<p>

Logga in som, eller <tt>su</tt>-a till, `<tt>root</tt>', och <tt>cd</tt>-a
till <tt>/usr/src</tt>. Om du installerade kärn-källkoden, då du först
installerade Linux (som de flesta gör), så finns där redan en katalog som
heter `<tt>linux</tt>', vilken innehåller hela källkods-trädet. Om du har
gott om hårddisk-utrymme och vill ta det säkra före det osäkra, så behåll
den katalogen. En bra idé är att ta reda på vilken version ditt system kör
nu och byta namn på katalogen, enligt versions-numret. Kommandot
`<tt>uname -r</tt>' skriver ut den aktuella kärnans version. Alltså, om
`<tt>uname -r</tt>' säger `<tt>1.0.9</tt>', så bör du ändra namnet (med
`<tt>mv</tt>') på `<tt>linux</tt>' till `<tt>linux-1.0.9</tt>'.
Om du känner dig hyffsat vårdslös, så kan du helt enkelt ta bort katalogen.
I vilket fall som helst, se till så att det inte finns någon 
`<tt>linux</tt>'-katalog i <tt>/usr/src</tt> innan du packar upp det
fullständiga källkods-trädet.

<p>

Packa nu upp källkoden i <tt>/usr/src</tt> med
`<tt>tar zxpvf linux-x.y.z.tar.gz</tt>' (om du har en <tt>.tar</tt>-fil, utan
<tt>.gz</tt> på slutet, så fungerar
`<tt>tar xpvf linux-x.y.z.tar</tt>').
Innehållet i källkoden kommer flyga förbi. När uppackningen är klar, kommer
det finnas en ny `<tt>linux</tt>'-katalog i <tt>/usr/src</tt>. <tt>cd</tt>-a
till <tt>linux</tt> och läs igenom <tt>README</tt>-filen. Där finns en
avdelning som heter `<tt>INSTALLING the kernel</tt>'. Utför instruktionerna
när det är passande -- symboliska länkar som ska finnas på plats, borttagande
av onödiga <tt>.o</tt>-filer osv.

<sect1>Konfigurera kärnan
<p>
    Observera: En del av detta är upprepningar/klargöranden av en
    liknande avdelning i Linus <tt>README</tt>-fil.
<p>

Kommandot `<tt>make config</tt>', när du är i <tt>/usr/src/linux</tt>
startar ett konfigurerings-skal-program, vilket ställer en massa frågor.
Det kräver bash, så se till att bash är <tt>/bin/bash</tt>, <tt>/bin/sh</tt>
eller <tt>&dollar;BASH</tt>.
<p>
Det finns några alternativ till `<tt>make config</tt>', och det är mycket
möjligt att du kommer tycka att de är lättare och mer bekväma att använda.
De som "kör X" kan pröva `<tt>make xconfig</tt>', om de har Tk installerat
(`click-o-rama' - Nat). `<tt>make menuconfig</tt>' är för de som har
(n)curses och föredrar en text-baserad meny. Dessa gränssnitt har en klar
fördel: om du ställer till något dumt, och väljer fel på något alternativ,
under konfigureringen, så är det enkelt att gå tillbaks och fixa det.
<p>

Du ska vara redo att svara på frågorna, vanligtvis med `<tt>y</tt>' (ja) 
eller `<tt>n</tt>' (nej). Enhets-drivrutiner har vanligtvis även ett
`<tt>m</tt>'-alternativ. Detta betyder "modul", vilket innebär att systemet
kommer att kompilera den, men inte direkt in i kärnan, utan som en
laddningsbar modul. Ett lustigare sätt att beskriva det är som "maybe" 
(kanske.övers.anm.). Några av de mer uppenbara och okritiska alternativen
beskrivs inte här; se avsnittet "Andra konfigurerings-alternativ" för 
korta beskrivningar av några andra.
<p>

I 2.0.x och sernare finns det ett `?'-alternativ, vilket ger en kort
beskrivning av det aktuella alternativet. Den informationen är troligen den
mest aktuella.
<p>

<sect2>Matte-emulering i kärnan (Math emulation in kernel)
<p>

Om du inte har en matte-hjälp-processor (om du har en "bar" 386 eller 486SX),
så måste du säga `<tt>y</tt>' till detta. Om du har en hjälp-processor och
ändå säger `<tt>y</tt>', så är det inget att oroa sig för --
hjälp-processorn används i alla fall, och emuleringen ignoreras. Den enda
konsekvens detta får är att kärnan blir större (slöseri med RAM). Jag har 
blivit informerad om att matte-emuleringen är långsam; även om detta inte
har något med detta avsnitt att göra, så kan det vara bra att ha i 
bakhuvudet om du tycker att X-Window-systemet uppträder klumpigt.

<p>

<sect2>Normal (MFM/RLL) disk och IDE disk/cdrom-stöd 
<p>

Du behöver antagligen stödja detta; det innebär att kärnan kommer att
stödja vanliga PC-hårddiskar, vilket de flesta har. Den här drivrutinen
inkluderar inte SCSI-hårddiskar; de kommer senare i konfigureringen.

<p>

Du kommer sedan bli tillfrågad om "old disk-only"- och "new IDE"-drivrutinerna.
Du bör välja en av dessa: den huvudsakliga skillnaden är att den gamla
drivrutinen endast stödjer två hårddiskar på ett enda gränssnitt, och att den
nya stödjer ett sekundärt gränssnitt och IDE/ATAPI CD-ROM-spelare. Den nya
drivrutinen är 4k större än den gamla, och påstås också vara "förbättrad",
vilket innebär att, förutom att den innehåller ett annat antal buggar, så
kan den förbättra dina hårddiskars prestanda, speciellt om du har nyare
(EIDE-typ) hårdvara.
<p>

<sect2>Nätverks-stöd (Networking support)
<p>
In princip, säg `<tt>y</tt>' endast om din maskin är i ett nätverk, som
Internet, eller om du vill använda SLIP, PPP, term osv för uppringd
Internet-förbindelse. Men eftersom många paket (som X-Window-systemet)
kräver nätverks-stöd, även om maskinen inte finns i ett riktigt nätverk,
så bör du säga `<tt>y</tt>'. Senare kommer du bli tillfrågad om du vill
stödja TCP/IP-nätverk; säg återigen `<tt>y</tt>' här om du inte är 
absolut säker.
<p>

<sect2>Begränsa minnet till 16 MB (Limit memory to low 16 MB)<p>

Det finns buggiga "386 DMA controllers", vilka har problem med att komma åt
mer än 16 MB RAM; säg `<tt>y</tt>' om det skulle råka vara så att du har en.

<p>

<sect2>System V IPC <p>

En av de bästa definitionerna av IPC (Interprocess Communication) finns i
Perl book's ordlista. Inte helt överraskande, så använder vissa
Perl-programmerare det för att låta processer tala med varandra, och även
andra paket (av vilka DOOM är det mest anmärkningsvärda), så det är inte en
bra idé att säga <tt>n</tt>, om du inte vet exakt vad du sysslar med.

<p>

<sect2>Processor-typ (386, 486, Pentium, PPro)<p>
(i äldre kärnor: använd -m486-flaggan för 486-specifika optimeringar)
<p>

Traditionellt så har detta kompilerat vissa optimeringar för speciella
processorer; Kärnorna fungerade fint på andra chips, men kärnan blev
kanske en aning större. I nyare kärnor är dock inte detta längre fallet, så du
bör välja den processor du kompilerar kärnan för. En "386"-kärna fungerar
på alla maskinerna.
<p>

<sect2>SCSI-stöd (SCSI support) <p>
Om du har SCSI-enheter, säg `<tt>y</tt>'. Du kommer bli tillfrågad om 
vidare information, som t.ex. stöd för CD-ROM, diskar och vilken sorts
SCSI-adapter du har. Se SCSI-HOWTOn för mer detaljer.
<p>

<sect2>Stöd för nätverks-enhets (Network device support) <p>

Om du har ett nätverks-kort, eller om du vill använda SLIP, PPP eller en
parallell-ports-adapter för att koppla upp dig på Internet, säg `<tt>y</tt>'.
Config-programmet kommer fråga efter vilket slags kort du har, och
vilket protokoll du använder.

<p>

<sect2>Filsystem <p>

Config-programmet frågar sedan om du vill ha stöd för de följande filsystemen:

<p>

Standard (minix) - Nyare distributioner skapar inte minix-filsystem, och 
många använder det inte, men det kan fortfarande vara en bra idé att
ta med detta. Programmen på vissa "räddnings-disketter" använder det, och
många disketter kan fortfarande ha minix-filsystemet, eftersom det är mindre
smärtsamt att använda på en diskett.

<p>

Extended fs - Detta var den första versionen av det utvidgade filsystemet,
vilket inte längre används speciellt mycket. Det är antagligen så att du
vet om du behöver det och om du är osäker, så behöver du det inte.

<p>

Second extended - Det här används mycket i nyare distributioner. Du har
antagligen ett sådant, och ska säga `<tt>y</tt>'.

<p>

xiafs filesystem - En gång i tiden var det här inte så ovanligt, men när
detta skrivs, så vet jag inte om någon som använder det.

<p>

msdos - Om du vill använda din MS-DOS-hårddisks partitioner, eller montera
MS-DOS-formatterade disketter, säg `<tt>y</tt>'.

<p>

umsdos - Det här filsystemet expanderar ett MS-DOS-filsystem med vanliga
Unix-liknande funktioner, såsom långa filnamn. Det är inte användbart för
folk (som jag), som "inte DOSar".

<p>

/proc - Ännu en av de bästa sakerna sedan torrmjölk (idén skamlöst stulen
från Bell Labs, antar jag). Man skapar inte ett proc-filsystem på en disk;
det här är ett filsystems-gränssnitt till kärnan och processerna. Många
process-listare (såsom `<tt>ps</tt>') använder det. Testa
`<tt>cat /proc/meminfo</tt>' eller <tt>cat /proc/devices</tt>' ibland.
Vissa skal (speciellt rc) använder <tt>/proc/self/id</tt> (känt som
<tt>/dev/fd</tt> på andra system) för in/ut-hantering. Du ska antagligen
säga `<tt>y</tt>' till det här; många viktiga Linux-verktyg är beroende av
det.

<p>

NFS - Om din maskin finns i ett nätverk och du vill kunna använda filsystemen,
som finns på andra system, med NFS, säg `<tt>y</tt>'.

<p>

ISO9660 - Finns på de flesta CD-ROMar. Om du har en CD-ROM-spelare och vill
kunna använda den under Linux, säg `<tt>y</tt>'.

<p>

OS/2 HPFS - När detta skrivs, ett filsystem som endast tillåter läsning, för
OS/2 HPFS.

<p>

System V och Coherent - för partitioner i System V- och Coherent-system (det
finns andra Unix-varianter för PC).

<p>

<sect3>Men jag vet inte vilka filsystem jag behöver!
<p>

Okej, skriv `<tt>mount</tt>'. Utdatan kommer se ut något i denna stil:

<p>

<tscreen><verb>
    blah# mount
    /dev/hda1 on / type ext2 (defaults)
    /dev/hda3 on /usr type ext2 (defaults)
    none on /proc type proc (defaults)
    /dev/fd0 on /mnt type msdos (defaults)
</verb></tscreen>

Titta på varje rad; ordet brevid `<tt>type</tt>' är filsystems-typen.
I det här exemplet, mina <tt>/</tt>- och <tt>/usr</tt>-filsystem är
"second extended", jag använder <tt>/proc</tt> och det finns en diskett
monterad, vilken använder msdos-filsystemet (blä).

<p>
Du kan testa `<tt>cat /proc/filesystem</tt>', om du har <tt>/proc</tt> på
för tillfället; det kommer lista din nuvarande kärnas filsystem.
<p>
Att ta med sällan använda, icke nödvändiga filsystem kan leda till att 
kärnan blir onödigt stor; se avsnittet om moduler för en väg runt detta och
"Fallgropar"-avsnittet, om varför en för stor kärna inte är bra.
<p>

<sect2>Tecken-enheter (Character devices) <p>

Här tar du med drivrutiner för din skrivare (parallell-skrivare alltså), 
buss-mus, PS/2-mus (många bärbara datorer använder PS/2-mus-protokollet för
sina inbyggda trackballs), vissa band-spelare (tape drivers) och andra
dylika "tecken"-enheter. Säg `<tt>y</tt>' där det passar.
<p>

Anmärkning: Selection är ett program som låter användaren använda en mus 
utanför X-Window-systemet, för att kunna klippa och klistra mellan 
virtuella konsoller. Det är ganska trevligt om du har en seriell mus, för
det samexisterar bra med X, men du måste ta till speciella trick för andra.
Selection-stöd var ett konfigurerings-alternativ en gång i tiden, men det
är nu standard.
<p>
Anmärkning 2: Selection anses nu föråldrat. "gpm" är namnet på det nya
programmet. Det kan göra häftigare saker, som att översätta mus-protokoll,
hantera mer än en mus...
<p>

<sect2>Ljud-kort
<p>
Om du känner att du har ett behov av att höra <tt>biff</tt> skälla, säg
`<tt>y</tt>', och ett annat config-program kommer senare kompilera och fråga
efter alla data om ditt ljudkort. (En anmärkning om ljudkorts-inställning: när
det frågar dig om du vill installera "the full version" (den fullständiga
versionen) av drivrutinen, så kan du säga `<tt>n</tt>', och spara en del
kärn-utrymme, genom att välja enbart de funktioner du finner nödvändiga.) 
Jag rekommenderar starkt att du tar en titt på Sound-HOWTO, för mer 
detaljer om ljud-stöd, om du har ett ljudkort.
<p>

<sect2>Andra konfigurerings-alternativ
<p>

Alla konfigurerings-alternativ listas inte här, eftersom de ändras alldeles
för ofta, eller är ganska själv-förklarande (t.ex. 3Com 3c509-stöd, för att
kompilera drivrutinen för just detta ethernet-kort). Det finns en ganska
innehållsrik lista på alla alternativ (och ett sätta att placera dem i
<tt>Configure</tt>-skal-programmet), sammansatt av Axel Boldt
(<tt>axel@uni-paderborn.de</tt>), med den följande URLen:
<p>
<verb>
     http://math-www.uni-paderborn.de/~axel/config_help.html
</verb>
eller via anonym FTP från:
<p>
<verb>
     ftp://sunsite.unc.edu/pub/Linux/kernel/config/krnl_cnfg_hlp.x.yz.tgz
</verb>
Där <tt>x.yz</tt> är versionsnumret.
<p>
För senare (2.0.x och senare) kärnor har detta blivit integrerat i 
källkods-trädet.

<p>

<sect2>"Kärn-hackande" (Kernel hacking) <p>

>Från Linus README:

"kernel hacking"-konfigurering ger ofta en större eller långsammare (eller
båda) kärna, och kan till och med göra kärnan mindre stabil, genom att
ställa in vissa rutiner för att aktivt försöka förstöra dålig kod, för att
hitta kärn-problem (kmalloc()). Du ska alltså antagligen svara `n' på den
här frågan, om du vill ha en "production"-kärna.
<p>

<sect1>Och nu då? (Makefile)
<p>
Efter att du har kört <tt>make config</tt>, kommer ett meddelande som talar
om att din kärna har blivit konfigurerad, och att du ska "check the top-level
<tt>Makefile</tt> for additional configuration" etc. 
<p>

Ta alltså en titt på <tt>Makefile</tt>. Du kommer antagligen inte behöva
ändra i den, men det skadar inte att ta en titt. Du kan också ändra dess
val med `<tt>rdev</tt>'-kommandot, så fort kärnan är på plats.

<p>

<sect>Kompilera kärnan
<p>

<sect1>Städa upp och ange beroenden (Cleaning and depending) <p>

När configure-programmet avslutas säger det också åt dig att 
`<tt>make dep</tt>' och (eventuellt) `<tt>clean</tt>'. Kör alltså
`<tt>make dep</tt>'. Detta ser till så att alla beroenden (dependencies),
som include-filerna, är på plats. Det tar inte lång stund, om inte din
dator är ganska långsam från början. För äldre kärn-versioner ska du köra
en `<tt>make clean</tt>' när du är klar. Detta tar bort alla object-filer
och några andra saker, som en gammal version lämnar efter sig. I vilket fall
som helst, glöm <it>inte</it> detta steg, innan du försöker kompilera om
en kärna.

<p>

<sect1>Kompilerings-dags
<p>
Efter <tt>dep</tt> och <tt>clean</tt>, så kan du nu antingen köra `<tt>make
zImage</tt>' eller `<tt>make zdisk</tt> (det är den här delen som tar lång
tid). `<tt>make zImage</tt>' kommer kompilera kärnan och lämna en fil i
<tt>arch/i386/boot</tt>, vilken heter `<tt>zImage</tt>' (tillsammans med en
del andra saker). Detta är den nya, packade kärnan. `<tt>make zdisk</tt>'
gör samma sak, men lägger också in den nya <tt>zImage</tt> på en diskett,
vilken du förhoppningsvis satt in i floppy-station "A:". `<tt>zdisk</tt>'
är ganska praktiskt för att pröva nya kärnor; om den krashar (eller helt
enkelt inte fungerar speciellt bra), ta bara ut disketten och starta om med
din gamla kärna. Det kan också vara ett praktiskt sätt att starta upp om
du av misstag tar bort din kärna (eller något lika hemskt). Du kan också
använda den för att installera nya system, när du just har dumpat innehållet
från en hårddisk på en annan ("allt det här och mer! HUR mycket skulle du
betala?").

<p>

Alla åtminstone halvvägs resonabla nya kärnor är packade, därav 
`<tt>z</tt>' framför namnet. En packad kärna packar automatiskt upp sig
själv när den körs.

<p>

<sect1>Andra "make"-prylar
<p>

`<tt>make mrproper</tt>' gör en mer omfattande `<tt>clean</tt>'. Ibland är
det nödvändigt; du kanske vill göra det vid varje patch. `<tt>make
mrproper</tt>' tar också bort din konfigurerings-fil, så du ska antagligen
ta en säkerhetskopia av den (<tt>.config</tt>) om du tycker den är 
värdefull.

<p>

`<tt>make oldconfig</tt>' gör ett försök att konfigurera kärnan från en
gammal konfigurerings-fil; det kör igenom `<tt>make config</tt>'-processen
åt dig. Om du aldrig har kompilerat en kärna förut eller inte har en gammal
config-fil, så ska du antagligen inte göra detta, eftersom du antagligen
kommer ändra standard-konfigureringen.
<p>

Se avsnitten om moduler för en beskrivning av `<tt>make modules</tt>'.

<p>



<sect1>Installera kärnan
<p>

När du har en ny kärna som verkar fungera som du vill att den ska fungera,
så är det dags att installera den. De flesta använder LILO (Linux Loader) 
till detta. `<tt>make zlilo</tt>' installerar kärnan, kör LILO på den och
fixar allt, så att det bara är att starta upp, MEN ENDAST om lilo är 
inställd på följande sätt på ditt system: kärnan är <tt>/vmlinuz</tt>, lilo
finns i <tt>/sbin</tt> och din lilo-konfigurering (<tt>/etc/lilo.conf</tt>) 
inte har något att invända.

<p>

Annars blir du tvungen att använda LILO direkt. Det är ett ganska enkelt
paket att installera och arbeta med, men det har en tendens att förvirra
människor med sin konfigurerings-fil. Titta på konfigurerings-filen
(antingen <tt>/etc/lilo/config</tt>, för äldre versioner, eller
<tt>/etc/lilo.conf</tt>, för nyare versioner), och kolla upp den 
nuvarande konfigureringen. lilo.conf-filen ser ut så här:

<p>

<verb>
    image = /vmlinuz
	label = Linux
	root = /dev/hda1
	...
</verb>

`<tt>image =</tt>' anger den kärna du för tillfället har installerad. De
flesta använder <tt>/vmlinuz</tt>. `<tt>label</tt>' används av lilo för
att bestämma vilken kärna, eller vilket operativ-system, som ska startas,
och `<tt>root</tt>' är <tt>/</tt> för just det operativ-systemet. Gör en
säkerhets-kopia av din gamla kärna och kopiera <tt>zImage</tt>-filen, vilken
du just skapat, dit den ska vara (du skulle köra `<tt>cp zImage /vmlinuz</tt>'
om du använder `<tt>/vmlinuz</tt>'). Kör sedan lilo igen -- på nyare system
så kan du köra `<tt>lilo</tt>', men på äldre grejer kanske du blir tvungen
att köra <tt>/etc/lilo/install</tt>, eller till och med en
<tt>/etc/lilo/lilo -C /etc/lilo/config</tt>.
<p>

Om du skulle vilja veta mer om LILOs konfigurering, eller om du inte har
LILO, skaffa den senaste versionen från din favorit-ftp-sajt och följ
instruktionerna.

<p>

För att starta upp en av dina gamla kärnor från hårddisken (ett annat sätt
att rädda dig om du gör något dumt med den nya kärnan), så kopiera raderna
nedan (och inklusive) `<tt>image = xxx</tt>' i LILOs konfigurerings-fil
till slutet av filen, och modifiera `<tt>image = xxx</tt>' till
`<tt>image = yyy</tt>', där `<tt>yyy</tt>' är den fullständiga sökvängen
till filen du sparade din säkerhetskopia av kärnan som. Ändra sedan
`<tt>label = zzz</tt>' till `<tt>label = linux-backup</tt>' och kör
<tt>lilo</tt> igen. Det kan vara nödvändigt att lägga in en rad som säger
`<tt>delay=x</tt>', där x är antalet tiondelar, vilket säger åt LILO att
vänta så lång tid innan det startar upp, så att du kan avbryta det (med
shift-knappen t.ex.), och skriva in den säkerhets-kopierade kärnans "label"
(om något otrevligt skulle hända).

<p>

<sect>Patcha kärnan
<p>

<sect1>Lägga till en patch
<p>

Gradvisa uppgraderingar till kärnan distribueras som patchar. Om du t.ex. har
version 1.1.45 och du upptäcker att det finns en `<tt>patch46.gz</tt>' till
den, så innebär det att du kan uppgradera till version 1.1.46 genom att
lägga till patchen. Det kan vara bra att ta en säkerhets-kopia av 
källkods-trädet först (`<tt>make clean</tt>' och sedan
`<tt>cd /usr/src; tar zcvf old-tree.tar.gz linux</tt>', vilket kommer att
skapa ett komprimerat tar-arkiv åt dig).
<p>

Om vi fortsätter på exemplet ovan, låt oss förutsätta att du har
`<tt>patch46.gz</tt>' i <tt>/usr/src</tt>. <tt>cd</tt>-a till
<tt>/usr/src</tt> och kör en `<tt>zcat patch46.gz | patch -p0</tt>'
(eller `<tt>patch -p0 &lt patch46</tt>', om patchen inte är packad). Du  
kommer se saker flyga förbi (eller krypa förbi, om ditt system är så
långsamt), vilka talar om för dig att det försöker lägga till bitar,
och huruvida det lyckas eller ej. Vanligtvis går det här för fort för att du
ska hinna med att läsa, och du kan inte vara så säker på om det fungerade
eller ej, men om du använder <tt>-s</tt>-flaggan till <tt>patch</tt> så 
kommer <tt>patch</tt> endast rapportera fel (du får inte lika mycket av den
där "hallå, min dator gör faktiskt saker, för en gångs skull!"-känslan, men
du kanske föredrar det här...). För att leta efter delar som inte har gått
så bra, cd-a till <tt>/usr/src/linux</tt> och leta efter filer med en
<tt>.rej</tt>-ändelse. Vissa versioner av <tt>patch</tt> (äldre versioner,
vilka kan har kompilerats på ett underlägset filsystem) lämnar dessa
misslyckanden med en <tt>&num;</tt>-ändelse. Du kan använda `<tt>find</tt>'
för att leta;
<verb>
    find .  -name '*.rej' -print
</verb>
skriver ut, till standard ut, vilka filer, i den aktuella katalogen eller 
underkataloger, somhar <tt>.rej</tt>-ändelser

<p>

Om något gick fel, gör en `<tt>make clean</tt>', `<tt>config</tt>' och
`<tt>dep</tt>', som det beskrivs i avsnitt 3 och 4.

<p>

Det finns en hel del alternativ till <tt>patch</tt>-kommandot. Som nämnts
ovan så kommer <tt>patch -s</tt> att hålla tyst om allt utom fel. Om du
har ditt kärn-källkods-träd någon annanstans än i <tt>/usr/src/linux</tt>, 
så patchar <tt>patch -p1</tt> allt korrekt (i den katalogen). Andra
<tt>patch</tt>-alternativ finns väl-dokumenterade på man-sidan.

<p>

<sect1>Om något går snett
<p>

(Observera: detta avsnitt hänvisar mestadels till ganska gamla kärnor)
<p>

Det vanligaste problemet som brukade uppstå, var när en patch modifierade
en fil som heter `<tt>config.in</tt>', och den inte såg riktigt rätt ut,
eftersom du ändrade alternativen för att passa din maskin. Det här har man
tagit hand om, men man kan fortfarande stöta på det hos äldre utgåvor.
För att fixa det, ta en titt på <tt>config.in.rej</tt>-filen, och se efter
vad som finns kvar av original-patchen. Förändringarna är vanligtvis
markerade med `<tt>+</tt>' och `<tt>-</tt>' i början av raderna. Ta en titt
på raderna före och efter, och tänk efter om de var satta till `<tt>y</tt>'
eller `<tt>n</tt>'. Editera nu <tt>config.in</tt>, och ändra `<tt>y</tt>'
till `<tt>n</tt>' och `<tt>n</tt>' till `<tt>y</tt>', där det ska vara så.
Gör en
<verb>
    patch -p0 < config.in.rej
</verb>
och om det rapporteras att det lyckades (inga fel), så kan du fortsätta med
konfigurering och kompilering. <tt>config.in.rej</tt> kommer finnas kvar,
men du kan ta bort den.
<p>

Om du stöter på vidare problem, så kan du ha lagt till en patch i fel ordning.
Om patch säger `<tt>previously applied patch detected: Assume -R?</tt>', så
försöker du antagligen lägga till en patch som är under ditt aktuella
versionsnummer; om du svarar `<tt>y</tt>', så kommer patch försöka 
nedgradera din källkod, och kommer antagligen misslyckas; då kommer du alltså
behöva skaffa ett helt nytt källkodsträd (vilket kanske inte skulle ha varit
en så dum idé från början).
<p>

För att backa ut (ta bort) en patch, använd `<tt>patch -R</tt>' på
original-patchen.

<p>

Det bästa du kan göra när patchningar verkligen går snett är att börja om
igen, med ett rent och opatchat källkodsträd (från en av 
<tt>linux-x.y.z.tar.gz</tt>-filerna, t.ex.) och börja om.

<p>

<sect1>Bli av med .orig-filer
<p>

Efter bara några få patchar kommer <tt>.orig</tt>-filerna vara ganska många.
T.ex. så hade ett 1.1.51-källkodsträd jag hade blivit rensat vid 1.1.48.
Att ta bort .orig-filerna sparade mig mer än en halv meg.
<verb>
    find .  -name '*.orig' -exec rm -f {} ';'
</verb>
tar hand om det åt dig. De versioner av <tt>patch</tt> som använder
<tt>&num;</tt> för misslyckaden, använder en tilde istället för <tt>.orig</tt>.
<p>

Det finns bättre sätt att bli av med <tt>.orig</tt>-filerna, vilka är
baserade på GNU <tt>xargs</tt>:
<verb>
    find .  -name '*.orig' | xargs rm
</verb>
eller "ganska säker men en aning mer pratig"-metoden:
<verb>
    find . -name '*.orig' -print0 | xargs --null rm --
</verb>
<p>

<sect1>Andra patchar
<p>
Det finns andra patchar (jag kallar dem "icke-standard") än de som Linus
distribuerar. Om du lägger till dessa så kanske inte Linus patchar fungerar
korrekt, och du blir tvungen att antagligen backa ut, fixa källkoden eller
patchen, installera ett nytt källkodsträd eller en kombination av dessa saker.
Detta kan bli väldigt frustrerande, så om du inte vill modifiera källkoden
(med möjligheten av väldigt dåliga resultat), ta bort icke-standard-patcharna
innan du lägger till Linus, eller installera helt enkelt ett nytt träd. Sen
kan du se efter om icke-standard-patcharna fortfarande fungerar. Om de inte gör
det, så är du antingen fast med en gammal kärna, och blir tvungen att greja
en massa med patcharna eller källkoden, för att få det att fungera, eller
tvingas vänta på (eller möjligtvis be om) en ny version av patchen.
<p>
Hur vanliga är patcharna, som inte ingår i standard-distributionen? Du kommer
antagligen höra talas om dem. Jag brukade använda noblink-patchen för min
virtuella konsoll, eftersom jag hatar blinkande markörer (denna patch blir
(eller blev, åtminstone) uppdaterad för varje ny utgåva av kärnan). Eftersom
de flesta nya enhets-drivrutiner utvecklas som laddningsbara moduler, så
minskar dock antalet icke-standard-patchar en hel del.
<p>

<sect>Ytterligare paket
<p>
Din Linux-kärna har många funktioner som inte förklaras i själva källkoden;
dessa funktioner används i typfallet av externa paket. Några av de vanligaste
räknas upp här.

<sect1>kbd<p>
Linux-konsollen har fler funktioner än den förtjänar. Bland dessa finns
möjligheten att byta typsnitt, definiera om tangentbordet, byta
grafik-lägen (i nyare kärnor) osv. kbd-paketet har program som låter
användaren göra allt detta, plus många typsnitt och tangentbords-tabeller
för i stort sett alla tangentbord, och är tillgängligt från samma sajter som
har kärn-källkoden.
<p>

<sect1>util-linux<p>
Rik Faith (<tt>faith@cs.unc.edu</tt>) plockade ihop en stor samling
Linux-verktyg vilka, av ett underligt sammanträffande, kallas util-linux.
Dessa utvecklas nu av Nicolai Langfeldt (<tt>util-linux@math.uio.no</tt>).
Det är tillgängligt via anonym ftp från sunsite.unc.edu, i
<tt>/pub/Linux/system/misc</tt>, och innehåller program såsom <tt>setterm</tt>,
<tt>rdev</tt> och <tt>ctrlaltdel</tt>, vilka är relevanta för kärnan. Som
Rik säger, <it>installera inte utan att tänka efter</it>; du behöver inte
installera allt i paketet, och det kan mycket väl skapa stora problem, om
du gör det.


<sect1>hdparm<p>
Som med många andra paket, så var detta en gång i tiden en kärn-patch och
stöd-program. Patcharna blev inplockade i den officiella kärnan, och 
programmen för att optimera och leka med hårddisken distribueras separat.

<p>

<sect1>gpm<p>

gpm står för general purpose mouse. Detta program tillåter dig att klippa
och klistra text mellan virtuella konsoller och göra andra saker, med en
stor uppsättning olika mus-typer.
<p>

<sect>Några fallgropar
<p>

<sect1>make clean <p>

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 <tt>make clean</tt>, 
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 <tt>make dep</tt> också.
<p>

<sect1>Enorma eller långsamma kärnor
<p>
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.
<p>

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 
<tt>/proc/meminfo</tt>, eller utdatan från kommandot `<tt>free</tt>'. Du kan
också ta reda på det genom att köra `<tt>dmesg</tt>' (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:
<p>
<tt>
Memory: 15124k/16384k available (552k kernel code, 384k reserved, 324k data)
</tt>
<p>

Min 386 (vilken har en aning mindre skräp in-konfigurerat) säger:
<p>
<tt>
Memory: 7000k/8192k available (496k kernel code, 384k reserved, 312k data)
</tt>
<p>

Om du bara `måste' ha en stor kärna, men systemet inte låter dig ha det, så
kan du testa `<tt>make bzimage</tt>'. Du kan mycket väl bli tvungen att
installera en ny version av LILO för att få detta att fungera.
<p>

<sect1>Kärnan kompilerar inte
<p>
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 <tt>README</tt>-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.
<p>
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 <tt>det-och-det undefined</tt>-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 <tt>arch/i386/Makefile</tt>:
<verb>
AS=/usr/i486-linuxaout/bin/as
LD=/usr/i486-linuxaout/bin/ld -m i386linux
CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
</verb>
Kör sedan <tt>make dep</tt> och <tt>zImage</tt> igen.
<p>

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.
<p>

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å
<tt>http://www.bitwizard.nl/sig11/</tt>.
<p>

<sect1>Den nya versionen av kärnan verkar inte starta (boot)
<p>
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 `<tt>boot =
/dev/hda1</tt>', istället för `<tt>boot = /dev/hda</tt>'. (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.)
<p>

<sect1> Du glömde köra LILO, eller systemet startar inte alls
<p>
Hoppsan! Det bästa du kan göra här är att starta upp med en diskett och
preparera en till start-diskett (som `<tt>make zdisk</tt>' skulle göra).
Du måste veta var ditt rot-filsystem (<tt>/</tt>) finns, och vilken sort
det är (t.ex. second extended, minix). I exemplet nedan måste du också veta
vilket filsystem ditt <tt>/usr/src/linux</tt>-källkodsträd finns på, dess
typ och var det vanligtvis monteras.
<p>

I det följande exemplet är <tt>/</tt> <tt>/dev/hda1</tt>, och filsystemet
som innehåller <tt>/usr/src/linux</tt> är <tt>/dev/hda3</tt>, och monteras
vanligtvis på <tt>/usr</tt>. Båda filsystemen är second extended. Den 
fungerande kärnan i <tt>/usr/src/linux/arch/i386/boot</tt> heter
<tt>zImage</tt>. 
<p>

Idén är, att om det finns en fungerande <tt>zImage</tt>, 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.
<p>

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:
<p>

<verb>
    mkdir /mnt
    mount -t ext2 /dev/hda3 /mnt
</verb>

Om <tt>mkdir</tt> säger åt dig att katalogen redan existerar, ignorera det
bara. <tt>cd</tt>-a nu till stället där den fungerande kärnan finns. 
Observera att
<verb>
/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/boot
</verb>
Sä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:
<p>
<verb>
    cd /mnt/src/linux/arch/i386/boot
    dd if=zImage of=/dev/fd0
    rdev /dev/fd0 /dev/hda1
</verb>

<tt>cd</tt>-a till <tt>/</tt> och avmontera det vanliga 
<tt>/usr</tt>-filsystemet: 
<p>
<verb>
    cd /
    umount /mnt
</verb>

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!
<p>

Som nämndes ovan, så finns det ett annat vanligt alternativ. Om du 
råkade ha en fungerande kärna i <tt>/</tt> (<tt>/vmlinuz</tt> 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 <tt>/vmlinuz</tt>, gör bara
följande ändringar i exemplet ovan: ändra
<tt>/dev/hda3</tt> till <tt>/dev/hda1</tt> (<tt>/</tt>-filsystemet),
<tt>/mnt/src/linux</tt> till
<tt>/mnt</tt>, och <tt>if=zImage</tt> till <tt>if=vmlinuz</tt>. Anmärkningen
som förklarar hur du tar reda på <tt>/mnt/src/linux</tt> kan du hoppa över.
<p>
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.
<p>

<sect1>Jag får `warning: bdflush not running' <p>

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
`<tt>update</tt>', vilket regelbundet spolar ur (flushes) filsystemets
buffrar. Skaffa källkoden till `<tt>bdflush</tt>' (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 `<tt>update</tt>', och efter att du startat om ska den nya kärnan inte
längre klaga.
<p>

<sect1>Den säger saker om "undefined symbols" och kompilerar inte<p>

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 <tt>arch/i386/Makefile</tt>: <p>
<verb>
AS=/usr/i486-linuxaout/bin/as
LD=/usr/i486-linuxaout/bin/ld -m i386linux
CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
</verb>
<p>
Detta kommer kompilera en 1.2.x-kärna med a.out-bibliotek.
<p>

<sect1>Jag får inte min IDE/ATAPI CD-ROM-spelare att fungera
<p>
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.
<p>
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.
<p>
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).

<p>
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.
<p>

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.
<p>
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.
<p>
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 <tt>drivers/block/README.ide</tt>. 
Det finns mycket mer information där.
<p>

<sect1>Den säger konstiga saker om "obsolete routing requests"
<p>
Skaffa nya versioner av <tt>route</tt>-programmet och alla andra program som
sysslar med route-manipulering. <tt>/usr/include/linux/route.h</tt> (vilken
faktiskt är en fil i <tt>/usr/src/linux</tt>) har ändrats.
<p>

<sect1>Brandvägg fungerar inte i 1.2.0
<p>

Uppgradera till åtminstone version 1.2.1.
<p>

<sect1>``Not a compressed kernel Image file''<p>
Använd inte <tt>vmlinux</tt>-filen, vilken skapas i <tt>/usr/src/linux</tt>
som kärna; <tt>[..]/arch/i386/boot/zImage</tt> är den rätta.
<p>

<sect1>Problem med konsoll-terminalen efter uppgradering till 1.3.x
<p>
Ändra ordet <tt>dumb</tt> till <tt>linux</tt> i konsollens termcap-rad i
<tt>/etc/termcap</tt>. Du kan också bli tvungen att skapa en 
terminfo-avdelning.
<p>

<sect1> Verkar inte som om jag kan kompilera saker efter kärn-uppgradering
<p>
Källkoden till Linux-kärnan innehåller ett antal include-filer (sakerna som
slutar med <tt>.h</tt>), vilka hänvisas till av standard-versionerna i
<tt>/usr/include</tt>. De hänvisas vanligtvis till på detta sätt (där
<tt>xyzzy.h</tt> skulle vara något i <tt>/usr/include/linux</tt>):
<verb>
    #include <linux/xyzzy.h>
</verb>
Vanligtvis finns det en länk, som heter <tt>linux</tt> i 
<tt>/usr/include</tt> till <tt>include/linux</tt>-katalogen i din kärn-källkod
(<tt>/usr/src/linux/include/linux</tt> 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 
<tt>root</tt> 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 
<tt>p</tt>-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
<tt>chmod</tt>-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:
<p>
<verb>
    blah# tar zxvpf linux.x.y.z.tar.gz linux/include
</verb>
Observera: "<tt>make config</tt>" kommer återskapa 
<tt>/usr/src/linux</tt>-länken, om den inte finns där.
<p>

<sect1>Utöka gränser
<p>
De följande få <it>exempel</it>-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:
<verb>
echo 4096 > /proc/sys/kernel/file-max
echo 12288 > /proc/sys/kernel/inode-max
echo 300 400 500 > /proc/sys/vm/freepages
</verb>
<p>

<sect>Anmärkning om att uppgradera till version 2.0.x
<p>
Version 2.0.x av kärnan introducerade en hel del förändringar, vad gäller
installering av kärnan. Filen <tt>Documentation/Changes</tt> i källkodsträdet
till 2.0.x innehåller information om saker du bör veta, när du uppgraderar
till version 2.0.x. Du kommer antagligen behöva uppgradera flera viktiga
paket, såsom gcc, libc och SysVInit, och kanske modifiera vissa system-filer,
så räkna med detta. Ta det bara lugnt.
<p>

<sect>Moduler<p>
Laddningsbara kärn-moduler kan spara minne och göra konfigureringen enklare.
Modulernas omfattning har växt till att inkludera filsystem, drivrutiner till
ethernet-kort, bandspelare, drivrutiner till skrivare m.m.
<p>

<sect1>Installera modul-verktygen
<p>
Modul-verktygen är tillgängliga från samma ställe som du hittar källkoden till
kärnan, som <tt>modules-x.y.z.tar.gz</tt>; välj den högsta patch-nivån
<tt>x.y.z</tt>, som är lika med eller under den till din aktuella kärna.
Packa upp det med `<tt>tar zxvf modules-x.y.z.tar.gz</tt>', <tt>cd</tt>-a
till katalogen det skapar (<tt>modules-x.y.z</tt>), ta en titt på
<tt>README</tt>-filen och utför det du instrueras att göra (vilket vanligtvis
är något enkelt, som <tt>make install</tt>). Du ska nu ha programmen
<tt>insmod</tt>, <tt>rmmod</tt>, <tt>ksyms</tt>, <tt>lsmod</tt>, 
<tt>genksyms</tt>, <tt>modprobe</tt> och <tt>depmod</tt> i
<tt>/sbin</tt>. Om du vill så kan du testa verktygen med 
"hw"-exempel-drivrutinen i <tt>insmod</tt>; titta till <tt>INSTALL</tt>-filen
i den underkatalogen, för detaljer.
<p>
<tt>insmod</tt> infogar en modul i en kärna som körs. Moduler har
vanligtvis en <tt>.o</tt>-ändelse; exempel-drivrutinen, som nämns ovan, 
heter <tt>drv_hello.o</tt>, så för att infoga denna skriver du
`<tt>insmod drv_hello.o</tt>'. För att ta reda på vilka moduler kärnan
använder för tillfället, använd <tt>lsmod</tt>. Utdatan ser ut så här:
<verb>
    blah# lsmod
    Module:        #pages:  Used by:
    drv_hello          1
</verb>
`<tt>drv_hello</tt>' är namnet på modulen, det använder en minnes-sida (page) 
(4k), och inga andra kärn-moduler är beroende av den för tillfället. För att
ta bort den här modulen, använd `<tt>rmmod drv_hello</tt>'. Observera att
<tt>rmmod</tt> vill ha ett <it>modul-namn</it>, inte ett filnamn; du får reda
på detta från <tt>lsmod</tt>s uppräkning. De andra modul-verktygen
dokumenteras i sina man-sidor.
<p>

<sect1>Moduler som distribueras med kärnan
<p>
I version 2.0.30 är nästan allt tillgängligt som laddningsbara moduler. För
att använda dem måste du först se till att inte konfigurera in dem i den
vanliga kärnan; säga alltså inte <tt>y</tt> till dem under
`<tt>make config</tt>'. Kompilera en ny kärna och starta om med den. 
<tt>cd</tt>-a sedan till <tt>/usr/src/linux</tt> igen och kör en
`<tt>make modules</tt>'. Detta kompilerar alla de moduler som du inte
specificerade i kärn-konfigureringen, och placerar länkar till i
<tt>/usr/src/linux/modules</tt>. Du kan använda dem direkt från den katalogen,
eller köra `<tt>make modules_install</tt>', vilket installerar dem i
<tt>/lib/modules/x.y.z</tt>, där <tt>x.y.z</tt> är versionen av kärnan.
<p>

Detta kan vara särskilt praktiskt med filsystem. Du kanske inte använder
minix- eller msdos-filsystemen så ofta. Om jag t.ex. stötte på en msdos-diskett
(usch då), så skulle jag <tt>insmod /usr/src/linux/modules/msdos.o</tt>, och
sedan <tt>rmmod msdos</tt> när jag var klar. Denna procedur spara runt
50k RAM i kärnan, under normal användning. En liten anmärkning är på sin
plats angående minix-filsystemet: du ska <it>alltid</it> konfigurera in det
direkt i kärnan, för användning på "räddnings"-disketter. 
<p>

<sect>Andra konfigurerings-alternativ
<p>
Detta avsnitt innehåller beskrivningar av utvalda konfigurerings-alternativ
(i <tt>make config</tt>), vilka inte tas upp i konfigurerings-avsnittet.
De flesta enhets-drivrutiner tas inte upp här.
<p>

<sect1>Vanliga inställningar (General setup) <p>

<tt>Normal floppy disk support</tt> - är precis det (stöd för vanliga
floppy-diskar). Du kan ta en titt på filen <tt>drivers/block/README.fd</tt>;
detta är extra viktigt för IBM Thinkpad-användare.
<p>

<tt>XT harddisk support</tt> - om du vill använda den där 8-bitars 
XT-controllern, som ligger i hörnet och samlar damm.
<p>

<tt>PCI bios support</tt> - om du har PCI, så kan du pröva på det här; ta
det försiktigt, bara, eftersom vissa gamla PCI-moderkort kommer krascha av 
det här. Mer information om PCI-bussen under Linux finns i PCI-HOWTOn.
<p>

<tt>Kernel support for ELF binaries</tt> - ELF är ett försök att låta
binär-filer fungera på olika arkitekturer och operativ-system; Linux verkar
vara på väg i den riktningen, så du vill antagligen ha detta.
<p>

<tt>Set version information on all symbols for modules</tt> - förut 
kompilerades alltid kärn-modulerna om med varje ny kärna. Om du säger
<tt>y</tt> så kommer det bli möjligt att använda moduler som kompilerats 
under en annan patch-nivå. Läs <tt>README.modules</tt> för mer detaljer.
<p>

<sect1>Networking options<p>
Networking options (nätverks-alternativ) beskriv i NET-3-HOWTOn (eller
NET-någonting-HOWTOn).

<sect>Tips och knep <p>

<sect1>Omdirigera utdatan från make- eller patch-kommandona
<p>
Om du skulle vilja ha log-filer, om vad de där `<tt>make</tt>'- eller
`<tt>patch</tt>'-kommandona gjorde, så kan du omdirigera utdatan till en fil.
Ta först reda på vilket skal du kör: `<tt>grep root /etc/passwd</tt>' och 
leta efter någonting i stil med `<tt>/bin/csh</tt>'. 
<p>

Om du använder sh eller bash, kör
<verb>
    (kommando) 2>&1 | tee (output file)
</verb>
vilket placerar en kopia av <tt>(kommando)</tt>s utdata i filen
`<tt>(output file)</tt>'.
<p>

För csh eller tcsh, använd
<verb>
    (command) |& tee (output file)
</verb>
<p>

För rc (Observera: du använder antagligen inte rc) är det
<verb>
    (command) >[2=1] | tee (output file)
</verb>
<p>

<sect1>Villkorlig kärn-installering
<p>
Förutom att använda disketter, så finns det ett flertal metoder för att pröva
en ny kärna, utan att röra den gamla. I motsats till flera andra Unix-varianter
så kan LILO starta en kärna från var som helst på hårddisken (om du har en 
stor (500 MB eller mer) hårddisk, läs igenom LILO-dokumentationen, om hur detta
kan leda till problem). Alltså, om du lägger till något i stil med
<verb>
    image = /usr/src/linux/arch/i386/boot/zImage
        label = new_kernel
</verb>
till slutet av LILOs konfigurerings-fil, så kan du välja att köra en nyligen
kompilerad kärna, utan att röra din gamla <tt>/vmlinuz</tt> (efter att du
kört <tt>lilo</tt> naturligtvis). Det enklaste sättet att säga åt LILO att
starta en ny kärna att trycka ner shift-tangenten då systemet startas (när
det står <tt>LILO</tt>, och inget annat, på skärmen), vilket ger dig en
prompt. Nu kan du skriva `<tt>new_kernel</tt>' för att starta den nya
kärnan.

<p>
Om du vill ha flera olika kärn-källkodsträd på ditt system, på samma gång
(detta kan ta upp en <it>massa</it> hårddisk-utrymme; var försiktig), så är
det vanligaste sättet att kalla dem <tt>/usr/src/linux-x.y.z</tt>, där
<tt>x.y.z</tt> är kärn-versionen. Du kan sedan "välja" ett källkodsträd med
en symbolisk länk; t.ex. så skulle `<tt>ln -sf linux-1.2.2
/usr/src/linux</tt>' göra 1.2.2 till det aktuella trädet. Innan du skapar en
sådan symbolisk länk, se till så att det sista parametern till <tt>ln</tt>
inte är en riktig katalog (gamla symboliska länkar går bra); resultatet
kanske inte blir vad du väntat dig.
<p>

<sect1>Uppdateringar av kärnan
<p>

Russell Nelson (<tt>nelson@crynwr.com</tt>) sammanfattar förändringarna i nya
utgåvor av kärnan. Dessa är korta och du kan ta en titt på dem innan du utför
en uppgradering. De är tillgängliga via anonym ftp från
<tt>ftp.emlist.com</tt> i <tt>pub/kchanges</tt>, eller genom URLen
<verb>
    http://www.crynwr.com/kchanges
</verb>
<p>

<sect> Andra relevanta HOWTOn, som kan vara användbara<p>
<itemize>
<item> Sound-HOWTO: ljud-kort och -verktyg
<item> SCSI-HOWTO: allt om SCSI-controllers och -verktyg
<item> NET-2-HOWTO: nätverk
<item> PPP-HOWTO: PPP-nätverk
<item> PCMCIA-HOWTO: om drivrutinerna till din bärbara dator
<item> ELF-HOWTO: ELF: vad det är, konvertering...
<item> Hardware-HOWTO: översikt av stödd hårdvara
<item> Module-HOWTO: mer om kärn-moduler
<item> Kerneld mini-HOWTO: om kerneld
<item> BogoMips mini-HOWTO: ifall du undrade
</itemize>

<sect>Diverse<p>

<sect1>Författare <p>

Författaren och utvecklaren av Linux Kernel-HOWTO är Brian Ward
(<tt>bri@blah.math.tu-graz.ac.at</tt>). Var vänlig skicka mig kommentarer,
tillägg, rättelser (rättelser är speciellt viktiga för mig).
<p>

Du kan ta en titt på min `hemsida' på en av dessa URLer:
<verb>
    http://www.math.psu.edu/ward/
    http://blah.math.tu-graz.ac.at/~bri/
</verb>
<p>

Även om jag försöker ta så mycket hänsyn som möjligt till e-post, var vänlig
kom ihåg att jag får en <it>massa</it> e-post varje dag, så det kan ta ett
tag att svara. Speciellt om du skickar mig en fråga, försök extra mycket att
vara klar och detaljerad i ditt meddelande. Ifall du inte skriver om 
icke fungerande hårdvara (eller något åt det hållet), så behöver jag veta 
hur din hårdvaru-konfigurering ser ut. Om du rapporterar ett fel, säg inte
bara "Jag försökte det här men fick ett fel". Jag behöver veta vad det var för
fel. Jag skulle också vilja veta vilka versioner av kärnan, gcc och libc du
använder. Om du bara säger att du använder den-eller-den distributionen,
så säger det mig inte så mycket. Jag bryr mig inte om att du frågar enkla
frågor; kom ihåg att, om du inte frågar, så får du aldrig reda på svaret!
Jag vill tacka alla som har gett mig respons.
<p>

Om du har skickat mig ett e-brev och inte fått något svar inom rimlig tid
(tre veckor eller så), så finns det en möjlighet att jag av misstag har 
raderat ditt meddelande eller något (ursäkta mig). Försök igen.
<p>

Jag får en massa e-brev om saker som faktiskt är hårdvaruproblem. Det är
okej, men försök komma ihåg att jag inte känner till all hårdvara i hela
världen och att jag inte vet hur hjälpsam jag kan vara; personligen använder
jag en maskin med IDE- och SCSI-hårddiskar, SCSI CD-ROM, 3Com och WD
ethernet-kort, seriella möss, moderkort med PCI, NCR 810 SCSI-controllers,
AMD 386DX40 med Cyric hjälp-processor, AMD5x86, AMD 486DX4 och Intel
486DX4-processorer (detta är en överblick över vad jag använder och känner
till, definitivt inte en rekommendation, men om det är vad du vill ha så
är du mer än välkommen att fråga <tt>:-)</tt>).
<p>
Version -0.1 skrevs 3 oktober 1994. Detta dokument är tillgängligt som
SGML, PostScript, TeX, roff och ren text.

<p>

<sect1>Att göra<p>
"Tips och knep"-avsnittet är lite litet. Jag hoppas kunna utöka det med
förslag från andra.<p>
Samma med "Ytterligare paket".<p>
Mer information om hur man klarar av avlusning/krash-återhämtning behövs.<p>

<sect1>Bidrag <p>
En liten del av Linux README (kärn-hackning-alternativet) är inkluderad.
(Tack Linus!)
<p>
<tt>uc@brian.lunetix.de</tt> (Ulrich Callmeier): patch -s and xargs.<p>
<tt>quinlan@yggdrasil.com</tt> (Daniel Quinlan): rättelser och tillägg i
många avsnitt.<p>
<tt>nat@nat@nataa.fr.eu.org</tt> (Nat Makarevitch): mrproper, tar -p, många fler saker <p>
<tt>boldt@math.ucsb.edu</tt> (Axel Boldt): samlade beskrivningar av
konfigurerings-alternativ på nätet; gav mig sedan listan<p>
<tt>lembark@wrkhors.psyber.com</tt> (Steve Lembark): flera uppstarts-förslag
(boot suggestions)
<tt>kbriggs@earwax.pd.uwa.edu.au</tt> (Keith Briggs): några rättelser och 
förslag<p>
<tt>rmcguire@freenet.columbus.oh.us</tt> (Ryan McGuire): make-tillägg<p>
<tt>dumas@excalibur.ibp.fr</tt> (Eric Dumas): fransk översättning<p>
<tt>simazaki@ab11.yamanashi.ac.jp</tt> (Yasutada Shimazaki): japansk
översättning<p>
<tt>jjamor@lml.ls.fi.upm.es</tt> (Juan Jose Amor Iglesias): spansk
översättning<p>
<tt>mva@sbbs.se</tt> (Martin Wahlen): svensk översättning<p>
<tt>jzp1218@stud.u-szeged.hu</tt> (Zoltan Vamosi): ungersk översättning<p>
<tt>bart@mat.uni.torun.pl</tt> (Bartosz Maruszewski): polsk översättning<p>
<tt>donahue@tiber.nist.gov</tt> (Michael J Donahue): skrivfel, vinnare i
"skivat bröd-tävlingen"<p>
<tt>rms@gnu.ai.mit.edu</tt> (Richard Stallman):
dokumentation om "fri" dokumentation och kommentarer om detta <p>
<tt>dak@Pool.Informatik.RWTH-Aachen.DE</tt> (David Kastrup): NFS-saker<p>
<tt>esr@snark.thyrsus.com</tt> (Eric Raymond): diverse småsaker<p>

De som har skickat mig e-brev med frågor och problem har också varit ganska
hjälpsamma.
<p>

<sect1>Upphovsrätt, licens och sådana grejer<p>
Copyright &copy Brian Ward, 1994-1997.<p>
Tillåtelse ges att göra och distribuera kopior av den här manualen,
förusatt att upphovsrätten och denna tillåtelse bevaras i alla kopior.
<p>

Tillåtelse ges att kopiera och distribuera modifierade versioner av den
här manualen, under villkoren för ordagrann kopiering, förutsatt att det
härledda verket distribueras under villkor som är identiska med dessa. 
Översättningar faller under kategorin "modifierade versioner".
<p>

Garanti: ingen.<p>

Rekommendationer:
Kommersiell vidaredistribuering är tillåten och uppmuntras; det rekommenderas
dock starkt att distributören tar kontakt med författaren innan
vidaredistribueringen, för att kunna hålla saker och ting aktuella (du kan
gärna skicka mig ett exemplar av saker du tillverkar när du ändå håller på).
Översättare rekommenderas också att ta kontakt med författaren innan de
översätter. Den tryckta versionen ser snyggare ut. Återanvänd.<p>

</article>
