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

Upgradeanleitung: 4.0 auf 4.1

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

Ü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.1-Kernel anwenden kannst.

rc.conf: Anders als bei früheren Anleitungen gehen wir nun davon aus, 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.

Besonderer Hinweis für ARM-Besitzer (armish, zaurus): Änderungen an der ABI setzten einen etwas anderen Upgradeprozess voraus, wenn der Standardinstallationskernel nicht verwendet wird. Starte das System nicht nach der Installation des neuen Kernels neu - erst, wenn das Userland ebenfalls installiert wurde.

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.1-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.0-Kernel angepasst hast. Wenn das der Fall ist, dann wirst du sehr wahrscheinlich das gleiche mit dem 4.1-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.1-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 /
```
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: 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 base41.tgz zu entpacken, verwende das Folgende als root vor dem nächsten Schritt:
```
cd /
tar -C / -xzpf ${RELEASEPATH}/base41.tgz ./etc/firmware
```
Starte mit dem neuen Kernel neu (gilt nicht für ARM-Besitzer): 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.
Hinweis: ARM-Besitzer (armish/zaurus) SOLLTEN diesen Schritt für diesen speziellen Upgradedurchlauf überspringen.
Installiere neue Userlandapplikationen Installiere noch NICHT etc41.tgz und xetc41.tgz, da sie deine aktuellen Konfigurationsdateien überschreiben würden!
```
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
```
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 etc41.tgz und xetc41.tgz an dieser Stelle NICHT entpackt werden.
Upgrade /dev. Die neue MAKEDEV-Datei wird durch die Installation von base41.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 unbesorgt ignoriert werden, du könntest aber auch sendmail(8) während dem Upgradeprozess beenden.

Letzte Schritte

1. `/etc` upgraden

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.1. Neue Benutzer und Gruppen

Sowohl ein RIP-Daemon als auch ein Hoststate-Daemon wurden integriert. Um diese neuen Daemons benutzen zu können, werden neue Benutzer und Gruppen benötigt. Füge als root mit useradd(8) die folgenden Benutzer und Gruppen hinzu:
```
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
```
Mit diesen Schritten werden sowohl die neuen Benutzer als auch die zu ihnen gehörenden Gruppen angelegt. Deine Systemeinrichtung wird es vermutlich ermöglichen, dass du diesen Befehl einfach kopieren und einfügen kannst.

1.2. Funktionsänderungen

Hierbei handelt es sich nicht um eine vollständige Liste aller Änderungen, die zwischen 4.0 und 4.1 stattgefunden haben. Stattdessen werden hier nur wichtige Dinge erwähnt, die einen Großteil der Anwender während des Upgradeprozesses betreffen werden. Wirf einen Blick auf plus41.html und in die CVS-Changelogs, wenn du eine vollständigere Liste sehen möchtest.

»flags S/SA keep state« ist in pf.conf(5) impliziert
flags S/SA keep state ist nun Standard für pass-Regeln in pf.conf(5). Des Weiteren wurden die beiden Optionen no state und flags any so umgestellt, dass sie diesen Standard überschreiben. Aktuelle Regelsätze können weiterhin geladen werden, doch wird sich ihr Verhalten geringfügig ändern, da diese Standard restriktiver sind. Regelsätze, die ohne Zustand filtern (no state) oder Zustände (states) für Zwischenpakete erstellen müssen (flags any, sollten aktualisiert werden, um ausdrücklich das gewünschte Verhalten zu erzielen.
Vor allem beim enc0-Interface ist besondere Vorsicht geboten, da Floatingstates ein potenzielles Problem für die Filterung von IPsec-Traffic darstellen: Zustände, müssen an ein Interface gebunden werden, um unverschlüsselten Datenverkehr zu verhindern, sollte isakmpd(8) beendet werden. Daher sollten alle Regeln für das enc0-Interface explizit mit keep state (if-bound) versehen werden.
Die DOS-MBR-Partitionen von FreeBSD und NetBSD werden nicht länger zum Abspeichern von Disklabels benutzt und auch nicht länger nach einem Disklabel durchsucht.
Deshalb werden Platten, die nur DOS-MBR-Partitionen für FreeBSD oder NetBSD haben, keine »a«-Partition im vorgetäuschten Disklabel auflisten. Das Disklabel solcher Platten wird vom ersten Sektor gelesen und auch dort gespeichert - dort könnte sich aber ein versehentlich eingerichtetes Disklabel befinden. Verwende fdisk(8), um den Partitionstyp auf OpenBSD (»A6«) umzustellen, damit du das vorhandene Disklabel benutzen kannst.
amd64, i386, macppc und mvmeppc versuchen nicht länger, von der ersten NetBSD-Partition zu booten, wenn keine OpenBSD-Partition gefunden wurde.
Verwende auch in diesem Fall fdisk(8), um den Partitionstyp auf OpenBSD (»A6«) umzustellen.
Prozessaccounting wird nun während des Bootvorgangs anders (de)aktiviert
Um Accouting während des Bootvorgangs zu aktivieren, setze die neue rc.conf-Variable »accouting=YES«. Das Vorhandensein der Datei /var/account/acct führt nicht länger zum automatischen Start.
spamd(8) läuft nun standardmäßig im Greylistmodus.
Während bisher Greylisting über die Option -g aktiviert werden musste, ist es nun der Standardlaufzeitmodus. Die Option -b (die bisher genutzt wurde, um spamd(8) die zu verwendende IP-Adresse mitzuteilen) kann nun verwendet werden, um spamd im reinen Blacklistmodus einzusetzen. Die neue Option -l gibt nun an, auf welcher IP spamd lauschen soll.
spamd.conf(5) nun in /etc/mail abgelegt.
Die spamd.conf(8)-Datei, die bisher in /etc lag, wurde in /etc/mail verschoben. Verschiebe deine spamd.conf-Datei in /etc/mail, damit spamd(8) die richtige Konfiguration lädt.
Die Kernelsensorsysctl(3) MIB ist nun hierarchisch.
Die Sensorsysctl(3) MIB enthält nun sowohl den Namen des Sensordevices als auch den Typ und den Index des tatsächlichen Sensors. Während die Ausgabe von »sysctl hw.sensors« bisher »hw.sensors.12=it0, Temp 1, 25.00 degC« war, wirst du nun »hw.sensors.it0.temp0=25.00 degC« sehen. Aktualisiere deine sensorsd.conf(5)-Datei, damit der neue Name deines Sensors berücksichtigt wird.

1.3. `/etc`-Dateiänderungen

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

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

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

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/*

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 etc41.tgz in dem zuvor empfohlenen Verzeichnis abgelegt hast:


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     # Careful on this one!!
cp mail/spamd.conf /etc/mail      # OR... 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/

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/changelist
etc/ftpusers
etc/login.conf
etc/newsyslog.conf
etc/services
etc/sysctl.conf
etc/mail/aliases
var/cron/tabs/root

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 < upgrade41.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 3.9 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/hostapd.conf
etc/pf.conf
etc/sensorsd.conf

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.0 einen angepassten Kernel verwendet hast, wirst du das gleiche vermutlich auch unter 4.1 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.

3. 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 dem folgenden Paket ist bekannt, dass ein Upgrade nicht trivial ist und eine große Anzahl der Benutzer Probleme damit haben werden. Die Tatsache, das ein Paket nicht in dieser Liste aufgeführt wird, bedeutet nicht, dass es keine Probleme beim Upgrade geben wird. Du musst dich also selbst mit den Pakete beschäftigen, die DU einsetzen möchtest.

Postgresql: du musst deine Datenbank vor dem Upgrade sichern (dump) und nachträglich wiederherstellen.

es schwere Upgradeprobleme 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-Spiegelservers zeigt, in dem sich die 4.1-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.