[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.0 -> 4.1] | [4.1 -> 4.2] | [4.2 -> 4.3] | [4.4 -> 4.5] | [FAQ-Index]

Upgradeanleitung: 4.3 auf 4.4

Hinweis: Upgrades werden nur von einem Release zum direkt darauf folgenden Release unterstützt. Überspringe keine Releases.

Es wird dringend dazu geraten, diesen Prozess zu lesen und voll und ganz zu verstehen, bevor du ihn durchführst. Wenn du das hier beschriebene auf einer wichtigen oder physikalisch entfernten Maschine machst, solltest du diesen Prozess erst auf einer identischen lokalen Maschinen versuchen, um sicherzustellen, dass alles funktioniert, bevor du dich an die wichtige oder entfernte Maschine wagst.

Upgrading ist ein bequemer Weg, um dein OpenBSD-System auf die aktuellste Version zu bringen. Jedoch sind die Ergebnisse nicht beabsichtigt, genau so zu sein wie eine Installation, bei der alles gelöscht und wieder aufgespielt wird. Insbesondere alte Bibliotheksdateien werden beim Upgradeprozess nicht deinstalliert, da sie von alten Applikationen, die vielleicht später noch aktualisiert werden, noch benötigt werden könnten. Wenn du WIRKLICH all diese alten Dateien loswerden möchtest, wärst du mit einer völligen Neuinstallation vermutlich besser dran.

Inhaltsverzeichnis:

Vor dem Upgrade
Der Upgradeprozess
Letzte Schritte

Vor dem Upgrade: Was zu beachten und berücksichtigt werden sollte

Dies ist keine vollständige Liste aller Änderungen, die zwischen 4.3 und 4.4 stattgefunden haben; stattdessen werden nur die wichtigsten Dinge angesprochen, die eine Großzahl Benutzer während eines Upgradeprozesses betreffen werden. Für eine vollständige Liste sieh plus44.html und die CVS-Changelogs.

Neues sysmerge(8)-Werkzeug:
OpenBSD 4.4 enthält das neue sysmerge(8)-Werkzeug, das Administratoren bei der Aktualisierung der Konfigurationsdateien nach einem Upgrade ihrerer Systeme behilflich ist. Sysmerge(8) vergleicht die aktuellen Dateien auf deinem System mit den Dateien, die mit einer Neuinstallation eingesetzt worden wären und gibt dir die Option, die alte Datei beizubehalten, die neue zu installieren oder dir dabei zu helfen, die alten in die neuen Dateien mit Hilfe von sdiff einzupflegen. Für frühere Upgrades haben wir sowohl eine Liste der Dateien angegeben, die normalerweise »so wie sie sind« übernommen werden konnten, als auch eine Liste der Dateien, die geändert wurden, und eine Korrekturroutine, die eben diese Änderungen in die möglicherweise von dir geänderten Dateien auf deinem System integriert. Für das Upgrade von 4.3 auf 4.4 könntest du auf die Korrekturroutine verzichten und die Nutzung von sysmerge in Erwägung ziehen, um diese Änderungen vornehmen zu lassen.
Wer sollte sysmerge(8) benutzen:
Personen, die ein hochgradig modifiziertes System oder Systeme verwenden, die nicht vom vorherigen Release upgegradet werden (zum Beispiel ein Schnappschuss zwischen den beiden Releases); Personen, die zuvor zu einem Schnappschuss wechselten, oder Personen, die ihr System in der Vergangenheit nicht sorgfältig geupgradet haben, werden sysmerge den Korrekturroutinen bei Weitem vorziehen, da es mit den tatsächlichen Dateien auf deinem System arbeitet und nicht mit dem, was auf deinem System vermutet wird. Es gibt dir auch wesentlich mehr Kontrolle über deinen Upgradeprozess und wird dich stärker mit einbeziehen.
Wer könnte sysmerge(8) NICHT einsetzen wollen:
Personen mit vielen Systemen, die ähnlich und simpel konfiguriert wurden und das vorherige Release (oder stabilen Zustand) betreiben, werden mit dem alten Korrekturroutinen-System schneller zum Ziel kommen.
Obwohl sysmerge mit ALLEN Änderungen in /etc, /dev, /root und /var umgehen kann, empfehlen wir dennoch, dass du einige Schritte manuell vornimmst, da Zeit eingespart werden kann und die Möglichkeit für Benutzerfehler reduziert. Insbesondere wird dringend dazu geraten, dass du sysmerge nicht verwendest, um Benutzer- und Gruppenaccounts zu aktualisieren, da es sehr leicht möglich ist, die falsche Option zu wählen, die deine gesamte Benutzerbasis löscht und das Rootpasswort auf einen leeren Wert setzt, wodurch Netzwerklogins gesperrt sind, über die das Problem behoben werden könnte.
dhcpd.interfaces wird nicht mehr genutzt:
Die Datei /etc/dhcpd.interfaces wird nicht mehr genutzt, um zu ermitteln, auf welchen Interfaces dhcpd lauschen soll. Dies kann nun in über die dhcpd_flags-Einstellung in /etc/rc.conf.local vorgenommen werden. Die meisten Anwender lassen dhcpd(8) selbst entscheiden, auf welchem Interface basierend auf der Konfigurationsinformation der dhcpd.conf-Datei gelauscht werden soll.
Neu X-Treiber Der xf86-video-openchrome-Treiber wurde zu Xenocara für VIA-Chipsätze als Ersatz für den alten »via«-Treiber hinzugefügt. Wenn du einen VIA-Chipsatz mit einer Konfigurationsdatei einsetzt, ersetze Driver "via" mit Driver "openchrome" in /etc/X11/xorg.conf, um den neuen Treiber zu verwenden. Lies ide openchrome(4)-Handbuchseite für weitere Konfigurationsoptionen.
Der ati(4)-Treiber wurde aktualisiert. Dieses Update des xf86-video-ati bringt viele wichtige Änderungen mit sich.
- Kein MergedFB mehr: Unterstützung für den MergedFB-Modus wurde für das bevorzugte xrandr(1) eingestellt.
- Korrekturoption für Macbooks geändert: Benutzer mit Macs oder Macbooks, die die Korrekturoption Option "iBookHacks" "on" nutzen, sollten die radeon(4)-Handbuchseite lesen; insbesondere die Sektion "MacModel" falls Probleme auftreten.
  Mit dieser Revision wurde diese Korrekturoption entfernt.
pfsync:
Wegen Änderungen an der pf(4)-State-Tabelle wurde die pfsync(4)-Protokollversionsnummer erhöht. Firewalls mit anderen Versionsnummern können ihre State-Tabellen nicht synchronisieren und bestehende Verbindungen werden beim "failover" beendet.
rc.conf:
Im Gegensatz zu früheren Upgradeanleitungen wird seit 4.1 davon ausgegangen, dass /etc/rc.conf nicht vom Benutzer geändert wurde. Falls du Änderungen an deiner /etc/rc.conf-Datei vorgenommen hast, übernehme sie bitte in /etc/rc.conf.local. Falls du KEINE /etc/rc.conf.local-Datei besitzt, kopiere einfach die Datei /etc/rc.conf mit dem neuen Namen /etc/rc.conf.local und entferne die letzte Zeile des Skripts!. Die andere Möglichkeit besteht darin, den Inhalt deiner rc.conf zum Anfang der bereits bestehenden rc.conf.local hinzuzufügen und die letzte Zeile zu entfernen, bevor du mit den nächsten Schritten weiter machst.
Angepasster Kernel:
Überprüfe, ob du irgendwelche Modifikationen an deinem Kernel vorgenommen hast. Zum Beispiel könntest du dein Netzwerkdevice mittels config(8) geändert haben, um eine nicht standardmäßige Einstellung verwenden zu können. Schreib die Änderungen auf, sodass du sie ebenfalls auf den neuen 4.4-Kernel anwenden kannst.

Der Upgradeprozess

Mit Installationskernel upgraden

Wenn du Zugriff auf die Systemkonsole hast, dann besteht der einfachste und sicherste Weg zu upgraden darin, mit Installationsmedien oder bsd.rd zu booten und den Upgradeschritten zu folgen, die dem Installationsprozess sehr ähneln. Schließe danach das Upgrade ab, in dem du die letzten Schritte wie weiter unten angegeben durchführst.

Den Installationskernel kannst du recht einfach booten, indem du die 4.4-Version von bsd.rd im Wurzelverzeichnis deines Bootlaufwerks ablegst und dem Bootloader mitteilst, dass er mit der neuen bsd.rd-Datei booten soll. Auf amd64 und i386 machst du das, indem du »boot bsd.rd« am ersten boot>-Prompt angibst.

Ohne Installationskernel upgraden

Diese Vorgehensweise wird NICHT empfohlen. Verwende die Installationskernel-Methode, wenn es irgendwie möglich ist!

Manchmal muss man ein Upgrade einer Maschine durchführen, wenn man nicht auf einfache Weise den normalen Upgradeprozess durchführen kann. Der häufigste Grund hierfür ist, dass sich die Maschine an einem anderen Ort befindet und man daher keinen Zugriff auf die Systemkonsole hat. Man kann dies normalerweise durchführen, indem man vorsichtig diesen Prozess befolgt:

Lege die Installationsdateien in einem »guten« Verzeichnis ab. Stelle sicher, dass du genügend freien Platz hast!
Deaktiviere das Starten aller »unsicheren« Applikationen beim Booten: Es wird Momente während der Installation geben, in denen zwar PF nicht geladen werden kann, deine Applikationen aber eventuell normal gestartet und ausgeführt werden. Jede Applikation, deren Sicherheit von PF abhängig ist, sollte daher zuvor deaktiviert werden; sie sollte auch erst erneut aktiviert werden, wenn die Funktionsweise von PF nach dem Upgrade sichergestellt worden ist. Es mag weitere Applikationen geben, die du während dem Upgradeprozess nicht ausführen möchtest - beende und deaktiviere sie ebenfalls.
Überprüfe den Kernel: Obwohl die meisten Leute diesen Schritt überspringen können, kann es sein, dass du den 4.3-Kernel angepasst hast. Wenn das der Fall ist, dann wirst du sehr wahrscheinlich das gleiche mit dem 4.4-Kernel machen müssen. Insbesondere wenn du ein Upgrade mit einem Remotesystem durchführst, ist jetzt der richtige Zeitpunkt gekommen, um sicherzustellen, dass der neue Kernel geladen werden kann, wenn du das System neustartest. Falls irgendwelche Änderungen am Kernel gemacht werden müssen, ist es am sichersten, das ganze auf einem lokalen 4.4-System zu machen. Dabei kann es sich um so einfache Dinge wie eine Änderung eines bestimmtes Devices mittels config(8) handeln, doch könnte es genauso gut bedeuten, dass du den Kernel neuerzeugen musst, da sich eine von dir benötigte Option nicht im GENERIC-Kernel befindet. Lies bitte FAQ 5 - Das System aus dem Quelltext erzeugen, bevor du in Erwägung ziehst, deinen Kernel neu zu erzeugen.
Installiere neue(n) Kernel
```
export RELEASEPATH=/usr/rel   # wo du die Dateien ablegst
cd ${RELEASEPATH}
rm /obsd ; ln /bsd /obsd && cp bsd /nbsd && mv /nbsd /bsd
cp bsd.rd bsd.mp /
```
(Wenn du einen Multiprozessorkernel verwendest, benutze
rm /obsd ; ln /bsd /obsd && cp bsd.mp /nbsd && mv /nbsd /bsd
stattdessen)
Achte auf die zusätzlichen Schritte, um den primären Kernel zu kopieren: Diese werden durchgeführt, um zu gewährleisten, dass immer eine funktionsfähige Kopie des Kernels auf der Platte ist, sodass das System booten kann, falls ein Stromausfall oder ein Systemabsturz zu sehr ungünstiger Zeit eintreten.
Installiere neue /etc/firmware-Dateien und andere kritische Dienstprogramme: Einige hochgeladene »firmware«-Dateien wurden eventuell aktualisiert. Falls du davon betroffen bist, musst du Dateien in deinem /etc/firmware-Verzeichnis aktualisieren. Dies betrifft jedoch nur Benutzer von ein paar Geräten - andere Benutzer können diesen Schritt ohne weiterer Beeinträchtigung ausführen können. Um sicherzustellen, dass dein Netzwerk während des Neustarts voll funktionsfähig ist, benötigt der neue Kernel aktualisierte ifconfig und pfctl Dienstprogramme, um im nächsten Schrit nach dem Neustart richtig konfiguriert werden zu können. Es gilt erneut, dass dieser Schritt von allen Nutzern gefahrlos durchgeführt werden kann, aber wenn du ein Remoteupgrade über eine pppoe(4)-Verbindung durchführst, kann dieser Schritt äußerst wichtig sein. Um die Firmwaredateien und ifconfig aus base44.tgz zu extrahieren, führe Folgendes als root aus:
```
tar -C / -xzphf ${RELEASEPATH}/base44.tgz ./etc/firmware ./sbin/ifconfig ./sbin/pfctl
```
Starte mit dem neuen Kernel neu: Es mag verführerisch sein, diesen Schritt zu überspringen, aber er sollte nun durchgeführt werden, da - wie üblich - der neue Kernel die alten Userlandapplikationen ausführen wird (wie zum Beispiel den bald wichtigen reboot!), ein neues Userland aber häufig NICHT mit einem alten Kernel zusammen funktioniert.
Installiere neue Userlandapplikationen Installiere noch NICHT etc44.tgz und xetc44.tgz, da sie deine aktuellen Konfigurationsdateien überschreiben würden!
```
export RELEASEPATH=/usr/rel
cd ${RELEASEPATH}
tar -C / -xzphf base44.tgz
tar -C / -xzphf comp44.tgz
tar -C / -xzphf game44.tgz
tar -C / -xzphf man44.tgz
tar -C / -xzphf misc44.tgz
tar -C / -xzphf xbase44.tgz
tar -C / -xzphf xfont44.tgz
tar -C / -xzphf xserv44.tgz
tar -C / -xzphf xshare44.tgz
```
Hinweis: Nicht alle Dateisets müssen für alle Einsatzgebiete installiert werden, wenn du jedoch ein Dateiset ursprünglich installiert hast, solltest du es jetzt doch mit einem neuen Dateiset upgraden.
Hinweis: Die Dateien in /etc werden weiter unten getrennt behandelt, sodass etc44.tgz und xetc44.tgz an dieser Stelle NICHT entpackt werden.
Upgrade /dev. Die neue MAKEDEV-Datei wird durch die Installation von base44.tgz nach /dev kopiert, sodass du einfach nur Folgendes machen musst:
```
cd /dev
./MAKEDEV all
```
Upgrade /etc wie unten beschrieben.
Starte neu

Während des Prozesses könnte sendmail(8) viele Fehlermeldungen wie diese erzeugen:

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

Diese Nachrichten können an dieser Stelle unbesorgt ignoriert werden, du könntest aber auch sendmail(8) während dem Upgradeprozess beenden. Zu diesem Zeitpunkt arbeitet sendmail noch nicht richtig und muss (als Teil des Reboots) neugestartet werden, bevor man erwarten kann, dass er E-Mails richtig verarbeitet.

Letzte Schritte

Falls du nun unter Verwendung eines Installationskernels (und dadurch einen formalen Upgradeprozesses) oder aber ein Binärupdate im laufenden System, gibt es einige Schritte, die manuell durchgeführt werden müssen.

1. Neue Benutzer und Gruppen

Neue Benutzer werden für rtadvd und das bald erscheinende ypldap(8) benötigt. Lege diese Benutzer und Gruppen mit useradd(8) an:

useradd -u92 -g=uid -c"IPv6 Router Advertisement Daemon" -d/var/empty -s/sbin/nologin _rtadvd
useradd -u93 -g=uid -c"YP to LDAP Daemon" -d/var/empty -s/sbin/nologin _ypldap

2. `/etc` upgraden

Du solltest die etc44.tgz-Dateien in ein temporäres Verzeichnis entpacken:

tar -C /tmp -xzphf ${RELEASEPATH}/etc44.tgz

Dateien, die ordnungsgemäß von etc44.tgz »so wie sie sind« kopiert werden können:

etc/magic
etc/netstart
etc/rc
etc/rc.conf
etc/security
etc/services
etc/mail/localhost.cf
etc/mail/sendmail.cf
etc/mail/submit.cf
etc/mtree/4.4BSD.dist

Bedenke, dass es möglich IST, all diese Dateien lokal zu modifizieren. Solltest du sie also modifiziert haben, kopiere diese Dateien NICHT rüber sondern folge stattdessen dem sysmerge(8)-Prozess. Achte besonders auf mail/*, wenn du eine angepasste Sendmail(8)-Konfiguration verwendest. Hier sind Copy&Paste-Zeilen, um diese Dateien zu kopieren, angenommen, dass du etc44.tgz in dem zuvor empfohlenen Verzeichnis abgelegt hast:

cd /tmp/etc
cp magic netstart rc rc.conf security services /etc
cp mtree/* /etc/mtree
cp mail/*.cf /etc/mail # Careful on this one!!

3a. Lokal geänderte Dateien mit einer Korrekturroutine einpflegen

Verwende entweder diese Korrekturroutine ODER folge dem sysmerge-Prozess weiter unten; aber nicht beides.

Diese Dateien werden sehr wahrscheinlich lokale Änderungen haben, sollten aber dennoch für 4.4 aktualisiert werden. Wenn du diese Dateien nicht geändert hast, kopiere einfach die neue Version, ansonsten musst du die Änderungen in deine Dateien übernehmen:

etc/changelist
etc/ftpusers
etc/hosts.lpd
etc/man.conf
etc/sudoers
etc/mail/aliases
etc/ssh/ssh_config
etc/ssh/sshd_config

Die Änderungen dieser Dateien befinden sich in dieser Korrekturroutine. Du kannst versuchen, sie zu verwenden, indem du das Folgende als root ausführst:

cd /
patch -C -p0 < upgrade44.patch

Hiermit wird geprüft, wie gut die Korrektur sich in DEIN System einbinden lässt. Um ihn tatsächlich einzubinden, lass die Option -C weg. Beachte, dass es sehr wahrscheinlich ist, dass wenn du diese Dateien modifiziert, nicht immer auf dem aktuellsten Stand gehalten hast oder von einem Schnappschuss von 4.3 aus upgradest, diese Korrektur nicht richtig angewandt werden kann. In diesen Fällen musst du die Änderungen manuell vornehmen. Teste diesen Prozess bitte, bevor du dich darauf verlässt, dass alles funktioniert, wenn du ihn an einem schwer zu erreichenden System anwendest.

Die folgenden Dateien haben Änderungen erfahren, die du dir genauer ansehen solltest, da sie sehr wahrscheinlich nicht direkt kopiert oder eingepflegt werden können (d. h. wenn du pf.conf verwendest, dann solltest du dir die empfohlene Änderung der Sicherheitsrichtlinie angucken und für dich selbst entscheiden, ob sie für deine Anwendungen eingesetzt werden kann):

etc/dhclient.conf
etc/pf.conf
var/www/conf/httpd.conf

Es gibt noch ein paar weitere Dateien, die du löschen kannst, da sie nicht länger in 4.4 verwendet werden:

rm /etc/dhcpd.interfaces

Verwende schlussendlich newaliases(8), um die Alias-Datenbank zu aktualisieren, mtree(8), um alle neuen Verzeichnisse zu erstellen:

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

3b. Lokal geänderte Dateien mit sysmerge(8) einpflegen

Verwende entweder diesen sysmerge(8)-Prozess ODER den Korrekturroutinen-Prozess weiter oben; nicht beide

Das neue sysmerge(8)-Werkzeug vergleicht die Dateien, die sich tatsächlich auf deinem System befinden, mit den Dateien, die mit einer frischen Installation eingesetzt worden wären, und hilft dir dabei, die Änderungen in dein System einzupflegen. Beachte, dass im Gegensatz zur Korrekturroutine keine Vermutungen darüber angestellt werden, was sich auf deinem System befindet und was nicht, so dass du sysmerge(8) verwenden kannst, um zwischen mehr beliebigen Punkten im Entwicklungsprozess (wie zum Beispiel einem früheren -current zu 4.4-release oder von einem -current zum nächsten) wechseln kannst.

Bitte lies die sysmerge(8)-Handbuchseite, bevor du es mit deinem System verwendest. Es wird dir ebenfalls dazu geraten, die diff(1)-, sdiff(1)- und sogar die more(1)-Handbuchseite nochmal durchzulesen, bevor du weitermachst.

Angenommen, die Dateien etc44.tgz und xetc44.tgz befinden sich in deinem $RELEASEPATH, dann führe Folgendes aus:

# sudo sysmerge -as $RELEASEPATH/etc44.tgz -x $RELEASEPATH/xetc44.tgz

Sysmerge(8) wird dir eine »unified diff(1)« erstellen, sie über deinen bevorzugten $PAGER anzeigen (d. h. more(1)) und dich für die meisten geänderten Dateien fragen, was du mit den geänderten Dateien machen möchtest:

  Use 'd' to delete the temporary ./var/www/htdocs/index.html
  Use 'i' to install the temporary ./var/www/htdocs/index.html
  Use 'm' to merge the temporary and installed versions
  Use 'v' to view the diff results again

  Default is to leave the temporary file to deal with by hand

Wenn du deine bestehende Datei beibehalten willst, entferne die temporäre Datei; wenn du die bestehende Datei mit der neuen Version ersetzen willst, installiere die temporäre Datei. Wenn du die beiden ineinander einpflegen möchtest, führt die Wahl von »m« dich in sdiff(1), wo du die Dateien manuell ineinander einpflegen kannst. Standardmäßig werden keine Änderungen durchgeführt und die Datei muss später verarbeitet werden - per Hand.

Obwohl es funktionieren kann, raten wir nicht dazu, sysmerge zu verwenden, um neue Benutzer in dein System zu integrieren. Verwende stattdessen lieber die useradd(8)-Zeile weiter oben. Wir gehen davon aus, dass sie nicht so fehleranfällig ist. (Hinweis: wähle nicht aus, die temporäre master.passwd-Datei über deine vorhandene zu installieren!).

Sysmerge(8) speichert alle ersetzten Dateien in einem temporären Verzeichnis (ähnlich wie /var/tmp/sysmerge.24959/backups), sodass du Änderungen, die du versehentlich vorgenommen hast, wieder rückgängig machen kannst. Beachte, dass daily(8) diese alten Dateien aus dem Verzeichnis löscht.

4. Überprüfe den Kernel

Hinweis: Die meisten Leute können diesen Schritt überspringen!

Wenn du den Anweisungen gefolgt bist, wie man einen Upgradeprozess ohne Installationskernel durchführt, hast du diesen Schritt bereits absolviert. Wenn du jedoch den Installationskernel und unter 4.3 einen angepassten Kernel verwendet hast, wirst du das gleiche vermutlich auch unter 4.4 machen wollen. Dabei kann es sich um so einfache Dinge wie eine Änderung eines bestimmtes Devices mittels config(8) handeln, doch könnte es genauso gut bedeuten, dass du den Kernel neuerzeugen musst, da sich eine von dir benötigte Option nicht im GENERIC-Kernel befindet. Lies bitte FAQ 5 - Das System aus dem Quelltext erzeugen, bevor du in Erwägung ziehst, deinen Kernel neu zu erzeugen.

5. Pakete upgraden

Wenn du irgendwelche Pakete auf deinem System installiert hattest, solltest du sie aktualisieren, nachdem du das Basissystem erfolgreich upgegradet hast. Du solltest jedoch darauf achten, dass viele Pakete weitere Konfigurationsschritte vor (und/oder nach) dem Paket-Upgrade benötigen. Lies die Upgradeanleitung für die Anwendung durch, wenn du weitere Informationen benötigst.

Von folgenden Paketen ist bekannt, dass es signifikante Upgradeprobleme gibt, die eine Großzahl der Anwender betreffen werden. Dass ein Pakete nicht in dieser Liste geführt wird, bedeutet nicht, dass es nicht eventuell doch Probleme geben wird. Du musst selbst überprüfen, ob die Anwendungen, die DU verwendest, auch problemlos upgegradet werden können.

ejabberd: Wenn ejabberd von 1.x auf 2.x upgegradet wird, musst du wie auf http://www.ejabberd.im/migrate-host beschrieben deine Datenbank sichern und wiederherstellen.
Postgresql: Du musst deine Datenbank vor einem Upgrade sichern und nachträglich wiederherstellen.

Mit den Paketwerkzeugen kann man direkt mittels pkg_add -u aktualisieren. Um zum Beispiel alle deine Pakete zu aktualisieren, stelle sicher, dass PKG_PATH auf das Verzeichnis deiner CD oder eines FTP-Spiegelservern zeigt, in dem sich die 4.4-Pakete befinden. Verwende dann Folgendes:

# pkg_add -ui -F update -F updatedepends

Dabei gibt -u den Updatemodus an und -i den interaktiven Modus, sodass pkg_add dich um Rat bittet, sollten Probleme auftreten. Lies die pkg_add(1)-Handbuchseite und das Kapitel Verwaltung der Pakete der FAQ für weitere Informationen.