The Linux Kernel HOWTO Brian Ward, bri@blah.math.tu-graz.ac.at, svensk översättning: Linus Åkerlund, uxm165t@tninet.se v0.80, 26 May 1997, svensk översättning 21 juni 1998 Detta är en detaljerad guide till kärn-konfigurering, kompilering, uppgraderingar och problem-lösning för ix86-baserade system. ______________________________________________________________________ Innehållsförteckning 1. Inledning 1.1 Läs det här först! (Jag menar det) 1.2 Några ord om stilen 1.3 Översättarens anmärkningar 2. Viktiga frågor och svar på dessa 2.1 Vad är det kärnan gör, förresten? 2.2 Varför skulle jag vilja uppgradera min kärna? 2.3 Vilken slags hårdvara stödjer de nyare kärnorna? 2.4 Vilka versioner av gcc och libc behöver jag? 2.5 Vad är en laddningsbar modul? 2.6 Hur mycket hårddisk-utrymme behöver jag? 2.7 Hur lång tid tar det? 3. Hur den faktiska konfigureringen av kärnan går till 3.1 Skaffa källkoden 3.2 Packa upp källkoden 3.3 Konfigurera kärnan 3.3.1 Matte-emulering i kärnan (Math emulation in kernel) 3.3.2 Normal (MFM/RLL) disk och IDE disk/cdrom-stöd 3.3.3 Nätverks-stöd (Networking support) 3.3.4 Begränsa minnet till 16 MB (Limit memory to low 16 MB) 3.3.5 System V IPC 3.3.6 Processor-typ (386, 486, Pentium, PPro) 3.3.7 SCSI-stöd (SCSI support) 3.3.8 Stöd för nätverks-enhets (Network device support) 3.3.9 Filsystem 3.3.9.1 Men jag vet inte vilka filsystem jag behöver! 3.3.10 Tecken-enheter (Character devices) 3.3.11 Ljud-kort 3.3.12 Andra konfigurerings-alternativ 3.3.13 "Kärn-hackande" (Kernel hacking) 3.4 Och nu då? (Makefile) 4. Kompilera kärnan 4.1 Städa upp och ange beroenden (Cleaning and depending) 4.2 Kompilerings-dags 4.3 Andra "make"-prylar 4.4 Installera kärnan 5. Patcha kärnan 5.1 Lägga till en patch 5.2 Om något går snett 5.3 Bli av med .orig-filer 5.4 Andra patchar 6. Ytterligare paket 6.1 kbd 6.2 util-linux 6.3 hdparm 6.4 gpm 7. Några fallgropar 7.1 make clean 7.2 Enorma eller långsamma kärnor 7.3 Kärnan kompilerar inte 7.4 Den nya versionen av kärnan verkar inte starta (boot) 7.5 Du glömde köra LILO, eller systemet startar inte alls 7.6 Jag får `warning: bdflush not running' 7.7 Den säger saker om "undefined symbols" och kompilerar inte 7.8 Jag får inte min IDE/ATAPI CD-ROM-spelare att fungera 7.9 Den säger konstiga saker om "obsolete routing requests" 7.10 Brandvägg fungerar inte i 1.2.0 7.11 ``Not a compressed kernel Image file'' 7.12 Problem med konsoll-terminalen efter uppgradering till 1.3.x 7.13 Verkar inte som om jag kan kompilera saker efter kärn-uppgradering 7.14 Utöka gränser 8. Anmärkning om att uppgradera till version 2.0.x 9. Moduler 9.1 Installera modul-verktygen 9.2 Moduler som distribueras med kärnan 10. Andra konfigurerings-alternativ 10.1 Vanliga inställningar (General setup) 10.2 Networking options 11. Tips och knep 11.1 Omdirigera utdatan från make- eller patch-kommandona 11.2 Villkorlig kärn-installering 11.3 Uppdateringar av kärnan 12. Andra relevanta HOWTOn, som kan vara användbara 13. Diverse 13.1 Författare 13.2 Att göra 13.3 Bidrag 13.4 Upphovsrätt, licens och sådana grejer ______________________________________________________________________ 1. Inledning Borde du läsa det här dokumentet? Tja, se efter om du har något av följande problem: · "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!" · Det finns en enhets-drivrutin i en av de nyare kärnorna som du bara måste ha · Du har verkligen inte en aning om hur man kompilerar en kärna · "Är de här grejerna i READMEn verkligen allt?" · Du kom, du försökte, det fungerade inte · Du behöver något att ge till folk som insisterar på att be dig att installera deras kärnor åt dem 1.1. Läs det här först! (Jag menar det) Några av exemplen i det här dokumentet förutsätter att du har GNU tar, find och xargs. 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 mount-kommandots utdata, under normala förhållanden (eller en listning av /etc/fstab, 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. 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. 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. 1.2. Några ord om stilen Text som ser ut så här ä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 "make config", så skriver jag `make config', inte `make config.' 1.3. Översättarens anmärkningar Uppdaterade dokumentet 13/11-98, genom att byta ut översättningen av "permissions" till "rättigheter", istället för det sämre "tillåtelser" 2. Viktiga frågor och svar på dessa 2.1. Vad är det kärnan gör, förresten? 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. Kärnan gör visserligen mer än så, men dessa grundläggande funktioner är de viktigaste att känna till. 2.2. Varför skulle jag vilja uppgradera min kärna? 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. 2.3. Vilken slags hårdvara stödjer de nyare kärnorna? Se Hardware-HOWTOn. Eller så kan du ta en titt på `config.in'-filen i Linux-källkoden, eller helt enkelt få reda på det när du kör `make config'. 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. 2.4. Vilka versioner av gcc och libc behöver jag? Linus rekommenderar en viss version av gcc i README-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. 2.5. Vad är en laddningsbar modul? 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. 2.6. Hur mycket hårddisk-utrymme behöver jag? 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). 2.7. Hur lång tid tar det? 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. 3. Hur den faktiska konfigureringen av kärnan går till 3.1. Skaffa källkoden Du kan skaffa källkoden via anonym ftp från ftp.funet.fi, i /pub/Linux/PEOPLE/Linus, en spegel eller någon annan sajt. Den heter i typfallet linux-x.y.z.tar.gz, där x.y.z är versionsnumret. Nyare (bättre?) versioner och patcharna finns vanligtvis i underkataloger som `v1.1'och `v1.2'. 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. Det rekommenderas starkt 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: 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 Rent generellt så är en spegel-sajt till sunsite.unc.edu ett bra ställe att leta på. Filen /pub/Linux/MIRRORS 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. Om du är ute efter generell information om Linux och distributioner, ta en titt på http://www.linux.org. 3.2. Packa upp källkoden Logga in som, eller su-a till, `root', och cd-a till /usr/src. 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 `linux', 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 `uname -r' skriver ut den aktuella kärnans version. Alltså, om `uname -r' säger `1.0.9', så bör du ändra namnet (med `mv') på `linux' till `linux-1.0.9'. 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 `linux'-katalog i /usr/src innan du packar upp det fullständiga källkods-trädet. Packa nu upp källkoden i /usr/src med `tar zxpvf linux-x.y.z.tar.gz' (om du har en .tar-fil, utan .gz på slutet, så fungerar `tar xpvf linux-x.y.z.tar'). Innehållet i källkoden kommer flyga förbi. När uppackningen är klar, kommer det finnas en ny `linux'-katalog i /usr/src. cd-a till linux och läs igenom README-filen. Där finns en avdelning som heter `INSTALLING the kernel'. Utför instruktionerna när det är passande -- symboliska länkar som ska finnas på plats, borttagande av onödiga .o-filer osv. 3.3. Konfigurera kärnan Observera: En del av detta är upprepningar/klargöranden av en liknande avdelning i Linus README-fil. Kommandot `make config', när du är i /usr/src/linux startar ett konfigurerings-skal-program, vilket ställer en massa frågor. Det kräver bash, så se till att bash är /bin/bash, /bin/sh eller $BASH. Det finns några alternativ till `make config', 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 `make xconfig', om de har Tk installerat (`click-o-rama' - Nat). `make menuconfig' ä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. Du ska vara redo att svara på frågorna, vanligtvis med `y' (ja) eller `n' (nej). Enhets-drivrutiner har vanligtvis även ett `m'-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. 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. 3.3.1. Matte-emulering i kärnan (Math emulation in kernel) Om du inte har en matte-hjälp-processor (om du har en "bar" 386 eller 486SX), så måste du säga `y' till detta. Om du har en hjälp-processor och ändå säger `y', 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. 3.3.2. Normal (MFM/RLL) disk och IDE disk/cdrom-stöd 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. 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. 3.3.3. Nätverks-stöd (Networking support) In princip, säg `y' 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 `y'. Senare kommer du bli tillfrågad om du vill stödja TCP/IP-nätverk; säg återigen `y' här om du inte är absolut säker. 3.3.4. Begränsa minnet till 16 MB (Limit memory to low 16 MB) Det finns buggiga "386 DMA controllers", vilka har problem med att komma åt mer än 16 MB RAM; säg `y' om det skulle råka vara så att du har en. 3.3.5. System V IPC 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 n, om du inte vet exakt vad du sysslar med. 3.3.6. Processor-typ (386, 486, Pentium, PPro) (i äldre kärnor: använd -m486-flaggan för 486-specifika optimeringar) 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. 3.3.7. SCSI-stöd (SCSI support) Om du har SCSI-enheter, säg `y'. 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. 3.3.8. Stöd för nätverks-enhets (Network device support) 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 `y'. Config-programmet kommer fråga efter vilket slags kort du har, och vilket protokoll du använder. 3.3.9. Filsystem Config-programmet frågar sedan om du vill ha stöd för de följande filsystemen: 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. 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. Second extended - Det här används mycket i nyare distributioner. Du har antagligen ett sådant, och ska säga `y'. 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. msdos - Om du vill använda din MS-DOS-hårddisks partitioner, eller montera MS-DOS-formatterade disketter, säg `y'. 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". /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 `ps') använder det. Testa `cat /proc/meminfo' eller cat /proc/devices' ibland. Vissa skal (speciellt rc) använder /proc/self/id (känt som /dev/fd på andra system) för in/ut-hantering. Du ska antagligen säga `y' till det här; många viktiga Linux-verktyg är beroende av det. 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 `y'. ISO9660 - Finns på de flesta CD-ROMar. Om du har en CD-ROM-spelare och vill kunna använda den under Linux, säg `y'. OS/2 HPFS - När detta skrivs, ett filsystem som endast tillåter läsning, för OS/2 HPFS. System V och Coherent - för partitioner i System V- och Coherent- system (det finns andra Unix-varianter för PC). 3.3.9.1. Men jag vet inte vilka filsystem jag behöver! Okej, skriv `mount'. Utdatan kommer se ut något i denna stil: 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) Titta på varje rad; ordet brevid `type' är filsystems-typen. I det här exemplet, mina /- och /usr-filsystem är "second extended", jag använder /proc och det finns en diskett monterad, vilken använder msdos-filsystemet (blä). Du kan testa `cat /proc/filesystem', om du har /proc på för tillfället; det kommer lista din nuvarande kärnas filsystem. 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. 3.3.10. Tecken-enheter (Character devices) 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 `y' där det passar. 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. 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... 3.3.11. Ljud-kort Om du känner att du har ett behov av att höra biff skälla, säg `y', 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 `n', 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. 3.3.12. Andra konfigurerings-alternativ 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 Configure-skal-programmet), sammansatt av Axel Boldt (axel@uni-paderborn.de), med den följande URLen: http://math-www.uni-paderborn.de/~axel/config_help.html eller via anonym FTP från: ftp://sunsite.unc.edu/pub/Linux/kernel/config/krnl_cnfg_hlp.x.yz.tgz Där x.yz är versionsnumret. För senare (2.0.x och senare) kärnor har detta blivit integrerat i källkods-trädet. 3.3.13. "Kärn-hackande" (Kernel hacking) >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. 3.4. Och nu då? (Makefile) Efter att du har kört make config, kommer ett meddelande som talar om att din kärna har blivit konfigurerad, och att du ska "check the top- level Makefile for additional configuration" etc. Ta alltså en titt på Makefile. Du kommer antagligen inte behöva ändra i den, men det skadar inte att ta en titt. Du kan också ändra dess val med `rdev'-kommandot, så fort kärnan är på plats. 4. Kompilera kärnan 4.1. Städa upp och ange beroenden (Cleaning and depending) När configure-programmet avslutas säger det också åt dig att `make dep' och (eventuellt) `clean'. Kör alltså `make dep'. 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 `make clean' 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 inte detta steg, innan du försöker kompilera om en kärna. 4.2. Kompilerings-dags Efter dep och clean, så kan du nu antingen köra `make zImage' eller `make zdisk (det är den här delen som tar lång tid). `make zImage' kommer kompilera kärnan och lämna en fil i arch/i386/boot, vilken heter `zImage' (tillsammans med en del andra saker). Detta är den nya, packade kärnan. `make zdisk' gör samma sak, men lägger också in den nya zImage på en diskett, vilken du förhoppningsvis satt in i floppy- station "A:". `zdisk' ä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?"). Alla åtminstone halvvägs resonabla nya kärnor är packade, därav `z' framför namnet. En packad kärna packar automatiskt upp sig själv när den körs. 4.3. Andra "make"-prylar `make mrproper' gör en mer omfattande `clean'. Ibland är det nödvändigt; du kanske vill göra det vid varje patch. `make mrproper' tar också bort din konfigurerings-fil, så du ska antagligen ta en säkerhetskopia av den (.config) om du tycker den är värdefull. `make oldconfig' gör ett försök att konfigurera kärnan från en gammal konfigurerings-fil; det kör igenom `make config'-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. Se avsnitten om moduler för en beskrivning av `make modules'. 4.4. Installera kärnan 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. `make zlilo' 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 /vmlinuz, lilo finns i /sbin och din lilo-konfigurering (/etc/lilo.conf) inte har något att invända. 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 /etc/lilo/config, för äldre versioner, eller /etc/lilo.conf, för nyare versioner), och kolla upp den nuvarande konfigureringen. lilo.conf-filen ser ut så här: image = /vmlinuz label = Linux root = /dev/hda1 ... `image =' anger den kärna du för tillfället har installerad. De flesta använder /vmlinuz. `label' används av lilo för att bestämma vilken kärna, eller vilket operativ-system, som ska startas, och `root' är / för just det operativ-systemet. Gör en säkerhets-kopia av din gamla kärna och kopiera zImage-filen, vilken du just skapat, dit den ska vara (du skulle köra `cp zImage /vmlinuz' om du använder `/vmlinuz'). Kör sedan lilo igen -- på nyare system så kan du köra `lilo', men på äldre grejer kanske du blir tvungen att köra /etc/lilo/install, eller till och med en /etc/lilo/lilo -C /etc/lilo/config. 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. 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) `image = xxx' i LILOs konfigurerings-fil till slutet av filen, och modifiera `image = xxx' till `image = yyy', där `yyy' är den fullständiga sökvängen till filen du sparade din säkerhetskopia av kärnan som. Ändra sedan `label = zzz' till `label = linux-backup' och kör lilo igen. Det kan vara nödvändigt att lägga in en rad som säger `delay=x', 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). 5. Patcha kärnan 5.1. Lägga till en patch 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 `patch46.gz' 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 (`make clean' och sedan `cd /usr/src; tar zcvf old-tree.tar.gz linux', vilket kommer att skapa ett komprimerat tar-arkiv åt dig). Om vi fortsätter på exemplet ovan, låt oss förutsätta att du har `patch46.gz' i /usr/src. cd-a till /usr/src och kör en `zcat patch46.gz | patch -p0' (eller `patch -p0 < patch46', 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 -s-flaggan till patch så kommer patch 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 /usr/src/linux och leta efter filer med en .rej-ändelse. Vissa versioner av patch (äldre versioner, vilka kan har kompilerats på ett underlägset filsystem) lämnar dessa misslyckanden med en #-ändelse. Du kan använda `find' för att leta; find . -name '*.rej' -print skriver ut, till standard ut, vilka filer, i den aktuella katalogen eller underkataloger, somhar .rej-ändelser Om något gick fel, gör en `make clean', `config' och `dep', som det beskrivs i avsnitt 3 och 4. Det finns en hel del alternativ till patch-kommandot. Som nämnts ovan så kommer patch -s att hålla tyst om allt utom fel. Om du har ditt kärn-källkods-träd någon annanstans än i /usr/src/linux, så patchar patch -p1 allt korrekt (i den katalogen). Andra patch-alternativ finns väl-dokumenterade på man-sidan. 5.2. Om något går snett (Observera: detta avsnitt hänvisar mestadels till ganska gamla kärnor) Det vanligaste problemet som brukade uppstå, var när en patch modifierade en fil som heter `config.in', 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å config.in.rej- filen, och se efter vad som finns kvar av original-patchen. Förändringarna är vanligtvis markerade med `+' och `-' i början av raderna. Ta en titt på raderna före och efter, och tänk efter om de var satta till `y' eller `n'. Editera nu config.in, och ändra `y' till `n' och `n' till `y', där det ska vara så. Gör en patch -p0 < config.in.rej och om det rapporteras att det lyckades (inga fel), så kan du fortsätta med konfigurering och kompilering. config.in.rej kommer finnas kvar, men du kan ta bort den. Om du stöter på vidare problem, så kan du ha lagt till en patch i fel ordning. Om patch säger `previously applied patch detected: Assume -R?', så försöker du antagligen lägga till en patch som är under ditt aktuella versionsnummer; om du svarar `y', 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). För att backa ut (ta bort) en patch, använd `patch -R' på original- patchen. 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 linux- x.y.z.tar.gz-filerna, t.ex.) och börja om. 5.3. Bli av med .orig-filer Efter bara några få patchar kommer .orig-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. find . -name '*.orig' -exec rm -f {} ';' tar hand om det åt dig. De versioner av patch som använder # för miss­ lyckaden, använder en tilde istället för .orig. Det finns bättre sätt att bli av med .orig-filerna, vilka är baserade på GNU xargs: find . -name '*.orig' | xargs rm eller "ganska säker men en aning mer pratig"-metoden: find . -name '*.orig' -print0 | xargs --null rm -- 5.4. Andra patchar 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. 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. 6. Ytterligare paket 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. 6.1. kbd 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. 6.2. util-linux Rik Faith (faith@cs.unc.edu) plockade ihop en stor samling Linux- verktyg vilka, av ett underligt sammanträffande, kallas util-linux. Dessa utvecklas nu av Nicolai Langfeldt (util-linux@math.uio.no). Det är tillgängligt via anonym ftp från sunsite.unc.edu, i /pub/Linux/system/misc, och innehåller program såsom setterm, rdev och ctrlaltdel, vilka är relevanta för kärnan. Som Rik säger, installera inte utan att tänka efter; du behöver inte installera allt i paketet, och det kan mycket väl skapa stora problem, om du gör det. 6.3. hdparm 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. 6.4. gpm 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. 7. Några fallgropar 7.1. make clean 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å. 7.2. Enorma eller långsamma kärnor 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. 7.3. Kärnan kompilerar inte 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)/include Kö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/. 7.4. Den nya versionen av kärnan verkar inte starta (boot) 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.) 7.5. Du glömde köra LILO, eller systemet startar inte alls 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/boot 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: 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. 7.6. Jag får `warning: bdflush not running' 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. 7.7. Den säger saker om "undefined symbols" och kompilerar inte 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. 7.8. Jag får inte min IDE/ATAPI CD-ROM-spelare att fungera 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. 7.9. Den säger konstiga saker om "obsolete routing requests" 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. 7.10. Brandvägg fungerar inte i 1.2.0 Uppgradera till åtminstone version 1.2.1. 7.11. ``Not a compressed kernel Image file'' Använd inte vmlinux-filen, vilken skapas i /usr/src/linux som kärna; [..]/arch/i386/boot/zImage är den rätta. 7.12. Problem med konsoll-terminalen efter uppgradering till 1.3.x Ändra ordet dumb till linux i konsollens termcap-rad i /etc/termcap. Du kan också bli tvungen att skapa en terminfo-avdelning. 7.13. Verkar inte som om jag kan kompilera saker efter kärn-upp­ gradering 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 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. 7.14. Utöka gränser 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 8. Anmärkning om att uppgradera till version 2.0.x Version 2.0.x av kärnan introducerade en hel del förändringar, vad gäller installering av kärnan. Filen Documentation/Changes 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. 9. Moduler 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. 9.1. Installera modul-verktygen Modul-verktygen är tillgängliga från samma ställe som du hittar källkoden till kärnan, som modules-x.y.z.tar.gz; välj den högsta patch-nivån x.y.z, som är lika med eller under den till din aktuella kärna. Packa upp det med `tar zxvf modules-x.y.z.tar.gz', cd-a till katalogen det skapar (modules-x.y.z), ta en titt på README-filen och utför det du instrueras att göra (vilket vanligtvis är något enkelt, som make install). Du ska nu ha programmen insmod, rmmod, ksyms, lsmod, genksyms, modprobe och depmod i /sbin. Om du vill så kan du testa verktygen med "hw"-exempel-drivrutinen i insmod; titta till INSTALL-filen i den underkatalogen, för detaljer. insmod infogar en modul i en kärna som körs. Moduler har vanligtvis en .o-ändelse; exempel-drivrutinen, som nämns ovan, heter drv_hello.o, så för att infoga denna skriver du `insmod drv_hello.o'. För att ta reda på vilka moduler kärnan använder för tillfället, använd lsmod. Utdatan ser ut så här: blah# lsmod Module: #pages: Used by: drv_hello 1 `drv_hello' ä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 `rmmod drv_hello'. Observera att rmmod vill ha ett modul-namn, inte ett filnamn; du får reda på detta från lsmods uppräkning. De andra modul-verktygen dokumenteras i sina man-sidor. 9.2. Moduler som distribueras med kärnan 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 y till dem under `make config'. Kompilera en ny kärna och starta om med den. cd- a sedan till /usr/src/linux igen och kör en `make modules'. Detta kompilerar alla de moduler som du inte specificerade i kärn- konfigureringen, och placerar länkar till i /usr/src/linux/modules. Du kan använda dem direkt från den katalogen, eller köra `make modules_install', vilket installerar dem i /lib/modules/x.y.z, där x.y.z är versionen av kärnan. 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 insmod /usr/src/linux/modules/msdos.o, och sedan rmmod msdos 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 alltid konfigurera in det direkt i kärnan, för användning på "räddnings"-disketter. 10. Andra konfigurerings-alternativ Detta avsnitt innehåller beskrivningar av utvalda konfigurerings- alternativ (i make config), vilka inte tas upp i konfigurerings- avsnittet. De flesta enhets-drivrutiner tas inte upp här. 10.1. Vanliga inställningar (General setup) Normal floppy disk support - är precis det (stöd för vanliga floppy- diskar). Du kan ta en titt på filen drivers/block/README.fd; detta är extra viktigt för IBM Thinkpad-användare. XT harddisk support - om du vill använda den där 8-bitars XT- controllern, som ligger i hörnet och samlar damm. PCI bios support - 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. Kernel support for ELF binaries - 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. Set version information on all symbols for modules - förut kompilerades alltid kärn-modulerna om med varje ny kärna. Om du säger y så kommer det bli möjligt att använda moduler som kompilerats under en annan patch-nivå. Läs README.modules för mer detaljer. 10.2. Networking options Networking options (nätverks-alternativ) beskriv i NET-3-HOWTOn (eller NET-någonting-HOWTOn). 11. Tips och knep 11.1. Omdirigera utdatan från make- eller patch-kommandona Om du skulle vilja ha log-filer, om vad de där `make'- eller `patch'-kommandona gjorde, så kan du omdirigera utdatan till en fil. Ta först reda på vilket skal du kör: `grep root /etc/passwd' och leta efter någonting i stil med `/bin/csh'. Om du använder sh eller bash, kör (kommando) 2>&1 | tee (output file) vilket placerar en kopia av (kommando)s utdata i filen `(output file)'. För csh eller tcsh, använd (command) |& tee (output file) För rc (Observera: du använder antagligen inte rc) är det (command) >[2=1] | tee (output file) 11.2. Villkorlig kärn-installering 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 image = /usr/src/linux/arch/i386/boot/zImage label = new_kernel 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 /vmlinuz (efter att du kört lilo 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 LILO, och inget annat, på skärmen), vilket ger dig en prompt. Nu kan du skriva `new_kernel' för att starta den nya kärnan. Om du vill ha flera olika kärn-källkodsträd på ditt system, på samma gång (detta kan ta upp en massa hårddisk-utrymme; var försiktig), så är det vanligaste sättet att kalla dem /usr/src/linux-x.y.z, där x.y.z är kärn-versionen. Du kan sedan "välja" ett källkodsträd med en symbolisk länk; t.ex. så skulle `ln -sf linux-1.2.2 /usr/src/linux' 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 ln inte är en riktig katalog (gamla symboliska länkar går bra); resultatet kanske inte blir vad du väntat dig. 11.3. Uppdateringar av kärnan Russell Nelson (nelson@crynwr.com) 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 ftp.emlist.com i pub/kchanges, eller genom URLen http://www.crynwr.com/kchanges 12. Andra relevanta HOWTOn, som kan vara användbara · Sound-HOWTO: ljud-kort och -verktyg · SCSI-HOWTO: allt om SCSI-controllers och -verktyg · NET-2-HOWTO: nätverk · PPP-HOWTO: PPP-nätverk · PCMCIA-HOWTO: om drivrutinerna till din bärbara dator · ELF-HOWTO: ELF: vad det är, konvertering... · Hardware-HOWTO: översikt av stödd hårdvara · Module-HOWTO: mer om kärn-moduler · Kerneld mini-HOWTO: om kerneld · BogoMips mini-HOWTO: ifall du undrade 13. Diverse 13.1. Författare Författaren och utvecklaren av Linux Kernel-HOWTO är Brian Ward (bri@blah.math.tu-graz.ac.at). Var vänlig skicka mig kommentarer, tillägg, rättelser (rättelser är speciellt viktiga för mig). Du kan ta en titt på min `hemsida' på en av dessa URLer: http://www.math.psu.edu/ward/ http://blah.math.tu-graz.ac.at/~bri/ Ä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 massa 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. 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. 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 :-)). Version -0.1 skrevs 3 oktober 1994. Detta dokument är tillgängligt som SGML, PostScript, TeX, roff och ren text. 13.2. Att göra "Tips och knep"-avsnittet är lite litet. Jag hoppas kunna utöka det med förslag från andra. Samma med "Ytterligare paket". Mer information om hur man klarar av avlusning/krash-återhämtning behövs. 13.3. Bidrag En liten del av Linux README (kärn-hackning-alternativet) är inkluderad. (Tack Linus!) uc@brian.lunetix.de (Ulrich Callmeier): patch -s and xargs. quinlan@yggdrasil.com (Daniel Quinlan): rättelser och tillägg i många avsnitt. nat@nat@nataa.fr.eu.org (Nat Makarevitch): mrproper, tar -p, många fler saker boldt@math.ucsb.edu (Axel Boldt): samlade beskrivningar av konfigurerings-alternativ på nätet; gav mig sedan listan lembark@wrkhors.psyber.com (Steve Lembark): flera uppstarts-förslag (boot suggestions) kbriggs@earwax.pd.uwa.edu.au (Keith Briggs): några rättelser och förslag rmcguire@freenet.columbus.oh.us (Ryan McGuire): make-tillägg dumas@excalibur.ibp.fr (Eric Dumas): fransk översättning simazaki@ab11.yamanashi.ac.jp (Yasutada Shimazaki): japansk översättning jjamor@lml.ls.fi.upm.es (Juan Jose Amor Iglesias): spansk översättning mva@sbbs.se (Martin Wahlen): svensk översättning jzp1218@stud.u-szeged.hu (Zoltan Vamosi): ungersk översättning bart@mat.uni.torun.pl (Bartosz Maruszewski): polsk översättning donahue@tiber.nist.gov (Michael J Donahue): skrivfel, vinnare i "skivat bröd-tävlingen" rms@gnu.ai.mit.edu (Richard Stallman): dokumentation om "fri" dokumentation och kommentarer om detta dak@Pool.Informatik.RWTH-Aachen.DE (David Kastrup): NFS-saker esr@snark.thyrsus.com (Eric Raymond): diverse småsaker De som har skickat mig e-brev med frågor och problem har också varit ganska hjälpsamma. 13.4. Upphovsrätt, licens och sådana grejer Copyright © Brian Ward, 1994-1997. 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. 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". Garanti: ingen. 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.