Ha az új kernel egy rutinszerû kernelfrissítés után elkezd nagyon vad
dolgokat mûvelni, akkor könnyen lehet, hogy elfeljtetted kiadni a
make clean parancsot az új kernel lefordítása elõtt. A tünetek
változatosak lehetnek: egyszerûen összeomlik, furcsa I/O problémák jönnek
elõ vagy csak nagyon lassú lesz. Ne felejtsd el a make dep-et se.
Ha a kernel sok memóriát foglal el, túl nagy, és/vagy egy örökkévalóságig tart lefordítani akkor is, ha a vadonatúj 786DX6/440 gépeddel esel neki, akkor valószínûleg túl sok fölösleges dolog (eszközmaghajtók, fájlrendszerek, stb.) van belekonfigurálva. Ha nem használod, akkor ne is konfiguráld be, mert foglalja a memóriát. A túl nagy kernel legszembetûnõbb tünete a memória és diszk közötti túlzott swappelés. Ha a merevlemez sokat zörög, és nem egy régi Fujitsu Eagles, ami kikapcsoláskor olyan hangot ad, mint egy sugárhajtású repülõgép leszálás közben, akkor nézd át a kernel konfigurálást.
Megtudhatod, hogy mennyi memóriát használ a kernel, ha fogod a gépedben levõ
összes memória mennyiségét és kivonod belõle a ``total mem'' mezõ értékét a
/proc/meminfo-ból, vagy a `free' outputjából.
Megtuthatod még úgy is, hogy kiadod a `dmesg' parancsot
(vagy megnézed a kernel log fájlt, bárhol is legyen a gépeden -- általában
ez a /var/log/messages).
Lesz benne egy ilyen sor:
Memory: 15124k/16384k available (552k kernel code, 384k reserved, 324k data)
A 386-osom (amelyen egy kicsit kevesebb plusz dolog van bekonfigurálva) ezt írja ki:
Memory: 7000k/8192k available (496k kernel code, 384k reserved, 312k data)
Ha nem bírsz élni nagy kernel nélkül, de a gép nem engedi, akkor próbáld ki a
`make bzimage'-t. Könnyen lehet, hogy akkor a LILO egy új verzióját
is installálnod kell.
Ha nem fordul le, akkor valószínûleg nem sikerült egy patch, vagy a forrás
valahogy megsérült. Lehet, hogy nem jó a gcc adott verziója, vagy az is lehet
sérült (például az include fájlok lehetnek hibásak). Ellenõrizd, hogy a
szimbólikus linkek, amelyeket Linus említ a README-ben jól vannak-e
beállítva. Általában elmondható, hogy ha a szabványos kernel nem fordul le,
akkor valami komoly baj van a rendszerrel, és valószínûleg újra kell
installálni bizonyos programokat.
Vagy talán egy 1.2.x kernelt fordítassz egy ELF fordítóval (gcc 2.6.3
és a fölött). Ha rengeteg ez-meg-az undefined
üzenetet kapsz fordítás közben, akkor lehet, hogy ez a baj. A megoldás a
legtöbb esetben nagyon egyszerû. Másold a következõ sorokat a
arch/i386/Makefile elejére:
AS=/usr/i486-linuxaout/bin/as LD=/usr/i486-linuxaout/bin/ld -m i386linux CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/includeAzután csinálj
make dep-t és zImage-t újra.
Ritka esetekben elõfordul, hogy a gcc hardver okok miatt száll el. A hibaüzenet valami olyasmi lesz, hogy ``xxx exited with signal 15'' és általában nagyon rejtélyesen néz ki. Talán nem is említeném, he nem történt volna meg velem is egyszer -- A cache memória hibás volt és a gcc idõnként véletlenszerûen elszállt. Elõször próbáld meg újrainstallálni a gcc-t, ha ilyen gond merül fel. Csak akkor kell gyanakodni, ha a kernel hiba nélkül lefordul kikapcsolt külsõ cache, kevesebb RAM, stb. mellett.
Az embereket általában nyugtalanítja, ha felvetõdik, hogy a hardverük
hibás lehet. Nos, nem én találtam ki. Itt van hozzá egy FAQ:
http://www.bitwizard.nl/sig11/.
Nem futtattad a LILO-t, vagy rosszul van konfigurálva. Egyszer az
``fogott'' meg, hogy hiba volt a konfig fájlban.
`boot =/dev/hda1' volt benne `boot = /dev/hda' helyett.
(Ez elsõre nagyon idegesítõ lehet, de ha már van egy mûködõ konfig fájl,
nem kell hozzányúlni.)
Hoppá! A legjobb amit ilyen helyzetben tehetsz az, hogy floppyról bootolsz
és csinálsz egy másik bootolható floppyt (ahogy a `make zdisk'
is csinálná). Tudnod kell, hogy hol van a root (/) fájlrendszer
és az milyen típusú (pl. második kiterjesztett, minix). Az alábbi példában
azt is tudni kell, hogy melyik fájlrendszeren van a linux forrás
/usr/src/linux, annak a típusa és hogy rendszerint hova van
mountolva.
A következõ példában a root a /dev/hda1, az /usr/src/linux
a /dev/hda3 fájlrendszeren van, normálisan az /usr-re
mountolva. Mindkettõ ext2 fájlrendszer. A mûködõ kernel
a /usr/src/linux/arch/i386/boot-ban van és a neve zImage.
Az alapötlet az, hogy ha van egy mûködõképes zImage, akkor lehet azt
használni az új floppyn. Egy másik módszerrõl, ami vagy jobban mûkõdik, vagy
nem (attól függõen, hogy pontosan hogyan rontottad el a rendszert) a példa
után lesz szó.
Elõször bootolj egy boot/root lemezpárosról vagy mentõlemezrõl és mountold föl azt a fájlrendszert, ami a mûködõ kernelt tartalmazza.
mkdir /mnt
mount -t ext2 /dev/hda3 /mnt
Ha a mkdir azt mondja, hogy a könyvtár már létezik, ne törõdj vele.
Menj be abba a könyvtárba, amelyben a mûködõ kernel volt. Ne feledd, hogy
/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/bootHelyezz egy formattált lemezt az ``A:'' meghajtóba (ne a boot vagy root lemezt!), másold a kernelt a lemezre és konfiguráld a root fájlrendszernek megfelelõen:
cd /mnt/src/linux/arch/i386/boot
dd if=zImage of=/dev/fd0
rdev /dev/fd0 /dev/hda1
Menj a root könyvtárba és csatold le a normálisan /usr fájlrendszert.
cd /
umount /mnt
Ezek után a megszokott módon lehet bootolni errõl a floppyról. Ne felejtsd el futtatni a LILO-t (vagy amit rosszul csináltál) az újrabootolás után.
Ahogy az elõbb említettem, van egy másik lehetõség. Ha van egy mûködõ kernel
a gyökérkönyvtárban (például /vmlinuz), akkor azt is lehet használni
egy bootlemezen. Feltéve, hogy minden változatlan, /vmlinuz a kernel,
a következõ változtatásokat kell eszközölni a fenti példán: legyen
/dev/hda3 helyett /dev/hda1 (a root fájlrendszer) az
/mnt/src/linux-t mountold az /mnt-re, és az if=zImage
paramétert írd át if=vmlinuz-re. A megjegyzést a
/mnt/src/linux levezetésérõl figyelmen kívül lehet hagyni.
A LILO használata nagy merevlemezekkel (több, mint 1024 cilinder) gondot okozhat. Lásd a LILO mini-HOWTO-t vagy a dokumentációt segítségért.
Ez súlyos probléma lehet. Az 1.0 kernel verzió kibocsátása után
(1994 április 20. táján) felfrissítették/lecserélték az `update'
nevû programot, amely rendszeresen kiüríti a fájlrendszer puffereit.
Szerezd meg a `bdflush' forrását (meg kell lennie ugyanott, ahol a
kernel forrásnak), és installáld fel. (Ezt még a régi kernelt futtatva
ajánlatos megtenni.) `update' néven installálja magát. Az újrabootolás
után a kernel nem fog többet panaszkodni.
Valószínüleg ELF fordítód van (gcc 2.6.3 és afölött) és 1.2.x (vagy korábbi)
kernel forrás. A szokásos megoldás az, hogy az alábbi sorokat bemásolod
a arch/i386/Makefile elejére:
AS=/usr/i486-linuxaout/bin/as LD=/usr/i486-linuxaout/bin/ld -m i386linux CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
Ez lefordítja az 1.2.x kernelt az a.out könyvtárakkal.
Különös módon sokan nem tudják használni az ATAPI meghajtókat, talán mert több oka lehet a hibának.
Ha a CD-ROM meghajtó az egyetlen eszköz egy adott IDE csatolón, akkor a jumpereknek ``master'' vagy ``single'' állásban kell lenniük. Valószínûleg ez a leggyakoribb hiba.
A Creative Labs (és mások is) IDE csatolókat építenek a hangkártyákra. Ebbõl következik az az érdekes probléma, hogy egyes gépeken csak egy csatoló van, másokon kettõ beépítve az alaplapra (általában IRQ15), ezért a soundblaster csatolót a harmadik IDE portra teszik (IRQ11, állítólag).
Ez problémákat okoz a linuxszal, mivel az 1.2.x kernelek nem támogatják a harmadik csatolót (az 1.3.x valamelyik tagjától kezdve már van,de az fejlesztõi és nem detektálja automatikusan). Ezt többféleképpen lehet kikerülni.
Ha már van második IDE port, könnyen lehet, hogy nem is használod, vagy még nincs rajta két eszköz. Vedd le az ATAPI meghajtót a hangkártyáról és rakd a második csatolóra. Ezután ki lehet kapcsolni a hangkártya csatolóját és még egy IRQ-t is megspórolsz.
Ha nincs második IDE csatoló, akkor jumperold a hangkártya IDE csatolóját (ne a hangkártya hang részét) az IRQ15-re (második IDE csatoló). Ennek mûködnie kell.
Ha valamilyen okból nélkülözhetetlen az ún. ``harmadik'' csatoló, vagy más
problémák vannak, szerezz egy 1.3.x kernelt ( az 1.3.57-ben van, például)
és olvasd el a drivers/block/README.ide-t. Ott sokkal több információ
van.
Szerezd be a route program, és minden más útvonalválasztást
manipuláló program egy új verzióját. Az /usr/include/linux/route.h
(ami valójában az /usr/src/linux-ban van) megváltozott.
Upgrade-elj legalább az 1.2.1 verzióra.
Nem tömörített kernel fájl.
Ne a /usr/src/linux könyvtárban keletkezõ vmlinux fájlt
használd kernelnek. Az [..]/arch/i386/boot/zImage a jó.
Az /etc/termcap fálban a konzol termcap bejegyzésben írd át a
dumb szót linux-ra. Lehet, hogy egy terminfo bejegyzést
is kell csinálni.
A linux kernel forrás tartalmaz számos include fájlt (a .h végû
fájlnevek) amelyekre a szabványos include fájlok hivatkoznak. A hivatkozások
általában így néznek ki (ahol xyzzy.h egy fájl az
/usr/include/linux-ban):
#include <linux/xyzzy.h>
Normális esetben van egy linux nevû link az /usr/include-ban,
amely a kernel forrás include/linux könyvtárára mutat
(általában /usr/src/linux/include/linux). Ha ez a link nincs a helyén,
vagy rossz helyre mutat, akkor a legtöbb programot egyáltalán nem lehet
lefordítani. Ha letörölted a kernel forrást, mert túl sok helyet foglalt, akkor
nyilvánvaló, hogy ez a gond. Lehet baj a hozzáférési jogosultságokkal is.
Ha a root umask-ja alapértelmezés szerint nem engedi meg, hogy a többi
felhasználó lássa a fájljait és a kernel forrást a p (preserve
file modes) opció nélkül csomagoltad ki, akkor a felhasználók a C
fordítót sem fogják tudni használni. Bár a chmod paranccsal is meg
lehet ezt oldani, könnyebb újra kicsomagolni az include fájlokat. Ezt ugyanúgy
kell csinálni, ahogy az elején kicsomagoltuk az egész forrást, csak még egy
paraméter kell használni:
blah# tar zxvpf linux.x.y.z.tar.gz linux/include
Megjegyzés: a ``make config'' létrehozza a /usr/src/linux
linket, ha nincs meg.
A következõ példa parancsok hasznosak lehetnek azoknak, akik szeretnék tudni hogyan lehet bizonyos, a kernel szabta korlátokat megemelni.
echo 4096 > /proc/sys/kernel/file-max echo 12288 > /proc/sys/kernel/inode-max echo 300 400 500 > /proc/sys/vm/freepages