bri@cs.uchicago.eduNeked szól ez a dokumentum? Igen, ha illik rád a következők valamelyike:
A példák feltételezik hogy van a gépeden GNU tar, find és xargs. Ezek eléggé szabványosak; ez nem okozhat problémát. Továbbá feltételezem, hogy ismered a géped fájlrendszerének felépítését; ha nem, akkor nagyon fontos, hogy legyen egy másolatod a mount parancs normál működés melletti outputjáról (vagy az /etc/fstab tartalmáról, ha el tudod olvasni). Ez az információ fontos, és csak akkor változik meg, ha újrapartícionálják a merevlemezt, installálnak egy újat, újratelepítik a rendszert, vagy valami hasonló.
Az aktuális ``stabil'' kernel verzió a dokumentum megírásnak idején a 2.2.9 volt, tehát a hivatkozások és példák erre a verzióra vonatkoznak. Bár megpróbáltam annyira verziófüggetlen lenni, amennyire lehetséges, a kernel állandóan fejlesztés alatt áll, így minden újabb verzióban elkerülhetetlenül lesznek bizonyos különbségek. Ez sem okozhat nagy problémákat, legfeljebb kisebb zavart.
A linux kernel forrásnak két változata van: ``stabil'' és ``fejlesztői''. A stabil verziók az 1.0.x -től kezdődtek, és páros számot viselnek. Tehát az 1.2.x, a 2.0.x és a 2.2.x is stabil. Ezeket tartják a legstabilabb, legkevésbé hibás kernelnek a kibocsátás idején. A fejlesztői kernelek (2.1.x, 2.3.x, stb.) tesztelésre valók, és olyanoknak szánják, akik hajlandóak új és esetleg sok hibával teli kerneleket kipróbálni. Ne mond, hogy nem szóltam.
Az a szöveg ami így néz ki, az vagy olyasmi ami megjelenik a képernyőn, vagy amit közvetlenül be kell gépelni, mint például egy parancs, vagy egy parancs opciói, vagy egy fájlnév. (A sima szöveges változatban nem látszik semmi különbség.) A parancsok általában egyszeres idézőjelek (`') jelek között vannak.
A Unix kernel a közvetítő a programok és a hardver között. Menedzseli a memóriát az összes futó program (processz) számára, és biztosítja, hogy mind egyenlően (vagy egyenlőtlenül, ha úgy tetszik) részesüljenek a processzor ciklusaiból. Továbbá egy kényelmes, hordozható felületet nyújt a programoknak, amelyen át kommunikálhatnak a hardverrel.
Ennél persze jóval több szót érdemelne a kernel működése, de ezeket az alapvető funkciókat a legfontosabb ismerni.
Az újabb kernelek általában többféle hardverrel tudnak együttműködni, mint a régebbiek (azaz több eszközmeghajtójuk van). Lehet hogy az új kernelnek jobb a processzkezelése, gyorsabb vagy stabilabb, mint a régi verzió, és már ki van benne javítva az előző ismert hibája. A legtöbben az eszközmeghajtók és a kijavított hibák miatt frissítenek kernelt.
Lásd a Hardware-HOWTO-t. Továbbá megnézheted a `.config' fájlt a linux forrásában, vagy kiderül, ha kiadod a `make config', a `make menuconfig' vagy a `make xconfig' parancsot.
Ez megmutatja az összes hardvert amit a szabványos kernel csomag támogat, de nem mindent, amit a linux támogat. Sok elterjedt eszközmeghajtó (mint például a PCMCIA kártyák és némely szalagos egység meghajtója) betölthető modulként van megírva, amelyeket külön gondoznak és terjesztenek.
Linus ajánl egy gcc verziót a linux forráshoz mellékelt README fájlban. Ha neked nincs meg ez a verzió, a gcc ajánlott verziójának dokumentációja megmondja, hogy kell-e frissíteni a libc-t.
Ez nem egy bonyolult eljarás, de fontos betartani az utasításokat.
Ezek a kernel program olyan részei, amelyek nincsenek közvetlenül beillesztve a kernelbe. Ezeket külön kell lefordítani, és szinte bármikor be lehet illeszteni őket a futó kernelbe, illetve ki lehet venni onnan. A rugalmassága miatt már ez a legelterjedtebb módszer bizonyos kernelszolgáltatások programozására. Sok népszerű eszközmeghajtó, mint például a PCMCIA meghajtók és a QIC-80/40 szalagos egység meghajtója betölthető modulként van megírva.
Ez az adott konfigurációtól függ. Először is a tömörített linux forrás majdnem 14 megabájt a 2.2.9-es verziónál. A legtöbb helyen ezt a kicsomagolás után is megtartják. Kibontva, és egy átlagos konfigurációval lefordítva még 67 MB hely kell neki.
Az újabb gépeken a fordítás sokkal kevesebb időt vesz igénybe, mint a régieken. Egy AMD K6-2/300 egy gyors merevlemezzel körülbelül négy perc alatt végez a 2.2.x kernel fordításával. A régi Pentiumos, 486-os és 386-os gépeken ez órákig, esetleg napokig is eltarthat.
Ha ez gondot okoz, akkor megkérhetsz valakit, akinek gyors gépe van, hogy fordítsa le neked a kernelt (feltéve, hogy jó paramétereket adsz meg, a legfrissebb segédprogramokat használod, stb.), és az új kernelt átmásolod a lassú gépre.
A forrást anonymous ftp-vel lehet beszerezni az ftp.kernel.org-on a /pub/linux/kernel/vx.y könyvtárból, egy tükrözésről, vagy egyéb helyről. Az x.y végződés a verziószám (pl. 2.2), és ahogy az előbb említettem, a páratlan számra végződőek a fejlesztői verziók, amelyek instabilak lehetnek.
Általában linux-x.y.z.tar.gz a neve, ahol x.y.z a verziószám. Ezeken az ftp helyeken gyakran .bz2 kiterjesztéssel is megtalálható a kernel forrása. Ezt a bzip2 programmal tömörítették, ami kisebb fájlokat eredményez, és ezért hamarabb letölthető.
A legjobb az ftp.xx.kernel.org ftp kiszolgálót használni, ahol xx az ország kódja. Például az ftp.hu.kernel.org a magyarországi, az ftp.us.kernel.org az amerikai szerver.
Lépj be `root'-ként (vagy válts át su-val) és menj át (cd-vel) az /usr/src könyvtárba.
Ha a linux telepítésekor a forrást is felraktad (ahogy a legtöbben teszik), akkor már lesz ott egy `linux' nevű könyvtár, ami tartalmazza az egész forrás-hierarchiát.
Ha van elég lemezterületed, és biztosra akarsz menni, akkor tartsd meg ezt a könyvtárat. A legjobb ha kideríted melyik verzió fut éppen, és a könyvtárat annak megfelelően nevezed át. A `uname -r' parancs kiírja az aktuális verziószámot.
Tehát ha az `uname -r' azt válaszolta, hogy `2.0.17', akkor nevezd át a `linux'-ot (`mv'-vel) `linux-2.0.17'-re.
Ha szeretsz kockáztatni, akkor csak töröld ki az egész könyvtárat. A lényeg, hogy ne legyen `linux' nevű könyvtár az /usr/src-ben amikor kibontod a forrást.
Most (még mindig az /usr/src-ben) bontsd ki a forrást a `tar zxpvf linux-x.y.z.tar.gz' paranccsal. (Ha csak egy .tar fájlunk van .gz kiterjesztés nélkül, akkor a `tar xpvf linux-x.y.z.tar' parancsot kell használni.)
Az archívum tartalma el fog száguldani a képernyőn. Amikor vége, lesz egy új `linux' könyvtár az /usr/src-ben. Menj bele és nézd át a README fájlt.
Lesz benne egy `INSTALLING the kernel' című rész.
Hajtsd végre az utasításait, ha szükséges -- például a szimbolikus linkek elkészítése a megfelelő helyre, régi .o fájlok eltávolítása, stb.
Ha .bz2 kiterjesztésű fájlod van, és megvan a bzip2 program (tudnivalók a http://www.muraroa.demon.co.uk/ webhelyen), akkor add ki a
bz2cat linux-x.y.z.tar.bz2 | tar xvf -
parancsot.
Megjegyzés: Az itt következők egy része a Linus-féle README egy hasonló fejezetének megismétlése, részletezése.
Az /usr/src/linux-ból kiadott `make config' parancs elindít egy konfiguráló scriptet, amely sok kérdést tesz fel. A bash kell hozzá, ezért ellenőrizd, hogy létezik-e a /bin/bash, a /bin/sh a /bin/bash-ra mutat-e, vagy a $BASH tartalmazza-e a /bin/bash-t.
A `make config'-nak van néhány könnyebben és kényelmesebben használható alternatívája.
A `make menuconfig' parancsot használják talán a legtöbben. Bármelyiket is választod, nem árt, ha előbb megismerkedsz a felhasználói felületével. Ha nem így teszel, hamarabb meg fogod bánni, mint gondolnád.
Azok akik X alatt dolgoznak, megpróbálhatják a `make xconfig'-ot, ha van Tk installálva. A `make menuconfig' azoknak való, akik jobban szeretnének egy szöveges menüt; (n)curses kell hozzá. Ezeknek a felületeknek van egy határozott előnyük: ha elrontasz valamit a konfigurálás közben, akkor egyszerűen vissza lehet menni kijavítani.
A `make menuconfig' és a `make xconfig' használata esetén a konfigurációs lehetőségek rendezett struktúrában jelennek meg.
A kérdésekre általában igennel (`y' (yes)) vagy nemmel (`n' (no)) kell válaszolni. Az eszközmeghajtóknál általában választhatjuk az `m' lehetőséget is.
Ez azt jelenti ``modul'', azaz a rendszer le fogja fordítani, de nem közvetlenül a kernelbe, hanem betölthető modulként. Sokkal viccesebb úgy magyarázni, hogy ``maybe'' (``talán''). Néhány nyilvánvaló vagy lényegtelen opciót itt nem magyarázok el, néhány egyéb opció rövid leírását lásd az ``Egyéb konfigurációs opciók'' című fejezetben.
A `make menuconfig'-ban a szóközbillentyűvel lehet kiválasztani valamit.
A 2.0.x verziótól kezdve van egy `?' opció is. Ennek hatására az adott paraméter egy rövid leírását kapjuk. Ez a legnaprakészebb információ az adott opcióról. A következőkben felsorolok néhány fontos beállítást, a helyüket az opciók hierarchiájában és egy rövid leírást.
Társprocesszor emuláció. Ha nincs matematikai társprocesszor a gépedben (egy sima 386 vagy 486SX esetén), akkor erre igennel kell válaszolni. Ha van társprocesszor, és mégis igennel válaszolsz, ne aggódj -- a kernel használni fogja a társprocesszort, és figyelmen kívül hagyja az emulációt. Minden többé-kevésbé modern gépre a válasz `nem' legyen, de semmi baj, ha véletlenül igent adtál meg, ha nem kell, nem fogja használni a kernel.
Továbbfejlesztett IDE/MFM/RLL disk/cdrom/szalagos egység támogatás. Erre valószínűleg szükség lesz. Ez azt jelenti, hogy a kernel támogatni fogja a szabványos PC merevlemezeket; a legtöbb gépben ilyen van. Ebbe nem tartoznak bele a SCSI meghajtók, ezek konfigurálására később kerül sor.
Ezután lehet választani az ``old disk-only'' (``csak régi merevlemez'') és a ``new IDE'' (``új IDE'') lehetőségek közül. Az egyiket ki kell választani. A fő különbség az, hogy a régi meghajtó csak két lemezegységet tud kezelni egy csatolón, míg a másik egy második csatolót is tud kezelni, illetve az IDE/ATAPI CD-ROM és szalagos egységeket is. Az új meghajtó 4k-val nagyobb, mint a régi, és feltételezhetően ``fejlettebb'', ami azt jelenti, hogy amellett, hogy több hibajavítást is tartalmaz, megnöveli a lemezek teljesítményét, különösen az újabb (EIDE) hardver esetén.
Hálózati támogatás. Elméletileg erre csak akkor kellene igennel válaszolni, ha géped egy hálózaton van, mint amilyen az Internet, vagy éppen SLIP, PPP, term, stb. segítségével telefonvonalon akarsz hálózatra kapcsolódni. De mivel sok programcsomag (mint például az X Window System) akkor is igényel hálózati támogatást, ha a gép nincs igazi hálózatra kötve, mindenképpen igennel kell válaszolni. Később megkérdezi, hogy akarsz-e TCP/IP támogatást; itt is `y' a válasz, hacsak nem vagy teljesen biztos az ellenkezőjében.
Az IPC (Interprocess Communication = ``processzek közötti kommunikáció'') egyik legjobb definíciója a Perl könyv szómagyarázatában található. Nem meglepő, hogy néhány Perl programozó ennek segítségével küld üzeneteket a processzek között, csakúgy mint sok más programcsomag (pl. a DOOM, hogy a legismertebbet említsem). Ezért nem ajánlatos n-el válaszolni, hacsak nem tudod pontosan mit csinálsz.
(A régebbi kerneleknél használd a -m486 kapcsolót a 486 optimalizációhoz.)
Régebben ez befordított bizonyos optimalizációt az adott processzorhoz; a kernel simán futott más processzorokon is, csak egy kicsit nagyobb volt. Az újabb kernelek esetén ez már nem így van, ezért annak a processzornak a típusát kell beírni, amelyhez a kernel készül. Egy ``386-os'' kernel minden gépen menni fog.
SCSI támogatás. Ha van SCSI eszközöd, válaszolj `y'-t. További kérdéseket fog feltenni CD-ROM támogatásról, a lemezegységek és az SCSI adapter típusáról. Részletesebb információért lásd az SCSI-HOWTO-t.
Hálózati eszköz támogatás. Ha van hálózati kártyád, vagy szeretnél SLIP-pel, PPP-vel vagy a párhuzamos porton át csatlakozni az Internethez, válaszolj igennel. A konfigurációs script megkérdezi a kártya típusát és a használandó protokollt.
Fájlrendszerek. A konfiguráló script ezek után megkérdi, hogy akarod-e használni a következő fájlrendszereket:
Minix - Az újabb disztribúciók nem hoznak létre minix fájlrendszereket, és sokan nem is használják, de ennek ellénére érdemes lehet bekonfigurálni. Néhány ``mentőlemez''-program használja, és sok hajlékony lemezen van minix fájlrendszer, mert hajlékony lemezen sokkal kényelmesebb ezt használni. (Kevesebb helyet foglal maga a fájlrendszer.)
Second extended - Ez a szabványos Linux fájlrendszer. Csaknem biztos, hogy ilyened van, igennel kell válaszolni.
msdos - Ha használni akarod a meglévő MS-DOS partíciókat, vagy DOS alatt formázott hajlékony lemezeket akarsz mountolni, akkor válaszolj igennel.
Egy csomó más operációs rendszer fájlrendszere is kiválasztható.
/proc - (A Bell Labs ötlete volt, azt hiszem.) A proc fájlrendszer nem arra való, hogy létrehozzák a lemezen; ez egy fájlrendszer felület a kernel és a processzek felé. Sok processzlistázó (mint a `ps') használja. Egyszer próbáld ki a `cat /proc/meminfo' vagy a `cat /proc/devices' parancsokat.
Néhány parancsértelmező (különösen az rc) használja a /proc/self/fd-t (más rendszereken /dev/fd néven ismert) I/O műveletekre. Majdnem biztosan igennel kell válaszolnod erre, sok fontos linux segédprogram támaszkodik rá.
NFS - Ha a géped hálózatra van kötve és szeretnél más gépeken lévő fájlrendszereket használni NFS-sel, akkor válaszd ki.
ISO9660 - A legtöbb CD-ROM-on ez található. Ha van CD-ROM meghajtód, és szeretnéd linux alatt használni, válaszd ki.
Jól van, írd be, hogy `mount'. A kimenet valami ilyesmi lesz:
blah# mount
/dev/hda1 on / type ext2 (defaults)
/dev/hda3 on /usr type ext2 (defaults)
none on /proc type proc (defaults)
/dev/fd0 on /mnt type msdos (defaults)
Nézd meg mindegyik sort. A `type' utáni szó a fájlrendszer típusa. Ebben a példában a / és a /usr fájlrendszerek típusa ext2 (second extended). Használok /proc fájlrendszert is, továbbá egy hajlékony lemez be van mountolva msdos fájlrendszerként.
Megpróbálkozhatsz a `cat /proc/filesystems' paranccsal, ha a /proc éppen támogatva van a futó kernelben és be van mountolva; ez ki fogja listázni az aktuális kernel fájlrendszereit.
A ritkán használt, nem létfontosságú fájlrendszerek bekonfigurálása túlméretezett kernelt eredményezhet. A ``modulokról'' szóló fejezetből kiderül, hogy ezt hogy lehet elkerülni. A ``Néhány kelepce'' címűből pedig az, hogy miért nem kívánatos a nagy kernel.
Karakteres eszközök. Itt állíthatók be a (párhuzamos) nyomtató, busz-egér (busmouse), PS/2 egér (sok notebook gép használ PS/2 egér protokollt a beépített trackballhoz), néhány szalagos egység és más hasonló ``karakteres'' eszközökhöz a meghajtók. Nyomj `y'-t a megfelelő helyen.
Megjegyzés: A gpm egy program, amely lehetővé teszi az egér használatát az X ablakozó rendszeren kívül is, virtuális konzolok közötti másolásra. Ha soros egered van, elég kellemes, mert jól megfér az X-el, de ha másmilyen, akkor trükközni kell.
Hang. Ha nagyon vágysz arra, hogy halljad a biff-et ugatni, nyomj `y'-t, és a konfigurációs program részletesen ki fog kérdezni a hangkártyádról. (Megjegyzés a hangkártya konfigurálásához: amikor megkérdezi, hogy a meghajtó teljes verzióját telepítse-e, válaszolhatsz nemmel. Ha csak azokat az opciókat választod ki, amelyekre tényleg szükséged van, megspórolhatsz egy kis kernel-memóriát.
Ha fontos neked a hangkártyád támogatottsága, nézd meg az ingyenes eszközmeghajtókat a http://www.linux.org.uk/OSS/ webhelyen, illetve a fizetős Open Sound System meghajtóit a http://www.opensound.com/ webhelyen.
Nincs az összes konfigurációs opció felsorolva itt, egyrészt mert túl gyorsan változnak, másrészt mert magától értetődőek. (Például a ``3Com 3C509 support'' az említett ethernet kártyához való támogatást jelenti.) Axel Boldt (boldt@math.ucsb.edu) összeállított egy meglehetősen széleskörű listát az összes opcióról (és egy módszert, amivel be lehet tenni őket a Configure scriptbe). Ez az online segítség, ami bele van integrálva a forrásba a 2.0.x feletti kernelekben (Documentation/Configure.help).
Linus írja a README-ben: A ``kernel hacking'' konfigurációs részletek általában nagyobb vagy lassabb (vagy mindkettő) kernelt eredményeznek, sőt akár kevésbé stabilabbá is tehetik a kernelt azáltal, hogy bekonfigurálnak néhány rutint, amelyek megpróbálják aktívan feltörni a hibás programrészleteket, hogy így találjanak problémákat. Ezért inkább `n'-t kell válaszolni az erre vonatkozó kérdésekre egy ``stabil'' kernel esetén.
A konfigurálás befejezése után egy üzenet tudatja, hogy a kernel konfigurálása megtörtént és felszólít, hogy ``check the top-level Makefile for additional configuration'', stb. (``További konfiguráláshoz ellenőrizd a felsőszintű Makefile-t'')
Nézz bele tehát a Makefile-ba. Valószínűleg nem kell megváltoztatni semmit, de megnézni sosem árthat. Az opciókat megváltoztathatod akkor is, amikor az új kernel már a helyén van, az `rdev' paranccsal. Ha egy kukkot sem értesz abból, mit a fájlban látsz, akkor hagyhatod nyugodtan.
Amikor a konfiguráló script véget ér, azt is mondja, hogy add ki a `make dep' és a `make clean' parancsokat. A `make dep' ellenőrzi, hogy az összes függőség, mint például az include fájlok, a helyükön vannak-e. Nem tart sokáig, hacsak a géped nem nagyon lassú. Egy `make clean'-t is csinálni kell. Ez letörli az összes object fájlt és néhány egyéb dolgot, amit a régi verzió hátrahagy. Mindenesetre ne felejtsd el ezt a lépést, mielőtt megpróbálod újrafordítani a kernelt.
A 'make dep` és a 'make clean` után jöhet a `make bzImage' vagy a `make bzdisk'. (Ez az a rész, ami sokáig tart.)
A `make bzImage' lefordítja a kernelt, és többek között egy `bzImage' nevű fájlt hagy maga után az arch/i386/boot könyvtárban. Ez az új tömörített kernel. A `make bzdisk' ugyanezt teszi, de az új bzImage-t rámásolja egy hajlékony lemezre, amelyet addigra remélhetőleg már betettél az ``A:'' meghajtóba.
A `bzdisk' nagyon kényelmes az új kernelek teszteléséhez. Ha lefagy (vagy egyszerűen csak nem működik jól), akkor csak kiveszed a lemezt, és bootolhatsz a régi kernellel. Akkor is jól jön, ha véletlenül letörlöd a kernelt (vagy valami hasonló szörnyűség történik). Új rendszerek telepítésére is lehet használni; az egyik lemez tartalmát egyszerűen átmásolod a másikra.
Minden valamirevaló újabb kernel tömörítve van, ezért van `bz' a nevük előtt. A tömörített kernel automatikusan kicsomagolja magát, amikor végrehajtódik.
A régebbi kerneleknél még nem volt lehetőség bzImage létrehozására, akkor még csak zImage volt. Ez a lehetőség még ma is megvan, de tekintve az újabb kernelek méretét, többé kevésbé kötelező bzImage-et fordítani, mert a régebbi módszerekkel nem lehet kezelni a túl nagy kerneleket.
A `make mrproper' alaposabb törlést végez.
Néha szükség van rá; ajánlatos minden foltozás alkalmával végrehajtani. A `make mrproper' a konfigurációs fájlt (.config) is letörli, ezért csinálj róla biztonsági másolatot, ha úgy gondolod, hogy még kellhet.
A `make oldconfig' megpróbálja egy régi konfigurációs fájl alapján konfigurálni a kernelt; elvégzi helyetted a `make config' lépést. Ha még sosem fordítottál kernelt, vagy nincs régi konfigurációs fájl kéznél, akkor ne tedd, mert minden bizonnyal meg kell változtatni az alapértelmezett konfigurációt.
A `make modules' leírása a modulokról szóló fejezetben található.
Ha kész van a kernel és az úgy is működik, ahogy szeretnéd, itt az ideje installálni. A legtöbben a LILO-t (Linux Loader) használják erre célra. A `make bzlilo' installálja a kernelt, lefuttatja rajta a LILO-t, és bootolásra kész állapotba hozza, DE CSAK AKKOR, ha a LILO a következőképpen van konfigurálva: a kernel /vmlinuz, a LILO az /sbin-ben van, és a LILO konfigurációs fájl (/etc/lilo.conf) tartalma is ennek megfelelő.
Ellenkező esetben közvetlenül kell a LILO-t használni. Eléggé könnyű installálni és használni, de a konfigurációs fájl hajlamos összezavarni az embereket. Nézd meg a konfigurációs fájlban (a régebbi verzióknál /etc/lilo/config, az újaknál /etc/lilo.conf), hogy mi az aktuális beállítás. A konfigurációs fájl így néz ki:
...
image = /vmlinuz
label = Linux
root = /dev/hda1
...
Az `image =' az aktuális kernelre mutat. A legtöbben /vmlinuz-t használnak. A `label' alapján dönti el a lilo, hogy melyik kernelt, vagy operációs rendszert indítsa el, és a `root' az adott operációs rendszert gyökérkönyvtára. Készíts biztonsági másolatot a régi kernelről és másold a frissen fordított bzImage-et a helyére. (Például, ha `/vmlinuz'-t használsz, azt mondod, hogy `cp bzImage /vmlinuz'.) Ezután futtasd a lilo-t -- az újabb rendszereken elég annyi, hogy `lilo', de régebbieken lehet, hogy `/etc/lilo/install' , vagy akár `/etc/lilo/lilo -C /etc/lilo/config' kell.
Ha szeretnél többet tudni a LILO konfigurálásáról, vagy nincs is meg neked, akkor szerezd meg a legújabb verziót a kedvenc ftp helyedről, és kövesd az utasításokat.
Ha szeretnél egy régi kernelt bootolni a merevlemezről (így is megmenekülhetsz, ha az újat elrontottad), másold le a lilo konfigurációs fájlban az `image = xxx' sort és az utánna következő sorokat a fájl aljára, és változtasd meg az `image = xxx' sort `image = yyy'-ra, ahol `yyy' annak a fájlnak a teljes elérési útvonala, amelybe a régi kernelt mentetted. Azután változtasd meg a `label = zzz' sort `label = linux-backup'-ra és futtasd a lilo-t. Lehet, hogy be kell tenni egy `delay=x' sort is a konfigurációs fájlba, ahol x az az idő tizedmásodpercben megadva, amennyit a lilo vár, mielőtt bootolna. Így meg lehet szakítani (például a shift billentyűvel), és be lehet írni a régi kernel címkéjét, ha valami kellemetlen történik az újjal.
A kernel inkrementális frissítéseit foltok (patch) formájában terjesztik. Például, ha neked a 2.2.9 verzió van meg, és észreveszed, hogy van hozzá valahol egy patch-2.2.10, akkor ez azt jelenti, frissíthetsz a 2.2.10 verzióra foltozással. Először talán készíts egy biztonsági másolatot a forrásról. (A `make clean' aztán a `cd /usr/src; tar zcvf old-tree.tar.gz linux' csinál neked egy tömörített tar archívumot.)
A fenti példát folytatva, tegyük fel, hogy a `patch-2.2.10.gz' az /usr/src könyvtárban van. Menj át (cd-vel) az /usr/src-be, és add ki a `zcat patch-2.2.10.gz | patch -p0' parancsot, (vagy a `patch -p0 < patch-2.2.10' parancsot, ha a folt nincs tömörítve). Egy csomó minden fog elsuhanni előtted a képernyőn (vagy épp elvánszorogni, ha annyira lassú a gép). Üzenetek jelennek meg arról, hogy a patch éppen mit csinál, és hogy sikerült-e neki vagy nem. Ez általában túl gyors ahhoz, hogy bármit is el lehessen olvasni. Ha nem vagy biztos benne, hogy sikerült-e, használd a patch -s kapcsolóját, aminek hatására csak a hibaüzeneteket írja ki. Ekkor nem lesz meg ``hejj, de szorgosan dolgozik a számítógépem'' érzésed, de talán így jobban kedveled... Menj be a /usr/src/linux-ba és keress .rej (``reject'') kiterjesztésű fájlokat, ezekből kiderül, ha valami nem ment simán. A patch néhány verziója (olyan régebbi verziók, amelyeket gyengébb fájlrendszerhez fordítottak) # kiterjesztést ad a ``reject'' fájloknak. A `find' parancsot használhatod a keresésre:
find . -name '*.rej' -print
Ez kiírja a standard outputra az összes olyan fájl nevét, amely az aktuális könyvtárban, vagy az abból nyíló alkönyvtárakban van és .rej a kiterjesztése.
Ha minden simán ment, add ki a `make clean', `config' és `dep' parancsokat a 3. és 4. fejezetben leírtaknak megfelelően.
A patch parancsnak elég sok opciója van. Ahogy az előbb is szó volt róla, a patch -s kikapcsolja az üzeneteket, a hibák kivételével. Ha a kernel forrását nem az /usr/src/linux-ban tartod, hanem valahol másutt, akkor a patch -p1 (az adott könyvtárban) fogja a foltozást helyesen végrehajtani. A többi patch opció jól le van írva a kézikönyvoldalon.
(Megjegyzés: ez a fejezet főként nagyon régi kernelekre vonatkozik.)
A leggyakrabban felmerülő probléma régebben az volt, hogy a patch módosított egy `config.in' nevű fájlt, és nem sikerült, mert a felhasználó megváltoztatta az opciókat, hogy illeszkedjen a gépéhez. Ezt azóta megoldották, de még lehet vele találkozni egy régebbi kibocsátás esetében.
A következőképpen lehet megjavítani: nézz bele a config.in.rej fájlba, és keresd meg, mi maradt az eredeti foltból. A változásokat általában sor eleji `+' and `-' jelek jelzik. Nézd meg a körülötte lévő sorokat, és jegyezd meg, hogy az állásuk `y' vagy `n'. Utána szerkeszd át a config.in-t, és változtasd meg a `y'-t `n'-re és az `n'-t `y'-ra a megfelelő helyeken. Adj ki egy
patch -p0 < config.in.rej
parancsot, és ha sikerül (nincs hibaüzenet), akkor lehet folytatni a konfigurálással és a fordítással. A config.in.rej fájl megmarad, de le lehet törölni.
Ha további problémák bukkannak elő, akkor lehet, hogy rossz sorrendben alkalmaztad a foltokat. Ha azt mondja, hogy `previously applied patch detected: Assume -R?', akkor lehet, hogy az aktuális verzió előtti foltot próbálsz felrakni. Ha `y'-t válaszolsz, akkor megpróbálja lerontani a forrást, és nagy valószínűséggel kudarcot vall. Így aztán szerezni kell egy teljes vadonatúj forrást. (Lehet, hogy mindjárt ezzel kellett volna kezdeni.)
Egy foltozást visszacsinálni a `patch -R' parancsal lehet.
Ha a foltok tényleg nem működnek, akkor legjobban teszed, ha beszerzel egy érintetlen forrást (például egy linux-x.y.z.tar.gz fájlt), és elkezded elölről.
Már néhány foltozás után az .orig fájlok kezdenek felhalmozódni. Például egyszer volt egy 1.1.51 forrásom, ami az 1.1.48. óta nem volt megtisztogatva. Az .orig fájlok letörlése több mint fél megát szabadított fel.
A
find . -name '*.orig' -exec rm -f {} ';'
parancs elintézi a dolgot. A patch azon verziói, amelyek #-el jelölik a ``reject'' fájlokat, tildét használnak az .orig kiterjesztés helyett.
Van egy jobb módja is az .orig fájloktól való megszabadulásnak, amihez kell a GNU xargs:
find . -name '*.orig' | xargs rm
vagy a ``hosszú de biztos'' módszer:
find . -name '*.orig' -print0 | xargs --null rm --
Linus Torvalds által terjesztett foltokon kívül vannak másmilyenek is, (nevezzük őket ``nem szabványos''-nak). Ha ezeket felrakod, akkor lehet, hogy a Linus féle foltok nem fognak jól működni, és akkor vagy visszacsinálod őket, és megjavítod a forrást vagy a foltot, vagy felraksz egy új forrást, vagy a fentiek valamilyen kombinációja. Ez nagyon idegesítő lehet, tehát ha nem akarod módosítani a forrást (kockáztatva egy nagyon rossz végkimenetelt), csináld vissza a nem szabványos foltokat mielőtt felrakod Linuséit, vagy rakj fel egy új forrást. Így ellenőrizheted, hogy a nem szabványos foltok működnek-e még. Ha nem, akkor vagy be kell érned egy régi kernellel, vagy addig bütykölöd vagy a forrást vagy a foltot amíg nem működik, vagy vársz (esetleg könyörögsz), hogy kijöjjön a folt egy új verziója.
Mennyire elterjedtek a nem szabványos foltok? Valószínűleg fogsz róluk hallani. Régebben használtam a ``noblink'' foltot a virtuális konzolokon, mert utálom a villogó kurzort. (Ezt gyakran frissítik -- vagy legalábbis frissítették -- a kernel új verzióihoz.) De mivel a legtöbb új eszközmeghajtót betölthető modulnak fejlesztik, a nem szabványos foltok gyakorisága jelentősen csökken.
A linux kernelnek sok olyan szolgáltatása van, amelyet nem említenek meg magában a forrásban. Ezeket a szolgáltatásokat általában külső programcsomagokon keresztül használják. A leggyakoribbakból néhány:
A linux konzolnak talán több szolgáltatása van, mint amennyit megérdemel. Többek között betűkészletet tud váltani, átállítja a billentyűzetet, átváltja a video módot (az újabb kerneleknél), stb. A kbd csomagban olyan programok vannak, amelyekkel a felhasználó végezheti el mindezeket, plusz sok betűkészlet és beállítások szinte minden billentyűzethez. Ugyanazokról a helyekről lehet beszerezni, mint a kernel forrást.
Rik Faith (faith@cs.unc.edu) összeállított egy linux segédprogramokból álló nagy gyűjteményt, amit valami különös véletlen folytán ``util-linux''-nak hívnak. Ennek karbantartója azóta Andries Brouwer (util-linux@math.uio.no).
Megszerezhető anonymous ftp-vel a sunsite.unc.edu-ról a /pub/Linux/system/misc könyvtárból. Tartalmazza többek között a setterm, rdev és ctrlaltdel programokat, a kernellel kapcsolatosak közül. Ahogy Rik mondja, ne rakd fel ész nélkül. Nem kell mindent installálni, ami a csomagban van, és könnyen okozhat komoly problémákat, ha megteszed.
Mint sok csomag, ez is egy kernel folt és hozzávaló segédprogramok gyűjteménye volt valaha. A folt bekerült a hivatalos kernelbe, a programokat, amelyekkel optimalizálni és bütykölni lehet a merevlemezt, külön terjesztik.
A gpm annyit tesz, mint ``general purpose mouse'' (``általános célú egér''). Ezzel a programmal szöveget lehet másolni (``cut and paste'') az egyik virtuális konzolról a másikra, és még sok minden mást lehet csinálni, sokféle egértípussal.
Ha az új kernel egy rutinszerű kernelfrissítés után elkezd nagyon vad dolgokat művelni, akkor könnyen lehet, hogy elfeljtetted kiadni a make clean parancsot az új kernel lefordítása előtt. A tünetek változatosak lehetnek: egyszerűen összeomlik, furcsa I/O problémák jönnek elő, vagy csak nagyon lassú lesz. Ne felejtsd el a make dep-et se.
Ha a kernel sok memóriát foglal el, túl nagy, és/vagy egy örökkévalóságig tart lefordítani akkor is, ha a vadonatúj Quadbazillium-III/4400 gépeddel esel neki, akkor valószínűleg túl sok fölösleges dolog (eszközmeghajtók, fájlrendszerek, stb.) van belekonfigurálva. Ha nem használod, akkor ne is konfiguráld be, mert foglalja a memóriát. A túl nagy kernel legszembetűnőbb tünete a memória és diszk közötti túlzott swappolás. Ha a merevlemez sokat zörög, és nem egy régi Fujitsu Eagles, ami kikapcsoláskor olyan hangot ad, mint egy sugárhajtású repülőgép leszálás közben, akkor nézd át a kernel konfigurálást.
Megtudhatod, hogy mennyi memóriát használ a kernel, ha fogod a gépedben levő összes memória mennyiségét és kivonod belőle a ``total mem'' mező értékét a /proc/meminfo-ból, vagy a `free' outputjából.
PC-n úgy lehet beállítani a párhuzamos portot, hogy a kernel konfigurálásánál kiválasztjuk a `Parallel port support'-ot és a `PC-style hardware'-t a `General Setup' csoportban, és a `Parallel printer support'-ot a `Character devices' csoportban.
A másik dolog az elnevezés. A Linux 2.2 másképp nevezi el a nyomtatókat, mit az előző verziók. A következmény az, hogy ha a régi kernel alatt lp1 volt a nyomtató neve, akkor azt most lp0-nak hívják az új alatt.
Add ki a `dmesg' parancsot, vagy nézd meg a logfájlokat a /var/log könyvtárban.
Ha nem fordul le, akkor valószínűleg nem sikerült egy patch, vagy a forrás valahogy megsérült. Lehet, hogy nem jó a gcc adott verziója, vagy az is lehet sérült (például az include fájlok lehetnek hibásak). Ellenőrizd, hogy a szimbolikus linkek, amelyeket Linus említ a README-ben jól vannak-e beállítva. Általában elmondható, hogy ha a szabványos kernel nem fordul le, akkor valami komoly baj van a rendszerrel, és valószínűleg újra kell installálni bizonyos programokat.
Ritka esetekben előfordul, hogy a gcc hardver okok miatt száll el. A hibaüzenet valami olyasmi lesz, hogy ``xxx exited with signal 11'' és általában nagyon rejtélyesen néz ki. Talán nem is említeném, ha nem történt volna meg velem is egyszer. A cache memória hibás volt, és a gcc időnként véletlenszerűen elszállt. Először próbáld meg újrainstallálni a gcc-t, ha ilyen gond merül fel. Csak akkor kell gyanakodni, ha a kernel hiba nélkül lefordul kikapcsolt külső cache, kevesebb RAM, stb. mellett.
Az embereket általában nyugtalanítja, ha felvetődik, hogy a hardverük hibás lehet. Nos, nem én találtam ki. Itt van hozzá egy FAQ: http://www.bitwizard.nl/sig11/.
Nem futtattad a LILO-t, vagy rosszul van konfigurálva. Egyszer az ``fogott'' meg, hogy hiba volt a konfig fájlban. `boot = /dev/hda' sor helyett `boot =/dev/hda1' volt benne. (Ez elsőre nagyon idegesítő lehet, de ha már van egy működő konfig fájl, nem kell hozzányúlni.)
Hoppá! A legjobb amit ilyen helyzetben tehetsz az, hogy hajlékony lemezről bootolsz, és csinálsz egy másik bootolható lemezt (ahogy a `make bzdisk' is csinálná).
Tudnod kell, hogy hol van a root (/) fájlrendszer és az milyen típusú (pl. second extended, minix). Az alábbi példában azt is tudni kell, hogy melyik fájlrendszeren van a linux forrás /usr/src/linux, annak a típusa, és hogy rendszerint hova van mountolva.
A következő példában a root a /dev/hda1, az /usr/src/linux a /dev/hda3 eszközön van, normálisan az /usr-re mountolva. Mindkettő ext2 fájlrendszer. A működő kernel az /usr/src/linux/arch/i386/boot-na van, és a neve bzImage.
Az alapötlet az, hogy ha van egy működőképes bzImage, akkor lehet azt használni az új hajlékony lemezen. Egy másik módszerről, ami vagy jobban műkődik, vagy nem (attól függően, hogy pontosan hogyan rontottad el a rendszert) a példa után lesz szó.
Először bootolj egy boot/root lemezpárosról vagy mentőlemezről, és mountold föl azt a fájlrendszert, ami a működő kernelt tartalmazza.
mkdir /mnt
mount -t ext2 /dev/hda3 /mnt
Ha az mkdir azt mondja, hogy a könyvtár már létezik, ne törődj vele. Menj be abba a könyvtárba, amelyben a működő kernel volt. Ne feledd, hogy
/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/boot
Helyezz egy formattált lemezt az ``A:'' meghajtóba (ne a boot vagy root lemezt!), másold a kernelt a lemezre, és konfiguráld a root fájlrendszernek megfelelően:
cd /mnt/src/linux/arch/i386/boot
dd if=bzImage of=/dev/fd0
rdev /dev/fd0 /dev/hda1
Menj a root könyvtárba és csatold le a normálisan /usr fájlrendszert.
cd /
umount /mnt
Ezek után a megszokott módon lehet bootolni erről a lemezről. Ne felejtsd el futtatni a LILO-t (vagy amit rosszul csináltál) az újrabootolás után.
Ahogy az előbb említettem, van egy másik lehetőség. Ha van egy működő kernel a gyökérkönyvtárban (például /vmlinuz), akkor azt is lehet használni egy bootlemezen. Feltéve, hogy minden változatlan, /vmlinuz a kernel, a következő változtatásokat kell eszközölni a fenti példán: legyen /dev/hda3 helyett /dev/hda1 (a root fájlrendszer) az /mnt/src/linux-ot mountold az /mnt-re, és az if=bzImage paramétert írd át if=vmlinuz-ra. A megjegyzést a /mnt/src/linux levezetéséről figyelmen kívül lehet hagyni.
A LILO használata nagy merevlemezekkel (több, mint 1024 cilinder) gondot okozhat. Lásd a LILO mini-HOWTO-t vagy a dokumentációt segítségért.
Ez súlyos probléma lehet. Az 1.0 kernel verzió kibocsátása után (1994. április 20. táján) felfrissítették/lecserélték az `update' nevű programot, amely rendszeresen kiüríti a fájlrendszer puffereit. Szerezd meg a `bdflush' forrását (meg kell lennie ugyanott, ahol a kernel forrásnak), és installáld fel. (Ezt még a régi kernelt futtatva ajánlatos megtenni.) A program `update' néven installálja magát. Az újrabootolás után a kernel nem fog többet panaszkodni.
Különös módon sokan nem tudják használni az ATAPI meghajtókat, talán mert több oka lehet a hibának.
Ha a CD-ROM meghajtó az egyetlen eszköz egy adott IDE csatolón, akkor a jumpereknek ``master'' vagy ``single'' állásban kell lenniük. Valószínűleg ez a leggyakoribb hiba.
A Creative Labs (és mások is) IDE csatolókat építenek a hangkártyákra. Ebből következik az az érdekes probléma, hogy egyes gépeken csak egy csatoló van, másokon kettő beépítve az alaplapra (általában IRQ15), ezért a soundblaster csatolót a harmadik IDE portra teszik (IRQ11, állítólag).
Ez problémákat okoz a linuxszal, mivel az 1.2.x kernelek nem támogatják a harmadik csatolót (az 1.3.x valamelyik tagjától kezdve már van, de az fejlesztői, és nem detektálja automatikusan). Ezt többféleképpen lehet kikerülni.
Ha már van második IDE port, könnyen lehet, hogy nem is használod, vagy még nincs rajta két eszköz. Vedd le az ATAPI meghajtót a hangkártyáról, és rakd a második csatolóra. Ezután ki lehet kapcsolni a hangkártya csatolóját és még egy IRQ-t is megspórolsz.
Ha nincs második IDE csatoló, akkor jumpereld a hangkártya IDE csatolóját (ne a hangkártya hang részét) az IRQ15-re (második IDE csatoló). Ennek működnie kell.
Szerezd be a route program, és minden más útvonalválasztást manipuláló program egy új verzióját. Az /usr/include/linux/route.h (ami valójában az /usr/src/linux-ban van) megváltozott.
Frissíts legalább az 1.2.1 verzióra.
Tömörítetlen kernel fájl. Ne a /usr/src/linux könyvtárban keletkező vmlinux fájlt használd kernelnek. Az [..]/arch/i386/boot/bzImage a jó..
Az /etc/termcap fálban a konzol termcap bejegyzésben írd át a dumb szót linux-ra. Lehet, hogy egy terminfo bejegyzést is kell csinálni.
A linux kernel forrás tartalmaz számos include fájlt (a .h) végű fájlnevek) amelyekre a szabványos include fájlok hivatkoznak az /usr/include könyvtárban. A hivatkozások általában így néznek ki (ahol xyzzy.h egy fájl az /usr/include/linux-ban):
#include <linux/xyzzy.h>
Normális esetben van egy linux nevű link az /usr/include-ban, amely a kernel forrás include/linux könyvtárára mutat (általában /usr/src/linux/include/linux). Ha ez a link nincs a helyén, vagy rossz helyre mutat, akkor a legtöbb programot egyáltalán nem lehet lefordítani. Ha letörölted a kernel forrást, mert túl sok helyet foglalt, akkor nyilvánvaló, hogy ez a gond. Lehet baj a hozzáférési jogosultságokkal is. Ha a root umask-ja alapértelmezés szerint nem engedi meg, hogy a többi felhasználó lássa a fájljait, és a kernel forrást a p (preserve filemodes = fájljogosultságok megőrzése) opció nélkül csomagoltad ki, akkor a felhasználók a C fordítót sem fogják tudni használni. Bár a chmod paranccsal is meg lehet ezt oldani, könnyebb újra kicsomagolni az include fájlokat. Ezt ugyanúgy kell csinálni, ahogy az elején kicsomagoltuk az egész forrást, csak még egy paraméter kell használni:
blah# tar zxvpf linux.x.y.z.tar.gz linux/include
Megjegyzés: A ``make config'' létrehozza az /usr/src/linux linket, ha nincs meg.
A következő néhány példa hasznos lehet azoknak, akik szeretnék tudni, hogyan lehet bizonyos, a kernel szabta korlátokat megemelni.
echo 4096 > /proc/sys/kernel/file-max
echo 12288 > /proc/sys/kernel/inode-max
echo 300 400 500 > /proc/sys/vm/freepages
A 2.0.x és a 2.2.x kernelverziók elég sok változást hoztak a kernel installálásában. A forrásban található Documentation/Changes fájl tartalmazza az ezekre a verziókra való átálláshoz szükséges tudnivalókat. Valószínűleg frissíteni kell több fontos programcsomagot, mint például a gcc, libc, és a SysVInit, és lehet, hogy meg kell változtatni néhány rendszerfájlt is. Ezekre készülj fel. De semmi pánik!
A betölthető kernel modulok memóriát takaríthatnak meg és megkönnyíthetik a konfigurálást. A modulok köre egyre bővül, magában foglal többek között fájlrendszereket, ethernet-kártya meghajtókat, szalagos egység és nyomtató meghajtókat.
A modulok használatához szükséges segédprogramokat ugyanonnan lehet megszerezni, ahonnan a kernel forrást is, modutils-x.y.z.tar.gz néven. Válaszd a legnagyobb x.y.z verziószámot, ami még kisebb-egyenlő a kerneled verziószámánál. Csomagold ki a `tar zxvf modutils-x.y.z.tar.gz' paranccsal, menj be a könyvtárba, amit létrehoz (modutils-x.y.z), nézd át a README fájlt és hajtsd végre az installálási utasításokat (ami általában elég egyszerű, például make install). Ezután kell hogy legyenek insmod, rmmod, ksyms, lsmod, genksyms, modprobe és depmod nevű programok az /sbin könyvtárban. Ha akarod, kipróbálhatod őket az insmod-ban található ``hw'' példameghajtóval. Ebben az alkönyvtárban, az INSTALL fájlban olvashatóak a részletek.
Az insmod beilleszt egy modult a futó kernelbe. A moduloknak általában .o kiterjesztésük van. A fent említett példában a meghajtó neve drv_hello.o, ezt a `insmod drv_hello.o' paranccsal lehet beilleszteni. Az lsmod kilistázza az éppen használt modulokat. Az output így néz ki:
blah# lsmod
Module: #pages: Used by:
drv_hello 1
A `drv_hello' a modul neve, egy lap (``page'', 4k) memóriát használ, és egyetlen másik kernel modul sem támaszkodik rá pillanatnyilag. Az `rmmod drv_hello' távolítja el a modult. Figyeljük meg, hogy az rmmod egy modulnevet vár, nem egy fájlnevet. Az előbbit az lsmod listájából lehet megtudni. A többi modul segédprogram is dokumentálva van a kézikönyvoldalakon.
A 2.0.30 verziótól kezdve majdnem minden elérhető modul formában is. Használatuk a következő: ne konfiguráld bele a kernelbe, azaz ne mondj rá `y'-t a `make config' alatt.
Fordíts egy új kernelt és bootolj vele újra. Menj be megint az /usr/src/linux-ba és add ki a `make modules' parancsot. Ez lefordítja az összes olyan modult, amely nem szerepelt a kernel konfigurációban és linkeket helyez el rájuk az /usr/src/linux/modules könyvtárban. Lehet őket közvetlenül innen is használni, vagy kiadhatod a `make modules_install' parancsot, ami elhelyezi őket a /lib/modules/x.y.z könyvtárban, ahol x.y.z a kernel verziója.
Ez különösen a fájlrendszerek esetén lehet kényelmes. Bizonyos fájlrendszereket általában ritkán használnak. Például ha a kezembe kerülne egy msdos hajlékony lemez, akkor annyit tennék, hogy insmod /usr/src/linux/modules/msdos.o, aztán rmmod msdos ha végeztem. Ez az eljárás kb. 50k memóriát szabadít fel a szokásos működés közben. Egy megjegyzést kell tenni a minix fájlrendszerrel kapcsolatban: a ``mentőlemeznek'' készített kernelbe mindig közvetlenül bele kell fordítani.
Ha szeretnéd nyomonkövetni, hogy mit művelnek a `make' vagy `patch' parancsok, átirányíthatod a kimenetüket egy fájlba. Először derítsd ki, milyen shellt használsz:
`grep root /etc/passwd' és keress valami olyasmit, hogy `/bin/csh'.
Ha sh-t vagy bash-t használsz, akkor a
(command) 2>&1 | tee (output file)
parancs fog egy másolatot küldeni a (command) parancs kimenetéről az `(output file)' fájlba.
A csh vagy tcsh esetén használd a
(command) |& tee (output file)
parancsot.
Az rc esetén (megjegyzés: nem hiszem, hogy rc-t használsz):
(command) >[2=1] | tee (output file)
A hajlékony lemezek használatán kívül még több módszer van arra, hogy anélkül próbáljuk ki az új kernelt, hogy a régihez hozzányúlnánk. Sok más UNIX változattól eltérően a LILO képes arra, hogy bárhonnan a merevlemezről elindítson egy kernelt. Ha nagy (500 MB vagy nagyobb) merevlemezed van, olvasd el a LILO dokumentácíót, mert ez gondot okozhat. Ha az alábbiakhoz hasonlót fűzöl a LILO konfigurációs fájl végére, akkor úgy választhatsz egy frissen fordított kernelt, hogy nem nyúlsz a régi /vmlinuz-hoz. (Persze előbb futtatni kell a lilo-t.)
image = /usr/src/linux/arch/i386/boot/bzImage
label = uj_kernel
A legkönnyebben úgy lehet a LILO-t az új kernel indítására utasítani, hogy lenyomod a shift billentyűt bootoláskor, amikor csak annyi van a képernyőn, hogy LILO.
Megjelenik egy prompt, ekkor be lehet írni, hogy `uj_kernel', hogy az új kernelt indítsa.
Ha több különböző kernel forrását szeretnéd megtartani a gépeden egyszerre, (ez nagyon sok helyet foglal, légy óvatos), akkor a legegyszerűbb elnevezni az őket tartalmazó könyvtárakat /usr/src/linux-x.y.z, formában, ahol x.y.z a kernel verziója. Ekkor egy szimbolikus linkkel lehet választani közöttük. Például az `ln -sf linux-1.2.2 /usr/src/linux' parancs az 1.2.2 verzió forrását teszi aktuálissá. Mielőtt létrehozol egy ilyen szimbolikus linket, bizonyosodj meg arról, hogy az ln utolsó argumentuma nem egy létező valódi könyvtár (régi szimbolikus link lehet), mivel az eredmény nem az lenne, amire számítasz.
Russell Nelson (nelson@crynwr.com) összefoglalja az új kernelverziók változásait. Ezek rövidek, érdemes beléjük pillantani egy frissítés előtt. Letölthető anonymous ftp-vel a
ftp://ftp.emlist.com/pub/kchanges
címről, vagy a
http://www.crynwr.com/kchanges
webhelyről.
A Linux Kernel-HOGYAN angol eredetijének szerzője és karbantartója Brian Ward (bri@cs.uchicago.edu). Kérem, küldjetek véleményt, kiegészítéseket, javításokat. (Főleg a javítások a legfontosabbak nekem). (A fordító megjegyzése: természetesen angolul írjatok neki, magyarul nem tud :-)
Vethetsz egy pillantást a honlapomra az alábbi címek valamelyikén:
http://www.math.psu.edu/bri/
http://blah.math.tu-graz.ac.at/~bri/
Bár igyekszem nagyon figyelmes lenni a levelezéssel, vedd figyelembe, hogy nagyon sokat kapok minden nap, ezért eltarthat egy darabig, amíg válaszolok. Különösen, ha kérdéssel keresel meg, légy szíves, próbálj meg minél világosabban és részletesebben fogalmazni. Ha arról írsz, hogy egy hardver-elem nem működik (vagy valami hasonló), tudnom kell, mi a hardver-konfiguráció. Ha egy hibát jelentesz, ne csak annyit írj, hogy ``megpróbáltam ezt vagy azt, de hibát jelzett''; tudnom kell, mi volt a hiba. Azt is szeretném tudni, hogy a kernel, a gcc és a libc melyik verzióját használod. Ha csak annyit mondasz, hogy ezt vagy azt a disztribúciót használod, az nekem nem mond sokat. Az nem baj, ha egyszerű kérdést teszel fel; ne feledd: ha nem kérdezel, nem is kapsz választ! Mindenkinek szeretném megköszönni, akitől visszajelzést kaptam.
Ha a kérdésednek semmi köze a kernelhez, vagy olyan nyelven van, amit nem értek, akkor valószínűleg nem válaszolok.
Ha írsz nekem és nem kapsz választ elfogadható időn belül (három hét vagy több), akkor lehet, hogy véletlenül letöröltem a leveledet, vagy ilyesmi (bocs). Kérem, próbáld meg újra!
Sok levelet kapok olyasmiről, ami valójában hardver probléma vagy téma. Ez rendben van, de ne feledd, hogy nem ismerem a világ összes hardverjét. Én AMD processzorokat, Adaptec és Symbios SCSI kártyákat és IBM SCSI merevlemezeket használok.
A 0.1 verzió 1994. október 3.-án készült. Ez a dokumentum elérhető SGML, PostScript, TeX, roff és sima szöveges formátumban.
A ``Tippek és trükkök'' fejezet egy kissé rövid. Remélem ki tudom bővíteni mások javaslatai alapján.
A ``További csomagok''-ra is vonatkozik ez.
Több hibakeresési és katasztrófaelhárító információ kell.
Linus README-jének egy kis része (kernel hackelés) át lett véve. (Kösz, Linus!)
uc@brian.lunetix.de (Ulrich Callmeier): patch -s és xargs.
quinlan@yggdrasil.com (Daniel Quinlan): sok javítás és kiegészítés több fejezetben
nat@nat@nataa.fr.eu.org (Nat Makarevitch): mrproper, tar -p, és sok egyéb dolog
boldt@math.ucsb.edu (Axel Boldt): összegyűjtötte a kernel konfiguráció opcióinak leírását a hálózaton, aztán átadta nekem a listát
lembark@wrkhors.psyber.com (Steve Lembark): többszörös boot ötlet
kbriggs@earwax.pd.uwa.edu.au (Keith Briggs): néhány javítás és javaslat
rmcguire@freenet.columbus.oh.us (Ryan McGuire): kiegészítések a make opcióihoz
dumas@excalibur.ibp.fr (Eric Dumas): francia fordítás
simazaki@ab11.yamanashi.ac.jp (Yasutada Shimazaki): japán fordítás
jjamor@lml.ls.fi.upm.es (Juan Jose Amor Iglesias): spanyol fordítás
mva@sbbs.se (Martin Wahlen): svéd fordítás
jzp1218@stud.u-szeged.hu (Zoltán Vámosi): magyar fordítás
bart@mat.uni.torun.pl (Bartosz Maruszewski): lengyel fordítás
donahue@tiber.nist.gov (Michael J Donahue): sajtóhibák, a ``szeletelt kenyér verseny'' győztese.
rms@gnu.ai.mit.edu (Richard Stallman): ``szabad'' dokumentáció koncepciója és a terjesztési engedély
dak@Pool.Informatik.RWTH-Aachen.DE (David Kastrup): NFS
esr@snark.thyrsus.com (Eric Raymond): vegyes apróságok
Azok is nagy segítségemre voltak, akik kérdésekkel és problémákkal kapcsolatban levelet küldtek.
Copyright © Brian Ward, 1994-1999.
Hungarian translation © Vámosi Zoltán, 1997., © Tímár András 1999.
Ez a dokumentum szabadon másolható és terjeszthető, ha a copyright és az engedély szövegét minden másolaton megőrzik.
E dokumentum módosított változatai a változatlan másolatokkal megegyező feltételek alapján másolhatók és terjeszthetők, ha a módosított változatot is az ezzel az engedéllyel megegyező feltételekkel terjesztik. A fordítások is a ``módosított változat'' kategóriájába tartoznak.
Garancia: Nincs.
Ajánlások: Az üzleti célú terjesztés megengedett és támogatott, de nyomatékosan ajánlott, hogy a terjesztő lépjen kapcsolatba a szerzővel a terjesztés előtt, a dolgok naprakészségének biztosítása végett. (Küldhetsz egy példányt abból, amit csinálsz, ha már úgyis csinálod.) A fordítóknak is ajánlott kapcsolatba lépni a szerzővel, mielőtt lefordítják. A nyomtatott változat jobban néz ki. A papírt használd fel újra!