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.
Maak een back-upHet 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”.
Abonneer op de juiste mailinglijstenDe 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.
Gebruik geen make worldVeel 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 25.6 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
Opmerking: 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
Lees verdere uitlegDe 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.
Belangrijk: 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:
Tip: 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 -printDit 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.
Opmerking: 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 -iDit 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 -x een optie die wordt meegegeven aan make(1). In de
hulppagina voor make(1) staat een
voorbeeld van de opties die meegegeven kunnen worden.
-DVARIABELE
geeft een variabele door aan 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.
Veel factoren bepalen de doorlooptijd van het bouwen van een boom, maar redelijk recente machines doen er maar 1 tot 2 uur over om de FreeBSD-STABLE boom te bouwen. zonder extra trucjes. Een FreeBSD-CURRENT boom kan wat langer duren.
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.
Opmerking: 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 25.7.5 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
Opmerking: 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 buildworldDan moet het resultaat geïnstalleerd worden met:
# make -DNO_PROFILE installworldAnders 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.
Back-up maken van /etcOndanks 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
-Rmaakt een recursieve kopie,-pbewaart 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.
Voeg aan de naam van de nieuwe rootmap (/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 distributionMigreer 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-19980221Vaak 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-19980214Herhaal 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
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:
src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk
Dan is het handiger om naar de juiste submappen te gaan, daar make all install uit te voeren en dat is het zo'n beetje. Maar als er iets wezenlijks is veranderd, bijvoorbeeld src/lib/libc/stdlib, dan dient ofwel de wereld herbouwd te worden of tenminste die delen die statisch gelinkt zijn (en ook al het andere dat statisch gelinkt is en onderdeel is van een systeem).
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.
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.
Het korte antwoord is ja.
/usr/obj bevat alle objectbestanden die tijdens het compileren zijn gemaakt. Normaliter is een van de eerste stappen in het make buildworld proces deze map verwijderen en een verse start maken. In dit geval heeft het behouden van /usr/obj na het afronden weinig zin en geeft het ook nogal wat extra vrije schijfruimte (ongeveer 2 GB).
Als er veel kennis aanwezig is bij een beheerder, dan kan make buildworld aangegeven worden deze stap over te slaan. Hierdoor draaien volgende builds veel sneller, omdat veel broncode niet opnieuw gecompileerd hoeft te worden. De andere kant van de medaille is dat er subtiele afhankelijkheidsproblemen kunnen ontstaan, waardoor een build op bijzondere wijze kan falen. Hierdoor onstaat regelmatig ruis op FreeBSD mailinglijsten als er iemand klaagt dat zijn build faalt, terwijl hij zich niet realiseert dat dit komt doordat hij zijn updateproces niet volgens het boekje heeft uitgevoerd.
Dit hangt af van hoever een systeem was voordat een probleem gevonden werd.
Normaal gesproken (en dit is geen vaste regel) maakt het proces make buildworld nieuwe kopieën van essentiele hulpprogramma's (zoals gcc(1) en make(1)) en de systeembibliotheken. Deze hulpprogramma's en bibliotheken worden daarna geïnstalleerd. De nieuwe hulpprogramma's en bibliotheken worden daarna gebruikt om zichzelf opnieuw op te bouwen en wederom te installeren. Het complete systeem (nu met gewone programma's zoals ls(1) en grep(1)) wordt daarna opnieuw gebouwd met de nieuwe systeembestanden.
Als een systeem in de laatste fase zit (wat uit de uitvoer blijkt) kan dit redelijk veilig gedaan worden:
… fix the problem …
# cd /usr/src
# make -DNO_CLEAN all
Dit maakt het werk van de vorige make buildworld niet ongedaan.
Als het onderstaande bericht in de uitvoer van make buildworld staat, dan is het redelijk veilig om het te doen:
-------------------------------------------------------------- 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.
Draai in single-user modus;
Zet de mappen /usr/src en /usr/obj op aparte bestandssystemen die op aparte schijven staan. Hang deze schijven als mogelijk aan aparte schijfcontrollers;
Nog beter, verspreid de bestandssystemen over meerdere schijven via het apparaat ccd(4) (concatenated disk driver);
Zet profiling uit (voeg “NO_PROFILE=true” toe aan /etc/make.conf). Het is zeer waarschijnlijk niet nodig;
Geef de optie -jn mee aan make(1) om meerdere
processen parallel te laten lopen. Dit helpt in de meeste gevallen,
onafhankelijk of er gewerkt wordt op een systeem met één of meerdere
processoren;
Het bestandssysteem dat /usr/src bevat, kan
(opnieuw) gemount worden met de optie noatime.
Dit voorkomt dat het bestandssysteem de toegangsmomenten
registreert. Deze informatie is waarschijnlijk toch niet nodig.
# mount -u -o noatime /usr/src
WaarschuwingIn dit voorbeeld wordt aangenomen dat /usr/src op zijn eigen bestandssysteem staat. Als dit niet het geval is (bijvoorbeeld als het onderdeel is van /usr), dan moet het mountpunt voor dat bestandssysteem gebruikt moeten worden en niet /usr/src;
Het bestandssysteem dat /usr/obj gevat kan
(opnieuw) worden gemount met de optie async.
Dit zorgt ervoor dat schrijfacties naar een schijf asynchroon
plaatsvinden. In andere woorden: de schrijfactie wordt direct uitgevoerd en de
gegevens worden later naar de schijf geschreven. Dit stelt het
systeem in staat om data geclusterd weg te schrijven, wat een grote
prestatieverbetering kan opleveren.
WaarschuwingHoud er rekening mee dat deze optie het bestandssysteem kwetsbaarder maakt. Met deze optie is er een vergrote kans dat, indien er een stroomstoring optreed, het bestandssysteem in een niet meer te herstellen staat komt als de machine herstart.
Als op dit bestandssysteem alleen /usr/obj staat, is dit geen probleem. Als er andere belangrijke gegevens op hetzelfde bestandssysteem staan, zorg er dan voor dat er verse back-ups zijn voordat deze optie aangezet wordt.
# mount -u -o async /usr/obj
WaarschuwingZorg ervoor, zoals al eerder is aangegeven, dat als /usr/obj niet op een eigen bestandssysteem staat, het juiste mountpunt wordt gebruikt.
Zorg ervoor dat het systeem geen rommel meer bevat van eerdere builds. Het volgende helpt daarbij:
# chflags -R noschg /usr/obj/usr # rm -rf /usr/obj/usr # cd /usr/src # make cleandir # make cleandir
Inderdaad, make cleandir moet twee keer gedraaid worden.
Herstart daarna het complete proces vanaf make buildworld.
Als er nog steeds problemen zijn, stuur dan de foutmelding en de uitvoer van uname -a naar de FreeBSD algemene vragen mailinglijst. Wees bereid aanvullende vragen over het systeem te beantwoorden!