10. Információk a rendszermag fájljairól

Ez a rész "rövid áttekintést" és "bemutatást" tartalmaz a Linux-rendszermag egyes részeiről. Ha van időd, olvasd el.

Figyelmeztetés: nagyon elővigyázatosnak kell lenned ezekkel a fájlokkal, és nem szabad szerkeszteni vagy mozgatni/törölni/átnevezni őket.

10.1. vmlinuz és vmlinux

A "vm" azt jelenti "Virtuális Memória" ("Virtual Memory"). A Linux támogatja a virtuális memória használatát, szemben az olyan régi rendszerekkel mint a DOS. Annál a 640 kByte egy komoly korlát volt. A Linux képes virtuális memóriaként használni a merevlemezt, ezért "vm" a neve. A vmlinuz a rendszermag végrehajtható fájlja. Helye a /boot/vmlinuz könyvtár. Ez lehet egy szimbolikus hivatkozás valamire, például /boot/vmlinuz-2.4.18-19.8.0. A "make zImage" parancs készíti el a vmlinuz fájlt, és a "cp /usr/src/linux/arch/i386/linux/boot/zImage /boot/vmlinuz" paranccsal rakhatod a helyére. A vmlinuz a vmlinux tömörített változata. A zImage ezért visszamenőleg kompatibilis (a kisebb rendszermagok esetében). Megjegyzendő, hogy a közeljövőben megszűnhet a zImage, és előnyben részesül a "make bzImage" (big zImage; nagy zImage). A zImage (vmlinuz) nem csak egy tömörített fájl, de van benne egy beépített gzip-kicsomagoló is (a fájl elejében). Tehát nem lehet használni a gzip -dc és gunzip parancsokat a vmlinuz kicsomagolására.

A zImage és a bzImage egyaránt tömörített a gzip programmal. A rendszermagban van egy mini-gunzip, ami a rendszermag kicsomagolására és indítására szolgál. A különbség az, hogy a régi zImage az alsó memóriába (az első 640 kByte-ra), míg a bzImage a rendszermagot a felső memóriába csomagolja ki (1 MByte fölé).

A vmlinux a tömörítetlen rendszermag-fájl, a vmlinuz a tömörített, amit betölthetővé tettek. (Figyeld meg, hogy mindkét név hasonlóan néz ki, kivéve az utolsó z betűt). Általában nem kell törődnöd a vmlinux fájllal, ez csak egy közbenső lépés.

A rendszermag általában egy bzImage fájlt készít, eltárolja az arch/i386/boot könyvtárban, és a felhasználónak kell átmásolni azt a /boot könyvtárba, majd beállítani a GRUB vagy a LILO rendszerbetöltőt.

10.2. Rendszerbetöltő (bootloader) fájlok

A .b fájlok a rendszerbetöltő fájlok. Ezek szükségesek a rendszermag memóriába való betöltéséhez. Lehetőleg NE bántsd őket.

	ls -l /boot/*.b
	-rw-r--r--    1 root     root         5824 Sep  5  2002 /boot/boot.b
	-rw-r--r--    1 root     root          612 Sep  5  2002 /boot/chain.b
	-rw-r--r--    1 root     root          640 Sep  5  2002 /boot/os2_d.b
        

10.3. Üzenetfájl (message file)

A "message" fájl tartalmazza a bootloader által megjeleníthető üzenetet, ami az operációs rendszer kiválasztására szólít fel. Ezért NE nyúlj hozzá.

	ls -l /boot/message*
	-rw-r--r--    1 root     root        23108 Sep  6  2002 /boot/message
	-rw-r--r--    1 root     root        21282 Sep  6  2002 /boot/message.ja
        

10.4. initrd.img

Részletesen az "A" függelék - initrd.img fájl készítése fejezetben olvashatsz erről.

10.5. bzImage

A bzImage a "make bzImage" parancs által készített tömörített rendszermag-fájl, ami a fordítás során jött létre. Fontos megjegyezni, hogy a bzImage nincs tömörítve a bzip2 programmal!! A bz a bzImage nevében félrevezető!! A valódi jelentése "Big Zimage". A "b" jelentése a bzImage szóban "big". A zImage és a bzImage egyaránt a gzip metódusával van tömörítve. A rendszermagban van egy mini-gunzip, ami a rendszermag kicsomagolására és indítására szolgál. A különbség az, hogy a régi zImage az alsó memóriába (az első 640 kByte-ra), míg a bzImage a rendszermagot a felső memóriába csomagolja ki (1 MByte fölé). Az egyetlen ismert probléma az lehet, hogy néhány gépen nem működik a bzImage (mert a gép bugyuta). A bzImage jelenleg gyorsabban elindul mint a zImage, de nincs különbség a rendszer *futásának* sebességében. A szabály az, ha az összes meghajtóprogram (driver) nem fér bele a zImage fájlba, akkor moduláris rendszermagra van szükség.

Ha a rendszermag kicsi a zImage és bzImage is használható, az elindított rendszer ugyanúgy fut. A nagy rendszermag mint bzImage fog futni, nem mint egy zImage. Mindkét rendszerfájl a gzip metódussal tömörített (a bzImage nem a bzip metódussal van tömörítve, mint azt a neve sugallja), de különböző módon töltődnek be a memóriába. A rendszermag a felső memóriaterületre is betölthető, így nem korlátozza a memóriaméret a gyagya intel architektúrán. Miért létezik két módszer? Néhány régebbi lilo és loadlin rendszerbetöltő nem kezeli a bzImage formátumot. Megjegyzendő, hogy a *betöltés* különböző, de a *futás* azonos. Sok tévinformáció származott abból, hogy mi is a bzImage fájl (a legtöbb szerint bzip2 metódussal tömörített fájl).

10.6. module-info

A "module-info" fájl egy szimbolikus hivatkozás:

	$ uname -r
	2.4.18-19.8.0custom
	  
	# ls -l /boot/module-info*
	lrwxrwxrwx    1 root     root           25 Jan 26 10:44 /boot/module-info -> module-info-2.4.18-19.8.0
	-rw-r--r--    1 root     root        15436 Sep  4  2002 /boot/module-info-2.4.18-14
	-rw-r--r--    1 root     root        15436 Jan 26 01:29 /boot/module-info-2.4.18-19.8.0
        

A fentiekhez hozzátéve megjegyzendő, hogy nem kötelező module-info szimbolikus hivatkozást készíteni egy rendszermaghoz kapcsolódó fájlhoz, mint amilyen a System-map és vmlinuz fájlokhoz szükséges. Ez csak egy szöveges fájl, amely akkora, mint az aktuális module-info lista. Mielőtt eltávolítanád az összes RH rendszermaghoz szükséges "alapanyagot" a rendszeredről, készítened kellene egy mentést erről a fájlról:

# cp /boot/module-info-2.4.20-19.9 /boot/module-info-2.4.20-19.9.backup 
        
Ezt biztonságosabb a module-info fájlal megtenni, ritkán változnak ugyanazon RH rendszermagok változatán belül.

Ez a "module-info" fájl az anaconda/utils/modlist (speciális RedHat Linux Anaconda telepítőhöz) programmal készült. Egyéb Linux összeállításokban létezhet ennek megfelelő parancs. Tájékozódj a Linux disztribútorod kézikönyv oldalaiból.

Nézd meg a szkriptet és keress rá a "module-info" szóra updmodules .

Következik egy részlet a szkriptből:

	#!/bin/bash
	# updmodules.sh
		MODLIST=$PWD/../anaconda/utils/modlist
		MODINFO=$KERNELROOT/boot/module-info-$version
	-- kivágás
	bla-bla-bla 
	-- kivágás
	    # module-info fajl elkeszitese
	    $MODLIST --modinfo-file $MODINFO --ignore-missing --modinfo \
			$(ls *.o | sed 's/\.o$//') > ../modinfo
        

Az anaconda/utils/modlist program az anaconda-runtime*.rpm csomagban van a RedHat CD-ROM-on:

	cd /mnt/cdrom/RedHat/RPMS
	rpm -i anaconda-8.0-4.i386.rpm
	rpm -i anaconda-runtime-8.0-4.i386.rpm
	ls -l /usr/lib/anaconda-runtime/modlist
        
Beszerezheted a forráskódját (anaconda/utils/modlist.c) az anaconda*.src.rpm-ből a "http://www.rpmfind.net/linux/rpm2html/search.php?query=anaconda" webhelyről. Egyből olvashatod is: modlist.c .

A "module-info" a fordítás során készül el. Ez egy információs fájl, amit legalábbis akkor használnak, mialatt kitöltésre kerülnek a rendszermag megfelelő Oops jelentései. Ez egy lista a modulok belépési pontjairól. Ezen kívül a depmod is használja azon táblák felépítésénél, amiket az insmod és rokonsága használ. Függőségi információkat tartalmaz azokról a modulokról, amiket egy adott modul előtt be kell tölteni stb.

A lényeg az, hogy "Ne távolítsd el a module-info fájlt."

Néhány információ a module-info fájlról:

10.7. config

Minden alkalommal, ha új rendszermagot fordítasz és telepíted a rendszermag-fájlt a /boot könyvtárba, a megfelelő beállítófájlt szintén át kell másolnod a /boot könyvtárba, dokumentációs célból és későbbi hivatkozás miatt. Ezeket a fájlokat NE változtasd vagy szerkeszd!

	ls -l /boot/config-*
	-rw-r--r--    1 root     root        42111 Sep  4  2002 /boot/config-2.4.18-14
	-rw-r--r--    1 root     root        42328 Jan 26 01:29 /boot/config-2.4.18-19.8.0
	-rw-r--r--    1 root     root        51426 Jan 25 22:21 /boot/config-2.4.18-19.8.0BOOT
	-rw-r--r--    1 root     root        52328 Jan 28 03:22 /boot/config-2.4.18-19.8.0-26mar2003
        

10.8. grub

Ha a GRUB rendszerbetöltőt használod, akkor lesz ott egy "grub" könyvtár is.

	ls /boot/grub
	device.map     ffs_stage1_5  menu.lst        reiserfs_stage1_5  stage2
	e2fs_stage1_5  grub.conf     minix_stage1_5  splash.xpm.gz      vstafs_stage1_5
	fat_stage1_5   jfs_stage1_5  stage1          xfs_stage1_5
        
Részletesen a
"C" függelék - GRUB részletesen, grub.conf mintafájl fejezetben olvashatsz erről.

10.9. System.map

A System.map egy "telefonkönyv-szerű" függvénylistája egy bizonyos lefordított rendszermagnak. Tipikusan egy szimbolikus hivatkozás az éppen futó rendszermag System.map fájljára. Ha rossz (vagy semmilyen) System.map fájlt használsz, az összeomlások nyomon követése nehezebb, de más hatása nincs. A System.map nélkül kisebb zavaró üzenetekkel kell szembesülnöd.

NE bántsd a System.map fájlokat.

	ls -ld /boot/System.map*
	lrwxrwxrwx    1 root     root           30 Jan 26 19:26 /boot/System.map -> System.map-2.4.18-19.8.0custom
	-rw-r--r--    1 root     root       501166 Sep  4  2002 /boot/System.map-2.4.18-14
	-rw-r--r--    1 root     root       510786 Jan 26 01:29 /boot/System.map-2.4.18-19.8.0
	-rw-r--r--    1 root     root       331213 Jan 25 22:21 /boot/System.map-2.4.18-19.8.0BOOT
	-rw-r--r--    1 root     root       503246 Jan 26 19:26 /boot/System.map-2.4.18-19.8.0custom
        

Hogyan készül a rendszermag szimbólumtáblája (Kernel Symbol Table)? A System.map fájlt az "nm vmlinux" készíti el, és a nem fontos vagy érdeklődésre számot nem tartó szimbólumokat kiszedi a grep. Amikor lefordítod a rendszermagot, a System.map fájl az /usr/src/linux/System.map fájlba kerül. Valahogy így:

	nm /boot/vmlinux-2.4.18-19.8.0 > System.map
	# Ez egy sor az /usr/src/linux/Makefile fájlból 
	nm vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map
	cp /usr/src/linux/System.map /boot/System.map-2.4.18-14   # For v2.4.18
        

Forrás: "http://www.dirac.org/linux/systemmap.html"

10.9.5. Mi az Oops?

Mi a leggyakoribb hiba a házilag készült programjaiddal? A szegmentációs hiba (segfault). A jó öreg signal 11.

Mi a Linux-rendszermag leggyakoribb hibája? A segfault. Itt azonban a segfault fogalma sokkal összetettebb, és ahogy az várható sokkal komolyabb. Amikor a rendszermag egy hibás mutatóra hivatkozik, azt nem segfault-nak hívjuk - ezt hívják "oops"-nak. Egy ilyen oops rendszermag-hibát jelez, mindig jelenteni és javítani kell.

Figyeld meg, hogy az oops nem ugyanaz a dolog, mint a segfault. A programod nem tud kijönni egy segfault-ból. A rendszermag viszont nem szükségszerűen kerül instabil állapotba, ha egy oops fordul elő. A rendszermag nagyon robusztus; az oops csak az aktuális folyamatot öli meg, a rendszermag többi részét megfelelően jó állapotban hagyhatja.

Az oops nem egyenlő a rendszermag pánikkal (kernel panic). Pánik alkalmával a rendszermag nem tud tovább futni; a rendszer halt állapotba zuhan és újra kell indítani. Egy oops akkor okozhat pánikot, ha a rendszer egy életfontosságú része semmisül meg. Egy oops valamely eszközvezérlőben például majdnem sosem okoz pánikot.

Amikor egy oops előfordul, a rendszer a hibakereséshez elengedhetetlen információt nyomtat ki, mint például a CPU összes regiszterének tartalmát és az oldalleíró táblák (page descriptor tables) helyét. Főleg az EIP (utasítás mutató) tartalma íródik ki. Mint ez itt:

	   EIP: 0010:[<00000000>]
	   Call Trace: [<c010b860>]
          

10.9.6. Mit köze egy oops-nak a System.map fájlhoz?

Egyetérthetsz azzal, hogy az EIP-ben adott információ és a nyomkövetési adatok nem valami információgazdagok. Ennél is fontosabb, hogy még a rendszermag fejlesztőinek sem azok. Mivel a szimbólumnak nincs fix címe, a c010b860 mutathat bárhova.

Ahhoz, hogy használhassuk ezeket a titkosított oops-kimeneteket, a Linux egy klogd nevű démont használ, a rendszermag naplózó démont. A klogd elfogja a rendszermag oops-ait és a syslog segítségével naplózza, kicserélve néhány haszontalan információt, mint a c010b860 olyanra, amit ember is tud használni. Más szóval, a klogd egy rendszermag-üzenet naplózó, ami név-cím feloldást tud végezni. Amint átalakítja a rendszermag üzeneteit, egy olyan naplózót használ, ami a rendszerszintű üzeneteket tudja naplózni, általában a syslogd démont.

A név-cím feloldáshoz a klogd a System.map fájlt használja. Most már tudod, mi az oops és mi köze a System.map fájlhoz.

Megjegyzések: Jelenleg kétféle címfeloldást végez a klogd.

a System.map fájlt, ezért nem fontos ennek tárgyalásánál, de azért röviden ismertetem.

A klogd dinamikus fordítása

Tegyük fel, hogy betöltöttél egy rendszermag-modult, ami oops-ot idézett elő. Egy oops üzenet készült és a klogd elfogta. Azt találta, hogy az oops a d00cf810-nál fordult elő. Mivel ez a cím egy dinamikusan betöltött modulhoz tartozik, nincs bejegyzés hozzá a System.map fájlban. A klogd keresi, de nem talál semmit így arra következtet, hogy egy betölthető modul generálta az üzenetet. A klogd ezután lekérdezi a rendszermagot olyan szimbólumokért, amiket a betölthető modulok exportáltak. Még ha a modul szerzője nem exportálta is a szimbólumokat, legalább a klogd tudni fogja, melyik modul idézte elő az oops-ot, ami jobb, mint semmit sem tudni az oops-ról.

Más programok is használják a System.map fájlt és rövidesen ezzel is foglalkozom.

10.9.7. Hol kellene lennie a System.map fájlnak?

A System.map bárhol lehet, ahol az őt használó szoftverek keresik. Most beszéljünk arról, hogy a klogd hol keresi. Az induláskor, ha a klogd nem kapta meg argumentumként a System.map helyét, akkor három helyen keresi a következő sorrendben:

  1. /boot/System.map

  2. /System.map

  3. /usr/src/linux/System.map

A System.map ezenkívül verzió-információkat is tartalmaz, és a klogd intelligens módon a megfelelő map (térkép)fájlt keresi meg. Például, ha a 2.4.18-as rendszermagot futtatod és a hozzá társított fájl a /boot/System.map. Most fordítasz egy új 2.5.1-es rendszermagot az /usr/src/linux fán belül. A fordítási folyamat közben elkészül az /usr/src/linux/System.map fájl. Amikor elindítod az új rendszermagot, a klogd először megnézi a /boot/System.map-et, megállapítja, hogy ez nem a futó rendszermagnak megfelelő térképfájl, ezután megnézi az /usr/src/linux/System.map-et, megállapítja, hogy ez a megfelelő, és elkezdi olvasni a szimbólumokat.

Néhány megjegyzés:

  • Valahol a 2.5.x szérián belül, a Linux-rendszermag elkezdett Linux-verziószám formában kicsomagolódni a tar archívumból, a sima linux helyett (kezeket fel: hányan vártuk már, hogy ez megtörténjen?) Nem tudom, hogy a klogd démont módosították-e már úgy, hogy az /usr/src/linux-verzió/System.map fájlt keresse. TENNIVALÓ: nézd meg a klogd forrását. ?? FIXME ?? Ha valaki megver is ezért, kérlek küldj e-mailt, és tudasd, hogy módosították-e a klogd-t úgy, hogy a forráskód új nevű könyvtárában keressen. ??FIXME??

  • A kézikönyv oldal nem ír le mindent. Nézd meg ezt:


	   # strace -f /sbin/klogd | grep 'System.map'
	   31208 open("/boot/System.map-2.4.18", O_RDONLY|O_LARGEFILE) = 2
          

Kétségtelen, hogy a klogd nemcsak a 3 keresési könyvtárban nézi meg a térképfájl megfelelő verzióját, de tudja azt is, hogy a "System.map" nevet követő "-kernelverzó"-t nézze, mint a System.map-2.4.18. Ez a klogd egy nem dokumentált képessége.

Néhány meghajtónak szüksége van a System.map-re a szombólumok feloldásához (mivel a rendszermag fejlécfájljaihoz lettek linkelve, és nem mondjuk a glibc-éihez). Ezek nem fognak jól működni a futó rendszermaghoz készült megfelelő System.map fájl nélkül. Ez NEM ugyanaz a dolog, mint hogy egy modul nem töltődik be a rendszermag verziószámának eltérése miatt. Ezt a rendszermag-verzió jelzésével kell megoldani, nem a szimbólumtáblával, ami változik az ugyanolyan verziójú rendszermagokon belül is!