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 |
Előző | Tartalomjegyzék | Következő |
A rendszermagról szóló könyvek és dokumentumok | Linux rendszer-adminisztrációs eszközök |