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 Quadbazillium-III/4400 gépeddel esel neki, akkor valószínűleg túl sok fölösleges dolog (eszközmeghajtó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 swappolá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.
PC-n úgy lehet beállítani a párhuzamos portot, hogy a kernel konfigurálásánál kiválasztjuk a `Parallel port support'-ot és a `PC-style hardware'-t a `General Setup' csoportban, és a `Parallel printer support'-ot a `Character devices' csoportban.
A másik dolog az elnevezés. A Linux 2.2 másképp nevezi el a nyomtatókat, mit az előző verziók. A következmény az, hogy ha a régi kernel alatt lp1 volt a nyomtató neve, akkor azt most lp0-nak hívják az új alatt.
Add ki a `dmesg' parancsot, vagy nézd meg a logfájlokat a /var/log könyvtárban.
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 szimbolikus 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.
Ritka esetekben előfordul, hogy a gcc hardver okok miatt száll el. A hibaüzenet valami olyasmi lesz, hogy ``xxx exited with signal 11'' és általában nagyon rejtélyesen néz ki. Talán nem is említeném, ha 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/hda' sor helyett `boot =/dev/hda1' volt benne. (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 hajlékony lemezről bootolsz, és csinálsz egy másik bootolható lemezt (ahogy a `make bzdisk' is csinálná).
Tudnod kell, hogy hol van a root (/) fájlrendszer és az milyen típusú (pl. second extended, 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 eszközön van, normálisan az /usr-re mountolva. Mindkettő ext2 fájlrendszer. A működő kernel az /usr/src/linux/arch/i386/boot-na van, és a neve bzImage.
Az alapötlet az, hogy ha van egy működőképes bzImage, akkor lehet azt használni az új hajlékony lemezen. 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 az 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/boot
Helyezz 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=bzImage 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 lemezrő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-ot mountold az /mnt-re, és az if=bzImage paramétert írd át if=vmlinuz-ra. 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.) A program `update' néven installálja magát. Az újrabootolás után a kernel nem fog többet panaszkodni.
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 jumpereld 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.
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.
Frissíts legalább az 1.2.1 verzióra.
Tömörítetlen kernel fájl. Ne a /usr/src/linux könyvtárban keletkező vmlinux fájlt használd kernelnek. Az [..]/arch/i386/boot/bzImage 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 az /usr/include könyvtárban. 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 filemodes = fájljogosultságok megőrzése) 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 az /usr/src/linux linket, ha nincs meg.
A következő néhány példa hasznos lehet 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