19. "E" függelék - a gyakori hibák elhárítása

19.1. A rendszermag rendben elkészül, de a "make modules" nem sikerül

Jelenség: A rendszermag elkészül, és elkészül a bzImage, de a "make modules" már nem sikerül.

Megoldás: Ez a legtrükkösebb probléma, számos oka lehet. Ilyenek például a Linux terjesztés maga, nem frissített csomagfüggőségek. Ez nagyon jellemző a RedHat terjesztésre, de másiknál is előfordulhat. Okozhatja továbbá néhány "ott felejtett" fájl is, amelyek felfüggesztik a programfordítási folyamatot, ezáltal problémát okoznak. Ennek ellenszere a "make mrproper" és "make clean", majd a "make modules" parancs kiadása. Szükséged lehet a beállítási fájlok mentésére, alább látható ennek menete:

bash# cd /usr/src/linux 
bash# mkdir /usr/src/kernelconfigs ;
bash# cp /usr/src/linux/.config  /usr/src/kernelconfigs/.config.save;
bash# cp /usr/src/linux/.config  /usr/src/linux/configs/.config.save  # Különösen biztonságos
bash# cp /boot/config*  /usr/src/linux/configs/  # Különösen biztonságos
bash# make clean
bash# make mrproper  # "EL KELL VÉGEZNED ezt az mrproper-t", különben pokolian sok problémával 
                     # kell szembenézned
bash# make clean
bash# cp /usr/src/kernelconfigs/.config.save .config  # abban az esetben, ha újra fel akarod 
                                                      # használni a beállítófájlt ??
	  	

19.2. A programfordítás rendben megtörténik, de a rendszermag nem indul

Jelenség: ha a rendszermag rendben lefordul, de nem töltődik be és mindig rendszermag pánikra panaszkodik valahol az /sbin/modprobe körül.

Megoldás: nem készítetted el az initrd fájlt. Olvasd el az "A" függelék - initrd.img fájl készítése fejezetet.

Az initrd elkészítésén kívül, ki kell adnod egy "make modules" és "make modules_install" parancsot. Még ha ki is adtad a "make modules" parancsot előtte, próbáld meg másodszor is lefuttatni (nem árthat). Add ki a "make modules" és "make modules_install" parancsokat még egyszer, hogy teljesen megbizonyosodj arról, miszerint a betölthető modulok a helyükre kerültek.

19.3. A rendszer működése felfüggesztődik a LILO-nál

Jelenség: Miután felépítetted a rendszermagot és újraindítottál, a rendszer várakozik épp a LILO előtt.

Ok: Valószínűleg nem állítottad be a BIOS-ban a megfelelő elsődleges mester IDE és másodlagos szolga IDE merevlemez partíciót.

Megoldás: Kapcsold be a gépet és nyomd meg a DEL gombot a BIOS (Basic Input Output System) Setup menübe történő belépéshez. Válaszd az IDE beállításokat és állítsd be a megfelelő elsődleges merevlemez partíciót és a szolga-meghajtókat. Amikor a rendszer indul, megkeresi az elsődleges IDE merevlemezt és a Master Boot Record partíciót. Kiolvassa az MBR-t és elkezdi betölteni a Linux-rendszermagját a merevlemez partíciójáról.

19.4. No init found (nem található init)

A következő hibát gyakran követik el a kezdő felhasználók.

Ha az új rendszermagod nem indul el, és a következőt hibaüzenetet kapod:

	Warning: unable to open an initial console
	Kernel panic: no init found. Try passing init= option to kernel
        
Az a probléma, hogy nem állítottad be megfelelően a "root=" paramétert az /etc/lilo.conf fájlban. Az én esetemben, a root=/dev/hda1 partíciót használom, amin a gyökér "/" partíció van. Jól kell beállítanod a root-eszközt, olyasminek kell lennie, mint /dev/hdb2 vagy /dev/hda7.

Lehetnek hibák ez előtt a rendszermag pánik előtt is. Nézd meg és olvasd el a lehetséges hibaüzeneteket a "Kernel panic:" felirat előtt. A hibát okozhatja bármely ez előtti hiba is (összegződő hatás). Például a "Kernel panic:" hibaüzenet előtt láthatsz olyat is, hogy "kernel-module version mismatch" (a rendszermag-modul verzió nem egyezik) vagy "ilyen-olyan-egyéb-hibaüzenet"-eket is. Próbáld meg az ELSŐ, rendszer által jelzett hibát kijavítani.

A rendszermag az init parancsot az /sbin/init alatt keresi. Az /sbin könyvtár pedig a gyökér-partíción van. További részleteket a

	bash# man init
        
parancs kiadásával, valamint a
"C" függelék - GRUB részletesen, grub.conf mintafájl és "B" függelék - lilo.conf mintafájl fejezetek olvasásával tudhatsz meg.

19.5. Csomó fordítási hiba (compile error)

A "make", "make bzImage", "make modules" vagy "make modules_install" fordítási hibákat jelez. Add ki a "make mrproper" parancsot a "make" parancs kiadása előtt.

	bash# make clean && make mrproper # "KÖTELEZŐ KIADNOD AZ mrproper parancsot", egyébként problémák százai jelentkeznek! 
        
Ha a probléma változatlanul fennáll, próbáld ki a "menuconfig"-ot az "xconfig" helyett. Néha a GUI adott verziója problémázik az "xconfig"-al:

	bash# export TERM=VT100
	bash# make menuconfig  # Újabb, az "ncurses"/"curses"-t használja, ha nincs telepítve nem működik 
        

19.6. A "depmod" parancs "Unresolved symbol error messages" hibaüzenetet ír ki

A depmod parancs futásakor "Unresolved symbols" hibaüzenetet ír ki. Az alábbi példa mutatja be az esetet:

	bash$ su - root
	bash# man depmod
	bash# depmod
	depmod: *** Unresolved symbols in /lib/modules/version/kernel/drivers/md/linear.o
	depmod: *** Unresolved symbols in /lib/modules/version/kernel/drivers/md/multipath.o
	depmod: *** Unresolved symbols in /lib/modules/version/kernel/drivers/md/raid0.o
	depmod: *** Unresolved symbols in /lib/modules/version/kernel/drivers/md/raid1.o
	depmod: *** Unresolved symbols in /lib/modules/version/kernel/drivers/md/raid5.o
        

Ok: Nem fordítottad és telepítetted a modulokat az új rendszermag elkészítése ( "make bzImage" ) után.

Megoldás: Az új rendszermag elkészítése után muszáj ezt tenned:

	bash$ su - root
	bash# cd /usr/src/linux
	bash# make modules
	bash# make modules_install
        

19.7. A rendszermag nem tölti be a modult, "Unresolved symbols" hibaüzenetet ír ki

Amikor betöltöd a rendszert, és az bármely modult megpróbálva betölteni a "Unresolved symbol : __some_function_name" üzenetet ír ki, akkor ez azt jelenti, hogy nem "tiszta helyzetből kiindulva" fordítottad a modulokat és a rendszermagot. Elengedhetetlen, a make clean parancs kiadása, majd a modulok fordítása. Ezt az alábbi parancsok kiadásával teheted meg:

		bash# cd /usr/src/linux
		bash# make dep
		bash# make clean
		bash# make mrproper  # "MUST DO THIS mrproper", otherwise you will face hell lot of problems !!
		bash# make clean
		bash# nohup make bzImage &  
		bash# tail -f nohup.out     (.... to monitor the progress) 
		bash# make modules
		bash# make modules_install
        

19.8. A rendszermag nem tud betölteni egy modult

Ha a rendszermag nem tud betölteni egy modult (mondjuk egy hálózati kártyáét vagy más eszközét), akkor megpróbálhatod az eszközt közvetlenül a rendszermagba fordítani. Néha a betölthető modul NEM működik és a meghajtót fixen a rendszermagba kell fordítani. Például - néhány hálózati kártya nem támogatja a betölthető modul szolgáltatást - egyből a rendszermagba KELL fordítanod. Ezért a "make xconfig"-ban NEM SZABAD a betölthető modul opciót választani ehhez az eszközhöz.

19.9. Betölthető modulok

Az alapértelmezett betölthető modulokat telepítheted így:

Az alább megadott lépés nem szükséges, de HIBA ESETÉN SZÜKSÉG LEHET RÁ , amikor a /lib/modules fájljai megsérültek. Ha már létezik a /lib/modules könyvtár, és ki akarod cserélni a tartalmát, használd a "--force" kapcsolót a csomag lecseréléséhez és válaszd a megfelelő CPU architektúrát.

A RedHat Linux új verzióiban (mint a 6.0 vagy későbbi) a rendszermag-modulokat a kernel-2.2*.rpm tartalmazza. Telepítsd a rendszermagot és a modulokat:

		Ez kilistázza a már telepített csomagokat. 
	bash# rpm -qa | grep -i kernel
		
	bash# rpm -U --force  /mnt/cdrom/Redhat/RPMS/kernel-2.2.14-5.0.i686.rpm
	(or)
	bash# rpm -U --force  /mnt/cdrom/Redhat/RPMS/kernel-2.2.14-5.0.i586.rpm
	(or)
	bash# rpm -U --force  /mnt/cdrom/Redhat/RPMS/kernel-2.2.14-5.0.i386.rpm
        

Ez csak a régi, 5.2 és az előtti verziókhoz szól. Indíts az új rendszermaggal és telepítsd a betölthető modulokat a RedHat "contrib" CD-ROM-ról: cdrom

	bash# rpm -i /mnt/cdrom/contrib/kernel-modules*.rpm 
	....(A régi Linux rendszerekhez, amikben nincs előre telepítve az insmod) 
        

19.10. Olvasd el a dokumentációt

Ha további problémák vannak, elolvashatod az /usr/src/linux/README (legalább egyszer), valamint az /usr/src/linux/Documentation fájlt is.

	bash [/] # cd /usr/src/linux/Documentation

	bash [/usr/src/linux/Documentation] # ls *.txt

	binfmt_misc.txt  ioctl-number.txt           nbd.txt               serial-console.txt
	cachetlb.txt     IO-mapping.txt             nfsroot.txt           sgi-visws.txt
	cciss.txt        IRQ-affinity.txt           nmi_watchdog.txt      smart-config.txt
	computone.txt    isapnp.txt                 oops-tracing.txt      smp.txt
	cpqarray.txt     java.txt                   paride.txt            sonypi.txt
	devices.txt      kernel-doc-nano-HOWTO.txt  parport-lowlevel.txt  specialix.txt
	digiboard.txt    kernel-docs.txt            parport.txt           spinlocks.txt
	digiepca.txt     kernel-parameters.txt      pci.txt               stallion.txt
	DMA-mapping.txt  kmod.txt                   pcwd-watchdog.txt     svga.txt
	dnotify.txt      locks.txt                  pm.txt                swsusp.txt
	exception.txt    logo.txt                   ramdisk.txt           sx.txt
	floppy.txt       magic-number.txt           riscom8.txt           sysrq.txt
	ftape.txt        mandatory.txt              rtc.txt               unicode.txt
	hayes-esp.txt    mca.txt                    SAK.txt               VGA-softcursor.txt
	highuid.txt      md.txt                     sched-coding.txt      watchdog-api.txt
	i810_rng.txt     memory.txt                 sched-design.txt      watchdog.txt
	ide.txt          modules.txt                scsi-generic.txt      zorro.txt
	initrd.txt       mtrr.txt                   scsi.txt
        

19.11. make clean

Ha az új rendszermag valóban furcsa dolgokat csinál egy rutinszerű frissítés után, esélye van annak, hogy elfelejtetted kiadni a make clean parancsot az új rendszermag fordítása előtt. A jelenségek kiterjedhetnek bármire az egybőli lefagyástól, a különös I/O hibákon át a csapnivaló teljesítményig. Bizonyosodj meg, hogy kiadtad a make dep parancsot is.

19.12. Óriási vagy lassú rendszermag

Ha a rendszermagod sok memóriát zabál, túl nagy, és/vagy örökké tart a programfordítása még az új Quadbazillium-III/4400-as gépeden is, akkor valószínűleg sok felesleges cuccot (eszközmeghajtót, fájlrendszert stb.) tettél bele. Ha nem használod, ne állítsd be, mivel memóriát foglal. A legkézenfekvőbb jelenség a rendszermag felfúvódására a memória állandó oda- visszatöltése a lemezről; ha a lemezed sok zajt bocsát ki, és nem egyike a régi Fujitsu Eagles-eknek (ami kikapcsoláskor olyan hangot ad ki, mint egy leszálló repülőgép), akkor nézd át a beállításaidat.

Megállapíthatod, hogy mennyi memóriát használ a rendszermag, ha veszed a teljes memóriamennyiséget és kivonod belőle a "total mem" értékét, amit a /proc/meminfo mutat, vagy a " free " parancs.

19.13. A párhuzamos port/nyomtató nem működik

A PC-k beállítási lépései: először is, a "General Setup" kategóriában válaszd a " Parallel port support" és "PC-style hardware" beállításokat. Aztán a "Character devices" alatt, válaszd a "Parallel printer support"-ot.

Ezután következnek a nevek. A Linux 2.2 máshogy nevezi a nyomtatóeszközöket, mint a korábbi kiadások. Ennek az a következménye, hogy ha lp1 eszközöd van a régi rendszermag alatt, ez valószínűleg lp0 az új verziónál. Használd a " dmesg parancsot , vagy nézd meg a naplókat a /var/log könyvtárban, hogy kiderítsd az eszköz nevét.

19.14. A rendszermag nem fordul le

Ha nem fordul le, akkor lehetséges, hogy egy foltozás nem sikerült, vagy a forrásod valamiért nem jó. A gcc verziód szintén nem biztos, hogy megfelelő, vagy szintén nem jó (például az include fájlok lehetnek hibásak). Győződj meg, hogy a Linus által leírt szimbolikus linkek, amiket a README fájlban ír le, jól vannak beállítva. Általánosan, ha egy hagyományos rendszermag nem fordul le, akkor valami komoly gond van a rendszerben, és bizonyos eszközök újbóli telepítése válhat szükségessé.

Néhány esetben, a gcc hardver problémák miatt szállhat el. A hibaüzenet olyasmi lehet, hogy "xxx exited with signal 15" és ez általában nagyon rejtélyesen néz ki. Valószínűleg nem említettem volna, de megtörtént velem, egyszer volt egy kevés rossz cache-memóriám, és időnként a fordító véletlenszerűen elhányta magát. Először próbáld meg a gcc-t kicserélni, ha problémád van. Kisakkozhatod, hogy lefordul-e a rendszermag a külső gyorsítótár kikapcsolásával, csökkentett méretű RAM-mal stb.

Fel tudja zaklatni az embereket, ha azt mondják nekik, hogy rossz a hardverük. Nos, én nem adom fel. Létezik egy GYIK is erről, ezen a "http://www.bitwizard.nl/sig11" webhelyen.

19.15. A rendszermag új verziója nem töltődik be

Nem futtattad a LILO-t, vagy nincs rendesen beállítva. Egy dolog, ami "megfogott" engem egyszer, egy konfigurációs fájl problémája volt: ez volt benne: " boot = /dev/hda1 " ahelyett, hogy " boot = /dev/hda " lett volna. (Ez először tényleg zavaró lehet, de ha egyszer van egy működő beállítófájlod, nem kell megváltoztatnod).

19.16. Elfelejtetted futtatni a LILO-t, vagy a rendszered egyáltalán nem indul el

Hoppá! A legjobb dolog, amit ekkor tehetsz, hogy hajlékonylemezről vagy CD-ROM-ról indítasz, és készítesz egy másik indítólemezt (amit a " make zdisk " paranccsal is megtehetsz). Tudnod kell, hol van a gyökér ( / ) fájlrendszered és milyen típusú (tehát például ext2, minix). Az alábbi példában azt is tudnod kell, milyen fájlrendszeren van a /usr/src/linux forrásfád, ennek típusát, és normál esetben hova csatolódik fel.

A következő példában a / a /dev/hda1 , és a fájlrendszer, ami tartalmazza a /usr/src/linux könyvtárat, a /dev/hda3 , normál esetben a /usr alá van felcsatolva. Mindkettő second extended (ext2) fájlrendszer. A működő rendszermag helye a /usr/src/linux/arch/i386/boot könyvtár, és bzImage a neve.

Az ötlet az, hogy ha van egy működő bzImage , akkor azt használhatod egy új hajlékonylemez készítéséhez. Egy másik lehetőséget, ami vagy jobban működik, vagy nem (attól az egyedi módszertől függ, amivel szétbarmoltad a rendszered) beszélünk meg a példa után.

Először indíts egy boot/root lemezpárosról vagy mentőlemezről, és csatold fel a működő rendszermagot tartalmazó fájlrendszert:

mkdir /mnt mount -t ext2 /dev/hda3 /mnt

Ha az mkdir azt írja ki, hogy a könyvtár már létezik, ne törődj vele. Most a cd paranccsal lépj be arra a helyre, ahol a működő rendszermag van. Figyeld meg, hogy /mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/boot. Helyezz egy formázott lemezt az "A" meghajtóba (ne a boot vagy root lemezed!), másold ki a fájlt a lemezre, és állítsd be a gyökér fájlrendszeredhez:

cd /mnt/src/linux/arch/i386/boot dd if=bzImage of=/dev/fd0 rdev /dev/fd0 /dev/hda1

A cd paranccsal lépj be a / könyvtárba és válaszd le a normál /usr fájlrendszert:

cd / umount /mnt

Most már képesnek kell lenned normál módon újraindítani a rendszert erről a hajlékonylemezről. Ne felejtsd el futtatni a lilo-t (vagy bármi volt, amit elrontottál) az újraindítás után!

Amint fentebb említettük, van egy másik általános lehetőség. Ha véletlenül van egy működő rendszermag a / könyvtárban ( /vmlinuz például), használhatod azt is a indítólemezhez. Feltéve, hogy teljesül az összes fenti feltétel, és a rendszermagod a /vmlinuz , csak ezeket a változásokat tedd meg a fenti példához képest: változtasd meg a /dev/hda3 -at /dev/hda1 -re (a / fájlrendszerre), az /mnt/src/linux -ot a /mnt -re, és a if=bzImage -et if=vmlinuz -ra. A jegyzet arról, hogyan származtatjuk a /mnt/src/linux -ot, figyelmen kívül hagyható.

A LILO használata nagy meghajtókkal (több mint 1024 cilinderrel) problámákat okozhat. Olvasd a LILO mini-HOWTO (LILO mini HOGYAN) , vagy egyéb dokumetációt ennek a kivédéséről.

19.17. Azt írja ki: "warning: bdflush not running"

Ez komoly probléma lehet. A rendszermag v1.0-ás verziójától kezdve (1994. ápr. 20-körül), az " update " nevű programot, ami rendszeresen üríti a fájlrendszer puffereit, fejlesztették/kicserélték. Szerezd meg a " bdflush " forrását (ott találod, ahol a rendszermag forrását), és telepítsd fel (valószínűleg a régi rendszermaggal futtatod a rendszert, amíg ezt teszed.) Ez önmagát " update " néven telepíti, és miután újraindítottad a rendszert, az új rendszermagnak már nem szabad panaszkodnia.

19.18. Nem tudom működésre bírni az IDE/ATAPI CD-ROM-ot

Különös módon sokan nem tudják működésre bírni az ATAPI meghajtóikat, valószínűleg mert több dolog sem stimmel.

Ha a CD-ROM az egyetlen eszköz egy bizonyos IDE csatolón, akkor "master"-ként és nem "slave"-ként kell beállítani. Meglepő, de ez a legáltalánosabb hiba.

A Creative Labs (elsőként) IDE csatolót rakott a hangkártyáira. Ez azonban ahhoz az érdekes problémához vezetett, hogy míg néhányan csak egy csatolóval rendelkeztek, sokan viszont kettővel, beépítve az alaplapon (általában a 15-ös IRQ-n), így egy általános megoldás lett a SoundBlaster csatolóját a harmadik IDE portnak venni (IRQ11, legalábbis így mondták).

Ez a régi, 1.3-as és az alatti Linux-verzióknál gondot okozott. Ezekben a verziókban a Linux nem támogatta a harmadik IDE csatolót. Ennek megkerülésére kevés lehetőség van.

Ha már van egy második IDE port, van esély rá, hogy nem használod, vagy nincs még rajta két eszköz. Vedd le az ATAPI meghajtót a hangkártyáról és rakd a második csatolóra. Ezek után le tudod tiltani a hangkártya csatolóját, ami egyébként egy IRQ-t is megspórol.

Ha nincs második csatolód, jumperrel állítsd be a hangkártya csatolóját (ne a kártya hang-részét) az IRQ15-re, a második csatolóra. Ennek működni kell.

19.19. Furcsa dolgokat jelez elavult útválasztási kérésekről (routing requests)

Szerezd be a route program újabb verzióját és bármely egyéb programét is, ami útválasztási információkat kezel. Az /usr/include/linux/route.h (ami igazából egy fájl a /usr/src/linux könyvtárban) megváltozott.

19.20. "Not a compressed kernel Image file" (nem tömörített rendszermag)

Ne használd betöltőfájlként a vmlinux fájlt, ami a /usr/src/linux könyvtárban van, a [..]/arch/i386/boot/bzImage a megfelelő.

19.21. Problémák a konzolos terminállal, miután 1.3.x-re frissítettünk

Változtasd meg a dumb szót linux -ra a konzol termcap bejegyzésében, a /etc/termcap fájlban. Ezen kívül egy terminfo bejegyzést is létre kell hoznod.

19.22. Úgy néz ki, hogy nem fordíthatók le dolgok a rendszermag frissítése után

A Linux-rendszermag forrása tartalmaz számos ún. include fájlt (azok a dolgok, amik .h -val végződnek), amikre a standard /usr/include könyvtárban lévő fájlok is hivatkoznak. Általában a következő módon hivatkoznak rájuk (ahol a xyzzy.h valamilyen fájl a /usr/include/linux könyvtárban): #include <linux/xyzzy.h> Normál esetben van egy linux nevű link a /usr/include könyvtárban az include/linux könyvtárra, ami a forráson belül van ( /usr/src/linux/include/linux egy tipikus rendszeren). Ha ez a link nincs ott, vagy rossz helyre mutat, a legtöbb dolog egyáltalán nem fordítódik le. Ha úgy döntesz, hogy a rendszermag forrása túl sok helyet foglal és letörlöd, ez bizony probléma lehet. Egy másik dolog, ami rossz lehet, a fájlok tulajdonjogai; ha a root felhasználónak olyan fájlmaszkja van, ami nem engedi meg alapértelmezésben a többi felhasználónak, hogy lássa a fájljait, és a rendszermag forrását a p (preserve filemodes) opció nélkül csomagoltad ki, ezek a felhasználók nem tudják használni a C fordítót sem. Bár használhatod a chmod parancsot ennek kijavítására, valószínűleg egyszerűbb újra kicsomagolni az include fájlokat. Ezt ugyanúgy teheted meg, ahogy a teljes forrást az elején, csak egy kiegészítő argumentummal:

blah# tar zxvpf linux.x.y.z.tar.gz linux/include Figyelem: a " make config " újra létrehozza a /usr/src/linux linket, ha az nincs ott.

19.23. Korlátok kitolása

A következő néhány példa parancs hasznos lehet azoknak, akik kíváncsiak arra, hogyan kell megemelni néhány változtatható korlátot, amit a rendszermag ránk kényszerít:

			echo 4096 > /proc/sys/kernel/file-max 
			echo 12288 > /proc/sys/kernel/inode-max 
			echo 300 400 500 > /proc/sys/vm/freepages 
        

19.24. Hová küldjem a hibajelentést?

Részletesen a Gyors lépések - Rendszermag-fordítás fejezet Hová küldjem a hibajelentést? alfejezetében olvashatsz erről.