alavoor[AT]yahoo.com
v7.3, 2003. október 27
Jelen útmutató a rendszermag beállításának, fordításának, frissítésének és hibaelhárításnak részletes leírása ix86-alapú rendszereken. Emellett hasznos lehet más architektúrákhoz is. A dokumentum rövid és egyszerű maradt, így még a nem technikai beállítottságú "otthoni felhasználók" is képesek lehetnek Linux-rendszermag készítésére és futtatására. (Időközben a The Linux Documentation Project átnézésre bevonta ezt a dokumentumot. Hamarosan átszerkesztett és frissített formában jelenik meg - a lektor)
A következő okokból fordíthatsz rendszermagot:
Rendszermag-fejlesztést végzel
Új hardvert raksz a számítógépbe
Testre akarod szabni a rendszermagot, és nem akarod a disztribúcióval szállított, alapértelmezett verziót használni.
Védelmi szervezetek vagy katonai alkalmazások esetében el kell olvasni a rendszermag forrását és saját kezűleg fordítani. Nincs kivétel! (Az Egyesült Államok Védelmi Hivatala lefordítja a rendszermagot, mielőtt szétosztja a számítógépeket).
A világon minden ország és minden kormány helyben fordítja a rendszermagot a biztonság és sértetlenség biztosítása érdekében. Minden kormányzat illetve szervezet auditálja és ellenőrzi a rendszermag-forrás minden egyes sorát, mielőtt használná a számítógépet.
A katonai elhárító ügynökségek világszerte tanulmányozzák és lefordítják a Linux-rendszermag forráskódját. Ők minden egyes soráról tudják, mit csinál!
Ha saját kezűleg fordítod a rendszermagot, akkor az felér a kód elolvasásával és ellenőrzésével!
Minden egyes egyetemnek, iskolának és kollégiumnak a gépek használata előtt le kellene fordítania az operációs rendszermagot!
A fejlődésed és tudásod növelése céljából, és persze csak szórakozásképpen!
A nagyon speciális tudományos alkalmazásokhoz - valószínűleg - rendszermagot kell fordítanod
Ez egy nemzetközi törvény: "Nem használhatod a számítógépet a rendszermag saját kezű lefordítása NÉLKÜL". Ha nem engedelmeskedsz ennek a törvénynek, sokféle géphiba lehet a "büntetésed"! Önmagadnak kell lefordítani, így nem függsz másoktól, akik megcsinálnák neked.
Illegális, törvénytelen, bűncselekmény és csalás a számítógép használata a rendszermag SAJÁT KEZŰ fordítása nélkül! 1-3 havi börtön és 100-2000 USD büntetés róható ki mindazokra, akik a számítógépet a rendszermag forráskódból történő újrafordítása nélkül használják. Néhány állam/ország/kormány szigorú törvénnyel akadályozza meg a rendszermag újrafordítása nélküli számítógép-használatot.
Az USA-ban az összes vállalat előírja a rendszermag fordítását, mielőtt használnánk a gépet, ezért van Linux, Linux és Linux mindenhol az Egyesült Államokban!
...és még ezer más okból - túl sok lenne mind felsorolni!
Megjegyzés: a dokumentum rövid és egyszerű maradt, így még a nem technikai beállítottságú "otthoni felhasználók" is képesek lehetnek a Linux-rendszermag fordítására és futtatására.
A megszokott ipari gyakorlatban van egy nyomkövető/hibakereső PC, egy teszt PC és a munkára használt PC. Senki sem dolgozik egyből a munkára használt PC-n, először mindig a hibakereső, majd a teszt PC-n kísérletezünk. Erre a különböző egyéni képzettség, illetve a betanulási idő miatt van szükség. A számítógép hardvere nagyon modern technológia, akárcsak az űrsikló, a kockázatok nagyon összetettek, képes váratlanul meghibásodni. Annak ellenére, hogy törekszünk eme dokumentum frissen tartására valamint az összes parancsot ellenőrizzük, nagyon ajánlott a szakértelmedet először egy gyakorló PC-n kipróbálni, mielőtt egy "ÉLES" gépen alkalmaznád azt. Pontosítsd szakértelmed és élesítsd tudásod először egy tesztgépen futtatott Linuxon. Amikor minden működik, akkor válts át a "munkagépre", fokozott óvatossággal. Ha elrontod a tesztgépet veszélyes parancsok használatával, ezekből a hibákból is tanulni fogsz. Először nagyon beképzelten fogsz dolgozni a tesztgépen. A legtöbb vállalat régi PC-ket szerez, amiket tesztgépnek használnak. Kérünk értsd meg, nincs garancia erre a dokumentumra, viszont megteremtheted a saját garanciád azzal, hogy ellenőrzöd ezt a dokumentumot a tesztgépeden vagy az otthoni PC-n (alacsonyabb kockázati tényezők mellett). (Készítsd el a saját garanciájú dokumentumodat, és akaszd ki a falra a számítógéped közelében!!)
Az eredeti fordítást (v0.9) Vámosi Zoltán készítette (1997). Újrafordította (v6.3) Szíjjártó László (2003.07.28). Frissítette (v7.3) és a lektorálta Daczi László (2003.11.21).
Ennek a résznek a szerzője Al Dev (alavoor[AT]yahoo.com) (A legfrissebb verzió megtalálható a "http://milkyway.has.it" és "http://www.milkywaygalaxy.freeservers.com" webhelyeken. Ezeken a helyeken ellenőrizheted a változásokat). A tükrözéseket megtalálod a http://milkyway.bounceme.net webhelyen. Ezek a webhelyeken sok linuxos nyalánkságot és tippet is találsz.
A rendszermag újrafordítására szükség lehet, ha kisebbé akarod tenni, ez GYORSABB működésű operációs rendszert eredményez. Az új eszközök támogatásához is elengedhetetlen.
Mielőtt lefordítanád a rendszermagot, jó ötlet a rendszer biztonsági mentése. Ha még eddig nem mentetted volna el, akkor most tedd meg. Kereskedelmi forgalmazású mentőprogramokat is használhatsz, mint a BRS Backup-Recovery-Software (ugyanezen az oldalon nyílt forrású/szabad felhasználású mentőprogramokat is találsz, a "Backup and Restore Utility" menüpont alatt felsorolva). A biztonsági mentés csak egy ajánlat, nem előírás annak elkészítése a Linux-rendszermag fordítása előtt.
Ha már fordítottál rendszermagot, és fel akarod fejleszteni a következő fejlesztési szintre (patch level), akkor egyszerűen másold be a meglévő beállítófájlt és használd fel újra. (Például: ha a 2.4.19-es rendszermagot már fordítottad, és a 2.4.20-ra akarsz fejleszteni.)
A kisebb fejlesztésekhez: Ez a lépés időt spórolhat, ha fel akarod használni a régi beállításokat. Amikor telepíted a rendszermagot, a konfigurációs fájlt általában a /boot könyvtárba rakod. A .config fájlt ne .config.save néven mentsd el, mivel a "make mrproper" ki fog törölni minden .config* fájlt! Tehát használhatod a meglévő beállítófájlt:
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# cp /boot/config-2.4.18-19.8.0 /usr/src/linux/.config
|
bash# ls -l /usr/src/lin* # You can see that /usr/src/linux is a soft link
bash# cd /usr/src/linux
bash# cp ../linux-old-tree/.config . # Például cp ../linux-2.4.19/.config .
|
vagy még egy módszer - használható a "make oldconfig" parancs is, ami alapértelmezésként felhasználja a meglévő ./.config fájlt a beállítás kérdéseihez.
FIGYELEM: ha nincs elég szabad hely az /usr/src alatt, akkor bármely partícióra kicsomagolható a rendszermag forrása, ahol van elég tárhely (például a /home-ra). Ez azért van, mert a rendszermag fordítása sok szabad helyet igényel az objektum-fájlok, mint a *.o, számára. Ezért az /usr/src/linux könyvtárnak egy szimbolikus hivatkozásnak (soft link) KELL lennie, ami arra a könyvtárra mutat, ahol a forrás van.
Ezek után lásd a következő részt, a programfordításról és a telepítésről.
Ha letöltötted az új rendszermag forrását, olvasd el a következő fájlokat az /usr/src/linux/Documentation könyvtárban
Changes: ebben olvashatók a minimális követelmények valamint néhány megjegyzés
kernel.txt: ebben van a "Linux-rendszermag magyarázata"
Olvasd el az összes *.txt fájlt az /usr/src/linux/Documentation könyvtárban, de legfontosabbak a kernel*.txt fájlok.
Csomagold ki a forrást
cd /usr/src/linux; mkdir /usr/src/kernelconfigs ; cp /usr/src/linux/.config /usr/src/kernelconfigs/.config.save; make clean; make mrproper; make clean; cp /usr/src/kernelconfigs/.config.save .config # Akkor, ha újra akarod használni a beállítófájlt ??
Opcionális - másold át a konfigurációs fájlt: átmásolhatod a beállítófájlt a régi rendszermag-forrásfából az újba (időt spórolhat, ha a régi beállításokat akarod használni).
make xconfig # Szebb, de korlátai vannak; csak "X" alatt fut
make dep
Adj egy egyedi nevet az új rendszermagnak - szerkeszd az /usr/src/linux/Makefile fájlt és az EXTRAVERSION bejegyzést
nohup make bzImage
"make modules" és "make modules_install"
...és elmehetsz vacsorázni vagy le is fekhetsz (szép Linuxos álmokat!), majd amikor visszajössz a rendszer kész! Nézd meg a naplófájlt a "less nohup.out" paranccsal.
make install # Ez "NEM ajánlott" - használd a "cp /usr/src/linux/arch/i386/boot/bzImage /boot/bzImage.myker" parancsot
Másold át a System.map fájlt a /boot könyvtárba: # cp System*.map* /boot/
Másold át a rendszermag konfigurációs fájlt (az általad kiválasztott opciókat). Nem elengedhetetlen, de később hasznos lehet. cp .config /boot/config.KERNEL_VERSION.Name
Állítsd be a GRUB vagy a LILO rendszerbetöltőt.
Indítsd újra a gépet, és ellenőrizd az új rendszermag betöltődését
Készíts biztonsági mentőlemezt a "bzdisk" vagy "mkbootdisk" paranccsal
Opcionális - make rpm # RPM csomag készítéséhez
Opcionális - make clean (ha tárhelyet akarsz felszabadítani)
Lásd a fenti lépések részleteit a következő fejezetekben...
Az előző részben említett lépések részletei:
Figyelem: Az alábbiakban a "bash#" jelzi a bash készenléti jelét (prompt), azokat a parancsokat kell begépelni, amiket a "bash#" jelzés után következnek. A következő parancsokat RedHat Linux alatt, a 2.4.7-10 verziójú rendszermaggal teszteltük, de más terjesztéseknél is (esetleg kisebb eltérésekkel működnie kell. Ugyanúgy működnie kéne a régi, 2.2, 2.0 és 1.3 verziójú rendszermagokkal is. Szintúgy a jövőbeli vagy új verziójúakkal (kis eltérésekkel - értesítsetek róla).
Figyelem: Sok rendszermagot (kernel image) tárolhatsz a rendszereden. A következő lépéseket követve nem írod felül vagy teszed tönkre a meglévő rendszermagodat. Ezek a lépések nagyon biztonságosak és a jelenlegi rendszermagot nem érintik, azt nem módosítják.
Csomagold ki a forrást: A következő lépések végrehajtása során "root" felhasználóként legyél bejelentkezve. Csatold fel a RedHat Linux CD-ROM-ot (a RedHat 9-ben Disc 2) és telepítsd a rendszermag forrás-RPM csomagját:
bash$ su - root
bash# cd /mnt/cdrom/RedHat/RPMS
bash# rpm -i kernel-headers*.rpm
bash# rpm -i kernel-source*.rpm
bash# rpm -i dev86*.rpm
bash# rpm -i bin86*.rpm
|
bash# cd /usr/src
bash# ls -l # Láthatod, hogy az /usr/src/linux egy szimbolikus hivatkozás, ami a forrásra mutat
lrwxrwxrwx 1 root root 19 Jan 26 11:01 linux -> linux-2.4.18-19.8.0
drwxr-xr-x 17 root root 4096 Jan 25 21:08 linux-2.4.18-14
drwxr-xr-x 17 root root 4096 Mar 26 12:50 linux-2.4.18-19.8.0
drwxr-xr-x 7 root root 4096 Jan 14 16:32 redhat
|
FIGYELEM: ha nincs elég szabad hely az /usr/src alatt, akkor bármelyik partícióra kicsomagolhatod a forrást, ahol van elegendő (mint a /home). Ez azért van, mert a rendszermag fordítása sok szabad helyet igényel az objektum-fájlok, mint a *.o, számára. Ezért az /usr/src/linux könyvtárnak egy szimbolikus hivatkozásnak KELL lennie, ami arra a könyvtárra mutat, ahol a forrás van.
Takarítás: Mielőtt az "mrproper" parancsot kiadnánk, elmentheted a .config fájlt.
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 rengeteg problémával szembesülsz !!
bash# make clean
bash# cp /usr/src/kernelconfigs/.config.save .config # ha újra akarod használni a beállítófájlt ??
|
Opcionális - másold át a beállítófájlt: Ez a lépés időt spórolhat meg, ha fel akarod használni a régi beállításokat. Amikor telepíted a rendszermagot, akkor a beállítófájlt általában a /boot alá rakod. Van néhány alapszintű beállítófájl, az /usr/src/linux/configs/kernel-*.config, amiket felhasználhatsz. Tehát használhatod a meglévő konfigurációs fájlt:
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# cp /boot/config-2.4.18-19.8.0 /usr/src/linux/.config
Vagy másold át az alapértelmezett beállítófájlt az /usr/src/linux/configs könyvtárból:
bash# cp /usr/src/linux/configs/kernel-2.4.18-i686.config /usr/src/linux/.config
Vagy Athlon processzorok esetében
bash# cp /usr/src/linux/configs/kernel-2.4.18-athlon.config /usr/src/linux/.config
|
bash# ls -l /usr/src/lin* # Látható, hogy az /usr/src/linux egy szimbolikus hivatkozás
bash# cd /usr/src/linux
bash# cp ../linux-old-tree/.config . # Például cp ../linux-2.4.19/.config .
|
Beállítás:
Indítsd el az X-Window rendszert a "startx" paranccsal. Ha nem tudod elindítani, lásd alább a következő lépést.
bash# man startx
bash# startx
bash# cd /usr/src/linux
bash# make xconfig # Szebb, bár korlátozott; csak "X" alatt fut
|
Ha nem tudod elindítani az "X"-et, akkor próbáld meg a következőt:
bash# export TERM=xterm
bash# make menuconfig # újabb, az ncurses/curses csomagot használja, nem működik, ha nincs telepítve
Ha összezavarodott képernyőt kapsz, használj más terminál-emulációt,
mint a vt100, vt102, vt220 vagy ansi. A képernyő zavaros lesz és
összevissza karaktereket látsz, ha telnet-tel lépsz be egy távoli Linux
rendszerbe. Ebben az esetben a vt100, vt220 terminál-emulátorokat használd.
Például:
bash# export TERM=vt220
bash# export TERM=ansi
A VT alacsonyabb szintjein használd:
bash# export TERM=vt100
bash# make menuconfig # újabb, az ncurses/curses csomagot használja, nem működik, ha nincs telepítve
Ha a "menuconfig" parancs nem működik, akkor próbáld meg:
bash# make config # régi, felhasználóbarát módszer !!
|
NAGYON FONTOS !!! : Válaszd a megfelelő CPU típust - Pentium 3, AMD K6, Cyrix, Pentium 4, Intel 386, DEC Alpha, PowerPC, egyébként a rendszermag fordítása nem sikerül, vagy ha igen, akkor nem fog elindulni!!
Válaszd az SMP támogatást - akár egy, akár több processzorod van
Fájlrendszerek - válaszd a Windows95 VFAT, MSDOS, NTFS fájlrendszereket mint a rendszermag részeit, és ne mint betölthető modulokat. (Nekem személy szerint előnyös, de szabadon válaszd a saját rendszerednek megfelelően).
Engedélyezd a "Loadable kernel modules" (betölthető rendszermag modulok) támogatást! Ezzel az opcióval, a futó Linux rendszeren tudod az eszközmeghajtókat dinamikusan ki/be tölteni. Részletesen a Betölthető modulok fejezetben olvashatsz erről.
Függőségek: Most add ki a következő parancsot:
bash# make dep
|
Adj egyedi nevet az új rendszermagodnak: Nevet is adhatsz a rendszermagnak, így az egyedi lesz és nem akad össze a többivel.
bash# cd /usr/src/linux
bash# vi Makefile
|
Add ki a "make" parancsot: Olvasd el a következő fájlt (hogy információt gyűjts a rendszermag fordításáról/építéséről. Tipp: használd a színes gvim szövegszerkesztőt a jobb olvashatóság érdekében.
bash# gvim -R /usr/src/linux/arch/i386/config.in
bash# man less
bash# less /usr/src/linux/arch/i386/config.in
Nyomd le a "h" billentyűt a súgóért és navigálj a szövegben az i, j, k, l, h
vagy a nyíl-, ill. a page up/down billentyűkkel.
|
bash# cd /usr/src/linux
bash# man nohup
bash# nohup make bzImage &
bash# man tail
bash# tail -f nohup.out (.... a folyamat figyeléséhez)
Ez a rendszermagot az /usr/src/linux/arch/i386/boot/bzImage fájlba helyezi el.
|
BETÖLTHETŐ MODULOK: Most amíg a "make" végigzörög az előző rész szerint, elindíthatsz egy másik xterm-es parancsértelmezőt és kövesd a lépéseket: ez a lépés CSAK AKKOR szükséges, ha engedélyezted a "loadable module support"-ot a fenti "Beállítás" lépésnél. A betölthető modulok a /lib/modules alatt találhatók. EL KELL végezned ezt a lépést, ha engedélyeztél vagy letiltottál bármely modult, egyébként "unresolved symbols" hibaüzeneteket fogsz kapni a rendszermag betöltődése közben vagy azután.
# indíts egy új xterm ablakot és ...
bash# cd /usr/src/linux
# írányítsd át a kimenetet, hogy ne írd felül a nohup.out-ot, amíg az fut...
bash# nohup make modules 1> modules.out 2> modules.err &
bash# make modules_install # csak akkor add ki, ha a fenti "make" parancs sikeresen lefutott
|
Most menj vacsorázni vagy feküdj le: Amíg mindkét "make"-ablak elzörög magában, addig elmehetsz vacsorázni (pihenj picit) vagy bújj ágyba (szép linuxos álmokat), mire felébredsz és visszajössz, a rendszer kész lesz! Ellenőrizheted a kimenet naplóját a "less nohup.out" paranccsal.
bash# cd /usr/src/linux
bash# less nohup.out
bash# less modules.err
bash# less modules.out
Ha nem volt hiba:
bash# make modules_install
|
bzImage: Miután a bzImage sikerült, másold át a rendszermagot (kernel image) a /boot könyvtárba. Át kell másolnod az új fájlt, különben az új rendszermag LEHET, HOGY NEM FOG betöltődni. Ezen kívül a beállítófájlt is át kell másolnod a /boot területre, hogy tükrözze a rendszermag beállításait dokumentációs szempontból.
bash# cp /usr/src/linux/arch/i386/boot/bzImage /boot/bzImage.myker.26mar2001
# Át KELL másolnod a beállítófájlt, hogy tükrözze a megfelelő rendszermagot
# dokumentációs célból
bash# cp /usr/src/linux/.config /boot/config-<your_kernelversion_date>
# Példa: cp /usr/src/linux/.config /boot/config-2.4.18-19.8.0-26mar2001
|
A LILO vagy a GRUB beállítása: Két lehetőség van a betöltésre RedHat Linux alatt - a GRUB és a LILO. A GRUB beállítása: A GRUB újabb és sokkal jobb eszköz mint a LILO, elsődlegesen ennek a használatát ajánlom. A LILO régebbi technológia. A GRUB különbözik a többi betöltőtől (mint például a LILO) abban, hogy ez "képes azt hazudni a MS Windowsnak (és elhitetni vele), hogy az első partícióra telepítették, akkor is ha nem így van!" . Így megtarthatod a jelenlegi Linux rendszeredet ott, ahol van, és telepíthetsz Windowst mellé. Részletesen a "C" függelék - GRUB részletesen, grub.conf mintafájl fejezetben olvashatsz erről. A LILO beállítása: A LILO régebbi eszköz, részletesen a "B" függelék - lilo.conf mintafájl fejezetben olvashatsz róla.
Indítsd újra a gépet, és a lilo futásakor nyomd meg a TAB billentyűt, majd gépeld be: "myker". Ha elindul, jó munkát végeztél! Egyébként a lilo menüjében válaszd a régi rendszermagot, indítsd el és próbálj meg mindent elölről kezdeni. A régi rendszermagod még mindig ÉRINTETLEN és BIZTONSÁGOS , például a /boot/vmlinuz-2.0.34-0.6
Ha az új rendszermagod betöltődik, és jól is működik, elkészítheted a indítólemezed. Tégy egy üres hajlékonylemezt a meghajtóba, majd:
bash# cd /usr/src/linux
bash# make bzdisk
Használható még az mkbootdisk parancs -
bash# rpm -i mkbootdisk*.rpm
bash# man mkbootdisk
|
Opcionálisan, készíts RPM csomagot: ha több gépre is telepíteni akarod az új rendszermagot, RPM csomagot is készíthetsz belőle.
make rpm # RPM csomag építéséhez
|
Takarítás: Opcionális: make clean (ha tárhelyet akarsz felszabadítani)
Olvasd el az "D" függelék - utólagos rendszermag fordítás fejezetet.
Ha a fenti lehetőségek mindegyikét kipróbáltad és úgy gondolod, hogy a rendszermag hibás. (Ez a fejezet eredetileg az "E" függelék - a gyakori hibák elhárítása fejezet végén volt, tehát először az ott leírt lehetőségeket próbáljátok végig - a lektor) Ebben az esetben jelentheted a hibát, így (talán) javítva lesz. Olvasd el az /usr/src/linux/REPORTING-BUGS fájlt, majd látogass el a Reporting Bugs for the Linux Kernel (A Linux-rendszermag hibáinak bejelentése) honlapra.
Mindenki, aki használta a "betölthető modulokat", igazán "megszerette" őket! Szeretem a modulokat, mivel agyafúrt dolgok, és a nagyobb feladatokat kicsi, kezelhető részekre szedik szét. Ha elkezded használni, fogadok, hogy megszereted őket! A modulok csak a Linuxra jellemzőek. Ez volt a világ első olyan operációs rendszere, ami bemutatta a betölthető modulok fogalmát. Egyetlen más operációs rendszer sem rendelkezik ezzel a fogalommal, de a közeljövőben más rendszerek is megvalósíthatják.
A betölthető modulok memóriát spórolhatnak, és megkönnyítik a beállítást. A modulok hatóköre magában foglalja a fájlrendszereket, ethernet kártyák, szalagos meghajtók, nyomtatók és mások eszközmeghajtóit.
A modulok a rendszermag kódjának darabjai, amelyeket nem csatoltak (foglaltak bele) közvetlenül a bele. Az ember lefordíthatja őket elkülönítve is, és beillesztheti vagy eltávolíthatja a futó rendszermagból majdnem bármikor. Rugalmasságából kifolyólag nem ajánlott bizonyos rendszermag-jellemzőket beléjük kódolni. Sok népszerű eszközmeghajtó, mint például a PCMCIA és a QIC-80/40 szalagos eszközmeghajtók, betölthető modulok.
Olvasd el a Module-HOWTO (Modul HOGYAN) doksit: "http://www.tldp.org/HOWTO/Module-HOWTO" .
Olvasd el ezeket a kézikönyv-oldalakat is:
bash# rpm -i /mnt/cdrom/Redhat/RPMS/modutils*.rpm
bash# man lsmod
bash# man insmod
bash# man rmmod
bash# man depmod
bash# man modprobe
|
bash# man insmod
bash# modprobe loop
bash# insmod loop
bash# lsmod
|
A modulok segédeszközeinek RPM csomagját így telepítheted:
bash# rpm -i /mnt/cdrom/Redhat/RPMS/modutils*.rpm
|
Az insmod beilleszti a modult a futó rendszermagba. A modulok általában a .o kiterjesztéssel rendelkeznek; a példaként említett neve drv_hello.o , így ennek beillesztéséhez kiadjuk az: " insmod drv_hello.o " parancsot. A rendszermag által jelenleg használt modulok listájához használd az lsmod parancsot. A kimenet valami ilyesmi: blah# lsmod Module: #pages: Used by: drv_hello 1 " drv_hello " a modul neve, egy lapnyi (4k) memóriát használ, és jelenleg nincs más modul, ami tőle függ. Eltávolításához használd az " rmmod drv_hello " parancsot. Figyeld meg, hogy az rmmod egy modulnevet, nem pedig egy fájlnevet igényel; ezt kinyerheted az lsmod listájából. A többi modul-segédeszköz céljait a kézikönyv-oldalaik írják le.
A 2.0.30-as verziótól kezdve, majdnem minden elérhető betölthető modul formájában. A használatukhoz először bizonyosodj meg, hogy nem állítod be őket a rendes rendszermagban; tehát nem válaszolsz y -el ezekre a " make config " alatt. Fordíts egy új rendszermagot és indítsd el. Aztán: cd az /usr/src/linux könyvtárba ismét, és: " make modules ". Ez lefordítja az összes modult, amit nem adtál meg a rendszermag konfigurációjában, és hivatkozást (link) készít hozzájuk az /usr/src/linux/modules könyvtárba. Használhatod őket egyenesen abból a könyvtárból vagy hajtsd végre a " make modules_install " parancsot, ami telepíti őket a /lib/modules/x.y.z könyvtárba, ahol x.y.z a rendszermag verziója.
Ez főleg a fájlrendszereknél lehet kényelmes. Valószínűleg nem használod gyakran a minix vagy a msdos fájlrendszert. Például, ha belebotlok egy msdos (iszonyat!) hajlékonylemezbe, csak beírom: insmod /usr/src/linux/modules/msdos.o , és aztán rmmod msdos , amikor végeztem. Ez az eljárás körülbelül 50k RAM-ot spórol a rendszermagban a normál működés során. Egy kis megjegyzés kívánkozik ide a minix fájlrendszer kapcsán: mindig közvetlenül a rendszermagba állítsd be, ha "mentőlemezen" akarod használni.
Tegyük fel, hogy már megcsináltad a "make modules" és "make modules_install" lépéseket. Később pedig még a "make clean"-t is a helyfelszabadítás érdekében. Most pedig változtatni akarsz valamelyik modul egyetlen C fájlján, és újra akarod építeni azt az egy modult, és a modulfájlt bemásolni a /lib/modules alá. Hogyan csinálod? Hiszen nem akarsz egy "make modules" parancsot kiadni, az mindent újraépít és 2-3 óráig tart!
Le tudsz fordítani egyetlen modulfájlt (mondjuk a foo.o-t) és telepítheted is. Ehhez egyszerűen szerkeszd meg a Makefile-t, és változtasd meg a SUBDIRS bejegyzést csakis azokra a könyvtárakra, amik érdekelnek.
Egy jó példa: azt vettem észre, hogy a rendszermagom nem támogatja az NTFS fájlrendszert (persze kiadtam a "make clean"-t a "make modules" után. A francba!). Így elhatároztam, hogy lefordítom az NTFS betölthető modulját. Nem akartam az egész készletet (mivel ez nálam 2 óráig tartana), ezért az alábbi módszert követtem, és csak a fs/ntfs modult fordítottam, majd kiadtam az "insmod ntfs" parancsot. Az egész 5 percig tartott!
Másik példa: ha csak az fs/autofs modul érdekel, akkor a következőket teszem:
cd /usr/src/linux
mv Makefile Makefile.original
cp Makefile.original Makefile.my
ln -s Makefile.my Makefile # mivel néhány fájlnak még szüksége lehet a "Makefile"-ra
vi Makefile.my
# Megjegyzésekkel láttam el a "SUBDIRS" sorokat, és hozzáadtam azokat a könyvtárakat, amik érdekeltek
# például a fs/autofs-hez:
#SUBDIRS =kernel drivers mm fs net ipc lib abi crypto
SUBDIRS =fs/autofs
# Elmentettem a Makefile.my fájlt és kiadtam a következő parancsot:
make -f Makefile.my modules
# Ez megcsinálja az autofs.o modult
# Most bemásoltam a modul objektumfájlt a célkönyvtárba: /lib/modules
# VESZÉLYES: NE CSINÁLD EZT: "make -f Makefile.my modules_install" , mivel kitakaríthatja
# a többi jót is a /lib/modules könyvtárból !! Csak másold be, így:
cp autofs.o /lib/modules/2.4.18-19.8.0/kernel/fs/autofs
# Most állítsunk vissza mindent a normál helyzetbe
rm Makefile # This is a link to Makefile.my
ln -s Makefile.original Makefile
# Rögzítsd a változtatásokat a beállítófájlban a későbbi használat érdekében
# Szerkeszd az /usr/src/linux/.config fájlt és állítsd be modulként a szolgáltatást
cd /usr/src/linux
mkdir /usr/src/kernelconfigs ;
cp /usr/src/linux/.config /usr/src/kernelconfigs/.config.save;
cp /usr/src/linux/.config /usr/src/linux/configs/.config.save # Különösen biztonságos
cp /boot/config* /usr/src/linux/configs/ # Különösen biztonságos
vi /usr/src/linux/.config
# és változtasd meg a beállító paramétert. Például az én esetemben
# az ntfs modulnál CONFIG_NTFS_FS=m jelzi, hogy ez modul.
|
Többet is megtudhatsz a Makefile-ról és a make-ről, ha elolvasod a GNU make kézikönyv oldat:
University of Utah Makefile "http://www.math.utah.edu/docs/info/make-stds_toc.html"
University of Hawaii Makefile "http://www.eng.hawaii.edu/Tutor/Make"
A Linuxban - man make
A Linuxban - info make
Ismerkedj meg a modulokat elkészítő Makefile-al. A fájlnak van egy "module" sora, mint:
modules: $(patsubst %, _mod_%, $(SUBDIRS))
|
A patsubst függvény szintaktikája $(patsubst minta,helyettesítés,szöveg). A százalékjelet ([percnt]) ugyanúgy használja, mint a mintaillesztő szabályok - mint egy sztringet, ami illeszkedik a mintában és a helyettesítő szövegben is. Végigkeresi a "szöveg"-et elválasztójellel tagolt szavakért, amik illeszkednek a "mintá"-ra és kicseréli az előfordulásaikat a "helyettesítés"-re.
Ez a Makefile ugyanúgy tartalmaz szabványos shell-függvényeket, mint szabványos make függvényeket. A shell-függvények szintaktikája $(shell parancs). Ez a függvény kimenetét adja vissza (az új sorok kihúzásával).
Lehet, hogy készíteni akarsz egy rendszermagot egy adott rendszeren, majd ezt sok hasonló PC-re is akarod nagyüzemben telepíteni. Az újonnan készített rendszermagnak a gépeik százaira való egyszerűbb telepítése érdekében RPM (RedHat) vagy DEB (Debian) csomag formájában akarod azt elkészíteni, vagy egyszerűen csak tar.gz fájl formájában.
RPM csomagot készíthetsz a rendszermagból az rpmbuild -ba kernel*.spec paranccsal
Ellenőrizd, hogy az elkészült kernel*.rpm minden, a /lib/modules/2.x.x-y könyvtárban lévő fájlt tartalmaz. Egyébiránt össze kell csomagolnod a tar és gzip segítségével ezt a könyvtárat, és átvinni a célgépekre.
Ellenőrizd, hogy a rendszermag-csomag tartalmazza a /boot/initrd-2.x.x-y.img fájlt, különben össze kell csomagolnod a tar és gzip segítségével, és átvinni a célgépekre.
Ezen felül a /boot könyvtár más fájljait is, amik nincsenek a kernel*.rpm csomagban.
A Unix rendszermagja közvetítőként viselkedik a programok és a hardver között. Először is, elvégzi (vagy elrendezi) a memóriakezelést az összes futó program (folyamat) számára, és biztosítja, hogy mindegyik igazságosan (vagy éppen nem annyira igazságosan, ha engeded) osztozzon a processzor ciklusain. Ezen felül egy szép, meglehetősen hordozható felületet biztosít a programok felé, hogy "beszélgethessenek" a hardverrel.
Biztosan van még több minden is, amit el lehet mondani a működéséről, de ezek az alapvető funkciók a legfontosabbak amikről tudni kell.
Az újabb rendszermagok általában több fajta hardver kezelését teszik lehetővé (vagyis több eszközvezérlőjük van), jobb folyamatvezérlésük lehet, gyorsabbak és stabilabbak lehetnek, mint a régi verziók és azok buta kis hibáit kijavíthatják. A legtöbben azért frissítenek, mert új eszközvezérlőket és hibajavításokat akarnak.
Olvasd el a Hardware-HOWTO (Hardver HOGYAN) dokumentumban. Ezen kívül megnézheted a " config.in " fájlt a Linux forráskódjában, vagy egyszerűen keresd ki a " make config " kiadásával. Ez megmutatja az összes, standard rendszermag által támogatott hardvert, de nem az összeset, amit a Linux támogat; sok elterjedt eszközvezérlőt (mint a PCMCIA vezérlők és néhány szalagos meghajtó) betölthető modulként tartanak karban és külön terjesztenek.
Linus ajánl egy adott verziójú gcc-t a README fájlban, ami a Linux forráskód része. Ha nincs meg ez a verzió, az ajánlott verziójú gcc dokumentációja jelzi, ha frissíteni kell a libc programkönyvtárat. Ez nem bonyolult eljárás, de fontos az útmutatások követése.
Ez függ az egyéni rendszer-beállításaidtól. Először is, a tömörített Linux forrás közel 14 MB méretű, legalábbis a 2.2.9 verzió. Sok helyen megtartják ezt is, miután kicsomagolták. Kicsomagolva és egy nem túl bonyolult beállítással, még további 67 MB-ot foglal.
Az újabb gépekkel a fordítás drámaian kevesebb időt igényel, mint a régieken; egy AMD K6-2/300 egy gyors merevlemezzel a 2.2.x rendszermagot elkészíti körülbelül 4 perc alatt. Viszont az öreg Pentiumokkal, 486-osokkal és 386-osokkal, ha úgy tervezed, hogy nekiállsz fordítani, várhatsz akár órákat, napokat...
Ha ez zavar téged, és éppen van egy gyorsabb gép a közelben, amin fordíthatsz, akkor lefordíthatod azon (feltéve, hogy jó adatokat adsz meg, a segédprogramjaid naprakészek stb.), majd átviheted a rendszermagot a lassabb gépre.
A rendszermag lépésenkénti fejlesztésének eszköze a foltozás. Például, ha v1.1.45-ös Linuxod van, és észreveszed, hogy létezik egy " patch46.gz " fájl ehhez, ez azt jelenti, hogy frissítheted az 1.1.46 verzióra a folt alkalmazásával. Először biztonsági másolatot ajánlott készíteni a forrásfáról (" make clean " majd ezután " cd /usr/src; tar zcvf old-tree.tar.gz linux ", ami egy tömörített tar archívumot készít).
Tehát folytatva a fenti példát, tegyük fel, hogy van egy " patch46.gz " fájl az /usr/src könyvtárban. Lépj be cd az /usr/src könyvtárba és add ki a " zcat patch46.gz [verbar] patch -p0 " (vagy " patch -p0 [lt ] patch46 " parancsot , ha a folt nincs tömörítve). Látni fogod, ahogy a feliratok elzúgnak (vagy elcsattognak, ha lassabb géped van), jelezve, hogy megpróbálják a kóddarabokat beilleszteni, és hogy ez sikerült-e vagy sem. Általában ez a folyamat túl gyors ahhoz, hogy elolvashasd és nem lehetsz biztos benne, hogy működött-e, ezért használd a -s kapcsolót a patch programhoz, ami azt jelzi a patch programnak, hogy csak a hibaüzeneteket írja ki (nem fogsz sokat kapni a "hé, a komputerem éppen valami változtatást csinál!" érzésből, de lehet, hogy épp ezt értékeled...) Azon dolgok megtekintéséért, amik nem mentek simán, lépj be az /usr/src/linux könyvtárba és keress .rej kiterjesztésű fájlokat. A patch régebbi verziói (azok a verziók, amiket alsóbbrendű fájlrendszeren fordítottak) a visszadobott dolgokat # kiterjesztéssel látják el. Használhatod a " find " parancsot, hogy keressen helyetted; a "find . -name '*.rej' -print" kiírja a standard kimenetre az összes .rej kiterjesztésű fájlt, ami az aktuális könyvtárban és alkönyvtáraiban van.
Ha minden rendben zajlott, adj ki egy " make clean ", " config ", and " dep " parancssorozatot, a 3. és 4. részben leírtak szerint.
Elég kevés kapcsolója van a patch parancsnak. Ahogy fentebb említettem, a patch -s minden üzenetet elnyom, kivéve a hibaüzeneteket. Ha valahol másutt tartod a rendszermag forrását, nem az /usr/src/linux könyvtárban, a patch -p1 (abban a könyvtárban) rendben megfoltozza a dolgokat. Egyéb patch kapcsolókat a jól dokumentált kézikönyv oldalakban keress.
(Figyelem: ez a rész leginkább a meglehetősen régi rendszermagokra vonatkozik)
A leggyakrabban előforduló probléma az volt, amikor egy folt módosította a " config.in " fájlt és az nem jól nézett ki, mivel megváltoztattad a beállításokat, hogy megfeleljenek a gépednek. Ezt már javították, de még belefuthatsz, ha régi rendszermagot fordítasz. A kijavításához nézd meg a config.in.rej fájlt, hogy mi maradt az eredeti foltból. A változásokat általában " + " és " - " karakterek jelzik a sorok elején. Nézd meg a szomszédos sorokat, és jegyezd meg, hogy " y "-al vagy " n " betűvel vannak jelölve. Most szerkeszd a config.in fájlt, és változtasd meg az " y "-t " n "-re és az " n "-et " y "-ra, amikor szükséges. Adj ki egy "patch -p0 < config.in.rej" parancsot és ha azt jelzi, hogy sikerült, akkor folytathatod a beállítást és fordítást. A config.in.rej fájl ottmarad, de törölhető.
Ha további problémákba ütközöl, akkor használaton kívüli foltot telepítettél. Ha azt mondja, hogy " previously applied patch detected: Assume -R? " (előzőleg már alkalmazott foltot észleltem), akkor valószínűleg olyan foltot próbáltál alkalmazni, ami a jelenlegi verziószám alatti; ha " y "-t válaszolsz, megpróbálja visszaállítani a forrásodat, és nagy valószínűséggel ez nem sikerül; ezért egy teljesen új forrásfára van szükséged (ami nem is olyan rossz ötlet első nekifutásra).
A folt visszavonásához használd a " patch -R " parancsot az eredeti folton.
A legjobb dolog, ha a foltozás tényleg rossz irányba megy, hogy újrakezdesz mindent egy tiszta, még nem használt forrásfával (például az egyik linux-x.y.z.tar.gz fájllal).
Már néhány foltozás után a .orig fájlok elkezdenek szaporodni. Például, egy 1.1.51-es fámat valamikor még az 1.1.48 tájékán takarítottam ki. A .orig fájlok törlésével majdnem fél MB hely szabadult fel. A "find . -name '*.orig' -exec rm -f {} ';' " parancs gondoskodik erről. A patch azon verziói, amik a # karaktert használják a visszautasítások fájlneveiben, a tilde (~) karakterrel jelzik a .orig fájlokat.
Vannak jobb módszerek is a .orig fájloktól történő megszabadulásra, amik függnek a GNU xargs parancstól: "find . -name '*.orig' | xargs rm" vagy az "elég biztonságos de kicsit bőbeszédűbb" módszer: find . -name '*.orig' -print0 | xargs --null rm --
A Linus által terjesztett foltokon kívül léteznek mások is (én "nem szabványos" foltoknak hívom őket). Ha ezeket használod, a Linus-félék lehet, hogy nem működnek megfelelően. Elképzelhető, hogy vissza kell őket vonnod, kijavítani a forrást vagy a foltot magát, telepíteni egy új forrásfát vagy ezek kombinációját kell tenned. Ez nagyon bosszantó lehet, ezért ha nem akarod módosítani a forrást (egy nagyon rossz végeredmény lehetőségét vállalva), forgasd vissza a nem szabványos foltokat, mielőtt a Linus-féléket alkalmazod, vagy telepíts egy új forrásfát. Ezután láthatod, hogy a nem szabványos foltok működnek-e még. Ha nem, akkor vagy maradsz a régi rendszermagnál, játszhatsz a folttal vagy a forrással, hogy működjön, vagy vársz (esetleg rimánkodsz érte) a folt új verziójáig.
Milyen gyakoriak azok a foltok, amik nincsenek a szabvány rendszermagban? Valószínűleg hallottál róluk. Valamikor használtam a "noblink" foltot a virtuális konzoljaimhoz, mert utálom a villogó kurzort. (Ezt a foltot (legalábbis régen) gyakran frissítették az új verziókhoz). Azonban mióta a legtöbb új eszközmeghajtót modulként fejlesztik, a "nem szabványos" foltok kibocsátási üteme jelentősen csökken.
Ha látni szeretnéd a naplókat, amiket a " make " vagy a " patch " parancsok csinálnak, akkor átirányíthatod a kimenetüket egy fájlba. Először nézd meg, milyen shellt használsz: " grep root /etc/passwd " és keress valami ehhez hasonlót: " /bin/csh ".
Ha sh-t vagy bash-t használsz, a (parancs) 2>&1 | tee (kimeneti fájl) utasítássor készít egy másolatot a (parancs) kimenetéről a " (kimeneti fájl) "-ba.
A csh vagy tcsh esetén használd a (parancs) |& tee (kimenti fájl) formát.
Az rc esetén (megjegyzés: valószínűleg nem ezt használod) : (parancs) >[2=1] | tee (kimeneti fájl)
A hajlékonylemezre történő telepítésen kívül még egyéb módszerek is léteznek az új rendszermag kipróbálására anélkül, hogy a régit bántatnánk. Sok egyéb Unix változatól eltérően, a LILO képes a rendszermagot a lemez bármely részéről betölteni (ha nagy méretű (500 MB vagy nagyobb) lemezed van, kérlek olvasd el a LILO dokumentációját, hogy ez mennyiben okozhat problémát). Ezért, ha az "image = /usr/src/linux/arch/i386/boot/bzImage label = new_kernel" sorokat berakod a LILO beállítófájljának végére, akkor választhatod az újonnan fordított rendszermagot is anélkül, hogy a régi /vmlinuz -hoz hozzányúlnál (természetesen miután futtatod a lilo parancsot). A legkönnyebben a betöltés közben a SHIFT lenyomásával lehet jelezni a LILO-nak, hogy az új rendszermagot töltse be (amikor azt látod a képernyőn, hogy LILO , és semmi mást), ami ad egy készenléti jelet. Ennél a pontnál beírhatod: " new_kernel " az új rendszermag indításához.
Ha több különböző rendszermag-forrásfát akarsz tárolni egyszerre a gépen (ez azonban rengeteg lemezterületet fogyaszthat; légy óvatos), a legtöbbször az /usr/src/linux-x.y.z könyvtárba kerülnek, ahol az x.y.z a rendszermag verziója. Ezután "kiválaszthatsz" egy forrásfát egy szimbolikus hivatkozás segítségével; például " ln -sf linux-1.2.2 /usr/src/linux ", ez az 1.2.2-t teszi aktuálissá. Mielőtt egy hasonló szimbolikus hivatkozást készítenél, bizonyosodj meg arról, hogy az ln utolsó paramétere nem egy létező könyvtár (régebbi szimbolikus hivatkozás elfogadható); különben az eredmény nem az lesz, amit várnál.
Russell Nelson ( nelson@crynwr.com ) foglalja össze az új rendszermag kiadásoknál a változásokat. Ezek rövidek, és fejlesztés előtt átnézheted őket. Hozzáférhetők anonymous FTP-vel az "ftp://ftp.emlist.com" webhelyen, a pub/kchanges könyvtárban, vagy a "http://www.crynwr.com/kchanges" webhelyen.
Mostanra lefordítódott az új rendszermagod és jól fut. Szükséged lehet arra a számtalan RPM csomagra, amiket lehet, hogy a közeljövőben telepítened kell majd. Ennek egyik útja, hogy fizikailag felcsatolod a LINUX CD-ROM-jait, de több mint 3 CD-ről van szó, kényelmetlen leválasztani és cserélgetni őket. Itt jön a képbe az FTPFS.
Ha automatizálni szeretnéd az RMP csomagok telepítését, fontold meg az "apt-get" parancs használatát. Az apt-get automatikusan feloldja a függőségeket, letölti és telepíti vagy frissíti a csomagokat. Részletesebben a Telepítés, frissítés fénysebességgel fejezetben olvashatsz erről.
Az FTP fájlrendszer (FTPFS) egy Linux-rendszermag-modul, ami kibővíti a VFS hatókörét arra, hogy FTP köteteket is fel tudjon csatolni. Tehát fel tudsz csatolni FTP-n megosztott könyvtárakat a saját fájlrendszeredbe, és a helyi fájlok kezelésének előnyeit élvezheted. Megtalálható a "http://lufs.sourceforge.net/lufs" és a "http://ftpfs.sourceforge.net" webhelyen.
Töltsd le az ftpfs-t, és telepítsd a rendszeredre. Az ftpfs modulként települ: /lib/modules/2.4.18-19.8.0/kernel/fs/ftpfs/ftpfs.o. Ezen kívül az ftpmount parancs az /usr/bin/ftpmount könyvtárba. Ezután megteheted a következőt:
Jelentkezz be root felhasználóként (su - root) és futtasd ezt a szkriptet:
#!/bin/sh -x
# Hasznald ezt a szkriptet a redhat cdroms rpm-konyvtar (disk1,2,3) felcsatolasahoz
# Built rpm by name ftpfs.
# http://lufs.sourceforge.net/main/projects.html
# ftpmount --help
# Probald ezt: ftpmount [user[:pass]@]host_name[:port][/root_dir] mount_point [-o]
# [-uid=id] [gid=id] [fmask=mask] [dmask=mask]
#ftpmount anonymous:pass@ftp.kernel.org /mnt/ftpfs
#mkdir -p /mnt/ftpfs /mnt/ftpfs/updates /mnt/ftpfs/rpms /mnt/ftpfs/contrib
# Redhat ftp mirror sites - http://www.redhat.com/download/mirror.html
FTPSITE="csociety-ftp.ecn.purdue.edu"
USER="anonymous:pass"
ftpmount $USER@$FTPSITE/pub/redhat/redhat /mnt/ftpfs/site
ftpmount $USER@$FTPSITE/pub/redhat/redhat/linux/updates/8.0/en/os /mnt/ftpfs/updates
ftpmount $USER@$FTPSITE/pub/redhat/redhat/linux/8.0/en/os/i386/RedHat /mnt/ftpfs/rpms
ftpmount $USER@$FTPSITE/pub/redhat-contrib /mnt/ftpfs/contrib
|
Mielőtt egyáltalán elkezdenél az FTP kötetek felcsatolásának gondolatával játszani, győződj meg, hogy elegendő sávszélességed van-e, különben nem lesz nagy élvezet.
Ha elég bölcs voltál, és telepítetted az autofs/automount szolgáltatást (nézd meg a telepítési feljegyzéseket), akkor nagyon fincsi módon használhatod az ftpfs-t: csak próbálj meg hozzáférni a kívánt szerveren bármelyik fájlhoz/könyvtárhoz az /mnt/ftpfs alatt.
cd /mnt/ftpfs/[user:pass@]ftp_server[:port]
|
Valami ilyesmit csinálj: cd /mnt/ftpfs/ftp.kernel.org. És mi történik? Már ott is vagy!
Normál esetben ezt csak anonymous FTP-vel használd, mivel nem akarhatod, hogy a felhasználói név/jelszó információid megjelenjenek az /mnt/ftpfs könyvtárfában.
ftpmount [lsqb ]user[lsqb ]:password]@]hostname[lsqb ]:port ][lsqb ]/root_dir] mount_point [lsqb ]-own] [lsqb ]-uid=id] [lsqb ]-gid=id] [lsqb ]-fmask=mask] [lsqb ]-dmask=mask] [lsqb ]-active]
A paraméterek: [alapértékek]
* user: A felhasználói név, amivel belépsz az FTP szerverre. [anonymous]
* password: A felhasználói jelszó. [user@ftpfs.sourceforge.net]
* hostname: Az FTP szerver.
* port: A port, amin a szerver figyel. [21]
* root_dir: Az FTP szerver felcsatolandó könyvtára. Megadható a bevezető / jel nélkül is (vagyis "home/duru", nem "/home/duru/"). [/]
* mount_point: A helyi könyvtár, amibe az FTP könyvtárat fel akarod csatolni.
* own: Jelzőbit minden távoli fájl tulajdonosi viszonyának jelzésére. Olyan FTP-knél hasznos, amik nem felhasználói neveket, hanem azonosítókat (UID) listáznak ki.
* uid: Annak a helyi felhasználónak az UID-je, akié lesz a felcsatolt könyvtár
* gid: A helyi csoport azonosítója, aki birtokolja a felcsatolt könyvtárat.
* fmask: A numerikus fájlmaszk, ami az összes felcsatolt fájléval VAGY kapcsolatban lesz.
* dmask: A numerikus könyvtármaszk, ami az összes felcsatolt könyvtáréval VAGY kapcsolatban lesz.
* active: Jelzőbit az aktív módú FTP forgalom jelzésére. Hasznos, ha valamilyen tűzfal mögött vagy, és nem tudsz véletlenszerűen kiválasztott portokhoz kapcsolódni.
|
Például: ftpmount mali@ftp.linuxnet.wox.org /mnt/ftpfs -uid=500 -gid=500 -dmask=555
Általában jó ötlet, ha nem adod meg paraméterként a jelszavadat, mivel az ftpmount úgyis kérdezni fogja.
Ha valamilyen okból nem az ftpmount-ot választod (valószínűleg valamilyen rendszermag-foltot telepítettél és lusta vagy az ftpmount-ot is telepíteni), itt egy módszer a jó öreg mount paranccsal:
mount -n -t ftpfs none mount_point -o ip=server_ip [lsqb ],user=user_name] [lsqb ],pass=password] [lsqb ],port=server_port] [lsqb ],root= root_dir] [lsqb ],own] [lsqb ],uid=id] [lsqb ],gid=id] [lsqb ],fmode=mask] [lsqb ],dmode=mask] [lsqb ],active]
Figyeld meg, hogy a szerver IP címét kell megadnod és az egyetlen lehetőség a jelszó megadására, ha egyszerűen beírod a parancssorba. Például, mialatt teszteltem, a következő parancsot használtam:
mount -n -t ftpfs none /mnt/ftpfs -o ip=127.0.0.1,user=mali,pass=my_pass
A kötet leválasztására használható az
umount mount_point
|
Az own opció (-o az ftpmount-nál) ráerőlteti az összes felcsatolt fájlra a felcsatolását végző felhasználó tulajdonosi jogát. Ez hasznos, ha ki akarjuk igazítani néhány szerver különös felhasználó/jogosultság beállítását (SERVU és hasonlók).
Néhány bölcs szó:
Használd a -n felcsatolási kapcsolót! Gondolom, nem akarod a felhasználó/jelszó információidat az mtab-ban viszontlátni.
Ne "tépd ki a falból"! (Kitépni a falból = egy tucat folyamat még olvassa a felcsatolási pont alatti dolgokat)
Egyetlen folyamattal működik a legjobban! Amíg a konkurens hozzáférés (normál körülmények közt) nem okoz semmilyen problémát, a kimenetet egy olvasási folyamatra optimalizálták (a TCP kapcsolat életben marad). Tehát ha mozit akarsz nézni, nem akarhatod, hogy másik folyamat is hozzáférjen a felcsatolási ponthoz és agyonvágja a teljesítményt (bízz bennem!).
Az IP címformátum nem kóser - használd az ftpmount-ot.
A Linux-rendszermagról szóló könyveket találsz a következő helyeken:
A Linux-rendszermag működésének megértéséhez ajánlott elolvasni az /usr/src/linux/Documentation könyvtárban lévő kernel-docs.txt fájlt, amely az interneten megtalálható a "http://www.dit.upm.es/~jmseyas/linux/kernel/hackers-docs.html" honlapon is. Ez számos fontos hivatkozást tartalmaz Linux-rendszermag tankönyvekre és dokumentációkra. El kell látogatni erre a webhelyre.
Kernel book (Rendszermag könyv) a "http://kernelbook.sourceforge.net" és a "http://sourceforge.net/projects/kernelbook" honlapon.
A rendszermagról szóló könyvek, mint a "The Linux Kernel Module Programming Guide", "Linux Kernel 2.4 Internals", "The Linux System Administrators Guide", 'The Linux Network Administrator's Guide" és mások megtalálhatók a "http://www.tldp.org/guides.html" honlapon.
FreeTech könyvek: "http://www.tcfb.com/freetechbooks/booklinuxdev.html"
Rusty-féle doksik: "http://www.netfilter.org/unreliable-guides"
Linux-rendszermag hivatkozások: "http://www.topology.org/soft/lkernel.html"
Linux Kernel Internals: "http://www.moses.uklinux.net/patches/lki.html"
Könyvekre mutató hivatkozások: "http://linux-mm.org/kernel-links.shtml"
A rendszermag készítésének bemutatása: Presentation of Kernel building process NBLUG Linux Seminars - Kernel Building Presentation Talks
Hivatkozások egyéb, a témába vágó HOGYANokra:
Bootdisk-HOWTO (Linux indítólemez HOGYAN)
Sound-HOWTO : hangkártyák és segédprogramjaik
SCSI-HOWTO: minden, amit tudni kell az SCSI vezérlőkről és eszközökről. Olvasd a SCSI-2.4-HOWTO doksiban.
NET-2-HOWTO: hálózatkezelés
PPP-HOWTO: PPP hálózatkezelés általában
PCMCIA-HOWTO: a notebook géped meghajtóiról
ELF-HOWTO: ELF: mi is ez, konvertálás... Tüköroldalak: ELF-HOWTO-mirror . Lásd még: GCC-HOWTO
Hardware-HOWTO: a támogatott hardverek áttekintése
Module mini-HOWTO: még több információ a rendszermag-modulokról
Kerneld mini-HOWTO: a kerneld démonról
BogoMips mini-HOWTO: ( BogoMips mini-HOGYAN: ) ha csak kíváncsi vagy.
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.
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.
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
|
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
|
Részletesen az "A" függelék - initrd.img fájl készítése fejezetben olvashatsz erről.
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).
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
|
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
|
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:
A rendszermag rpm fájlok tartalmazzák (az anaconda-runtime*.rpm építi fel)
Egy hivatkozás a module-info-{kernel-version} fájlhoz
Az összes hozzáférhető modulról tartalmaz információt (legalábbis azokról, amik benne vannak az alapértelmezett rendszermag beállításban).
Fontos az anaconda számára - az anaconda/utils/modlist parancsban.
A kudzu is használhatja, hogy felderítse a modulok alapértelmezett paramétereit, amikor elkészíti a bejegyzéseket az /etc/modules.conf fájlban. Ha használaton kívül helyezed a module-info fájlt, leállítod a gépet, beraksz egy új hálózati kártyát és újraindítasz, a kudzu hangosan reklamálni fog. Nézd meg a kudzu forráskódját.
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
|
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
|
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"
Úgy néz ki, hogy információhiány van a System.map fájlról. Tényleg semmi rendkívüli nincs benne, és a dolgok állása szerint tényleg nem olyan fontos. De az információ hiánya homályossá teszi. Olyan, mint a fülcimpa: mindenkinek van, de senki sem tudja igazán, miért. Ez egy kis weboldal, amit a "miért" leírására hoztam össze.
Megjegyzem, nem vagyok 100%-ig korrekt. Példának okáért lehetséges, hogy egy rendszerben nincs /proc fájlrendszer támogatás, de a legtöbben van. Feltételezem, hogy "úszol az árral" és egy meglehetősen tipikus rendszered van.
A dolgok egy része az Oops-okról az Alessandro Rubini-féle "Linux Device Drivers" (Linux meghajtóprogramok) leírásból származik, amiből a legtöbbet tanultam a rendszermag programozásáról.
Programozási környezetben a szimbólum a program építőeleme: változónév vagy függvénynév. Nem meglepetés, hogy a rendszermagnak is vannak szimbólumai, ugyanúgy, mint az általad írt programoknak. A különbség persze ott van, hogy a rendszermag nagyon bonyolult darab kódolási szempontból, és sok-sok globális szimbóluma van.
A rendszermag nem használ szimbólumneveket. Sokkal jobban szereti tudni a változó vagy függvény nevét azok címei által. Ahelyett, hogy a size_t BytesRead formát használná, előnyben részesíti azt, ha erre a változóra (példának okáért) c0343f20 formában hivatkozhat.
Másrészről, az emberek nem szeretik a c0343f20 kinézetű neveket. Jobban kedveljük azt, hogy size_t BytesRead. Normál esetben ez nem jelent problémát. A rendszermagot főleg C nyelven írták, ezért a fordító/szerkesztő megengedi, hogy szimbólumneveket használjunk kódolás közben, a rendszermagnak pedig engedi, hogy címeket használjon futás közben. Mindenki boldog lehet.
Azonban vannak olyan szituációk, amikor tudnunk kell egy szimbólum címét (vagy egy címhez tartozó szimbólumot). Ez a szimbólumtábla által valósul meg, és nagyon hasonló ahhoz, ahogy a gdb (GNU debugger - a ford.) visszaadja a függvényneveket egy címről (vagy egy címet a függvénynévből). A szimbólumtábla egy lista az összes szimbólumról, a címeikkel együtt. Íme egy példa:
c03441a0 B dmi_broken
c03441a4 B is_sony_vaio_laptop
c03441c0 b dmi_ident
c0344200 b pci_bios_present
c0344204 b pirq_table
c0344208 b pirq_router
c034420c b pirq_router_dev
c0344220 b ascii_buffer
c0344224 b ascii_buf_bytes
|
Látható, hogy a dmi_broken nevű változó a c03441a0 rendszermag-címen van.
Két fájl használatos szimbólumtáblaként:
/proc/ksyms
System.map
Na mármost. Már tudod, mi is a System.map fájl.
Minden alkalommal, ha új rendszermagot fordítasz, a különböző szimbólumnevek címei megváltoznak.
A /proc/ksyms egy "folyamatfájl" és a rendszermag indulásakor menet közben készül el. Valójában ez nem fájl: egyszerűen a rendszermag adatainak megjelenítése, ami azt az illúziót adja, mintha lemezn lévő fájl lenne. Ha nem hiszel nekem, próbáld megállapítani a /proc/ksyms fájl méretét. Ezért mindig az aktuálisan futó rendszermaghoz képest lesz korrekt.
A System.map azonban egy létező fájl a fájlrendszeredben. Amikor új rendszermagot fordítasz, ennek régi verziója rossz szimbólum-információkat tartalmaz. Egy új verzió készül minden egyes új fordításkor, és ki kell cserélned a régit az újjal.
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>]
|
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.
Statikus fordítást, ami használja a System.map fájlt.
A dinamikus fordítást, amit a betölthető modulokkal használnak, nem használja
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.
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:
/boot/System.map
/System.map
/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!
Ne gondold, hogy a System.map csak a rendszermag oops-ok számára hasznos. Bár a rendszermag maga nem igazán használja, más programok, mint a klogd, az lsof,
satan# strace lsof 2>&1 1> /dev/null | grep System
readlink("/proc/22711/fd/4", "/boot/System.map-2.4.18", 4095) = 23
|
és a ps :
satan# strace ps 2>&1 1> /dev/null | grep System
open("/boot/System.map-2.4.18", O_RDONLY|O_NONBLOCK|O_NOCTTY) = 6
|
valamint számos egyéb szoftver is, mint a dosemu igényli a megfelelő System.map-et.
Tegyük fel, hogy több rendszermagod van ugyanazon a gépen. Minden egyes rendszermaghoz más-más System.map-re van szükség! Ha olyan rendszermagot indítasz, amihez nem tartozik System.map, rendszeresen látsz majd olyan üzeneteket, hogy: System.map does not match actual kernel (A System.map nem felel meg az aktuális rendszermagnak). Nem végzetes hiba, de bosszantó lehet mindig ezt látni, ha kiadsz egy "ps ax" parancsot. Néhány program, mint a dosemu, lehet, hogy nem működik megfelelően (bár nem tudok semmi biztosat erről). Végül, a klogd vagy a ksymoops kimenete nem lesz megbízható egy rendszermag oops esetén. Olvasd el a kézikönyv oldalakat, a "man ksymoops" és "man klogd" parancsok kiadása után.
A megoldás, hogy az összes System.map fájlt a /boot-ban tárolod és átnevezed a rendszermag verziószámára. Tegyük fel hogy több rendszermagod van, mint:
/boot/vmlinuz-2.2.14
/boot/vmlinuz-2.2.13
Ezután csak nevezd át a térképfájlokat a rendszermag verziójának megfelelően és rakd őket a /boot könyvtárba:
/boot/System.map-2.2.14
/boot/System.map-2.2.13
|
Mi van, ha két másolatod van ugyanabból a rendszermagból? Mint itt:
/boot/vmlinuz-2.2.14
/boot/vmlinuz-2.2.14.nosound
A legjobb válasz az lehet, ha az összes szoftver a következő fájlokat nézi meg:
/boot/System.map-2.2.14
/boot/System.map-2.2.14.nosound
|
Használhatsz szimbolikus hivatkozásokat is:
System.map-2.2.14
System.map-2.2.14.sound
ln -s System.map-2.2.14.sound System.map # Itt System.map -> System.map-2.2.14.sound
|
Két igazán jó adminisztrációs eszköz létezik Linuxra, ezek a Linuxconf és a Webmin.
Linux rendszer-adminisztrációs eszközök:
A Linuxconf megtalálható a http://www.solucorp.qc.ca/linuxconf webhelyen. A Linuxconf egy különösen nagy projekt. A program félelmetesen jól használható, sok beállítási lehetőség van benne. A Linuxconf a LEGISMERTEBB rendszer-adminisztrációs eszköz Linuxra. Ez az összes disztribúcióban megtalálható, mint a Redhat, Debian, Suse stb. A Linuxconf egyenértékű a HPUX SAM, valamint az AIX SMITTY programjával. Egyaránt fut konzolon és az X-Window GUI felületén. Debian Linux esetén a letöltéshez és telepítéshez elég az "apt-get linuxconf".
A Webmin a legjobban használható és nagyon népszerű rendszer-adminisztrációs eszköz a Linuxhoz. Elég elterjedt és díjazott, mint legjobb rendszer-adminisztriciós eszköz Solaris BSD, Linux, HPUX, AIX, SCO és más rendszerekhez. A Webmin évről-évre szervezetek, konferenciák és szerkesztők által odaítélt díjakat nyert az elmúlt 5 évben. A Webmin más rendszerek alatt is használható mint például AIX, Solaris, HPUX, IRIX, BSD, SCO Unix, OSF, Darwin, Apple Macintosh Mac OS X és Cygwin. Jelenleg a leginkább támogatott rendszerek a Solaris, Linux (különösen a Redhat) és FreeBSD. Perl nyelven írták, ez hordozható akárcsak a "C", de ellentétben azzal szkript-nyelv. A Perl "unokatestvére" a "C" nyelvnek. A legfőbb hátránya, hogy szüksége van az X-Window rendszerre, az Apache webszerver és a Perl telepítése és futtatása után használható a Webmin. Ezt a hézagot tömi be a Linuxconf, nincs szükség az X-Window vagy más program telepítésére a használatához. A Linuxconf akár egy buta karakteres terminálon is futhat az ncurses-al. A Webmin megtalálható a http://www.webmin.com webhelyen. Itt letölthető a Webmin csomag.
Google könyvtár http://directory.google.com/Top/Computers/Software/Operating_Systems/Unix/Administration/
Íme a RedHat adminisztrációs eszközök listája:
# ls /usr/sbin/redhat-con* /usr/sbin/redhat-config-bind /usr/sbin/redhat-config-packages /usr/sbin/redhat-config-bind-gui /usr/sbin/redhat-config-printer /usr/sbin/redhat-config-kickstart /usr/sbin/redhat-config-printer-gui /usr/sbin/redhat-config-network /usr/sbin/redhat-config-printer-tui /usr/sbin/redhat-config-network-cmd /usr/sbin/redhat-config-proc /usr/sbin/redhat-config-network-druid /usr/sbin/redhat-config-services A program indításához - # /usr/sbin/redhat-config-bind & # /usr/sbin/redhat-config-network & Majd próbálkozz más parancsokkal. |
Vizuális valamint Samba segédprogramok és egyebek megtalálhatók a http://www.ibiblio.org/pub/Linux/system/admin/frontends/!INDEX.html és http://www.ibiblio.org/pub/Linux/system/admin/!INDEX.html honlapokon.
Rendszer, hálózati és adminisztrációs segédprogramok találhatók a http://gd.tuwien.ac.at/opsys/linux/applications/text1.html#sysad honlapon.
Képernyő-alapú adminisztrációs segédprogramok a Linux Refresher webhelyről: http://linuxrefresher.com/maintenance/admgui/guiconf.htm
SuSE YAST adminisztrációs segédprogram, Redhat /usr/sbin/redhat-conf* és egyéb segédprogramok: http://freshmeat.net/browse/253/?topic_id=253 http://freshmeat.net/browse/201/?topic_id=201
Linux rendszer-adminisztrációval kapcsolatos felhasználói kézikönyvek:
http://tldp.org/LDP/lame/LAME/linux-admin-made-easy/index.html
Linux rendszer-adminisztrációval kapcsolatos gyakorlatok: http://www.yolinux.com/TUTORIALS/LinuxTutorialSysAdmin.html
Rendszer-adminisztrációs System Administration magazin:
Linux rendszer-adminisztrációs tanfolyamok:
Online India, Pune: http://www.nixcraft.com/services/education/redhat/
On