[OpenBSD]

[FAQ Index] [Naar Sectie 4 - Installatiegids] [Naar Sectie 6 - Netwerken]

5 - Het Systeem vanaf Broncode Bouwen

Inhoudsopgave


5.1 - OpenBSD's Flavors

Er zijn drie "flavors" van OpenBSD: Grafisch ziet de ontwikkeling van deze flavors er ongeveer zo uit:
,------o-----------o----X 3.9 Stable | . . | . ,------o---------o----X 4.0 Stable | . | . . | . | . ,----o----------o--> 4.1 Stable | . | . | . . | . | . | . ,-----o--> 4.2 Stable | . | . | . | . | . | . | . | . -->3.9Rel----->4.0Rel----->4.1Rel----->4.2Rel----> Current Tijd --->

-Current is waar actieve ontwikkeling gebeurt, en uiteindelijk zal dit de volgende -release van OpenBSD worden. Elke zes maanden, wanneer een nieuwe versie van OpenBSD vrijgegeven wordt, wordt -current getagged, en wordt -release: een bevroren punt in de geschiedenis van de source tree. Elke -release wordt nooit meer verandered; dit is wat op de CD's en FTP servers staat.

-stable is gebaseerd op -release, en is een vertakking ("branch") van het hoofdontwikkelingspad van OpenBSD. Wanneer heel belangrijke correcties aangebracht worden aan -current, worden deze ge"back-ported" ("merged") in de -stable branches; om deze reden staat -stable ook bekend als de patch branch. In de bovenstaande illustratie geven de verticale stippellijnen bugcorrecties aan die in de -stable branches opgenomen worden. U zal ook merken dat in het bovenstaande voorbeeld, de 3.9-stable branch aan zijn einde kwam bij 4.1-release, en de 4.0-stable aan zijn einde kwam bij 4.2-release -- oude releases worden typisch tot twee releases terug ondersteund. Het vergt middelen en tijd om oudere versies te ondersteunen, en hoewel we voortdurende ondersteuning voor oude releases graag zouden aanbieden, zouden we ons liever toespitsen op nieuwe functionaliteiten. De -stable branch is, door ontwerp, heel gemakkelijk op te bouwen vanaf -release van dezelfde versie (dus gaande van 4.2-release naar 4.2-stable).

De -stable branch is -release plus patches die terug te vinden zijn op de errata pagina. De werking van -stable is dezelfde als de -release waarop het gebaseerd is. Als de man pagina's moeten veranderen, zal het waarschijnlijk niet in -stable gaan. Met andere woorden, nieuwe device ondersteuning en nieuwe functionaliteit zullen NIET toegevoegd worden aan -stable.

Het loont de moeite er op te wijzen dat de naam "-stable" niet bedoeld is om te impliceren dat -current onbetrouwbaar is. -current verandert en evolueert eerder, terwijl de werking en API's van -stable niet zullen veranderen, dus u zal uw systeem niet opnieuw moeten leren of configuratiebestanden wijzigen, of problemen hebben met het toevoegen van bijkomende toepassingen aan uw systeem.

In feite, aangezien het onze hoop is om OpenBSD voortdurend te verbeteren, is het de bedoeling dat -current meer betrouwbaar en veiliger is, en uiteraard meer mogelijkheden heeft dan -stable. Om het cru te zeggen, de "beste" versie van OpenBSD is -current.

Waarschuwing: -current is een doel in beweging. Het verandert met de minuut, en kan gerust enkele keren veranderen in de tijd die het vergt om de broncode op te vragen. Hoewel de ontwikkelaars hard werken om te verzekeren dat het systeem altijd compileert en dat er geen belangrijke bugs zijn, is het volledig mogelijk om de -current broncode af te halen en vast te stellen dat het mislukt om ze te compileren, terwijl vijf minuten later alles prima zal zijn. Er zijn ook "flag days" en belangrijke systeemveranderingen die de ontwikkelaars navigeren met één-wegs-tools, wat betekent dat broncode-gebaseerd updaten niet mogelijk is. Indien u niet bereid bent om hiermee om te gaan, blijf dan weg van -current.

De meeste gebruikers draaien best ofwel -stable of -release. Dat gezegd zijnde, draaien veel mensen -current op productiesystemen, en het is belangrijk dat enkele mensen dat doen om bugs op te sporen en nieuwe functionaliteiten te testen. Als u echter niet weet hoe een probleem behoorlijk te beschrijven, te diagnosticeren en ermee om te gaan, zeg dan niet tegen uzelf (of iemand anders) dat u "het project helpt" door -current te draaien. "Het werkte niet!" is geen nuttige bug melding. "De recente wijzigingen aan de pciide driver hebben de compatibiliteit met mijn Slugchip-gebaseerde IDE interface gebroken, dmesg van werkende en gebroken systemen volgen..." zou een nuttige melding kunnen zijn.

Er zijn momenten wanneer "gewone" gebruikers misschien op het scherp van de snee willen leven en -current draaien. De meest voorkomende reden is dat de gebruiker een device heeft dat niet ondersteund wordt door -release (en dus ook niet door -stable), of verkiest om een nieuwe functionaliteit van -current te gebruiken. In dit geval kan de keuze zijn om ofwel -current te gebruiken ofwel het device niet te gebruiken, en -current kan het kleinste kwaad zijn. Men moet echter geen "handjes vasthouden" van de ontwikkelaars verwachten.

Snapshots

Tussen formele releases van OpenBSD worden er snapshots beschikbaar gemaakt via de FTP sites. Zoals de naam impliceert, zijn dit builds van welke code er ook in de tree zit op het ogenblik dat de builder een kopie nam van de code voor dat bepaald platform. Onthou dat, op sommige platformen, het DAGEN kan duren voor de snapshot build voltooid is en voor verspreiding vrijgegeven wordt. Er is geen belofte dat de snapshots volledig functioneel zijn, of zelfs goed installeren. Vaak kan een verandering die getest moet worden, het aanmaken van snapshots teweegbrengen. Voor sommige platformen worden bijna dagelijks snapshots gebouwd, voor andere zal dit veel minder frequent gebeuren. Als u -current wenst te draaien, is een recent snapshot vaak al wat u nodig hebt, en naar een snapshot upgraden is een vereist vertrekpunt alvorens -current proberen te bouwen vanaf broncode.

Soms wordt gevraagd of er een manier is om precies de broncode te verkrijgen die gebruikt werd om een snapshot te bouwen. Het antwoord is neen. Ten eerste biedt dit geen aanzienlijk voordeel. Ten tweede worden snapshots gebouwd zoals gewenst, naarmate de tijd het toelaat, en naarmate middelen beschikbaar worden. Op snelle platformen is het mogelijk dat er meerdere snapshots uitgebracht worden op één dag. Op tragere platformen kan het een week of langer duren om een snapshot te bouwen. Etiketten ("tags") of kentekens voorzien in de source tree voor elk snapshot zou erg onpraktisch zijn. Ten derde bevatten snapshots vaak experimentele code die nog niet gecommitted is in de tree.

Upgrade vs. Update

U zal dikwijls verwijzingen vinden naar het "upgraden" en "updaten" van OpenBSD installaties. Hoewel deze begrippen gelijkaardige betekenissen hebben, wordt er toch een onderscheid gemaakt onder OpenBSD.

Upgraden betekent een nieuwe versie van OpenBSD installeren, met nieuwe functionaliteiten. Bijvoorbeeld, van v4.1 naar v4.2 gaan, of van de snapshot van 12 juni naar de snapshot van 20 juni gaan. Bij het upgraden moet u doorgaans Following -current of de Upgrade gids (wanneer u van release verandert) raadplegen, om de nodige veranderingen voor de geüpgraded versie van OpenBSD te kunnen maken.
Updaten is het proces van patches aanbrengen op een systeem om de werking te verbeteren ZONDER de basisfunctionaliteit of binaire compatibiliteit te veranderen. Dit wordt doorgaans gedaan door het patchen van broncode of door -stable (de "patch branch") te volgen. Wanneer u uw systeem updatet, gaat het van een -release naar een -stable (of gepatchte -release) van de zelfde release versie, bijvoorbeeld van 4.2-release naar 4.2-stable. U kan dan later updaten naar een nieuwere -stable van dezelfde release versie. Het update proces verloopt doorgaans zonder problemen, omdat geen /etc bestanden of andere systeemconfiguraties moeten veranderd worden.

U kan dus een systeem installeren (bijvoorbeeld, 4.1-release) van CD, nadien meermaals updaten naar 4.1-stable, vervolgens upgraden naar 4.2-release van CD, en deze dan weer meermaals updaten alvorens het weer te upgraden naar de volgende release.

De Dingen in Sync houden

Het is belangrijk om te begrijpen dat OpenBSD een Besturingssysteem is, bedoeld om als een geheel genomen te worden, niet als een kernel met een hoop utilities er op gekleefd. U moet ervoor zorgen dat uw kernel, "userland" (de ondersteunende utilities en bestanden) en ports tree allemaal in sync zijn, of er zullen onaangename dingen gebeuren. Anders gezegd (omdat de mensen de fout gewoon blijven maken), u kan geen splinternieuwe ports draaien op een systeem van een maand oud, of een kernel van -current broncode herbouwen en verwachten dat deze werkt met een -release userland. Ja, dit betekent dat u uw systeem moet upgraden als u een nieuw programma wil draaien dat vandaag aan de ports tree werd toegevoegd. Sorry, maar opnieuw, OpenBSD heeft beperkte middelen ter beschikking.

Men zou ook moeten begrijpen dat het upgrade proces in slechts één richting: van ouder naar nieuwer ondersteund wordt, en van -stable naar -current. U kan niet 4.1-current (of een snapshot) draaien, vervolgens beslissen dat u te gevaarlijk aan het leven bent, en een stap terugzetten naar 4.1-stable. U staat er alleen voor als u een ander pad verkiest dan de ondersteunde optie om uw systeem vanaf nul te herladen, verwacht geen assistentie van het OpenBSD ontwikkelingsteam.

Ja, dit betekent dat u lang en hard moet nadenken alvorens u zichzelf aan het gebruik van -current waagt.

5.2 - Waarom moet ik mijn systeem vanaf broncode bouwen?

Eigenlijk is het heel waarschijnlijk dat u dat niet moet.

Enkele redenen waarom NIET vanaf broncode te bouwen:

Enkele redenen waarom u misschien vanaf broncode wil of moet bouwen:

Het OpenBSD team geeft op heel regelmatige basis voor alle platformen nieuwe snapshots vrij, gebaseerd op -current code. Waarschijnlijk zal dit alles zijn wat u nodig hebt om -current te draaien.

De meest voorkomende reden om vanaf broncode te bouwen is om de -stable branch te volgen, waarbij vanaf broncode bouwen de enige ondersteunde optie is.

5.3 - OpenBSD vanaf broncode bouwen

5.3.1 - Overzicht van het bouwproces

OpenBSD vanaf broncode bouwen brengt een aantal stappen met zich mee: Er zijn een paar bijkomende stappen die sommige gebruikers misschien wensen uit te voeren, afhankelijk van het doel van het bouwen en of X al dan niet geïnstalleerd is:

5.3.2 - Installeren of upgraden naar de dichtstbijzijnde beschikbare binary

De eerste stap bij het bouwen vanaf broncode is er zeker van zijn dat de dichtstbijzijnde beschikbare binary geïnstalleerd hebt. Gebruik deze tabel om op te zoeken waar u bent, waar u naartoe wil, en met welke binary u moet beginnen:

U bent op Doel Binary upgrade naar vervolgens ...
Oude -release Nieuwe release Nieuwste release Klaar!
-release -stable Nieuwste release Afhalen & bouwen van -stable
Oude -stable -stable Nieuwste release Afhalen & bouwen van -stable
-release -current Laatste Snapshot (optioneel) Afhalen & bouwen van -current
Oude -current -current Laatste Snapshot (optioneel) Afhalen & bouwen van -current

Het wordt aanbevolen dat u de binary installeert door de "Upgrade" optie van het installatiemedium te gebruiken. Als dat niet mogelijk is, kan u ook de binaries uitpakken zoals hier beschreven. Hoe dan ook, u moet het volledige upgrade proces doen, inclusief het aanmaken van gebruikers of andere benodigde veranderingen in de /etc directory.

5.3.3 - De gepaste broncode afhalen

OpenBSD broncode wordt beheerd met het CVS versiebeheersysteem, en cvs(1) wordt gebruikt om een kopie van de gewenste broncode naar uw lokale machine af te halen voor compilatie. Dit kan gedaan worden door gebruik te maken van een AnonCVS server (een machine waarop een publiek toegankelijke kopie staat van de volledige CVS repository gebruikt door het OpenBSD project) of van een lokale CVS repository die u beheert met de CVSup of CVSync programma's, beschikbaar via packages. CVSup kan ook gebruikt worden in een "checkout" modus, maar dat zal hier niet behandeld worden. Als u meerdere machines hebt waarop u source trees op wil onderhouden, kan u het de moeite vinden een lokale CVS repository te hebben, aangemaakt en onderhouden met CVSup of CVSync.

Nadat u beslist hebt welke AnonCVS server u wenst te gebruiken, moet u een "checkout" van de source tree uitvoeren, daarna onderhoudt u dan de tree door "updates" uit te voeren, om geüpdatet bestanden naar u lokale tree te halen.

Het CVS(1) commando heeft vele opties, sommige ervan zijn vereist voor de checkout en update van een nuttige tree. Andere commando's kunnen een gebroken tree veroorzaken. Aanwijzingen volgen en begrijpen is hier belangrijk.

-current volgen

In dit geval zullen we veronderstellen dat we een publieke AnonCVS server, anoncvs@anoncvs.example.org:/cvs, gebruiken. We zullen ook veronderstellen dat u sh(1) als uw commando-shell gebruikt, indien u een andere shell gebruikt, zal u sommige van deze commando's moeten aanpassen.

Voor de checkout van een -current CVS src tree, kan u het volgende gebruiken: # cd /usr # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT checkout -P src

Zodra u de tree hebt, kan u hem op een later tijdstip updaten: # cd /usr/src # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT up -Pd

-Stable volgen
Indien u een checkout wil doen van een alternatieve "branch" van de tree, zoals de -stable branch, zal u de "-r" modifier gebruiken voor uw checkout: # cd /usr # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT checkout -rOPENBSD_4_2 -P src Dit zal de src bestanden van de OPENBSD_4_2 branch afhalen, die ook bekend staat als de "Patch branch" of "-stable". U zou de code gelijkaardig updaten: # cd /usr/src # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT up -rOPENBSD_4_2 -Pd In feite is CVS vriendelijk genoeg om een "Tag" in het uitgecheckte bestandssysteem te plakken, zodat u het "-rOPENBSD_4_2" gedeelte van de commandolijn niet moet onthouden, het zal dit zelf onthouden totdat u ze expliciet wist of een nieuwe tag instelt door de "-A" optie bij "update" te gebruiken. Het is waarschijnlijk echter beter om te veel info in uw CVS commandolijn mee te geven dan te weinig.

Hoewel tot nu toe alleen de "src" tree getoond werd, zal u dezelfde stappen uitvoeren voor "xenocara" en "ports". Aangezien alle delen van OpenBSD in sync gehouden moeten worden, moeten alle trees die u gebruikt op hetzelfde moment uitgecheckt en geüpdatet worden. U kan de checkouts in een lijn combineren (-stable getoond): # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cd /usr # cvs -d$CVSROOT checkout -rOPENBSD_4_2 -P src ports # cd /usr/src # cvs -d$CVSROOT checkout -rOPENBSD_4_2 -P xenocara Updates moeten echter directory-per-directory gedaan worden.

Op dit punt, of u nu -stable of -current gevolgd hebt, zou u een bruikbare source tree moeten hebben. Wees heel voorzichtig met welke tree u afhaalt -- het is gemakkelijk om -current te proberen compileren wanneer u op -stable uit bent.

De tree vooraf laden: src.tar.gz, sys.tar.gz

Hoewel u de volledige source tree vanaf een AnonCVS server kan downloaden, kan u vaak veel tijd en bandbreedte besparen door uw source tree "vooraf te laden" met de bronbestanden ofwel van de OpenBSD CD ofwel van een FTP server. Dit is vooral zo als u -stable draait, aangezien relatief weinig bestanden veranderen tussen deze versie en de -release waarop ze gebaseerd is.

Om de source tree vanaf CD uit te pakken in /usr/src (in de veronderstelling dat de CD gemount is op /mnt): # cd /usr/src; tar xzf /mnt/src.tar.gz # tar xzf /mnt/xenocara.tar.gz # cd /usr; tar xzf /mnt/ports.tar.gz De bronbestanden beschikbaar om te downloaden vanaf de FTP servers zijn afgezonderd in twee bestanden om de downloadtijd te minimaliseren voor hen die met slechts één deel van de tree willen werken. De twee bestanden zijn sys.tar.gz, dat de bestanden bevat die gebruikt worden om de kernel te maken, en src.tar.gz dat al de andere "userland" utilities bevat, behalve de ports tree en de X11 broncode. In het algemeen zal u ze echter allebei geïnstalleerd willen hebben. In de veronderstelling dat de gedownloade bestanden, src.tar.gz en sys.tar.gz, in /usr staan: # cd /usr/src # tar xzf ../sys.tar.gz # tar xzf ../src.tar.gz # tar xzf ../xenocara.tar.gz # cd /usr # tar xzf ports.tar.gz

Niet alle mensen zullen al de bestandensets willen uitpakken, maar aangezien het systeem in sync gehouden moet worden, zal u in het algemeen alle delen van de tree moeten opstellen.

Algemene CVS tips

Zoals eerder aangegeven, zijn sommige opties verplicht om een geldige src tree te krijgen in OpenBSD. De "-P" optie hierboven is daar een van: Deze verwijdert ("prune") directories die leeg zijn. Over de jaren zijn er directories aangemaakt en verwijderd in de OpenBSD source tree, en soms worden de namen van oude directories momenteel gebruikt als bestandsnamen. Zonder de "-P" optie ZAL uw zonet uitgecheckte tree NIET succesvol compileren.

Vrijwel hetzelfde voor de -d optie bij het 'update' commando -- het maakt nieuwe directories aan die mogelijk aan de tree zijn toegevoegd sedert uw initiele checkout. Om een succesvolle update te bekomen, moet u de -Pd opties gebruiken.

Ervaren CVS gebruikers kunnen zich afvragen waarom de CVSROOT in dit voorbeeld gespecificeerd en gebruikt werd, aangezien cvs(1) de lokatie van de CVS server zal registreren in de uitgecheckte tree. Dit is correct, men moet misschien echter vaak genoeg de standaard anoncvs server opheffen, veel mensen bevelen aan altijd de repository expliciet te specificeren. Het loont ook de moeite op te merken dat hoewel de CVSROOT omgevingsvariabele rechtstreeks door cvs(1) kan gebruikt worden, deze alleen gebruikt wordt als niets anders hem opheft (bv., zonder zou cvs(1) een fout geven), terwijl het specificeren ervan in de cvs(1) commandolijn alle andere waarden opheft.

Het is vaak nuttig om een .cvsrc in uw home directory te gebruiken om standaardwaarden voor sommige van deze opties te specificeren. Een voorbeeld .cvsrc bestand: $ more ~/.cvsrc cvs -q -danoncvs@anoncvs.example.org:/cvs diff -up update -Pd checkout -P Dit bestand zou ervoor zorgen dat cvs(1) de anoncvs@anoncvs.example.org:/cvs server gebruikt, gewoonlijk onnodige uitvoer onderdrukt ("-q" is "quiet") voor alle operaties, een "cvs up" commando gebruikt standaard -Pd, een "cvs diff" geeft standaard "unified diffs" door de "-u", en een "cvs checkout" zal de "-P" optie gebruiken. Hoewel dit handig is, als u vergeet dat dit bestand bestaat, of commando's probeert uit te voeren waaraan u gewend bent geraakt op een machine zonder dit bestand, zal u problemen hebben.

Aangezien de source trees bestaan uit grote hoeveelheden van meestal kleine bestanden, zal het inschakelen van soft updates voor de partitie waarop de source tree staat vaak aanzienlijk betere prestatie geven.

5.3.4 - De kernel bouwen

We zullen hier veronderstellen dat u een standaard (GENERIC of GENERIC.MP) kernel wenst te bouwen. Normaal gezien is dit wat u wil doen. Overweeg niet een op maat gemaakte kernel te bouwen als u het standaard bouwproces niet beheerst.

Vanzelfsprekend is de kernel een HEEL hardware-afhankelijk gedeelte van het systeem. De broncode van de kernel staat in de /usr/src/sys directory. Sommige delen van de OpenBSD kernel code worden op alle platformen gebruikt, andere zijn heel specifiek voor één processor of één architectuur. Als u in de /usr/src/sys/arch/ directory kijkt, kan u enkele dingen zien die er een beetje verwarrend uitzien -- er zijn bijvoorbeeld mac68k, m68k en mvme68k directories. In dit geval gebruiken de mvme68k en mac68k systemen allebei dezelfde processor, maar de machines waarop ze gebaseerd zijn, zijn heel verschillend, en vereisen dus een heel verschillende kernel (er is meer aan het ontwerp van een computer dan zijn processor!). Delen van de kernel zijn echter gemeenschappelijk, die delen worden in de m68k directory gehouden. Als u gewoon een kernel bouwt, zijn de basis architectuurdirectories als m68k niets om zich zorgen over te maken, u zal uitsluitend werken met de "compound architecture" directories, zoals mvme68k.

Kernels worden gebouwd gebaseerd op kernel configuratiebestanden, die in de /usr/src/sys/arch/<uw platform>/conf directory staan. De kernel bouwen bestaat uit het config(8) programma gebruiken om een kernel compileerdirectory aan te maken en te vullen, die in /usr/src/sys/arch/<your platform>/compile/<KernelName> zal komen te staan. Voor dit voorbeeld zullen we veronderstellen dat u het i386 platform gebruikt:

# cd /usr/src/sys/arch/i386/conf # config GENERIC # cd ../compile/GENERIC # make clean && make depend && make [...veel uitvoer...] # make install
Vervang "i386" in de eerste lijn door de naam van uw platform. Het machine(1) commando kan u vertellen wat uw huidige machinenaam is, dus een voor de hand liggende veralgemening zou zijn om in de plaats het commando "cd /usr/src/sys/arch/`machine`/conf" op de eerste lijn te gebruiken.

Herstart op dit punt uw machine om deze nieuwe kernel te activeren. Merk op dat de nieuwe kernel moet draaien voor de volgende stap, hoewel als u de raad hierboven over upgraden naar de meest recente snapshot gevolgd hebt, kan het dat het niet zo heel veel uitmaakt. Soms veranderen API's echter, en zal de oude kernel nieuwe toepassingen niet kunnen uitvoeren, maar de nieuwe kernel zal in het algemeen de oude wel ondersteunen.

Variatie op het bovenstaande proces: Read-only source tree

Soms kan u er wensen voor te zorgen dat uw /usr/src/sys directory onaangeroerd blijft. Dit kan gedaan worden door het volgende proces te gebruiken:
$ cd /ergens $ cp /usr/src/sys/arch/i386/conf/GENERIC . $ config -s /usr/src/sys -b . GENERIC $ make clean && make depend && make ... veel uitvoer ...
Merk op dat u een kernel kan bouwen zonder root toegang, maar u moet root hebben om de kernel te installeren.

5.3.5 - Het userland bouwen

Er is een specifiek proces dat OpenBSD gebruikt. Processen gebruikt op andere besturingssystemen waarmee u misschien vertrouwd bent geweest, zullen heel waarschijnlijk niet werken op OpenBSD, en zullen ervoor zorgen dat u uitgelachen wordt wanneer u vraagt waarom.

5.4 - Een Release bouwen

Wat is een "release", en waarom zou ik er één willen maken?

Een release is de volledige set van bestanden die kan gebruikt worden om OpenBSD op een andere computer te installeren. Indien u slechts één computer hebt die OpenBSD draait, hebt u echt geen enkele reden om een release te maken, aangezien het bouwproces hierboven alles zal doen dat u nodig hebt. Een voorbeeldgebruik van het release proces zou zijn om -stable te bouwen op een snelle machine, en vervolgens een release te maken die geïnstalleerd wordt op al uw andere machines in uw kantoor.

Het release-proces gebruikt de binaries aangemaakt in de /usr/obj directory in het bovenstaande bouwproces, dus u moet eerst succesvol het bouwen voltooien, en niets mag de /usr/obj directory verstoren. Een moment waarop dit een probleem kan zijn is als u een geheugenschijf als uw /usr/obj gebruikt voor een beetje extra prestatie in het bouwproces, u zou de computer niet willen herstarten tussen de "build" en "release" stappen!

Het release-proces gebruikt twee werkdirectories, die we DESTDIR en RELEASEDIR zullen noemen. Alle bestanden die deel uitmaken van een "schone" OpenBSD installatie zullen gekopieerd worden naar hun juiste plaats binnen de DESTDIR. Zij zullen dan getar(1)d worden en in de RELEASEDIR geplaatst. Aan het einde van het proces zal RELEASEDIR de voltooide OpenBSD release bevatten. Het release-proces zal ook de /mnt lokatie gebruiken, dus dit zou door niets mogen gebruikt worden terwijl het release-proces draait. Voor het doel van het voorbeeld, zullen we de DESTDIR /usr/dest en de RELEASEDIR /usr/rel gebruiken.

Het release-proces omvat een aantal utilities die niet in het basis OpenBSD systeem aanwezig zijn, crunch en crunchgen(1), die gebruikt worden om één enkel uitvoerbaar bestand aan te maken bestaande uit vele individuele binaries. De naam waarmee dit enkel uitvoerbaar bestand aangeroepen wordt, bepaalt welke component-binary uitgevoerd wordt. Dit is hoe een aantal individuele programmabestanden in de ramschijf-kernel geperst worden die op bootdiskettes en andere bootmedia zit. Deze utilities moeten gebouwd worden voordat het release-proces gestart wordt. Ze hoeven slechts éénmaal gebouwd en geïnstalleerd te worden, maar aangezien mensen deze stap vaak vergeten, en deze programma's snel bouwen, verkiezen sommige mensen om gewoon crunch en crunchgen elke keer te bouwen als onderdeel van het script dat ze gebruiken om een release te maken.

U moet root privileges hebben om een release te maken.

Een release doen

Ten eerste, als het nog niet gedaan werd op deze machine, bouw crunch en crunchgen:
# cd /usr/src/distrib/crunch && make obj depend all install
Nu definieren we onze DESTDIR en RELEASEDIR omgevingsvariabelen:
# export DESTDIR=/usr/dest # export RELEASEDIR=/usr/rel
We maken nu de DESTDIR leeg en maken de directories aan indien nodig:
# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}.old && rm -rf ${DESTDIR}.old & # mkdir -p ${DESTDIR} ${RELEASEDIR}
RELEASEDIR hoeft normaal gezien niet leeg te zijn alvorens het release proces te starten, als er echter wijzigingen zijn in de release bestanden of hun namen, kunnen oude bestanden achtergelaten worden. U kan verkiezen om ook deze directory leeg te maken alvorens te beginnen.

We maken nu de release zelf:

# cd /usr/src/etc # make release
Nadat de release gemaakt is, is het een goed idee om de release na te kijken om er zeker van te zijn dat de tar bestanden overeenstemmen met wat er in de DESTDIR staat. De uitvoer van deze stap zou heel minimaal moeten zijn.
# cd /usr/src/distrib/sets # sh checkflist
U hebt nu volledige en nagekeken release bestandensets in de RELEASEDIR. Deze bestanden kunnen nu gebruikt worden om OpenBSD te installeren of te upgraden op andere machines.

De gezaghebbende instructies over het maken van een release staan in release(8).

Opmerking: als u de resulterende bestanden over HTTP wil verspreiden voor gebruik door de upgrade- of installatiescripts, zal u een bestand "index.txt" moeten toevoegen, dat de lijst bevat van al de bestanden in uw nieuwe aangemaakte release.

# /bin/ls -1 >index.txt

5.5 - X bouwen

Opmerking: de volgende instructies zijn voor OpenBSD 4.2 en later. Indien u X wenst te bouwen voor 4.1 of eerder (u zou echt moeten upgraden!), dan kan u de vorige versie van deze instructies vinden in cvsweb.

Vanaf X.org v7 is X omgeschakeld naar een "modulair bouwsysteem", waarbij de x.org source tree in meer dan driehonderd min of meer onafhankelijke packages opgedeeld werd.

Om het leven te vereenvoudigen voor OpenBSD gebruikers, werd een "meta-bouwproces" ontwikkeld met de naam Xenocara. Dit systeem zet X terug in één grote tree die in één proces kan gebouwd worden. Het bijkomend voordeel is dat dit bouwproces veel meer dan de vorige versies lijkt op het bouwproces dat door de rest van OpenBSD gebruikt wordt.

De officiële instructies om X te bouwen zitten in het /usr/src/xenocara/README bestand op uw machine en in release(8).

Broncode bekomen

De "gewoonlijke" locatie voor de xenocara source tree is /usr/src/xenocara, en de source wordt in CVS bewaard in de xenocara module. Het checkout proces is dus dit:
$ cd /usr/src $ cvs -qdanoncvs@anoncvs.example.org:/cvs checkout -P xenocara

Xenocara bouwen

Om de standaard xenocara tree te bouwen zoals ondersteund door OpenBSD, zijn geen externe tools nodig.
# cd /usr/src/xenocara # make bootstrap # make obj # make build
Indien u werkelijk wijzigingen wil aanbrengen aan de broncode, zal u waarschijnlijk verscheidene packages moeten toevoegen. Details staan in het /usr/src/xenocara/README bestand.

Een release maken

Dit is gelijkaardig aan het hoofdsysteem release-proces. Na succesvol X te bouwen, zal u een DESTDIR en RELEASEDIR definieren, met dezelfde doelen als hierboven. De RELEASEDIR kan dezelfde directory zijn als de hoofdsysteem RELEASEDIR, maar DESTDIR zal leeggemaakt en herbouwd worden in dit proces. Indien het voorzichtig gedaan wordt, is dit geen probleem, maar een afzonderlijke DESTDIR gebruiken kan "veiliger" zijn.

Voor dit voorbeeld zullen we een DESTDIR en RELEASEDIR, respectievelijk /usr/dest en /usr/rel, gebruiken. Dit moet gedaan worden na het bovenstaande bouwproces.

# export DESTDIR=/usr/dest # export RELEASEDIR=/usr/rel # test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}- && \ rm -rf ${DESTDIR}- & # mkdir -p ${DESTDIR} ${RELEASEDIR} # make release
Als dit proces voltooid is, zal u een verzameling release bestanden hebben in de $RELEASEDIR.

5.6 - Waarom heb ik een op maat gemaakte kernel nodig?

Eigenlijk hebt u dat waarschijnlijk niet nodig.

Een op maat gemaakte kernel is een kernel gebouwd met een configuratiebestand verschillend van het meegeleverde GENERIC configuratiebestand. Een op maat gemaakte kernel kan gebaseerd zijn op -release, -stable of -current code, net zoals een GENERIC kernel dat kan zijn. Terwijl het compileren van uw eigen GENERIC kernel ondersteund is door het OpenBSD team, is dit niet zo voor het compileren van uw eigen op maat gemaakte kernel.

De standaard OpenBSD kernelconfigurate (GENERIC) is ontworpen om geschikt te zijn voor de meeste mensen. Door het proberen tweaken van hun kernel hebben er meer mensen hun systeem gebroken dan er de werking van het systeem verbeterd hebben. Er zijn mensen die geloven dat u uw kernel en systeem moet aanpassen voor optimale performantie, maar dit is niet waar voor OpenBSD. Alleen de meest geavanceerde en best geïnformeerde gebruikers met de meest veeleisende toepassingen hoeven zich zorgen te maken over een op maat gemaakte kernel of systeem.

Enkele redenen waarom u misschien een op maat gemaakte kernel zou willen of moeten bouwen:

Enkele redenen waarom u beter niet een op maat gemaakte kernel bouwt:

Het verwijderen van device drivers kan het bootproces op uw systeem versnellen, maar kan het herstel bemoeilijken als u een hardware probleem hebt, en het wordt heel vaak verkeerd gedaan. Het verwijderen van device drivers zal uw systeem NIET met een merkbare hoeveelheid sneller laten draaien, maar kan wel een kleinere kernel produceren. Het verwijderen van debugging en errorcontrole kan tot een meetbare prestatiewinst leiden, maar zal het onmogelijk maken om een systeem te onderzoeken als er iets verkeerd gaat.

Opnieuw, ontwikkelaars zullen gewoonlijk bugmeldingen negeren die te maken hebben met op maat gemaakte kernels, tenzij het probleem ook in een GENERIC kernel kan gereproduceerd worden. U bent gewaarschuwd.

5.7 - Een op maat gemaakte kernel bouwen

Er wordt verondersteld dat u het bovenstaande gelezen hebt, en echt geniet van pijn. Er wordt ook verondersteld dat u een doel hebt dat niet kan bereikt worden door ofwel een Boot time configuratie (UKC>) of door een GENERIC kernel te config(8)en. Als dit allebei niet waar is, blijft u beter bij het gebruik van GENERIC. Echt.

OpenBSD kernel generatie wordt gestuurd door configuratiebestanden, die standaard in de /usr/src/sys/arch/<arch>/conf/ directory staan. Alle architecturen hebben een bestand, GENERIC, dat gebruikt wordt om de standaard OpenBSD kernel voor dat platform te genereren. Het kan dat er ook andere configuratiebestanden zijn die gebruikt worden om kernels met verschillende doelen aan te maken, bijvoorbeeld, voor minimale RAM, schijfloze werkstations, etc.

Het configuratiebestand wordt verwerkt door config(8), dat een compilatiedirectory aanmaakt en opvult in ../compile, op een typische installatie zou dat in /usr/src/sys/arch/<arch>/compile/ zijn. config(8) maakt ook een Makefile aan, en andere bestanden die vereist zijn om met succes de kernel te bouwen.

Kernel Configuratie Opties zijn opties die u aan uw kernelconfiguratie toevoegt en die bepaalde functionaliteiten in uw kernel plaatsen. Dit laat u toe om precies de ondersteuning te hebben die u wenst, zonder ondersteuning te hebben voor onnodige devices. Er zijn een veelheid aan opties die u toelaten om uw kernel aan te passen. Hier zullen we er slechts enkele overlopen, degene die het vaakst gebruikt worden. Bekijk de options(4) man pagina voor een volledige lijst van opties, en aangezien deze van tijd tot tijd veranderen, moet u ervoor zorgen dat u een man pagina gebruikt voor dezelfde versie van OpenBSD die u aan het bouwen bent. U kan ook de voorbeeldconfiguratiebestanden nakijken die beschikbaar zijn voor uw architectuur.

Gelieve geen opties toe te voegen, te verwijderen of te veranderen in uw kernel tenzij u werkelijk een reden hebt om dat te doen! Bewerk niet het GENERIC configuratiebestand!! De enige kernelconfiguratie die ondersteund wordt door het OpenBSD team is de GENERIC kernel, de combinatie van de opties in /usr/src/sys/arch/<arch>/conf/GENERIC en /usr/src/sys/conf/GENERIC zoals verdeeld door het OpenBSD team (dus NIET bewerkt). Een probleem melden over een aangepaste kernel zal er bijna altijd toe leiden dat u gezegd wordt om het probleem trachten te reproduceren met een GENERIC kernel. Niet alle opties zijn compatibel met elkaar, en vele opties zijn vereist opdat het systeem zou werken. Er is geen garantie dat, louter omdat u er in slaagt om een aangepaste kernel te compileren, deze ook werkelijk zal draaien. Er is geen garantie dat een kernel die kan "geconfig(8)ed" worden, gebouwd kan worden.

U kan hier de platform-specifieke configuratiebestanden zien:

Bekijk deze bestanden van nabij en u zal bovenaan een lijn opmerken gelijkaardig aan: include "../../../conf/GENERIC" Dit betekent dat het naar een ander configuratiebestand verwijst, één dat de platform-onafhankelijke opties bewaart. Wanneer u uw kernelconfiguratie aanmaakt, overloop dan zeker sys/conf/GENERIC.

Kernel configuratie-opties moeten in uw kernelconfiguratiebestand geplaatst worden in het volgende formaat:

option      name
of
option      name=value
Bijvoorbeeld, om de optie "DEBUG" in de kernel te plaatsen, voegt u een lijn als deze toe:
option DEBUG
Opties in de OpenBSD kernel worden vertaald in compiler preprocessor opties, daarom zou een optie als DEBUG ervoor zorgen dat de broncode gecompileerd wordt met de optie -DDEBUG, wat equivalent is met een #define DEBUG te doen doorheen de hele kernel.

Soms kan het dat u een optie wenst uit te schakelen die reeds gedefinieerd is, typisch in het "src/sys/conf/GENERIC" bestand. Hoewel u een kopie van dat bestand zou kunnen wijzigen, is het een betere keuze om de rmoption opdracht te gebruiken. Als u bijvoorbeeld echt de in-kernel debugger wil uitschakelen (niet aanbevolen!), zou u een lijn als deze toevoegen: rmoption DDB in uw kernelconfiguratiebestand. option DDB wordt gedefinieerd in src/sys/conf/GENERIC, maar de bovenstaande rmoption lijn deactiveert ze.

Nog eens, zie options(4) voor meer informatie over de bijzonderheden van deze opties. Merk ook op dat veel van de opties ook hun eigen manual pagina's hebben -- lees steeds alles wat over een optie beschikbaar is alvorens deze toe te voegen aan of te verwijderen uit uw kernel.

Een op maat gemaakte kernel bouwen

In dit geval zullen we een kernel bouwen die de boca(4) ISA multi-poort seriële kaart ondersteunt. Deze kaart is niet aanwezig in de GENERIC kernel, door conflicten met andere drivers. Een andere veel voorkomende reden om een kernel op maat te maken zou zijn om RAIDframe te gebruiken, dat te groot is om in de stock kernel te hebben. Er zijn twee veel voorkomende manieren om een kernel op maat te maken: kopieer het GENERIC config bestand naar een andere naam en bewerk het, of maak een "wrapper" bestand aan dat de standaard GENERIC kernel "include"t en gelijk welke opties die u nodig hebt en niet in GENERIC staan. In dit geval ziet ons wrapper bestand er zo uit:
include "arch/i386/conf/GENERIC" boca0 at isa? port 0x100 irq 10 # BOCA 8-port serial cards pccom* at boca? slave ?
De twee lijnen met betrekking tot de boca(4) kaart zijn gekopieerd van de uitgecommentarieerde lijnen in GENERIC, met het IRQ aangepast zoals nodig. Het voordeel van dit "wrapper" bestand te gebruiken is dat gelijk welke ongerelateerde wijzigingen in GENERIC automatisch geüpdatet worden bij gelijk welke andere broncode update. Het nadeel is dat men geen devices kan verwijderen (hoewel dat in het algemeen toch een slecht idee is).

Een andere manier om een op maat gemaakte kernel te genereren is om een kopie te maken van de standaard GENERIC, deze een andere naam te geven, en vervolgens te bewerken zoals nodig. Het nadeel hiervan is dat latere updates aan het GENERIC configuratiebestand in uw kopie moeten ge"merged" worden, of dat u uw configuratiebestand opnieuw moet maken.

In beide gevallen, na het op maat maken van uw kernel configuratiebestand, gebruikt u config(8) en maakt de kernel zoals gedocumenteerd hierboven.

Volledige instructies voor het aanmaken van uw eigen kernel staan in de afterboot(8) man pagina.

5.8 - Boot-Time Configuratie

Soms wanneer u uw systeem boot, zou het kunnen dat u opmerkt dat de kernel uw device vindt maar misschien op de verkeerde IRQ. En misschien moet u dit device meteen gebruiken. Wel, zonder de kernel opnieuw te bouwen, kan u OpenBSD's boot time kernelconfiguratie gebruiken. Dit zal uw probleem slechts voor één keer corrigeren. Als u herstart, zal u deze procedure moeten herhalen. Dus, dit is slechts als tijdelijke oplossing bedoeld, en u corrigeert het probleem best door config(8) te gebruiken. Uw kernel heeft echter option BOOT_CONFIG nodig, wat het geval is bij GENERIC.

Het grootste deel van dit document kan u vinden in de man pagina boot_config(8).

Om in de User Kernel Config, of UKC, te booten, gebruikt u de -c optie bij het booten.

boot> boot hd0a:/bsd -c
Of welke kernel u ook wil booten. Dit zal een UKC prompt tevoorschijn brengen. Van daar kan u rechtstreeks aan de kernel commando's opgeven die devices specificeren die u wil veranderen of uitschakelen of zelfs inschakelen.

Hier is een lijst van vaak voorkomende commando's in de UKC.

Zodra u uw kernel geconfigureerd hebt, gebruikt u quit of exit en gaat u verder met booten. Daarna zou u de verandering blijvend moeten maken in uw kernel image, zoals beschreven in Uw kernel aanpassen met config(8).

5.9 - Uw kernel aanpassen met config(8)

De -e en -u opties van config(8) kunnen erg behulpzaam zijn en tijdsverspilling vermijden bij het compileren van uw kernel. De -e vlag laat u toe om de UKC of User Kernel Config binnen te gaan op een draaiend systeem. Deze veranderingen zullen dan plaatsvinden bij de volgende reboot. De -u vlag test om te zien of er tijdens het booten veranderingen gedaan werden aan de draaiende kernel, wat betekent dat u boot -c gebruikte om de UKC binnen te gaan tijdens het booten van uw systeem.

Het volgende voorbeeld toont het uitschakelen van de ep* devices in de kernel. Voor de veiligheid moet u de -o optie gebruiken die de veranderingen wegschrijft naar het aangegeven bestand. Bijvoorbeeld: config -e -o bsd.new /bsd zal de veranderingen schrijven naar bsd.new. Het voorbeeld gebruikt de -o optie niet, daarom worden veranderingen gewoon genegeeerd, en niet teruggeschreven naar de kernel binary. Voor meer informatie relevant voor fout- en waarschuwingsboodschappen, leest u de config(8) man pagina.

$ sudo config -e /bsd OpenBSD 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007 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

In het bovenstaande voorbeeld worden alle ep* devices uitgeschakeld in de kernel en ze zullen niet gezocht worden. In sommige situaties waarbij u tijdens het booten de UKC gebruikt hebt, via boot -c, zal u deze veranderingen permanent moeten wegschrijven. Om dit te doen moet u de -u optie gebruiken. In het volgende voorbeeld werd de computer geboot naar de UKC en werd het wi(4) device uitgeschakeld. Aangezien veranderingen gemaakt met boot -c NIET blijvend zijn, moeten deze veranderingen weggeschreven worden. Dit voorbeeld schrijft de veranderingen gemaakt met boot -c naar een nieuwe kernel binary bsd.new.

$ sudo config -e -u -o bsd.new /bsd OpenBSD 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007 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

5.10 - Meer uitgebreide uitvoer bekomen tijdens het opstarten

Meer uitgebreide uitvoer bekomen kan heel nuttig zijn bij het proberen debuggen van problemen bij het booten. Als u een probleem hebt waarbij uw bootdiskette niet wil booten en u meer informatie moet verkrijgen, herstart dan gewoon. Wanneer u aan de "boot>" prompt bent gekomen, boot dan met boot -c. Dit brengt u naar de UKC>, doe vervolgens:
UKC> verbose autoconf verbose enabled UKC> quit

Nu zal u extreem uitvoerige uitvoer gegeven worden bij het booten.

5.11 - Vaak voorkomende problemen, tips en vragen bij het compileren en bouwen

Meestal worden problemen in het bouwproces veroorzaakt door de bovenstaande richtlijnen niet nauwkeurig te volgen. Er zijn soms echte problemen bij het bouwen van -current vanuit het meest recente snapshot, maar mislukking bij het bouwen van -release of -stable zijn bijna altijd een fout van de gebruiker.

De meeste problemen zijn gewoonlijk één van de volgende:

Hier zijn echter nog bijkomende problemen die u kan tegenkomen:

5.11.1 - De build stopte met een "Signal 11" fout

OpenBSD en andere programma's vanaf broncode bouwen, is een taak die meer van hardware vergt dan de meeste andere, het gebruikt intensief de CPU, de schijf en het geheugen. Dit heeft als gevolg dat, indien u hardware hebt die een probleem heeft, het meest waarschijnlijke moment waarop dit probleem zich zal voordoen, gedurende een build is. Signal 11 fouten worden typisch veroorzaakt door hardwareproblemen, heel vaak geheugenproblemen, maar het kunnen ook problemen met CPU, moederbord of warmte zijn. Uw systeem kan verder eigenlijk heel stabiel zijn, maar het kan geen programma's compileren.

U zal het waarschijnlijk het best vinden om de componenten die problemen veroorzaken, te vervangen, aangezien de problemen zich in de toekomst op andere manieren kunnen manifesteren. Als u hardware hebt die u echt wenst te gebruiken en die u geen andere problemen geeft, installeer dan gewoon een snapshot of een release.

Voor veel meer informatie, zie de Sig11 FAQ.

5.11.2 - "make build" mislukt met "cannot open output file snake: is a directory"

Dit is het resultaat van twee afzonderlijke fouten: Het is belangrijk om nauwkeurig de instructies te volgen bij het afhalen en bouwen van uw tree.

5.11.3 - Mijn IPv6-loos systeem werkt niet!

Ja. Breng alstublieft geen wijzigingen in het basissysteem aan waarvan u de implicaties niet begrijpt. Een "kleine" verandering in de kernel kan een heel grote impact hebben op de volledige rest van het systeem. Herlees alstublieft dit.

5.11.4 - Oeps! Ik vergat eerst de /usr/obj directory aan te maken!

Door een "make build" te doen voor een "make obj" zal u met de object bestanden verstrooid in uw /usr/src directory komen te zitten. Dit is een slechte zaak. Als u wenst te vermijden om uw volledige src tree opnieuw af te halen, kan u het volgende proberen om obj bestanden er uit te poetsen: # cd /usr/src # find . -type l -name obj | xargs rm # make cleandir # rm -rf /usr/obj/* # make obj

5.11.5 - Tip: Zet /usr/obj op zijn eigen partitie

Indien u vaak bouwt, kan u het sneller vinden om /usr/obj op zijn eigen partitie te zetten. Het voordeel is eenvoudig, het is typisch sneller om # umount /usr/obj # newfs YourObjPartition # mount /usr/obj dan om "rm -rf /usr/obj/*" te doen.

5.11.6 - Hoe bouw ik delen van de tree niet?

Soms kan u wensen bepaalde delen van de tree niet te bouwen, typisch omdat u een vervanging hebt geïnstalleerd voor een gebundelde toepassing vanuit packages, of een "kleinere" release wenst te maken om welke reden dan ook. De oplossing hiervoor is om de SKIPDIR optie te gebruiken in /etc/mk.conf.

Opmerking: het is mogelijk om op deze manier een gebroken systeem te maken. De resultaten van deze optie worden niet ondersteund door het OpenBSD project.

5.11.7 - Waar kan ik meer leren over het bouwproces?

Hier zijn enkele andere bronnen:

5.11.8 - Ik zag geen snapshots op de FTP site. Waar zijn ze naartoe?

Snapshots kunnen verwijderd worden naarmate ze oud (of niet langer relevant) worden wanneer het moment van een nieuwe -release nadert.

5.11.9 - Hoe bootstrap ik een nieuwere versie van de compiler (gcc)?

U zou echt best gewoon het laatste snapshot installeren.

OpenBSD ondersteunt nu twee compilers in-tree, gcc v3.3.5 gebruikt door de meeste platformen, maar ook gcc v2.95.3 gebruikt door enkele platformen die nog niet omgeschakeld werden, of misschien nooit omgeschakeld zullen worden door gebrek aan gcc3 ondersteuning of slechte gcc3 prestatie.

De twee compilers staan in verschillende delen van de tree:

Omdat een compiler upgraden een beetje een kip-en-ei probleem is, vereisen veranderingen aan de in-tree compiler een beetje extra aandacht. U moet de compiler tweemaal bouwen -- de eerste bouw produceert een compiler die nieuwe code genereert maar draait met code gegenereerd door de oude compiler, de tweede bouw maakt er een volledig nieuwe compiler van. In het algemeen zal u de volgende procedure willen uitvoeren: Indien uw platform gcc 2.95.3 gebruikt: # rm -r /usr/obj/gnu/egcs/gcc/* # cd /usr/src/gnu/egcs/gcc - or - Indien uw platform gcc 3.3.5: gebruikt: # rm -r /usr/obj/gnu/usr.bin/gcc/* # cd /usr/src/gnu/usr.bin/gcc Gemeenschappelijke bouwprocedure voor v3.3.5 of v2.95.3 # make -f Makefile.bsd-wrapper clean # make -f Makefile.bsd-wrapper obj # make -f Makefile.bsd-wrapper depend # make -f Makefile.bsd-wrapper # make -f Makefile.bsd-wrapper install # make -f Makefile.bsd-wrapper clean # make -f Makefile.bsd-wrapper depend # make -f Makefile.bsd-wrapper # make -f Makefile.bsd-wrapper install

En vervolgens voert u een normale make build uit.

5.11.10 - Wat is de beste manier om /etc, /var, en /dev te updaten?

Als beleid, wijzigt software in de OpenBSD tree niet automatisch bestanden in /etc. Dit betekent dat het altijd aan de beheerder is om daar de nodige wijzigingen uit te voeren. Upgrades vormen geen uitzondering. Om bestanden in deze directories te updaten, bepaalt u eerst welke veranderingen zich hebben voorgedaan in de basis (distributie) bestanden, en vervolgens brengt u deze wijzigingen handmatig opnieuw aan.

Om bijvoorbeeld de bestanden in de tree te zien die het meest recent veranderd zijn, doet u: # cd /usr/src/etc # ls -lt |more

Om alle veranderingen in /etc te zien tussen willekeurige versies van OpenBSD, kan u CVS gebruiken. Om bijvoorbeeld de veranderingen te zien tussen 4.1 en 4.2, doet u: # cd /usr/src/etc # cvs diff -u -rOPENBSD_4_1 -rOPENBSD_4_2 Om de veranderingen te zien tussen 4.2 en -current ("HEAD"), gebruikt u: # cd /usr/src/etc # cvs diff -u -rOPENBSD_4_2 -rHEAD Het /dev/MAKEDEV script wordt niet automatisch geüpdatet als onderdeel van het make build proces, het wordt echter geïnstalleerd als onderdeel van een binaire upgrade. Als algemene regel is het een goed idee om dit script (indien nodig) te kopieren en uit te voeren vanuit uw source tree wanneer u een upgrade uitvoert: # cd /dev # cp /usr/src/etc/etc.`machine`/MAKEDEV ./ # ./MAKEDEV all

Zodra u de veranderingen geïdentificeerd hebt, brengt u ze opnieuw aan in uw lokale tree, en behoudt daarbij gelijk welke lokale configuratie die u hebt gedaan.

Typische /etc veranderingen om voor uit te kijken tussen releases omvatten:

Deze veranderingen worden samengevat in upgrade42.html (om naar 4.2-release te gaan) of current.html (om naar -current te gaan).

5.11.11 - Is er een gemakkelijke manier om alle veranderingen aan de bestandshiërarchie uit te voeren?

Van tijd tot tijd worden bestanden of directories toegevoegd aan of verwijderd uit de bestandshiërarchie. Ook kan eigendomsinformatie voor delen van het bestandssysteem veranderen. Een gemakkelijke manier om ervoor te zorgen dat uw bestandshiërarchie up-to-date is, is om de mtree(8) utility te gebruiken.

Haal eerst de laatste broncode af, en doe vervolgens: # cd /usr/src/etc/mtree # install -c -o root -g wheel -m 600 special /etc/mtree # install -c -o root -g wheel -m 444 4.4BSD.dist /etc/mtree # mtree -qdef /etc/mtree/4.4BSD.dist -p / -u

Uw bestandshiërarchie zou nu up to date moeten zijn.

5.11.12 - Kan ik cross-compileren? Waarom niet?

Er zitten cross-compileertools in het systeem, voor gebruik door ontwikkelaars die een nieuw platform lanceren. Ze worden echter niet onderhouden voor algemeen gebruik.

Wanneer de ontwikkelaars ondersteuning voor een nieuw platform lanceren, is één van de eerste grote tests een "native build". Het systeem vanaf broncode bouwen zet een aanzienlijke belasting op het OS en de machine, en laat toe heel goed te testen hoe goed het systeem echt werkt. Om deze reden doet OpenBSD het hele bouwproces op het platform waarvoor de build gebruikt wordt, ook bekend als "native building". Zonder native building is het veel moeilijker om er zeker van te zijn dat de verscheidene platformen werkelijk betrouwbaar draaien, en niet enkel opstarten.

[FAQ Index] [Naar Sectie 4 - Installatiegids] [Naar Sectie 6 - Netwerken]

[terug] www@openbsd.org
$OpenBSD: faq5.html,v 1.41 2007/11/19 10:43:15 tobias Exp $