![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ Index] [4. Fejezet - Telepítési Útmutató] [6. Fejezet - Hálózat]
,------o-----------o----X 3.3 Stable
| . .
| . ,------o---------o----X 3.4 Stable
| . | . .
| . | . ,----o----------o--> 3.5 Stable
| . | . | . .
| . | . | . ,-----o--> 3.6 Stable
| . | . | . | .
| . | . | . | .
-->3.3Rel----->3.4Rel----->3.5Rel----->3.6Rel----> Current
Idő --->
A kód fa minden hatodik hónapban ágazik el -current, -release és -stable ágakra -- -release (kiadás) egy befagyott pont (egy "Jelzés") a forrás fa történelmében - sosem változik meg és ez az ami fenn van a CD-ken és az FTP kiszolgálókon. A -Current amelyben az aktív munka folyik, és amelyből az OpenBSD következő kiadása (-release) lesz.
A -stable (avagy más néven a "Folt ág - Patch branch") a -release kiadáson alapul, és mint ahogy ez jól látható egy újabb ág az OpenBSD fejlesztési útján. Amint fontos javítások kerülnek a -current ágba, ezek belekerülnek ("back port") a -stable ágakba is. A fenti ábrán látható függőleges pontvonalak azok a hibajavítások, amelyeket beleépítettek a -stable ágba. Ezen kívül az is látható a fenti példában, hogy a 3.3-stable ág befejeződik a 3.5-release kiadásakor, a 3.4-stable ág pedig a 3.6-release kiadásakor -- régebbi kiadások általában további két kiadásig vannak támogatva. Sok erőforrásba és időbe kerül a régebbi kiadások támogatását fenntartani és habár szeretnénk a régebbi kiadásokat is támogatni, mégis inkább az új szolgáltatásokra koncentrálunk. A -stable ágat a tervezése miatt igen könnyű felépíteni az ugyanolyan verziójú -release-ből (azaz pl. a 3.6-release-ből 3.6-stable-re).
A -stable ág egy -release plusz az errata oldalon megtalálható foltok és néhány olyan egyszerűbb javítás, amelyből nem érdemes errata feljegyzést készíteni. Általában a -stable működése megegyezik az alapjául szolgáló -release működésével. Ha a kézikönyvet (man pages) át kell írni egy változás miatt, akkor az valószínűleg nem fog belekerülni a -stable-be. Más szavakkal, új eszköz támogatása NEM lesz hozzáadva a -stable-hez és új szolgáltatás is csak akkor ha feltétlenül szükséges.
Vigyázat: -current egy mozgó célpont. Percről percre változik és többször megváltozhat az alatt az idő alatt is, amíg letöltöd a forráskódot. Mint ezt már korábban említettük, nincs arra semmi garancia, hogy a rendszer lefordítható, sem arra, hogy működik (persze van rá remény). Teljesen lehetséges, mint ahogy gyakran megtörténik, hogy a -current forrását nem lehet lefordítani, majd öt perccel későbbi állapot teljesen rendben működik. Ha nem akarsz ilyen dolgokkal foglalkozni, akkor jobb, ha távol maradsz a -current-től.
A legtöbb felhasználónak a -stable vagy a -release verzió a megfelelő. Elmondható, hogy sok ember használja "éles" rendszeren a -current-et, mivel fontos, hogy legyenek akik megtalálják a hibákat és tesztelik az új szolgáltatásokat. Ha azonban nem tudod, hogy hogyan kell megfelelően a hibákkal bánni, jelenteni, elemezni, akkor ne mondd magadnak (és másnak sem), hogy azzal segíted a projektet, hogy -current-et futtatsz. A "Nem működik!" nem egy használható hibajelentés. "A pciide meghajtó legutolsó változtatása nem kompatibilis a Slugchip-alapú IDE csatolómmal, a működő és a hibás rendszerem dmesg-je itt van..." lehet egy használható jelentés.
Előfordulhat azonban, hogy "normál" felhasználók is szeretnének a penge élén táncolni és -current-rendszert futtatni. A leggyakoribb ok, hogy a felhasználónak van olyan eszköze amelyet nem támogat a -release (és így a -stable sem), illetve a -current valamely új szolgáltatását kívánja használni. Ebben az esetben két választás lehet: a -current használata, illetve hogy nem használja az eszközt. És valószínűleg a -current használata a kisebbik rossz. De azt ne várja, hogy a fejlesztők elkényeztetik majd.
Gyakran felteszik a kérdést, hogy meg lehet-e szerezni a forráskódnak pontosan azt a másolatát, amelyből a snapshot készült. A válasz az, hogy nem. Először is ennek nincs igazán semmi haszna. Másodszor, snapshotok akkor készülnek ha van rá valami igény, ha az idő megengedi, illetve ha van rá elég erőforrás. Gyors platformokon számos snapshot is készülhet egy nap. Lassabbakon akár egy hétig vagy tovább is tarthat amíg elkészül. Különböző jelölések vagy megjegyzések elhelyezése a forrásban minden egyes snapshot készítésekor pedig nem igazán praktikus.
Azt is meg kell érteni, hogy amikor forrásból frissíted a rendszert, akkor a frissítés (aktualizálás) csak egy irányba működik: régebbiről az újabb felé, illetve a -stable-től a -current felé. Nem teheted meg, hogy ha mondjuk 3.6-current-et (vagy snapshot-ot) futtatsz, majd rájössz, hogy túlságosan veszélyesen élsz és inkább visszalépsz a 3.6-stable-re. Magadra maradsz hogyha más módszert választasz mint ami támogatott arra, hogy újraépítsd a rendszered a semmiből, és ne várj segítséget az OpenBSD fejlesztői csapattól.
Igen, ez azt jelenti, hogy nagyon jól meg kell gondolnod mielőtt ráveszed magad a -current használatára.
Valójában valószínűleg nincs.
Az egyedi rendszermag egy olyan rendszermag, amelyet nem az adott "gyári" ún. GENERIC konfigurációs fájl segítségével építettek. Az egyedi rendszermag alapja lehet a -release, -stable vagy -current kód, ugyanúgy ahogy a GENERIC rendszermagé is lehet. Amíg az egyedi GENERIC rendszermagod fordítását támogatja az OpenBSD csapat, addig a custom rendszermagét nem.
A szabvány OpenBSD rendszermag konfigurációt (GENERIC) arra tervezték,
hogy megfeleljen a legtöbb embernek. Többen megbontják a rendszerüket azzal,
hogy megpróbálják a rendszermagot állítgatni, hogy ezzel javítsa a rendszere
teljesítményét. Néhányan azt hiszik, hogy mindenképpen testre kell szabni a
rendszermagot és a rendszert a megfelelő teljesítményhez, de ez nem igaz az
OpenBSD-re. Csak a megfelelően képzett és hozzáértő felhasználóknak és csak
nagyon szükséges esetekben, bizonyos alkalmazásoknál kell az egyedi,
testreszabott rendszermaggal vagy rendszerrel.
Néhány ok amiért akarhatsz, illetve szükséged lehet egyedi rendszermag építésére:
Néhány ok, amiért nem kéne egyedi rendszermagot építened:
Az eszközmeghajtók eltávolítása gyorsíthatja a rendszerindítást, viszont megnehezítik a helyreállítást hardver hiba esetén, sőt gyakran ez nem is sikerül. Az eszközmeghajtók eltávolításától nem lesz észrevehetően gyorsabb a rendszered, habár a rendszermag mérete kisebb lesz. A debug és hibaellenőrzés eltávolítása számottevően javíthatja a teljesítményt, viszont lehetetlenné teszi a hibakeresést, ha valami mégis elromlik.
Tehát még egyszer: a fejlesztők nem foglalkoznak az olyan hibajelentésekkel, amelyek egyedi rendszermagról szólnak, kivéve akkor, ha a hibát elő lehet állítani a GENERIC rendszermaggal is. Mi szóltunk.
A konfigurációs fájlt a config(8) dolgozza fel, amely elkészíti és feltölti a fordítási katalógust a ../compile alatt, amely egy tipikus telepítésben az /usr/src/sys/arch/<arch>/compile/ katalógusban van. A config(8) ezen kívül elkészíti a Makefile-t és egyéb fájlokat, amelyek szükségesek a rendszermag sikeres felépítéséhez.
Rendszermag Konfigurációs Opciók azok az opciók, amelyeket hozzáadsz a rendszermag konfigurációhoz, hogy benne legyenek bizonyos szolgáltatások a saját rendszermagodban. Ennek segítségével pontosan csak azok a támogatások lesznek belefordítva, amiket akarsz a felesleges támogatások nélkül. Rengeteg opció van, amelyekkel testre szabhatod a rendszermagod. Itt most csak azokról lesz szó, amelyek a leggyakrabban használatosak. Az opciók teljes listájához nézd meg az options(4) kézikönyv (man) oldalt. Mivel ezek változhatnak időről időre, ezért bizonyosodj meg arról, hogy a man oldal verziója ugyan az, mint az OpenBSD-jé, amelyet építesz. Ezen kívül tanulmányozhatod az architektúrádhoz tartozó példa konfigurációs fájlt is. Ne adj hozzá, törölj vagy változtass meg opciókat a rendszermagban, hacsak nincs rá igazán jó okod! Az egyetlen konfiguráció amit az OpenBSD csapat támogat a GENERIC, az /usr/src/sys/arch/<arch>/conf/GENERIC és az /usr/src/sys/conf/GENERIC fájlokban lévő opciók kombinációja, abban a formában, ahogy az OpenBSD csapat szállította (azaz NINCS átszerkesztve). Egy átszerkesztett rendszermag hibajelentésekor szinte mindig azt mondják, hogy próbáld reprodukálni a hibát egy GENERIC rendszermaggal. Nem minden opció kompatibilis egymással és bizonyos opciókra mindenképp szükség van a rendszer működéséhez. Arra sincs garancia, hogy ha sikerül is lefordítanod egy egyedi rendszermagot az tényleg futni is fog.
Itt láthatók a platform specifikus konfigurációs fájlok:
Ha jól megnézed ezeket a fájlokat, akkor észrevehetsz egy ehhez hasonló sort a fájl tetejéhez közel:
include "../../../conf/GENERIC"
Ez egy hivatkozás egy másik konfigurációs fájlra, amely a platform független
opciókat tartalmazza. Amikor elkészíted a saját Rendszermag Config-od,
mindenképpen nézd át a
sys/conf/GENERIC
fájlt.
A rendszermag konfigurációs opcióknak a következő formában kell lenniük a konfigurációs fájlban:
option névPéldául a "DEBUG" opció engedélyezéséhe a rendszermagban a következő sort kell beírni:
option DEBUG
Az OpenBSD rendszermagban lévő opciók le lesznek fordítva compiler
előfeldolgozó (preprocessor) opciókká, így egy olyan opciót mint a
DEBUG meg lehetett volna adni fordításkor a -DDEBUG kapcsolóval,
ami viszont egyenértékű egy #define DEBUG-gal a rendszermag forrásban.
Előfordulhat, hogy ki akarsz kapcsolni egy olyan opciót, amely korábban engedélyezett volt, tipikusan a "src/sys/conf/GENERIC" fájlban. Ugyan tudnád szerkeszteni ennek a fájlnak egy másolatát is, de sokkal jobb megoldás lehet az rmoption utasítás használata. Például ha tényleg ki akarod kapcsolni a a rendszermagban lévő hibakeresőt - debugger - (ami nem ajánlott!), akkor hozzáadhatsz egy ilyen sort mint ez
rmoption DDB
a rendszermag konfigurációs fájlhoz. A option DDB definiálva van a
src/sys/conf/GENERIC fájlban, de a fenti rmoption sor
inaktiválja.
Még egyszer kérünk, nézd meg a options(4) kézikönyv (man) oldalt további információkért az opciók leírásával kapcsolatban. Ezen kívül sok olyan opció van, amelyeknek van saját man oldaluk -- mindig olvass el mindent egy opcióról mielőtt hozzáadod vagy eltávolítod a rendszermagból.
Az egyedi rendszermag készítésének teljes leírása megtalálható a afterboot(8) man oldalon.
A rendszermag lefordításához először is szükséged van a forráskódra. Ez megtalálható mind a hivatalos CD-ROM-on (3. lemez) és az FTP helyeken. A következő példa feltételezi, hogy a CD3 fel van csatolva az /mnt katalógusba:
Megjegyzés: Ha FTP-n keresztül töltesz le, akkor KÉT fájlt fogsz találni, az src.tar.gz-t és a sys.tar.gz-t. Az első az ún. "userland" -- a rendszermagon kívül minden, a második maga a rendszermag forrása. Töltsd le és csomagold ki mindkettőt, mivel a legtöbb felhasználónak mindkettőre szüksége van. A CD-ROM-on ezek egy fájlban vannak.# cd /usr/src # tar xvzf /mnt/src.tar.gz
Ezek után a saját rendszermag készítéséhez a legegyszerűbb a GENERIC rendszermag használata. Ez a /usr/src/sys/arch/$ARCH/conf/GENERIC katalógusban található, ahol az $ARCH a te architektúrád. Egyéb konfigurációs fájl páldák is vannak ugyanebben a katalógusban. Most nézzünk két példát a rendszermag fordításra. Az első egy rendszermag fordítás csak olvasható forrásfa esetén. A második pedig egy írható forrásfa fordítása.
Akkor kell futtatnod a 'make depend' parancsot, ha valamit változtattál a forrásfában (ebbe beletartozik a rendszerfrissítés és a foltozás is), más szavakkal, szinte mindig. Ha a config azt mondja, hogy futtasd a 'make clean'-t is, akkor azt a 'make depend' futtatása előtt kell megtenned.# cd /akarhova # cp /usr/src/sys/arch/$ARCH/conf/VALAMIFILE . # vi VALAMIFILE (a kívánt változtatások elvégzése) # config -s /usr/src/sys -b . VALAMIFILEezután vagy:# make depend - VAGY - # make clean && make depend # make
Ha megváltoztattad a rendszermag konfigurációs beállításokat, és/vagy jelentősebb változtatásokat végeztél a forrásfában, akkor a 'make clean' parancsot kell használnod a fenti 'make depend' helyett. Mindig biztonságos a 'make clean' használata, habár hosszabb fordítási időt eredményez, mivel sokkal többet kell újrafordítani.
Egy írható forrásfában való rendszermag fordításhoz a következőt kell tenni:
# cd sys/arch/$ARCH/conf
# vi VALAMIFILE (a kívánt változtatások elvégzése)
# config VALAMIFILE (itt olvashatsz róla többet: config(8))
# cd ../compile/VALAMIFILE
# make
Ahol az $ARCH az általad használt architektúra (pl. i386). Ezen kívül csinálhatsz egy make depend -et is, hogy beállítsd a függőségeket a következő rendszermag fordításhoz.
A rendszermag elhelyezése a megfelelő helyre:
Ha a régi rendszermaggal akarsz indítani rendszerindításkor, akkor írd be a boot promptnál:# cp /bsd /bsd.old # cp /sys/arch/$ARCH/compile/VALAMIFILE/bsd /bsd
és a régi rendszermag töltődik be a /bsd helyett.boot> bsd.old
Néha, ha új rendszermagot építesz szükséges lehet új bootblokkokat telepíteni. Ehhez olvasd el a FAQ 14, Bootblokkok Telepítése oldalt, amely elmagyarázza az OpenBSD Bootloader használatát.
Néha azt veheted észre, hogy a rendszermag ugyan megtalálja az eszközöd, de nem jó IRQ-n. Viszont azonnal szeretnéd használni az eszközt. Semmi gond. Anélkül, hogy újra kellene fordítani a rendszermagot megoldhatod a problémát az OpenBSD rendszermag rendszerindításkori konfigurálásával. Ez csak egyetlen alkalomra segít ki, ha újraindítod a gépet akkor meg kell ismételned az eljárást. Tehát ez csak egy átmeneti megoldás, később ki kell javítanod és újrafordítanod a rendszermagot. Ehhez a rendszermagban benne kell lennie a option BOOT_CONFIG opciónak. Ez benne van a GENERIC rendszermagban.
Ennek a dokumentumnak a nagy része megtalálható a boot_config(8) kézikönyv oldalon.
A Felhasználói Rendszermag Konfigurációhoz (User Kernel Config - UKC) a -c opciót kell használni rendszerindításkor.
Illetve az a rendszermag amit be akarsz tölteni. Ekkor feljön az UKC prompt. Itt kiadhatsz parancsokat közvetlenül a rendszermagnak, amelyekkel meghatározhatsz eszközöket, amelyeket meg akarsz változtatni, letiltani vagy akár engedélyezni.boot> boot hd0a:/bsd -c
Itt a listája a legáltalánosabb UKC parancsoknak:
Miután bekonfiguráltad az eszközeidet, használd a quit vagy az exit parancsot a rendszerindítás folytatásához. Majd ezután ezt a változást véglegesítsd a rendszermag image -ben, A rendszermag megváltoztatása a config(8) segítségével fejezetben leírt módon.
UKC> verbose autoconf verbose enabled UKC> quit
Most már rendkívül bőséges kimenetet fogsz kapni.
Az -e és az -u opciók a config(8) használatakor nagyon hasznos lehet és megtakaríthatjuk vele a rendszermag újrafordításának idejét. Az -e flag engedélyezi, hogy beléphessünk az UKC-be (Felhasználói Rendszermag Konfiguráció - User Kernel Config) egy futó rendszeren. Ezek a változások azután a következő rendszerindításkor lépnek életbe. Az -u flag leteszteli, vajon történt-e valamilyen változás a futó rendszermagban rendszerindításkor, azaz használtad a boot -c kapcsolót, hogy belépj az UKC-ba mikor indult a rendszered.
A következő példa megmutatja hogyan kell letiltani az ep* eszközöket a rendszermagban. A biztonság kedvéért használd a -o opciót, amely egy általad megadott fájlba írja ki a változtatást. Például: config -e -o bsd.new /bsd a bsd.new fájlba írja a változásokat. A következő példa nem használja az -o opciót, ezért a változások figyelmen kívül maradnak és nem kerülnek kiírásra a rendszermag binárisába. A hiba és figyelmeztető üzenetekkel kapcsolatos további információkért olvasd el a config(8) man oldalt.
$ sudo config -e /bsd
OpenBSD 3.6 (GENERIC) #59: Fri Sep 17 12:32:57 MST 2004
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
warning: no output file specified
Enter 'help' for information
ukc> ?
help Command help list
add dev Add a device
base 8|10|16 Base on large numbers
change devno|dev Change device
disable attr val|devno|dev Disable device
enable attr val|devno|dev Enable device
find devno|dev Find device
list List configuration
lines count # of lines per page
show [attr [val]] Show attribute
exit Exit, without saving changes
quit Quit, saving current changes
timezone [mins [dst]] Show/change timezone
nmbclust [number] Show/change NMBCLUSTERS
cachepct [number] Show/change BUFCACHEPERCENT
nkmempg [number] Show/change NKMEMPAGES
shmseg [number] Show/change SHMSEG
shmmaxpgs [number] Show/change SHMMAXPGS
ukc> list
0 audio* at sb0|sb*|gus0|pas0|sp0|ess*|wss0|wss*|ym*|eap*|eso*|sv*|neo*|cmpci*
|clcs*|clct*|auich*|autri*|auvia*|fms*|uaudio*|maestro*|esa*|yds*|emu* flags 0x0
1 midi* at sb0|sb*|opl*|opl*|opl*|opl*|ym*|mpu*|autri* flags 0x0
2 nsphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
3 nsphyter* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|
vr*|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep
*|ep*|ep* phy -1 flags 0x0
4 qsphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
5 inphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
6 iophy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
7 eephy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
8 exphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*
|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|e
p*|ep* phy -1 flags 0x0
[...snip...]
ukc> disable ep
67 ep0 disabled
68 ep* disabled
69 ep* disabled
155 ep0 disabled
156 ep0 disabled
157 ep* disabled
158 ep* disabled
210 ep* disabled
ukc> quit
not forced
A fenti példában minden ep* eszköz le van tiltva a rendszermagban és nem is lesznek lepróbálva. Bizonyos esetekben amikor az UKC-t használod rendszerindításkor a boot -c segítségével, szükséges lehet, hogy a változásokat véglegesen kiírd. Ehhez a -u opciót kell használnod. A következő példában belépünk az UKC-be, letiltjuk a wi(4) eszközt. Mivel ezeket a változásokat a boot -c segítségével csináltuk, ezért NEM véglegesek, csak akkor lesznek azok, ha külön kiírjuk. Ez a példa kiírja a boot -c használatával végzett változtatásokat egy új rendszermag binárisba, a bsd.new-ba.
$ sudo config -e -u -o bsd.new /bsd
OpenBSD 3.6 (GENERIC) #59: Fri Sep 17 12:32:57 MST 2004
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Processing history...
105 wi* disabled
106 wi* disabled
Enter 'help' for information
ukc> quit
OpenBSD és más programok építése forrásból sokkal jobban leterheli a hardvert mint más feladatok, erőteljesebben használva a CPU-t, a merevlemezt és a memóriát. Ezért, ha a hardverednek van valamilyen problémája, ekkor sokkal nagyobb valószínűséggel fog előjönni mint máskor. Signal 11 hibák tipikusan hardver problémából erednek, gyakran memória hibából, de lehet CPU, alaplap, vagy túlmelegedés is az oka. Lehet, hogy a rendszered egyébként stabilan működik, mégsem tudsz vele lefordítani programokat.
A leghelyesebb ha kijavítod vagy kicseréled azokat az alkatrészeket, amelyek a hibát okozzák, mivel ezek később is okozhatnak akár másmilyen problémákat is. Ha mégis van olyan hardvered amit mindenképpen szeretnél használni és egyéb más problémát nem okoz, akkor telepíts egy kiadás (release) vagy pillanatkép (snapshot) verziót.
További információkért nézd meg a Sig11 FAQ oldalt.
Ennek részletei megtalálhatók a release(8) oldalon.
[FAQ Index] [4. Fejezet - Telepítési Útmutató] [6. Fejezet - Hálózat]
![[back]](../../images/back.gif){kind=small}
www@openbsd.org