Zodra de lokale broncode gesynchroniseerd is met een bepaalde versie van FreeBSD (FreeBSD-STABLE, FreeBSD-CURRENT, enzovoort) kan de broncode gebruikt worden om een systeem te herbouwen.
Het kan niet vaak genoeg verteld worden hoe belangrijk het is om een back-up te maken van een systeem vóór deze taak uit te voeren. Ook al is het opnieuw bouwen van de wereld vrij simpel (als deze instructies gevolgd worden), er worden ongetwijfeld ooit fouten gemaakt, misschien zelfs in de broncode, die het onmogelijk maken om een systeem op te starten.
Wees ervan verzekerd dat er een back-up gemaakt is en dat er een reparatiediskette of cd-rom bij de hand is. Deze wordt waarschijnlijk nooit gebruikt maar “better safe than sorry”.
De FreeBSD-STABLE en FreeBSD-CURRENT takken zijn van nature in ontwikkeling. Mensen die bijdragen aan FreeBSD zijn menselijk en foutjes ontstaan regelmatig.
Soms zijn deze foutjes onschadelijk, ze geven dan hooguit een nieuwe diagnostische waarschuwing weer. Maar de wijziging kan ook catastrofaal zijn en ervoor zorgen dat een systeem niet meer opstart of bestandssystemen vernietigt (of erger).
Als problemen zoals deze voorkomen wordt er een “heads up” naar de juiste mailinglijst gestuurd, waarin uitgelegd wordt wat het probleem is en welke systemen het raakt. Er wordt een “all clear” bericht gestuurd als het probleem is opgelost.
FreeBSD-STABLE of FreeBSD-CURRENT volgen zonder de FreeBSD-STABLE mailinglijst of FreeBSD-CURRENT mailinglijst te volgen is vragen om problemen.
make world
: Veel oudere documentatie raadt aan om make
world
te gebruiken. In dat geval worden er
belangrijke stappen overgeslagen en gebruik het commando alleen
als er voldoende kennis over aanwezig is. In bijna alle
omstandigheden is make world
verkeerd en
de procedure die hier beschreven is hoort in plaats daarvan
gebruikt te worden.
Om uw systeem bij te werken, dient u
/usr/src/UPDATING
te controleren op
eventuele pre-buildworld stappen die nodig zijn voor uw versie
van de broncode en daarna de procedure te gebruiken die hier
beschreven staat.
Deze bijwerkstappen nemen aan dat u nu een oude versie van FreeBSD gebruikt, die uit een oude compiler, een oude kernel, een oude wereld en oude instellingenbestanden bestaat. Onder “wereld” worden de binairen, bibliotheken, en programmeerbestanden van het kernsysteem verstaan. De compiler is deel van “wereld”, maar heeft enkele speciale aandachtspunten.
We nemen ook aan dat u reeds de broncode van een nieuwer systeem heeft verkregen. Bekijk, als de bronnen op een bepaald systeem ook oud zijn, Paragraaf 24.6, “Broncode synchroniseren” voor uitgebreide hulp over het synchroniseren ervan naar een nieuwere versie.
Het bijwerken van het systeem vanaf de broncode is wat subtieler dan het op het eerste gezicht lijkt, en de ontwikkelaars van FreeBSD vonden het in de loop der jaren nodig om de aangeraden methode redelijk drastisch te veranderen met het aan het licht komen van nieuwe soorten onontwijkbare afhankelijkheden. De rest van deze sectie beschrijft de rationale achter de huidige aanbevolen bijwerkmethode.
Elke succesvolle bijwerkmethode krijgt te maken met de volgende punten:
Het kan voorkomen dat de oude compiler de nieuwe kernel niet kan compileren. (Oude compilers bevatten soms bugs.) De nieuwe kernel dient dus met de nieuwe compiler gebouwd te worden. In het bijzonder moet de nieuwe compiler gebouwd worden voordat de nieuwe kernel gebouwd wordt. Dit betekent niet per se dat de nieuwe compiler geïnstalleerd moet worden voordat de nieuwe kernel gebouwd wordt.
De nieuwe wereld kan afhankelijk zijn van mogelijkheden van de nieuwe kernel. Dus moet de nieuwe kernel worden geïnstalleerd voordat de nieuwe wereld wordt geïnstalleerd.
De eerste twee gevallen zijn de basis voor de methode
buildworld
,
buildkernel
,
installkernel
,
installworld
die we in de volgende
paragrafen beschrijven. Dit is geen uitputtende lijst van alle
redenen waarom het huidige aanbevolen bijwerkproces de voorkeur
verdient. Wat minder voor de hand liggende redenen worden
hieronder genoemd:
Het kan zijn dat de oude wereld niet correct draait op de nieuwe kernel, dus moet de nieuwe wereld onmiddellijk na het installeren van de nieuwe kernel geïnstalleerd worden.
Sommige instellingen moeten veranderd worden voordat de nieuwe wereld wordt geïnstalleerd, maar anderen kunnen de oude wereld kapot maken. Vandaar dat over het algemeen twee verschillende bijwerkstappen voor de instellingen nodig zijn.
Voor het grootste gedeelte houdt het bijwerkproces zich alleen bezig met het vervangen of toevoegen van bestanden; bestaande oude bestanden worden niet verwijderd. Dit kan in sommige gevallen problemen geven. Als een gevolg zal de bijwerkprocedure soms aangeven dat bepaalde bestanden tijdens bepaalde stappen handmatig verwijderd dienen te worden. Dit kan in de toekomst eventueel geautomatiseerd worden.
Deze zorgen hebben tot het volgende aanbevolen bijwerkproces geleid. Merk op dat het gedetailleerde proces voor bepaalde updates aanvullende stappen nodig kan hebben, maar dit kernproces zou de komende tijd ongewijzigd moeten blijven:
make
buildworld
Dit compileert eerst de nieuwe compiler en enkele
aanverwante gereedschappen, daarna wordt de nieuwe compiler
gebruikt om de rest van de nieuwe wereld te compileren. Het
resultaat komt in /usr/obj
te staan.
make
buildkernel
In tegenstelling tot de oude aanpak, die config(8)
en make(1) gebruikt, gebruikt dit de
nieuwe compiler die in /usr/obj
verblijft. Dit
beschermt u tegen mismatches tussen de compiler en de
kernel.
make
installkernel
Plaatst de nieuwe kernel en kernelmodules op de schijf, waardoor het mogelijk wordt om met de nieuw bijgewerkte kernel op te starten.
Start opnieuw op in enkele-gebruikersmodus.
De enkele-gebruikersmodus minimaliseert problemen met het bijwerken van software die al draait. Het minimaliseert ook problemen die opduiken door een oude wereld op een nieuwe kernel te draaien.
mergemaster -p
Dit voert wat initiële updates aan
instellingenbestanden uit ter voorbereiding op de nieuwe
wereld. Het kan bijvoorbeeld nieuwe gebruikersgroepen aan
het systeem, of nieuwe gebruikersnamen aan de
wachtwoorddatabase toevoegen. Dit is vaak nodig wanneer er
nieuwe groepen of speciale accounts voor systeemgebruikers
zijn toegevoegd sinds de laatste keer bijwerken, zodat de
stap installworld
zonder problemen
de nieuw geïnstalleerde namen van systeemgebruikers of
systeemgroepen kan gebruiken.
make
installworld
Kopieert de wereld van /usr/obj
. U heeft nu een
nieuwe kernel en een nieuwe wereld op schijf staan.
mergemaster
Nu kunt u de overgebleven instellingenbestanden bijwerken, aangezien u een nieuwe wereld op schijf heeft staan.
Start opnieuw op.
Een volledige nieuwe start van de machine is nodig om de nieuwe kernel en de nieuwe wereld met nieuwe instellingenbestanden te laden.
Merk op dat als u van de ene uitgave van dezelfde tak van
FreeBSD bijwerkt naar een recentere uitgave van dezelfde tak, i.e.
van 7.0 naar 7.1, dat deze procedure dan niet absoluut nodig is,
aangezien het onwaarschijnlijk is dat u serieuze problemen
krijgt met de compiler, kernel, gebruikersland en
instellingenbestanden. De oudere aanpak met make
world
gevolgd door het
bouwen en installeren van een nieuwe kernel kan voor kleine
updates goed genoeg zijn.
Maar mensen die deze procedure niet volgen tijdens het bijwerken tussen grote uitgaven kunnen wat problemen verwachten.
Het is ook goed om op te merken dat veel upgrades (i.e.
4.X
naar 5.0) wat specifieke
aanvullende stappen nodig hebben (bijvoorbeeld het hernoemen of
verwijderen van specifieke bestanden voorafgaand aan
installworld). Lees het bestand
/usr/src/UPDATING
zorgvuldig, met name het
einde, waar het huidig aangeraden bijwerkproces expliciet wordt
beschreven.
Deze procedure is in de loop der tijd veranderd aangezien de ontwikkelaars zagen dat het onmogelijk was om bepaalde mismatch-problemen volledig te voorkomen. Hopelijk blijft de huidige procedure voor een lange tijd stabiel.
Samengevat is de huidige aanbevolen manier om FreeBSD vanaf broncode bij te werken:
#
cd /usr/src
#
make buildworld
#
make buildkernel
#
make installkernel
#
shutdown -r now
Er zijn een aantal zeldzame gevallen waarin
mergemaster -p
nog een keer moet draaien
voor de stap met buildworld
. Deze
staan beschreven in UPDATING
. In het
algemeen kan deze stap echter zonder risico worden
overgeslagen als er niet tussen een of meer hoofdversies
wordt bijgewerkt.
Nadat installkernel
succesvol is
afgerond, dient er in single-user modus opgestart te worden
(met boot -s
vanaf de loaderprompt). Draai
dan:
#
mount -u /
#
mount -a -t ufs
#
adjkerntz -i
#
mergemaster -p
#
cd /usr/src
#
make installworld
#
mergemaster
#
reboot
De hierboven beschreven volgorde is alleen een korte samenvatting. Ook de volgende secties lezen geeft een beter beeld van elke stap, met name als er een op maat gemaakte kernelinstelling wordt gebruikt.
Lees voor verder te gaan
/usr/src/UPDATING
(of het gelijknamige
bestand waar de kopie van de broncode ook staat). Dit bestand
kan belangrijke informatie bevatten over mogelijke problemen of
specificeert de volgorde waarin bepaalde commando's gestart
moeten worden. Als UPDATING
tegenstrijdig
is met wat hier wordt beschreven, heeft
UPDATING
voorrang.
UPDATING
lezen is geen acceptabele
vervanging voor het abonneren op de correcte mailinglijst
zoals eerder beschreven. De twee vullen elkaar aan en zijn
niet exclusief.
Controleer
/usr/share/examples/etc/make.conf
en /etc/make.conf
. Het
eerste bestand bevat standaard definities, waarvan de meeste
uitgecommentarieerd zijn. Om hiervan gebruik te maken als het
systeem opnieuw opgebouwd wordt vanuit de broncode, moeten ze
toegevoegd worden aan /etc/make.conf
.
Bedenk dat alles wat toegevoegd wordt aan
/etc/make.conf
ook gebruikt wordt bij elk
make
commando. Het is dus verstandig om
daar redelijke waardes in te vullen voor een systeem.
Een typische gebruiker wil waarschijnlijk de regel
NO_PROFILE
uit
/usr/share/examples/etc/make.conf
kopiëren naar /etc/make.conf
en het
commentaar verwijderen.
Bekijk de andere definities, zoals NOPORTDOCS
en
bepaal of deze relevant zijn.
De map /etc
bevat een groot deel van
de systeeminstellingen en scripts die gestart worden tijdens de
systeemstart. Sommige van deze scripts verschillen van versie
tot versie in FreeBSD.
Sommige van de instellingenbestanden worden dagelijks
gebruikt voor het draaien van een systeem. In het bijzonder
/etc/group
.
Er zijn gevallen geweest waarbij het installatiegedeelte
van make installworld
een aantal
gebruikersnamen of groepen verwachtte. Als er een upgrade
wordt uitgevoerd is het waarschijnlijk dat deze gebruikers of
groepen niet bestaan. Dit levert problemen op bij upgraden.
In sommige gevallen controleert make
buildworld
of deze gebruikers of groepen
bestaan.
Een voorbeeld hiervan is het toevoegen van de gebruiker
smmsp
. Gebruikers hadden een falend
installatieproces toen mtree(8) probeerde om
/var/spool/clientmqueue
te
creëren.
mergemaster(8) kan in voorbereidende modus gedraaid
worden als de optie -p
wordt meegegeven. Dan
worden alleen de bestanden vergeleken die essentieel zijn voor
het succes van buildworld
of
installworld
:
In “paranoide beheerdersmodus” kan er gecontroleerd worden welke bestanden op een systeem eigendom zijn van de groep die wordt hernoemd of verwijderd:
#
find / -group GID -print
Dit commando toont alle bestanden die eigendom zijn van
de groep GID
(een groepsnaam of
een numeriek groeps-ID).
Het kan zijn dat een systeem in single-user modus gecompileerd moet worden. Buiten het duidelijke voordeel dat de operatie iets sneller verloopt, is het voordeel dat bij een herinstallatie van een systeem een aantal belangrijke systeembestanden waaronder binaire systeembestanden, bibliotheken, include bestanden, enzovoort, worden aangepast, iets wat op een actief systeem vragen om problemen is (zeker als er actieve gebruikers op een systeem aanwezig zijn).
Een andere methode is het systeem compileren in multi-user
modus en daarna naar single-user modus gaan voor de
installatie. Bij deze methode moeten de volgende stappen
gevolgd worden. Het overschakelen naar single-user modus kan
uitgesteld worden tot en met
installkernel
of
installworld
.
Een supergebruiker kan als volgt een draaiend systeem naar single-user modus overgeschakelen:
#
shutdown now
Als alternatief kan tijdens het opstarten de optie
single user
worden gekozen. Het systeem start dan
in single-user modus. Op de shell prompt moet dan worden
ingegeven:
#
fsck -p
#
mount -u /
#
mount -a -t ufs
#
swapon -a
Hierdoor worden de bestandssystemen gecontroleerd,
/
met lees en schrijf rechten opnieuw
gemount, worden alle andere UFS bestandssystemen die in
/etc/fstab
staan gemount en wordt swap
ingeschakeld.
Als de CMOS-klok ingesteld is naar de lokale tijd en niet naar GMT (dit is waar als het resultaat van date(1) niet de correcte tijd en zone weergeeft), dan is het misschien handig om het volgende commando te starten:
#
adjkerntz -i
Dit zorgt ervoor dat de lokale tijdzoneinstellingen correct ingesteld worden. Zonder deze instelling kunnen er later problemen ontstaan.
Als delen van een systeem opnieuw gebouwd worden, worden ze
standaard geplaatst in mappen onder
/usr/obj
. Deze mappen schaduwen de mappen
onder /usr/src
.
Het proces make buildworld
kan versneld
worden en problemen met afhankelijkheden kunnen voorkomen
worden als deze map wordt verwijderd.
Sommige bestanden onder /usr/obj
hebben mogelijk de optie “niet aanpassen”
ingesteld (zie chflags(1)) die eerst verwijderd moet
worden:
#
cd /usr/obj
#
chflags -R noschg *
#
rm -rf *
Het is een goed idee om de uitvoer van make(1) te bewaren in een ander bestand. Als er iets misgaat is er een kopie van de foutmelding aanwezig. Hoewel dit misschien niet helpt in de diagnose van wat er fout is gegaan, kan het anderen helpen als het probleem wordt aangegeven in een FreeBSD mailinglijst.
De makkelijkste manier om dit te doen is door het
commando script(1) te gebruiken, met een parameter
die de naam specificeert waar de uitvoer naartoe moet. Dit
moet direct gedaan worden vóór het herbouwen
van de wereld, zodat het proces klaar is moet
exit
worden ingegeven:
#
script /var/tmp/mw.out
Script started, output file is /var/tmp/mw.out#
make TARGET
… compile, compile, compile …#
exit
Script done, …
Bewaar de uitvoer in deze stap niet
in /tmp
. Deze map wordt mogelijk
opgeschoond tijdens de volgende herstart. Een betere plaats
om dit bestand te bewaren is de map
/var/tmp
(zoals in het vorige voorbeeld)
of in de thuismap van root
.
Ga naar de map /usr/src
, tenzij de
broncode ergens anders staat, in welk geval naar die map
gegaan moet worden:
#
cd /usr/src
Om de wereld opnieuw te bouwen moet het commando
make(1) gebruikt worden. Dit commando leest zijn
instructies uit het bestand Makefile
,
dat beschrijft hoe de programma's die samen FreeBSD vormen
moeten worden gebouwd, in welke volgorde ze gebouwd moeten
worden, enzovoort.
Het algemene formaat van de commandoregel die gebruikt moet worden is als volgt:
#
make -x -DVARIABELE doel
In dit voorbeeld is de optie
-
een optie die
wordt meegegeven aan make(1). In de hulppagina voor
make(1) staat een voorbeeld van de opties die meegegeven
kunnen worden.x
-D
geeft een variabele door aan VARIABELE
Makefile
.
Het gedrag van Makefile
wordt
beïnvloed door deze variabele. Dit zijn dezelfde
variabelen die ingesteld worden in
/etc/make.conf
. Deze optie biedt een
alternatief om deze opties in te stellen.
#
make -DNO_PROFILE doel
Het bovenstaande commando is een andere manier om aan te
geven dat geprofileerde bibliotheken niet gebouwd moeten
worden en correspondeert met de onderstaande regel in
/etc/make.conf
:
NO_PROFILE= true # Avoid compiling profiled libraries
doel
geeft make(1) aan
wat er gedaan moet worden. Elke
Makefile
definieert een aantal van
verschillende doelen en het gekozen doel bepaalt wat er
gebeurt.
Sommige doelen staan vermeld in het bestand
Makefile
, maar zijn niet geschikt om
direct te starten. Integendeel, deze worden gebruikt door
het bouwproces om de benodigde stappen onder te
verdelen.
In veel gevallen hoeven er geen parameters te worden meegegeven aan make(1) en dus ziet de commando regel er als volgt uit:
#
make doel
Waar doel
een van de vele
bouw opties is. De eerste target moet echter altijd
buildworld
zijn.
Zoals de namen impliceren bouwt
buildworld
een compleet nieuwe boom
onder /usr/obj
en
installworld
, een andere target,
installeert deze boom op de huidige machine.
Het hebben van verschillende opties is handig om twee
redenen. Als eerste biedt het
de mogelijkheid om de bouw veilig te doen met de wetenschap
dat geen enkel draaiend onderdeel van een systeem geraakt
wordt. De bouw is “zelf ondersteunend”.
Hierdoor kan veilig in multi-user modus
buildworld
gedraaid worden. Het
wordt echter nog steeds aangeraden om
installworld
in single-user modus te
starten.
Ten tweede geeft het de mogelijkheid om NFS-mounts te
gebruiken om meerdere machines in het netwerk bij te werken.
Als er drie machines zijn, A
,
B
en C
, die bijgewerkt
moeten worden, dan kunnen make buildworld
en make installworld
gedraaid worden op
A
waarna B
en
C
een NFS-mount kunnen opzetten naar
/usr/src
en
/usr/obj
op machine A
waarna make installworld
gedraaid kan
worden op B
en C
om de
resultaten de installeren.
Alhoewel het doel world
nog wel
bestaat wordt het gebruik ervan sterk
afgeraden.
Voer het volgende commando uit:
#
make buildworld
Het is mogelijk om de optie -j
mee te
geven aan make
, wat resulteert in meerdere
processen die tegelijkertijd draaien. Dit heeft het meeste
effect op machines met meerdere processoren. Echter, omdat
het compilatieproces meer IO-gericht is dan processorgericht,
kan het ook nuttig zijn op systemen met één
processor.
Start als volgt op een systeem met één processor:
#
make -j4 buildworld
make(1) draait dan maximaal 4 processen tegelijkertijd. In het algemeen blijkt uit de mailinglijsten dat dit de beste resultaten geeft.
Als er meerdere processoren in een systeem zitten en gebruik gemaakt wordt van een SMP kernel, probeer dan waardes tussen de 6 en 10 en bekijk hoe het systeem reageert.
Om volledig gebruik te maken van het nieuwe systeem moet de kernel opnieuw gecompileerd worden. Dit is bijna altijd nodig omdat sommige geheugenstructuren mogelijkerwijs veranderd zijn en programma's als ps(1) en top(1) niet werken totdat de kernel en de broncode dezelfde versie hebben.
De simpelste en makkelijkste manier om dit te doen is
om een kernel te maken die gebaseerd is op
GENERIC
. Ondanks dat
GENERIC
mogelijk niet alle benodigde
apparaten heeft voor een systeem, hoort het alles te bevatten
dat nodig is om een systeem te starten in single-user modus.
Dit is een goede test op de correcte werking van een nieuw
systeem. Na het opstarten van GENERIC
en
een systeemcontrole kan erna een nieuwe kernel gebouwd worden
gebaseerd op een aangepast kernelinstellingenbestand.
Op FreeBSD is het belangrijk om de wereld opnieuw te bouwen voordat een nieuwe kernel gebouwd wordt.
Als een aangepaste kernel gemaakt moet worden en er reeds
een instellingenbestand aanwezig is, gebruik dan
KERNCONF=MYKERNEL
als volgt:
#
cd /usr/src
#
make buildkernel KERNCONF=MYKERNEL
#
make installkernel KERNCONF=MYKERNEL
Let op dat als kern.securelevel
een
waarde hoger dan 1 heeft of
noschg
of gelijksoortige opties geplaatst
zijn op het binaire kernelbestand, is het misschien nodig om
terug te gaan naar single-user modus om
installkernel
uit te voeren. In
andere gevallen moet het mogelijk zijn om deze commando's
zonder problemen uit te voeren in multi-user modus. Zie
init(8) voor meer informatie over
kern.securelevel
en chflags(1) voor
informatie over diverse bestandsopties.
Start met de instructies in Paragraaf 24.7.5, “Systeem naar single-user modus brengen” in single-user modus op om te testen of de nieuwe kernel werkt.
Na het draaien van make buildworld
kan
nu installworld
gebruikt worden om de
nieuwe binaire systeembestanden te installeren.
Voer de volgende commando's uit:
#
cd /usr/src
#
make installworld
Als er variabelen gespecificeerd zijn op de commandoregel
van make buildworld
moeten dezelfde
variabelen gebruikt worden op de commandoregel van
make installworld
. Dit is niet per se
waar voor opties zoals -j
, die nooit
gebruikt mogen worden met
installworld
.
Als bijvoorbeeld het volgende commando is uitgevoerd:
#
make -DNO_PROFILE buildworld
Dan moet het resultaat geïnstalleerd worden met:
#
make -DNO_PROFILE installworld
Anders wordt geprobeerd geprofileerde bibliotheken te
installeren die niet gebouwd zijn tijdens de fase
make buildworld
.
Het herbouwen van de wereld werkt bepaalde mappen niet
bij (in het bijzonder /etc
,
/var
en /usr
) met
nieuwe of gewijzigde instellingenbestanden.
De simpelste manier om deze bestanden bij te werken is door
mergemaster(8) te gebruiken, maar het is ook mogelijk
dit handmatig te doen. Welke manier er ook gekozen wordt, zorg
er altijd voor dat een back-up van /etc
beschikbaar is voor het geval er iets misgaat.
Het hulpprogramma mergemaster(8) is een Bourne script
dat helpt bij het bepalen van de verschillen tussen de
instellingenbestanden in /etc
en de
instellingenbestanden in de broncodeboom
/usr/src/etc
. Deze methode wordt
aangeraden om instellingenbestanden van een systeem bijgewerkt
te houden met de bestanden die in de broncodeboom staan.
Het programma wordt gestart met
mergemaster
op de commandoregel en geeft dan
resultaten weer. mergemaster
bouwt dan een
tijdelijke root omgeving vanaf /
en vult
deze met diverse instellingenbestanden voor een systeem. Deze
bestanden worden vergeleken met de bestanden die
geïnstalleerd zijn op een systeem. Op dit punt worden de
bestanden getoond die verschillen in het diff(1)-formaat,
met een +
voor toegevoegde of gewijzigde
regels en een -
voor regels die verwijderd of
vervangen zijn. In de hulppagina voor diff(1) staat meer
informatie over de syntaxis van diff(1) en hoe
bestandsverschillen getoond worden.
mergemaster(8) toont dan elk bestand dat verschilt en op dit moment is er de mogelijkheid om of het nieuwe bestand te verwijderen (ofwel het tijdelijke bestand), het tijdelijke bestand te installeren zonder enige wijzigingen, het verwerken van het oude bestand in het nieuwe bestand of de resultaten van diff(1) nogmaals te tonen.
Als gekozen wordt om het tijdelijke bestand te verwijderen, geeft dit mergemaster(8) aan dat het huidige bestand niet gewijzigd dient te worden en de nieuwe versie verwijderd kan worden. Deze optie wordt niet aangeraden, behalve als er geen reden is om het huidige bestand aan te passen. Op ieder moment kunnen hulpteksten getoond worden door ? in te geven op de prompt van mergemaster(8). Als een bestand wordt overgeslagen, dan wordt het weer getoond als alle overige bestanden verwerkt zijn.
Bij de keuze om het ongewijzigde tijdelijke bestand te installeren wordt het huidige bestand vervangen door het nieuwe. Voor de meeste ongewijzigde bestanden is dit de beste optie.
Als ervoor gekozen wordt om de wijzigingen te verwerken wordt er een tekstverwerker gestart die de inhoud van beide bestanden toont. De verschillen kunnen verwerkt worden terwijl beide bestanden naast elkaar op het scherm staan. Hier kunnen delen gekozen worden die gezamenlijk een nieuw bestand opleveren. Als de bestanden zij aan zij vergeleken worden, wordt met de toets l de inhoud links geselecteerd en met de toets r de inhoud rechts geselecteerd. Het eindresultaat bestaat uit delen van beide bestanden die erna geinstalleerd kunnen worden. Deze optie wordt voornamelijk gebruikt voor bestanden die gewijzigd zijn door de beheerder.
Als ervoor gekozen wordt om de diff(1) resultaten nog een keer te tonen, worden dezelfde verschillen getoond zoals mergemaster(8) deed voordat een optie gevraagd werd.
Zodra mergemaster(8) klaar is met de systeembestanden worden er andere opties getoond. mergemaster(8) kan vragen of het wachtwoordbestand opnieuw gebouwd moet worden. Als laatste wordt een optie getoond om alle overgebleven tijdelijke bestanden te verwijderen.
Bij handmatig bijwerken kunnen de bestanden van
/usr/src/etc
niet zomaar naar
/etc
gekopieerd worden om een werkend
systeem te krijgen. Sommige van deze bestanden moeten eerst
“geïnstalleerd” worden. Dit omdat de map
/usr/src/etc
geen
kopie is van /etc
. Daarnaast staan er
in /etc
bestanden die niet in
/usr/src/etc
staan.
Als mergemaster(8) gebruikt wordt (zoals aangeraden), kan doorgegaan worden met het volgende onderdeel.
De simpelste manier om met de hand bij te werken, is de bestanden in een nieuwe map installeren en daarna naar verschillen tussen de bestanden te zoeken.
/etc
: Ondanks dat, in theorie, niets in deze map automatisch
wordt aangepast, is het altijd beter om daar zeker van te
zijn. Dus kopieer de bestaande /etc
naar een veilige locatie. Zoals bijvoorbeeld met het
volgende commando:
#
cp -Rp /etc /etc.old
-R
maakt een recursieve kopie,
-p
bewaart tijden, eigenaarschap,
enzovoorts op bestanden.
Er moet een dummyset van mappen gemaakt worden om de
nieuwe /etc
en andere bestanden in te
installeren. /var/tmp/root
is een
redelijke keuze en er zijn hier een aantal benodigde
submappen aanwezig:
#
mkdir /var/tmp/root
#
cd /usr/src/etc
#
make DESTDIR=/var/tmp/root distrib-dirs distribution
Dit maakt de benodigde mappenstructuur en installeert de
bestanden. Een groot deel van de submappen die gemaakt zijn
in /var/tmp/root
zijn leeg en moeten
verwijderd worden. De simpelste manier om dit te doen
is:
#
cd /var/tmp/root
#
find -d . -type d | xargs rmdir 2>/dev/null
Dit verwijderd alle lege mappen. De standaardfout wordt
omgeleid naar /dev/null
om
waarschuwingen te voorkomen over mappen die niet leeg
zijn.
/var/tmp/root
bevat nu alle
bestanden die geplaatst zouden moeten worden op de juiste
locaties in /
. Er moet nu in de
bestanden gekeken worden om te bepalen of deze verschillen
met de huidige betanden.
Let op dat sommige van de bestanden die
geïnstalleerd zijn in /var/tmp/root
beginnen met een “.”. Op het moment van
schrijven hebben alleen shell opstartscripts in
/var/tmp/root
en
/var/tmp/root/root
dit, maar er kunnen
ook andere zijn. Zorg ervoor dat ls -a
gebruikt wordt om deze bestanden te zien.
De simpelste manier om twee bestanden te vergelijken is diff(1) gebruiken:
#
diff /etc/shells /var/tmp/root/etc/shells
Dit toont de verschillen tussen de huidige
/etc/shells
en de nieuwe
/var/tmp/root/etc/shells
. Gebruik dit
om te bepalen of de wijzigingen gemigreerd moeten worden of
dat het oude bestand gekopieërd moet worden.
/var/tmp/root
) een tijdsindicatie toe
zodat makkelijk verschillen tussen versies bepaald kunnen
worden: Als de wereld regelmatig wordt herbouwd moeten
bestanden in /etc
ook regelmatig
bijgewerkt moeten worden, wat een vervelend werkje kan
zijn.
Dit proces kan versneld worden door een kopie te
bewaren van de bestanden die gemigreerd zijn naar
/etc
. De volgende procedure geeft een
idee over hoe dit gedaan kan worden.
Maak de wereld zoals normaal. Als
/etc
en de andere mappen
bijgewerkt moeten worden, geef dan de doelmap een naam
gebaseerd op de huidige datum. Op 14 februari 1998
wordt dat als volgt gedaan:
#
mkdir /var/tmp/root-19980214
#
cd /usr/src/etc
#
make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution
Migreer de wijzigingen van deze map zoals hierboven beschreven.
Verwijder de map
/var/tmp/root-19980214
niet na afronden.
Als de laatste versie van de broncode gedownload en
opnieuw gemaakt is, volg stap 1. Dit geeft een nieuwe
map die wellicht
/var/tmp/root-19980221
heet (als
er een week zit tussen het bijwerken).
De verschillen die gemaakt zijn in de tussenliggende week kunnen nu getoond worden door met diff(1) een recursieve diff te maken tussen de twee mappen:
#
cd /var/tmp
#
diff -r root-19980214 root-19980221
Vaak is dit een kleinere set aan verschillen dan
tussen /var/tmp/root-19980221/etc
en /etc
. Omdat de set
verschillen kleiner is, is het makkelijker om deze te
migreren naar de map /etc
.
De oudste van de twee
/var/tmp/root-*
-mappen kan nu
verwijderd worden:
#
rm -rf /var/tmp/root-19980214
Herhaal dit proces elke keer als er wijzigingen
gemigreerd moeten worden naar
/etc
.
Met date(1) kan het maken van de mappen geautomatiseerd worden:
#
mkdir /var/tmp/root-`date "+%Y%m%d"`
Dit was het. Na een controle of alles op de juiste plaats staat kan het systeem herstart worden. Dan kan met een simpele shutdown(8):
#
shutdown -r now
Het FreeBSD systeem is nu succesvol bijgewerkt. Gefeliciteerd!
Als er dingen misgingen is het makkelijk om een deel van
het systeem opnieuw te bouwen. Als bijvoorbeeld per ongeluk
/etc/magic
verwijderd is als onderdeel
van de upgrade of door het samenvoegen van
/etc
, dan werkt file(1) niet meer.
Dat kan als volgt opgelost worden:
#
cd /usr/src/usr.bin/file
#
make all install
24.7.14.1. | Moet de wereld opnieuw gemaakt worden voor elke wijziging? |
Op deze vraag bestaat geen eenvoudig antwoord, omdat dit afhangt van de aard van de wijziging. Als bijvoorbeeld net CVSup is gedraaid en de onderstaande bestanden zijn bijgewerkt, dan is het waarschijnlijk niet de moeite waard om de volledige wereld te herbouwen:
Dan is het handiger om naar de juiste submappen te
gaan, daar Uiteindelijk beslist een beheerder zelf. Misschien vindt die het prettig iedere twee weken de wereld te herbouwen terwijl de wijzigingen in die twee weken binnenkomen. Een andere beheerder herbouwt alleen die onderdelen die veranderd zijn en vertrouwt erop dat hij alle afhankelijkheden in de gaten heeft. Natuurlijk hangt het ook af van de keuze hoe vaak het wenselijk is bij te werken en of FreeBSD-STABLE of FreeBSD-CURRENT wordt bijgehouden. | |
24.7.14.2. | Het compileren gaat fout met veel meldingen van signal 11 (of andere signalnummers). Wat is er aan de hand? |
Dit wijst meestal op hardwareproblemen. Het (her)bouwen van de wereld is een prima manier om een stresstest op hardware uit te voeren en hierdoor komen vaak geheugenproblemen bovendrijven. Die resulteren vaak in een compiler die op mysterieuze wijze overlijdt na het ontvangen van vreemde signalen. Dit probleem is nog duidelijker als na het herstarten van de make het proces opnieuw stopt op een ander punt. Hier biedt niets anders uitkomst dan componenten in een systeem wisselen om uit te zoeken welk component er faalt. | |
24.7.14.3. | Kan |
Het korte antwoord is ja.
Als er veel kennis aanwezig is bij een beheerder, dan
kan | |
24.7.14.4. | Kunnen onderbroken builds gecontinueerd worden? |
Dit hangt af van hoever een systeem was voordat een probleem gevonden werd. Normaal gesproken (en dit is
geen vaste regel) maakt het proces Als een systeem in de laatste fase zit (wat uit de uitvoer blijkt) kan dit redelijk veilig gedaan worden: … fix the problem … Dit maakt het werk van de vorige Als het onderstaande bericht in de uitvoer van
-------------------------------------------------------------- Building everything.. -------------------------------------------------------------- Als dat bericht er niet is, of er is onzekerheid over, dan is het altijd beter om de build opnieuw te starten vanaf het begin. | |
24.7.14.5. | Kan kan de wereld bouwen versneld worden? |
| |
24.7.14.6. | Wat te doen als er iets mis gaat? |
Zorg ervoor dat het systeem geen rommel meer bevat van eerdere builds. Het volgende helpt daarbij:
Inderdaad, Herstart daarna het complete proces vanaf
Als er nog steeds problemen zijn, stuur dan de
foutmelding en de uitvoer van |
All FreeBSD documents are available for download at http://ftp.FreeBSD.org/pub/FreeBSD/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.