[3.4 -> 3.5] | [3.5 -> 3.6] | [3.6 -> 3.7] | [3.7 -> 3.8] | [3.8 -> 3.9] | [3.9 -> 4.0] | [4.1 -> 4.2] | [FAQ Index]

Upgrade Gids: 4.0 naar 4.1

Opmerking: Upgrades worden alleen ondersteund van één uitgave naar de uitgave die er onmiddellijk op volgt. Sla geen uitgaven over.

Het wordt ten zeerste aanbevolen dat u dit proces doorleest en het volledig begrijpt alvorens het te proberen. Als u het doet op een kritieke of fysisch verafgelegen machine, wordt het aanbevolen dat u dit proces test op een identiek, lokaal systeem om het welslagen ervan te verifiëren alvorens het te proberen op een kritieke of verafgelegen computer.

Upgraden is een handige manier om uw OpenBSD systeem naar de meest recente versie te brengen. De resultaten zijn echter niet bedoeld om precies overeen te stemmen met de resultaten van een wis-en-herlaad installatie. Oude library-bestanden worden meer bepaald niet verwijderd tijdens het upgrade-proces, aangezien ze vereist zouden kunnen zijn door oudere toepassingen die op dit moment al dan niet geüpgraded kunnen worden. Als u ECHT van al deze oude bestanden wenst af te raken, zou u waarschijnlijk beter af zijn door vanaf nul te herinstalleren.

Inhoudstafel:

Vóór het upgraden
Het upgrade proces
Laatste stappen

Vóór het upgraden

Controleer of u wijzigingen gedaan hebt aan uw kernel. Het kan bijvoorbeeld dat u uw netwerkapparaat met config(8) gewijzigd heeft zodat het een niet-standaard instelling gebruikt. Noteer uw wijzigingen, zodat u ze kan herhalen voor de nieuwe 4.1 kernel.

rc.conf: In tegenstelling tot bij vorige versies van dit proces, wordt nu aangenomen dat /etc/rc.conf een niet door de gebruiker aan te passen bestand is. Indien u reeds wijzigingen gemaakt hebt aan uw /etc/rc.conf bestand, smelt dan deze wijzigingen samen in /etc/rc.conf.local. Heeft u GEEN /etc/rc.conf.local, kopieer dan simpelweg uw bestaande /etc/rc.conf bestand naar /etc/rc.conf.local en verwijder de laatste lijn van het script! Voeg in het andere geval uw bestaande rc.conf in bovenaan uw bestaand rc.conf.local bestand en verwijder de laatste lijn alvorens de rest van dit proces te doen.

Speciale opmerking voor ARM gebruikers (armish, zaurus): Wijzigingen in de ABI vereisen een lichtjes verschillend upgrade proces wanneer niet de standaard installatiekernel gebruikt wordt. Herstart niet na het installeren van de kernel en alvorens het nieuw userland te installeren.

Het upgrade proces

Upgraden met een installatiekernel

Indien u toegang heeft tot de systeemconsole is de gemakkelijkste en veiligste manier om te upgraden door te booten vanaf een installatiemedium of bsd.rd en de upgrade-stappen te volgen, die heel gelijkaardig zijn aan het installatieproces. Nadien voltooit u de upgrade door de laatste stappen te volgen zoals hieronder uitgelegd.

Een gemakkelijke manier om de installatie kernel op te starten is het plaatsen van de 4.1 versie van bsd.rd in de root van uw opstartschrijf, en dan de "boot loader" aan te geven met dit nieuwe bsd.rd bestand te starten. Op amd64 en i386 doet u dit door "boot bsd.rd" in te geven op de initiële boot> prompt.

Upgraden zonder installatiekernel

Dit is NIET het aanbevolen proces. Gebruik de methode met installatiekernel indien überhaupt mogelijk!

Soms moet men een machine upgraden wanneer men niet gemakkelijk het normale upgrade proces kan gebruiken. Het meest voorkomende geval is wanneer de machine op een afgelegen locatie staat en u geen gemakkelijke toegang tot de systeemconsole heeft. Men kan dit gewoonlijk doen door nauwgezet dit proces te volgen:

Plaats installatiebestanden op een "goede" locatie. Zorg ervoor dat u voldoende ruimte hebt!
Belet dat "onveilige" toepassingen opstarten bij het booten: Er zal tijdens dit upgrade-proces een moment zijn waarop PF waarschijnlijk niet zal draaien, maar het kan dat uw toepassingen wel nog steeds naar behoren opstarten en draaien. Gelijk welke toepassing die afhangt van PF voor de veiligheid, zou moeten uitgeschakeld worden voordat dit gebeurt, en mag niet opnieuw ingeschakeld worden totdat de juiste PF werking geverifieerd wordt na de upgrade. Er kunnen andere toepassingen zijn die u niet wil draaien tijdens de upgrade, sluit ze af en schakel ze ook uit.
Controleer de kernel: Hoewel de meeste mensen deze stap kunnen overslaan, als u een gewijzigde kernel had in 4.0, is het waarschijnlijk dat u de standaard kernel van 4.1 ook zal moeten wijzigen. Vooral wanneer u het upgrade proces vanop afstand uitvoert, is nu het moment aangebroken om te verzekeren dat de nieuwe kernel zal werken bij het rebooten van de machine. Als er wijzigingen moeten gedaan worden aan de kernel, is het het veiligst om die wijzigingen te doen op een lokaal 4.1 systeem. Dit kan zo eenvoudig zijn als het wijzigen van een specifiek apparaat met config(8), of het kan een hercompilatie betekenen als de optie die u nodig hebt niet in de GENERIC kernel is opgenomen. Raadpleeg alstublieft FAQ 5 - Het Systeem vanaf Broncode Bouwen alvorens te overwegen om uw kernel te hercompileren.
Installeer nieuwe kernel(s)
```
export RELEASEPATH=/usr/rel   # waar u de bestanden plaatst
cd ${RELEASEPATH}
rm /obsd ; ln /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd
cp bsd.rd bsd.mp /
```
Bemerk de extra stappen om over de primaire kernel te kopiëren: die worden gedaan om te verzekeren dat er steeds een geldige kopie van de kernel op de schijf staat, waarvan het systeem kan booten, in het geval dat er zich een erg slecht getimede stroomonderbreking of systeemcrash zou voordoen.
Installeer nieuwe /etc/firmware bestanden: Wegens het feit dat enkele geüploade "firmware" bestanden geüpdatet zouden kunnen zijn, kan het dat u de bestanden in de /etc/firmware directory moet updaten. Dit zal alleen gebruikers van enkele apparaten treffen, hoewel alle gebruikers deze stap zonder problemen kunnen gebruiken. Om de firmware bestanden uit te pakken uit base41.tgz, gebruikt u het volgende als root:
```
cd /
tar -C / -xzpf ${RELEASEPATH}/base41.tgz ./etc/firmware
```
Herstart met de nieuwe kernel: (NIET voor ARM gebruikers) Het zou verleidelijk kunnen zijn deze stap over te slaan, maar het moet nu gebeuren, aangezien de nieuwe kernel gewoonlijk wel oude userland toepassingen zal draaien (zoals het binnenkort belangrijke reboot!), maar vaak zal een nieuw userland NIET werken op de oude kernel.
Opmerking: ARM gebruikers (armish/zaurus) MOETEN deze stap overslaan voor deze upgrade cyclus.
Installeer nieuwe userland toepassingen. Installeer nu NIET etc41.tgz en xetc41.tgz, omdat dat uw huidige configuratiebestanden zal overschrijven!
```
export RELEASEPATH=/usr/rel
cd ${RELEASEPATH}
tar -C / -xzpf base41.tgz
tar -C / -xzpf comp41.tgz
tar -C / -xzpf game41.tgz
tar -C / -xzpf man41.tgz
tar -C / -xzpf misc41.tgz
tar -C / -xzpf xbase41.tgz
tar -C / -xzpf xfont41.tgz
tar -C / -xzpf xserv41.tgz
tar -C / -xzpf xshare41.tgz
```
Opmerking: niet alle bestandensets zullen geïnstalleerd moeten worden voor alle toepassingen, als u echter oorspronkelijk een bestandenset installeerde, dan moet u hem nu zeker upgraden met de nieuwe bestandenset.
Opmerking: de bestanden in /etc worden hieronder afzonderlijk behandeld, dus etc41.tgz en xetc41.tgz worden hier NIET uitgepakt.
Bijwerken van /dev. Het nieuwe MAKEDEV bestand zal gekopieerd worden naar /dev door de installatie van base41.tgz, zodat u eenvoudigweg het volgende moet doen:
```
cd /dev
./MAKEDEV all
```
Upgrade /etc zoals hieronder.
Herstart

Tijdens dit proces zou sendmail(8) enkele foutboodschappen kunnen produceren zoals de volgende:

    Nov 1 12:47:05 puffy sm-mta[16733]: filesys_update failed: No such file or dire
    ctory, fs=., avail=-1, blocksize=380204

Deze boodschappen kunnen veilig genegeerd worden, of misschien wenst u sendmail(8) af te sluiten tijdens het upgrade-proces.

Laatste stappen

1. Upgraden van `/etc`

Of u nu upgradet door een installatiekernel te gebruiken en een formeel "upgrade" proces te doen, of "ter plaatse" een binaire upgrade doet, er zijn bepaalde handmatige stappen die uitgevoerd moeten worden.

1.1. Nieuwe gebruikers en groepen

Een RIP daemon en een host state daemon zijn ingevoerd en om deze nieuwe daemons te gebruiken, zijn nieuwe gebruikers en groepen vereist. Voeg de volgende gebruikers en groepen toe als root, met useradd(8):
```
useradd -u88 -g=uid -c"RIP Daemon" -d/var/empty -s/sbin/nologin _ripd
useradd -u89 -g=uid -c"HostState Daemon" -d/var/empty -s/sbin/nologin _hoststated
```
Deze stap zal zowel de nieuwe gebruikers als hun overeenkomstige groepen toevoegen. Uw omgeving kan u toelaten die commando's te kopiëren/plakken.

1.2. Operationele veranderingen

Dit is niet een volledige lijst van de veranderingen die plaats hebben gehad tussen 4.0 en 4.1, maar eerder enkele van de belangrijke zaken die een groot aantal gebruikers tijdens het upgrade proces zullen treffen. Voor een meer complete lijst van veranderingen, bekijk plus41.html en "CVS change logs".

"flags S/SA keep state" impliciet in pf.conf(5)
flags S/SA keepstate is nu standaard voor pass regels in pf.conf(5), en nieuwe no state en flags any opties zijn toegevoegd om deze standaard opties op te heffen. Bestaande regelsets zullen nog steeds laden, maar het gedrag zal lichtjes afwijken omdat deze standaardinstellingen meer beperkend zijn. Regelsets met toestandloos filteren (no state) of een vereiste om toestand bij te houden op tussenliggende pakketten (flags any) moeten geüpdated worden om explicitet het gewenste gedrag te verzoeken.
Meer bepaald moet opgelet worden met de enc0 interface, omdat "floating states" een potentiëel probleem zijn om IPsec verkeer te filteren: toestanden moeten interface gebonden zijn om te vermijden verkeer zonder encryptie toe te laten in het geval isakmpd(8) er zou uit gaan. Daarom zouden alle regels op de enc0 interface expliciet keep state (if-bound) moeten zetten.
FreeBSD en NetBSD DOS MBR partities worden niet langer gebruikt om disklabels in te bewaren, en worden niet langer afgezocht voor een disklabel
Hieruit volgt dat schijven met alleen FreeBSD of NetBSD DOS MBR partities niet langer een 'a' partitie aangemaakt hebben in de gespoofte disklabel. De disklabel op zulke schijven zal bewaard en geladen worden van sektor 1, en hierdoor kan per ongeluk een oude disklabel gevonden worden. Gebruik fdisk(8) om het partitietype te veranderen in OpenBSD ('A6') om de bestaande disklabel te gebruiken.
amd64, i386, macppc, and mvmeppc proberen niet langer op te starten vanaf de eerste NetBSD partitie als er geen OpenBSD partitie gevonden is.
Gebruik ook hier fdisk (8) om het partitietype te veranderen in OpenBSD ('A6').
Nieuwe manier om proces accounting bij het opstarten in of uit te schakelen
Om accounting in te schakelen bij het opstarten is het nodig de nieuwe rc.conf variabele "accounting=YES" te zetten. De aanwezigheid van het /var/account/acct bestand is niet meer voldoende om het automatisch te starten.
spamd(8) draait nu standaard in greylist modus
Waar voordien greylisten moest ingeschakeld worden via de -g vlag, is het nu de standaard runtime mode. De -b vlag (die voordien aangaf op welk IP spamd(8) moest luisteren) kan gebruikt worden om spamd te draaien in blacklist-only modus. De nieuwe -l vlag wordt gebruikt om aam te geven op welk IP spamd moet luisteren.
spamd.conf(5) wordt nu geplaatst in /etc/mail
Het spamd.conf(5) bestand dat in /etc geplaatst was werd verplaatst naar /etc/mail. Verplaats uw spamd.conf bestand naar/etc/mail zodat spamd(8) de juiste configuratie laadt.
Kernel sensors sysctl(3) MIB is nu hiërarchisch
De sensors sysctl(3) MIB bevat nu zowel de naam van het sensorapparaat als het type en de index van de eigenlijke sensor. Zo kon u voordien, bij "sysctl hw.sensors" "hw.sensors.12=it0, Temp 1, 25.00 degC" zien, alwaar u nu "hw.sensors.it0.temp0=25.00 degC" zal zien. Update uw sensorsd.conf(5) bestand met de nieuwe namen van uw sensors.

1.3. Wijzigingen aan `/etc` bestanden

U zal de etc41.tgz bestanden in een tijdelijke locatie willen uitpakken:

tar -C /tmp -xzpf ${RELEASEPATH}/etc41.tgz

Bestanden die waarschijnlijk kunnen gekopieerd worden vanuit etc41.tgz "zoals ze zijn":

etc/daily
etc/disktab
etc/hoststated.conf
etc/magic
etc/monthly
etc/netstart
etc/rc
etc/rc.conf
etc/ripd.conf
etc/sasyncd.conf
etc/security
etc/weekly
etc/mail/Makefile
etc/mail/localhost.cf
etc/mail/sendmail.cf
etc/mail/submit.cf
etc/mail/spamd.conf
etc/mtree/*
var/www/conf/bgplg.css
var/www/conf/bgplg.foot
var/www/conf/bgplg.head
var/www/htdocs/bgplg/*

Merk op dat het WEL mogelijk is om deze bestanden lokaal te wijzigen, als dit gedaan werd, zal handmatig samensmelten (merge) nodig zijn. Let goed op mail/* indien u iets anders gebruikt dan de standaard Sendmail(8) configuratie. Hier zijn kopieer/plak lijnen om deze bestanden te kopiëren, in de veronderstelling dat u etc41.tgz uitpakte op de hierboven aanbevolen plaats:


cd /tmp/etc
cp daily disktab hoststated.conf magic monthly netstart rc rc.conf ripd.conf sasyncd.conf security weekly /etc
cp mtree/* /etc/mtree/
cp mail/Makefile mail/localhost.cf mail/submit.cf /etc/mail
cp mail/sendmail.cf /etc/mail     # Wees voorzichtig hiermee!!
cp mail/spamd.conf /etc/mail      # OF... mv /etc/spamd.conf /etc/mail 
cd /tmp/var/www
cp conf/bgplg.css conf/bgplg.foot conf/bgplg.head /var/www/conf
mkdir /var/www/htdocs/bgplg
cp htdocs/bgplg/* /var/www/htdocs/bgplg/

Bestanden die handmatig samengesmolten moeten worden, met behoud van lokale wijzigingen die er in werden aangebracht, indien ze gewijzigd werden in vergelijking met de standaard bestanden, anders kopieert u ze ook gewoon:

etc/changelist
etc/ftpusers
etc/login.conf
etc/newsyslog.conf
etc/services
etc/sysctl.conf
etc/mail/aliases
var/cron/tabs/root

De wijzigingen aan deze bestanden staan in dit patchbestand. U kan dit proberen te gebruiken door het volgende uit te voeren als root:

cd /
patch -C -p0 < upgrade41.patch

Dit zal de patch testen om te zien hoe goed hij aangebracht zal worden op UW systeem, om hem werkelijk aan te brengen, laat u de "-C" optie weg. Merk op dat ze waarschijnlijk de patch niet zuiver zullen aanvaarden, als u bestanden aangepast hebt of niet nauwgezet geüpdatet, of als u aan het upgraden bent vanaf een 3.9 snapshot. In zulke gevallen zal u de wijzigingen handmatig moeten aanbrengen. Test dit proces alstublieft alvorens erop te vertrouwen voor een machine waar u niet gemakkelijk bij kan.

De volgende bestanden bevatten wijzigingen waarnaar best gekeken wordt, maar het is onwaarschijnlijk dat ze rechtstreeks gekopieerd of samengesmolten zouden moeten worden (dus als u pf.conf gebruikt, bekijk dan de voorgestelde verandering van strategie, en beslis of het gepast is voor uw gebruik).

etc/hostapd.conf
etc/pf.conf
etc/sensorsd.conf

Gebruik tenslotte newaliases(8) om de aliasen database bij te werken, en mtree(8) om nieuwe directories aan te maken:

newaliases
mtree -qdef /etc/mtree/4.4BSD.dist -p / -u

2. Controleren van de kernel

Opmerking: de meeste mensen kunnen deze stap overslaan!

Indien u de instructies hebt gevolgd voor het upgrade proces zonder installatiekernel, dan hebt u deze stap al voltooid. Als u daarentegen een installatiekernel gebruikte, en als u een gewijzigde kernel had in 4.0, dan is het waarschijnlijk dat u de standaard kernel van 4.1 ook zal moeten wijzigen. Dit kan zo eenvoudig zijn als het wijzigen van een specifiek apparaat met config(8), of het kan een hercompilatie betekenen als de optie die u nodig hebt niet in de GENERIC kernel is opgenomen. Raadpleeg alstublieft FAQ 5 - Het Systeem vanaf Broncode Bouwen alvorens te overwegen om uw kernel te hercompileren.

3. Upgraden van packages

Als u packages op uw systeem geïnstalleerd hebt, zal u die moeten upgraden nadat de upgrade van het basissysteem voltooid is. Hou er echter rekening mee dat vele packages bijkomende instellingen kunnen vereisen vóór en/of na het upgraden van de package. Verifieer met de upgrade gids van de toepassing voor meer detail.

De volgende package staat ervoor bekend aanzienlijke upgrade problemen te hebben die een groot aantal gebruikers zullen treffen. Het feit dat een package niet op deze lijst voorkomt, betekent niet dat het een triviale upgrade zal hebben. U moet uw huiswerk maken voor de applikaties die U gebruikt.

Postgresql: u moet uw database dumpen alvorens te upgraden en nadien herzetten.

De package tools ondersteunen het "terplaatse" updaten met pkg_add -u. Om bijvoorbeeld al uw packages te updaten, zorgt u ervoor dat PKG_PATH verwijst naar de 4.1 packages directory op uw CD of uw dichtstbijzijnde FTP mirror, en gebruikt u iets als

# pkg_add -ui -F update -F updatedepends

waarbij de -u update modus aangeeft, en -i interactieve modus specificeert, zodat pkg_add u vragen zal stellen wanneer het dubbelzinnigheden tegenkomt. Lees de pkg_add(1) manual pagina en het package beheer hoofdstuk van de FAQ voor meer informatie.