[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] | [FAQ-Index]

Upgradeanleitung: 4.1 auf 4.2

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.1 und 4.2 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 plus42.html und die CVS-Changelogs.

Packages verwenden nun libexpat, das mit X ausgeliefert wird; xbase42.tgz ist dein Freund:
Der libexpat-Port wurde entfernt. Packages verwenden stattdessen nun libexpat, die mit X ausgeliefert wird. Sehr viele Packages benötigen über weitere Abhängigkeiten libexpat. Zum Beispiel die etlichen Packages, die gettext benötigen, benötigen auch libexpat.
Das bedeutet, dass du viele Systeme, die bisher ohne X ausgekommen sind, xbase42.tgz installieren müssen. Falls du dies nicht machst und ein Package installieren willst, das libexpat benötigt, wird pkg_add(1) eine Fehlermeldung ausgeben.
Beachte ebenfalls, dass die Übersetzung von Ports nur mit einer vollständigen Installation unterstützt wird; darunter fallen auch alle X-Dateisets.
Nachdem du all deine Packages auf 4.2-Versionen aktualisiert hast, entferne das alte expat-Package von deinem System:
# pkg_delete expat
Dies wird große Auswirkung für eine Großzahl der Anwender haben! Es war eine unglückliche Entscheidung, dessen große Wirkung nicht frühzeitig erkannt wurde. In Version 4.3 wird libexpat Teil von base43.tgz sein, so dass das Problem dann behoben ist.
Beginn von X.org v7.2, Ende von XF3:
Es wurde eine neue Version von X in OpenBSD 4.2 eingebunden. Es kann sein, dass die alte X-Konfiguration angepasst werden muss, doch werden viele Anwender bereits über keine X-Konfiguration mehr verfügen.
Mit der Unterstützung der neuesten Versionen von X.org wurde die Unterstützung für XF3 auf der i386-Plattform eingestellt (die einzige Plattform, die diese Unterstützung noch hatte). XF3 wurde für die Unterstützung sehr alter Videochipsätze benötigt, die mit XF4 oder X.org nicht mehr genutzt werden konnten. Es werden wohl nicht sonderlich viele Leute etwas davon merken.
Die neue X.org-Version äntert eine Großzahl Konfigurationsdateien, so dass eine eigene Sektion in diesem Upgradeprozess für X-Anwender angelegt wurde.
Aktualisierter ahci-Treiber kann Auswirkung auf die Plattenhandhabung haben:
Kürzlich vorgenommene Änderungen am ahci(4)-Subsystem könnten dazu führen, dass Geräte, die zuvor vom wd(4)-Treiber (z. B. wd0) gehandhabt wurden, nun als sd(4)-Gerät (z. B. sd0) angesprochen werden. Achte auf die dmesg-Ausgabe während des Bootvorgangs. Ein Laufwerk, das zuerst wie folgt erkannt wurde:

pciide1 at pci0 dev 31 function 2 "Intel 82801GBM AHCI SATA" rev 0x02: DMA, chanel 0 wired to native-PCI, channel 1 wired to native-PCI pciide1: using apic 2 int 11 (irq 11) for native-PCI interrupt wd0 at pciide1 channel 0 drive 0: <FUJITSU MHV2080BH> wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
könnte nun so aufgelistet werden:

ahci0 at pci0 dev 31 function 2 "Intel 82801GBM AHCI SATA" rev 0x02: AHCI 1.1: apic 2 int 16 (irq 11) scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: <ATA, FUJITSU MHV2080B, 0084> SCSI2 0/direct fixed sd0: 76319MB, 76319 cyl, 64 head, 32 sec, 512 bytes/sec, 156301488 sec total
Dies wird Probleme für jene verursachen, die ihre Systeme remote upgraden, da die fstab-Datei nicht »korrekt« ist und das System den Bootvorgang nicht abschließen kann. Unglücklicherweise ist die Handhabung der Platten abhängig von vielen Aspekten, einschließlich der BIOS-Konfigurationen. FALLS du also ein AHCI-SATA-Interface hast, musst du mit einer gleich konfigurierten lokalen Maschine testen, um zu testen, ob die /etc/fstab-Datei angepasst werden muss.
Vermutlich werden nur wenige Anwender hiervon betroffen sein, da ahci(4)-Geräte bisher eher gering verbreitet sind; es werden aber immer mehr.
Änderung der bgpd-Filtersprache:
bgpd-Filter, die nur mit prefixlen als Filterparameter arbeiten, müssen nun eine Adressfamilie als Bezeichner wie zum Beispiel inet oder inet6 angeben:

allow from any inet prefixlen 8 - 24 deny from any inet6 prefixlen > 64

Als Erinnerung: bgplg und zugehörige Binarys werden während der Installation und während des Upgrades deaktiviert. Wenn du sie verwendest, dann musst du sie wie in bgplg(8) beschrieben wieder aktivieren.
In neuen Installationen wird vom SSH-Protokoll 1 abgeraten:
Neue OpenBSD-Installation akzeptieren nun standardmäßig keine SSH-v1-Verbindungen mehr. Dieser Upgradeprozess wird /etc/ssh zwar nicht ersetzen, doch solltest du sie manuell anpassen, um das neue Verhalten zu aktivieren. Die folgende Diff zeigt, was auf neuen Installationen geändert wurde:
--- ./etc/ssh/sshd_config Sat Mar 10 20:31:32 2007 +++ ../42/etc/ssh/sshd_config Tue Aug 28 11:59:52 2007 @@ -11,3 +11,2 @@ #Port 22 -#Protocol 2,1 #AddressFamily any @@ -15,2 +14,7 @@ #ListenAddress :: + +# Disable legacy (protocol version 1) support in the server for new +# installations. In future the default will change to require explicit +# activation of protocol 1 +Protocol 2
Noch einmal: Diese Änderung ist KEIN Bestandteil des standardmäßigen Upgradeprozesses.
Änderungen in der Umgebungsübergabe in sudo(8):
Aus Sicherheitsgründen setzt sudo(8) die Umgebungsvariablen auf ein kleines Standardset zurück, in die nur wenige bestimmte Variablen aus der vorherigen Umgebung übernommen werden.
Damit ein Großteil der Aufrufe weiterhin wie erwartet funktionieren, fügt der weiter unten aufgeführte Patch die Zeile »Defaults env_keep« in deine /etc/sudoers-Datei ein und ansonsten versuchen, dass die Datei wie die in etc42.tgz aussieht - beides könnte fehlschlagen. In diesem Fall sicherstellen, dass deine sudoers-Datei eine Zeile wie diese enthält:
%wheel ALL=(ALL) SETENV: ALL -- or -- %wheel ALL=(ALL) NOPASSWD: SETENV: ALL
Hier wird angenommen, dass du möchtest, dass die Benutzer in der Gruppe »wheel« volle sudo-Rechte erhalten. Es ist wahrscheinlich ratsam zu testen, ob sudo(8) erwartungsgemäß arbeitet, bevor du dich vom System abmeldest, nachdem die Patchdatei eingespielt wurde.
[nur Alpha] Einige de(4)-NICs werden zu dc(4):
Auf der Alpha-Plattform werden einige Netzwerkkarten, die zuvor vom de(4)-Treiber unterstützt wurden, jetzt vom dc(4)-Treiber unterstützt.
FALLS deine Netzwerkkarte dazugehört, musst du auf jeden Fall deine /etc/hostname.deX (Hinweis: Hardlink) und deine pf.conf anpassen.
Noch einmal: Dies gilt nur für die Alpha-Plattform.
[nur i386] apm(4) hat Vorrang gegenüber acpi(4):
Die Geräteerkennung für i386 wurde so verändert, dass apm(4) gegenüber acpi(4) bevorzugt wird. Das bedeutet, dass nur apm aktiviert wird, falls deine Hardware sowohl über APM- als auch ACPI-Geräte verfügt. Falls du aus irgendeinem Grund acpi bevorzugen solltest, deaktiviere apm in deinem acpi-aktivierten Kernel unter Verwendung von config(8) oder boot -c.
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.2-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.2-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!
Deaktivere 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.1-Kernel angepasst hast. Wenn das der Fall ist, dann wirst du sehr wahrscheinlich das gleiche mit dem 4.2-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.2-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 genausogut 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 /
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üstiger Zeit eintreten.
Installiere neue /etc/firmware-Dateien: Einige hochgeladene »firmware«-Blobs 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 die Firmwaredateien aus base42.tgz zu entpacken, verwende das Folgende als root vor dem nächsten Schritt:
cd / tar -C / -xzphf ${RELEASEPATH}/base42.tgz ./etc/firmware
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 etc42.tgz und xetc42.tgz, da sie deine aktuellen Konfigurationsdateien überschreiben würden!
export RELEASEPATH=/usr/rel cd ${RELEASEPATH} tar -C / -xzphf base42.tgz tar -C / -xzphf comp42.tgz tar -C / -xzphf game42.tgz tar -C / -xzphf man42.tgz tar -C / -xzphf misc42.tgz tar -C / -xzphf xbase42.tgz tar -C / -xzphf xfont42.tgz tar -C / -xzphf xserv42.tgz tar -C / -xzphf xshare42.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 etc42.tgz und xetc42.tgz an dieser Stelle NICHT entpackt werden.
Upgrade /dev. Die neue MAKEDEV-Datei wird durch die Installation von base42.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 dire
    ctory, 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. `/etc` upgraden

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

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

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

etc/magic etc/man.conf etc/netstart etc/rc etc/rc.conf etc/rpc etc/services etc/mail/helpfile etc/mail/localhost.cf etc/mail/sendmail.cf etc/mail/submit.cf etc/mtree/4.4BSD.dist etc/mtree/BSD.local.dist etc/mtree/special

Bedenke, dass es möglich IST, all diese Dateien lokal zu modifizieren. Solltest du sie also modifiziert haben, musst du sie manuell anpassen. 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 etc42.tgz in dem zuvor empfohlenen Verzeichnis abgelegt hast:

cd /tmp/etc cp magic man.conf netstart rc rc.conf rpc services /etc cp mail/helpfile mail/localhost.cf mail/submit.cf /etc/mail cp mail/sendmail.cf /etc/mail # Careful on this one!!

Dateien, die per Hand angepasst werden müssen, sodass alle lokalen Änderungen beibehalten werden (falls sie vom Original abweichen) - ansonsten kannst du sie auch einfach kopieren:

etc/ntpd.conf etc/sensorsd.conf etc/ssh/ssh_config etc/ssl/x509v3.cnf etc/sudoers etc/sysctl.conf etc/wsconsctl.conf var/www/conf/httpd.conf

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

cd / patch -C -p0 < upgrade42.patch

Hiermit wird geprüft, wie gut der Patch 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 Snapshot von 3.9 aus upgradest, dieser Patch 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 bgpd.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/bgpd.conf etc/mail/spamd.conf etc/ospfd.conf etc/ssh/sshd_config

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

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

2. Ü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.1 einen angepassten Kernel verwendet hast, wirst du das gleiche vermutlich auch unter 4.2 machen wollen. Dabei kann es sich um so einfache Dinge wie eine Änderung eines bestimmtes Devices mittels config(8) handeln, doch könnte es genausogut 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.

3. X-Konfigurationsdateien

Aufgrund signifikanter Änderungen in X für dieses Release, wäre das X-Upgrade für 4.2 wohl am einfachsten, wenn du deine vorhandenen Konfigurationsdateien sicherst, xetc42.tgz entpackst und die von dir vorgenommenen Änderungen manuell wieder einspielst.

Die Dateien, die du am wahrscheinlichsten speichern solltest, sind /etc/X11/xorg.conf und /etc/X11/xinit/xinitrc. Da X nun sehr oft OHNE xorg.conf-Datei läuft, könntest du erst einmal versuchen, ob du auch ohne zurückkopierte Datei auskommst.

Entpacke xetc42.tgz so, wie du auch andere Dateisets extrahierst:

export RELEASEPATH=/usr/rel cd ${RELEASEPATH} tar -C / -xzphf xetc42.tgz

4. Packages upgraden

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

Vom folgenden Package ist bekannt, dass es signifiakten Upgradeprobleme gibt, die eine Großzahl der Anwender betreffen werden. Dass ein Package 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 geupgradet werden können.

xfce: Verzeichnis und Dateien der Basiskonfiguration wurden generalüberholt. Du musst deine Konfiguration eventuell von Grund auf neu einrichten.

Bevor du weitermachst, solltest du über die folgenden großen Änderungen im 4.2-Release informiert sein:

Der libexpat-Port wurde entfernt. Packages verwenden stattdessen nun libexpat, die mit X ausgeliefert wird. Sehr viele Packages benötigen über weitere Abhängigkeiten libexpat. Zum Beispiel die etlichen Packages, die gettext benötigen, benötigen auch libexpat. Bevor du also Packages hinzufügen oder upgraden kannst, musst du zuvor sehr wahrscheinlich xbase42.tgz installiert haben - selbst wenn die Packages, die du installieren möchtest, keine grafische Funktionalitäten anbieten. Lies die FAQ, um zu erfahren, wie xbase42.tgz in ein installiertes System eingebunden werden kann. Falls du dies nicht machst und ein Package installieren willst, das libexpat benötigt, wird pkg_add(1) eine Fehlermeldung ausgeben.
Wenn du pkg_add(1) in Verbindung mit sudo(8) verwendest, dann musst du Änderungen an /etc/sudoers vornehmen, wie sie mit der Patchfile eingespielt werden sollen. Lies über Änderungen in sudo(8) für weiterführende Informationen.

Mit den Packagewerkzeugen kann man direkt mittels pkg_add -u aktualisieren. Um zum Beispiel alle deine Packages zu aktualisieren, stelle sicher, dass PKG_PATH auf das Verzeichnis deiner CD oder eines FTP-Mirrors zeigt, in dem sich die 4.2-Packages 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)-Manualseite und das Kapitel Verwaltung der Packages der FAQ für weitere Informationen.

Du wirst sehr wahrscheinlich eine Ausgabe wie diese sehen, wenn du die genannten Kommandos ausführst:

Looking for updates: complete Cannot find updates for expat-2.0.0 Proceed? [y/N]

Dies weist darauf hin, dass du das libexpat-Problem hast und nun xbase42.tgz wie zuvor beschrieben installieren musst. Wenn du xbase42.tgz nicht installiert hast, dann solltest du das Packageupgrade nun beenden, xbase42.tgz installieren und das Packageupgrade erneut starten.

Zum Schluss - wenn alle Packages geupgradet wurden - entferne das alte expat-Package von deinem System:

# pkg_delete expat