![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ-Index] [Zum Kapitel 4 - Installationsanleitung] [Zum Kapitel 6 - Vernetzung]
,------o-----------o----X 4.9 Stable
| . .
| . ,------o---------o----X 5.0 Stable
| . | . .
| . | . ,----o----------o--> 5.1 Stable
| . | . | . .
| . | . | . ,-----o--> 5.2 Stable
| . | . | . | .
| . | . | . | .
-->4.9Rel----->5.0Rel----->5.1Rel----->5.2Rel----> Current
Zeit --->
In und an -current findet die aktive Entwicklung statt, das sich, schließlich, in das nächste -release von OpenBSD verwandelt. Alle sechs Monate, wenn eine neue Version von OpenBSD veröffentlicht wird, wird -current etikettiert und somit zu -release: ein fester Punkt in der Geschichte des Quelltextbaums. Kein -release wird jemals verändert; es ist das, was auf den CDs und FTP-Servern vorliegt.
-stable basiert auf -release und ist ein Zweig des Hauptentwicklungspfads von OpenBSD. Wenn sehr wichtige Korrekturen in -current eingebracht werden, so werden sie in den Zweig -stable »zurückportiert« (eingefügt). Das ist der Grund, warum -stable auch als »patch-branch« bezeichnet wird. In obiger Illustration sind die vertikalen, gepunkteten Linien Fehlerkorrekturen, die in die -stable-Zweige eingefügt wurden. Du wirst auch bemerken, dass der Lebenszyklus des Zweigs 4.9-stable im obigen Beispiel mit Erscheinen des 5.1-release und der Zweig 5.0-stable mit Erscheinen von 5.2-release beendet war - alte Versionen werden typischerweise noch zwei Releases lang weiter gepflegt. Es braucht nun mal Ressourcen und Zeit, ältere Versionen zu pflegen - und obwohl wir das gerne tun würden, konzentrieren wir uns doch lieber auf neue Funktionen. Der Zweig -stable kann vom Design her sehr leicht aus dem Zweig -release derselben Version erzeugt werden (z. B. von 5.2-release zu 5.2-stable).
Der Zweig -stable ist in der Tat -release inklusive jener Korrekturroutinen, die auf der Errataseite aufgeführt sind. Die Benutzung von -stable ist identisch der des -release, auf dem er basiert. Wenn die Handbuchseiten geändert werden müssen, wird es wahrscheinlich nicht in -stable eingefügt werden. Mit anderen Worten: Unterstützung für neue Hardware und neue Funktionen werden NICHT in -stable eingefügt.
Es lohnt sich, darauf hinzuweisen, dass der Name -stable keineswegs impliziert, dass -current in einem Produktivsystem unzuverlässig oder gar weniger stabil ist. Vielmehr bedeutet es, das sich die APIs (Programmierschnittstellen der Programme mit dem Betriebssystem) und Eigenschaften von -current ändern und entwickeln, wohingegen jene von -stable die gleichen sind wie die des Release, auf dem er basiert, sodass es nicht nötig sein sollte, umlernen-, oder irgendwelche Konfigurationsdateien ändern zu müssen, und es keine Probleme geben sollte, zusätzliche Anwendungen zu dem System hinzuzufügen.
In der Tat ist, da es unsere Hoffnung ist, OpenBSD stetig zu verbessern, das Ziel, dass -current zuverlässiger und sicherer ist und, natürlich, großartigere Eigenschaften besitzt als -stable. Grob gesagt ist -current die »beste« Version von OpenBSD.
Die meisten Benutzer sollten entweder -stable oder aber -release benutzen. Nachdem dies gesagt ist, ist anzumerken, dass viele Leute -current auf Produktivsystemen einsetzen, und das es wichtig ist, dass es Leute gibt, die dies tun, damit Fehler gefunden und neue Eigenschaften und Funktionen getestet werden. Allerdings, wenn du nicht wissen solltest, wie man Probleme vernünftig beschreibt, diagnostiziert und mit ihnen umgeht, dann rede bitte dir (oder jemand anderem) nicht ein, dass du »dem Projekt hilfst«, indem du -current benutzt. »Es funktionierte nicht!« ist kein nützlicher Fehlerbericht. »The recent changes to the pciide driver broke compatibility with my Slugchip-based IDE interface, dmesg of working and broken systems follow...« könnte dagegen durchaus ein sinnvoller und nützlicher Bericht sein.
Es mag Zeiten geben, in denen auch ein normaler Benutzer gerne auf des Messers Schneide leben will und -current benutzt. Der häufigste Grund dafür ist, dass er ein Gerät hat, das nicht von -release unterstützt wird (und daher auch nicht von -stable), oder dass er eine neue Funktion von -current benutzen möchte. In diesem Fall besteht die Wahl zwischen -current oder dem Nichtbenutzen des Gerätes, und -current mag das kleinere Übel sein. Wie auch immer, niemand sollte erwarten, dass die Entwickler Händchen halten.
Wenn es dein Wunsch ist, -current zu benutzen, so ist ein halbwegs aktueller Schnappschuss oft das Einzige, was du benötigst, und das Upgraden auf einen Schnappschuss ist eine erforderliche Voraussetzung, bevor man den Versuch starten kann, -current zu erzeugen.
Manchmal wird gefragt, ob es einen Weg gibt, genau den Quelltext zu bekommen, der zur Erzeugung eines Schnappschuss eingesetzt wurde. Die Antwort ist nein. Erstens ergibt sich daraus kein besonderer Vorteil. Zweitens werden Schnappschüsse nach Bedarf erzeugt, wenn die Zeit es erlaubt, und wenn Ressourcen verfügbar werden. Auf schnellen Plattformen können mehrere Schnappschüsse an einem Tag freigegeben werden. Auf langsameren Plattformen kann es eine Woche oder länger dauern, bis ein Schnappschuss vollständig erzeugt ist. Und für jeden Schnappschuss Etiketten oder Markierungen im Quelltextbaum anzubringen ist nicht wirklich praktikabel. Drittens, Schnappschüsse enthalten oft experimentellen Kode, der noch nicht in Baum eingebunden wurde.
Upgraden bezeichnet den Prozess der Installation einer neueren Version
von OpenBSD, mit neuer Funktionalität.
Zm Beispiel ein Wechsel von v5.1 auf v5.2 oder vom Schnappschuss des 12. Juni
auf den Schnappschuss des 20. Juni.
Wenn du upgradest, so wirst du dich typischerweise an die Anleitungen in
der Entwicklung von -current folgen oder der
Upgrade-Anleitung (wenn das Release gewechselt
wird) halten, um die Änderungen vorzunehmen, die nötig sind, damit die
upgegradete Version von OpenBSD eingesetzt werden kann.
Updaten bezeichnet den Prozess des Einspielens von Korrekturroutinen in
ein System, um die Lauffähigkeit zu verbessern, OHNE dass die grundlegenden
Funktionen oder die Binärkompatibilität verändert wird.
Entweder folgst du hierbei den Anweisungen wie man
Korrekturroutinen einspielt,
oder wie man -stable folgt.
Wenn du dein System »updatest«, dann wechselt es von einem
-release-Zweig auf einen -stable-Zweig (oder auf einen
korrigierten -release) der gleichen Version von OpenBSD, zum Beispiel
von 5.2-release auf 5.2-stable.
Du kannst es dann später auf einen neueren -stable derselben
OpenBSD-Version updaten.
Der Updatevorgang ist normalerweise schmerzlos, da keine Datein unter
/etc modifiziert oder andere Systemkonfigurationen geändert
werden müssen.
Du könntest also ein System von CD installieren (zum Beispiel 4.9-release), dann ein paar Mal auf 4.9-stable updaten, dann auf 5.0-release per CD upgraden, wieder ein paar Mal updaten und dann wieder auf OpenBSD 5.2-release upzugraden.
Man sollte ebenfalls verstehen, dass der Upgradevorgang nur in eine Richtung unterstützt wird: von älter zu neuer und von -stable zu -current. Du kannst kein 5.2-current (oder einen Schnappschuss) laufen lassen und dich dann entscheiden, dass dir das zu gefährlich ist, und einfach nach 5.2-stable zurückgehen. Du bist auf dich allein gestellt, wenn du einen anderen Weg wählst als den unterstützten der kompletten Neuinstallation, also erwarte bitte keinerlei Hilfeleistung des OpenBSD-Entwicklerteams.
Ja, das soll wirklich heißen, dass du darüber nachdenken solltest, bevor du dich -current verschreibst.
Einige Gründe, NICHT aus dem Quelltext heraus zu erzeugen:
Das OpenBSD-Team stellt für alle Plattformen regelmäßig neue, auf -current Quelltext basierende Schnappschüsse bereit. Es ist wahrscheinlich, dass du nichts Anderes benötigst, um -current zu betreiben.
Der häufigste Grund, aus dem Quelltext heraus zu erzeugen, ist, dem Zweig -stable zu folgen, da das Erzeugen aus den Quellen die einzige unterstützte Option ist.
Wird -current aus dem Quelltext übersetzt, so ist es SEHR empfehlenswert, dies nur auf einer Maschine zu machen, auf deren Konsole man uneingeschränkten Zugriff hat. Es wird Zeiten im Entwicklungsprozess geben, in denen die Diskrepanz zwischen deinem neuen Betriebssystemkern und deinem alten Userland dazu führt, dass das System über das Netzwerk nicht ansprechbar ist. Dies ist kein Problem mit einem korrekt erzeugten -stable.
| Du bist beim | Ziel | Binärdatei-Upgrade auf | dann ... |
| alten -release | neues Release | neuestes Release | Fertig! |
| -release | -stable | neuestes Release | downloade u. erzeuge -stable |
| alten -stable | -stable | neuestes Release | downloade u. erzeuge -stable |
| -release | -current | aktuellsten Schnappschuss | (optional) downloade u. erzeuge -current |
| alten -current | -current | aktuellsten Schnappschuss | (optional) downloade u. erzeuge -current |
Es wird empfohlen, dass du die Binärdatei unter Verwendung der Option »Upgrade« des Installationsmediums installierst. Wenn das nicht möglich ist, kannst du auch die Binärdatei entpacken, so wie es hier beschrieben ist. Unabhängig davon musst du den gesamten Upgradeprozess durchführen, einschließlich des Erzeugens möglicher Benutzer oder anderer Änderungen im Verzeichnis /etc.
Nach der Entscheidung, welchen AnonCVS-Server du zu verwenden wünschst, musst du eine »Arbeitskopie« des Quelltextbaums erzeugen, und danach diesen Baum durch das Ausführen von »Updates« pflegen, um aktualisierte Dateien in deinen lokalen Baum einzubinden.
Das Kommando CVS(1) hat viele Optionen, einige von ihnen sind notwendig, um eine Arbeitskopie eines nutzbaren Baum zu erzeugen und ihn upzudaten. Andere Kommandos können dazu führen, dass dein Baum unbrauchbar wird. Diesen Anweisungen hier zu folgen, und sie zu verstehen, ist wichtig.
-current folgen
In diesem Fall nehmen wir an, dass wir einen öffentlichen AnonCVS-Server, anoncvs@anoncvs.example.org:/cvs, verwenden. Wir nehmen des Weiteren an, dass du sh(1) als deine Kommandoshell verwendest; solltest du eine andere Shell verwenden, so musst du einige dieser Kommandos anpassen.-stable folgenUm die Arbeitskopie eines -current CVS Quelltextbaums zu erhalten, kannst du Folgendes nutzen:
# cd /usr # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT checkout -P srcSobald du einen Baum hast, kannst du ihn später jederzeit aktualisieren:
# cd /usr/src # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT up -Pd
Wenn du die Arbeitskopie eines alternativen »Zweigs« des Baums, wie zum Beispiel des Zweigs -stable, haben möchtest, so musst du die Option -r benutzen:# cd /usr # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT checkout -rOPENBSD_5_1 -P srcDies wird die Quelltextdateien des Zweigs OPENBSD_5_1 populieren, welcher ebenfalls als »patch-branch« oder »-stable« bekannt ist. Den Kode würdest du ähnlich aktualisieren:# cd /usr/src # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT up -rOPENBSD_5_1 -PdTatsächlich ist CVS nett genug, ein Etikett (»tag«) an die heruntergeladenen Dateien anzuhängen, sodass du dir -rOPENBSD_5_1 für die Kommandozeile nicht merken musst. CVS wird sich immer daran erinnern, bis du dies explizit zurücksetzt oder eine neue Markierung unter Verwendung der Option -A mit update verwendest. Jedoch ist es vermutlich besser, zu viele Informationen in deine CVS-Kommandozeilen zu packen als zu wenig.
Obwohl bis jetzt nur der Baum »src« gezeigt wurde, wirst du die gleichen Schritte für »xenocara« und »ports« durchführen. Da alle Teile von OpenBSD synchron gehalten werden müssen, sollten alle Bäume, die du verwendest, zur gleichen Zeit als Arbeitskopie erzeugt und geupdated werden. Du kannst das Erzeugen der Arbeitskopien in einer Zeile kombinieren (-stable gezeigt):
# export CVSROOT=anoncvs@anoncvs.example.org:/cvs
# cd /usr
# cvs -d$CVSROOT checkout -rOPENBSD_5_1 -P src ports xenocara
Updates jedoch müssen Verzeichnis für Verzeichnis durchgeführt werden.
Zu diesem Zeitpunkt, egal ob du nun -stable oder -current gefolgt bist, solltest du einen einsetzbaren Quelltextbaum haben. Sei sehr vorsichtig damit, welchen Baum du beziehst - es ist einfach, zu versuchen, -current zu übersetzen, obwohl du in Wirklichkeit auf -stable abziehlst.
Um den Quelltextbaum von der CD unter /usr/src zu entpacken (und angenommen, dass die CD unter /mnt eingehängt wurde):
# cd /usr/src; tar xzf /mnt/src.tar.gz
# cd /usr; tar xzf /mnt/xenocara.tar.gz
# cd /usr; tar xzf /mnt/ports.tar.gz
Die zum Download auf den FTP-Servern vorliegenden Quelltextdateien
befinden sich in zwei separaten Dateien, um die Downloadzeit für jene Benutzer
zu minimieren, die nur mit einem Teil des Baum arbeiten wollen.
Die beiden Dateien sind sys.tar.gz, das alle zur Erzeugung des
Betriebssystemkerns nötigen Dateien enthält, und src.tar.gz, das all
die anderen Werkzeuge des »Userlands« mit Ausnahme des Portierungsbaums und der
X11-Quellen enthält.
Generell gesagt ist es jedoch so, dass du normalerweise beide installieren
möchtest.
Angenommen, dass sich die heruntergeladenen Dateien src.tar.gz
und sys.tar.gz in /usr befinden:
# cd /usr/src
# tar xzf ../sys.tar.gz
# tar xzf ../src.tar.gz
# cd /usr
# tar xzf xenocara.tar.gz
# tar xzf ports.tar.gz
Nicht jeder möchte alle Dateisets auspacken, doch da das System synchron gehalten werden muss, ist es generell nötig, alle Teile des Baums einzurichten.
Größtenteils gilt das Gleiche für die Option »-d« des Kommandos »update« -- es erstellt neue Verzeichnisse, die eventuell seit der ersten Erstellung deiner lokalen Arbeitskopie zum Baum hinzugefügt worden sind. Um ein erfolgreiches Update durchzuführen, musst du die Optionen -Pd verwenden.
Erfahrene CVS-Anwender wundern sich vielleicht, warum CVSROOT angegeben und in diesem Beispiel benutzt wurde, obwohl cvs(1) die Adresse des Servers in der Arbeitskopie des Baums abspeichert. Das ist korrekt, jedoch gibt es genug Momente, in denen man den standardmäßigen AnonCVS-Server überschreiben muss, weshalb viele Leute empfehlen, das Repositorium immer explizit anzugeben. Es ist an dieser Stelle ebenfalls erwähnenswert, dass, obwohl die Umgebungsvariable CVSROOT direkt von cvs(1) genutzt werden kann, sie nur genutzt wird, wenn sie nicht von einer anderen Angabe überschrieben wird (d. h., wenn cvs(1) ohne sie einen Fehler produzieren würde), wohingegen ihre Angabe in der cvs(1)-Kommandozeile alle anderen Werte überschreibt.
Es ist oft nützlich, eine .cvsrc in deinem Heimatverzeichnis zu verwenden, um Standardwerte für einige dieser Optionen anzugeben. Ein Beispiel einer solchen .cvsrc-Datei:
$ more ~/.cvsrc
cvs -q -danoncvs@anoncvs.example.org:/cvs
diff -up
update -Pd
checkout -P
Diese Datei würde cvs(1) dazu veranlassen, den Server
anoncvs@anoncvs.example.org:/cvs zu verwenden,
für alle Operationen normalerweise unnötige Ausgaben zu unterdrücken
(»-q« steht für »quiet«, still), dass das Kommando »cvs up«
standardmäßig die Optionen -Pd nutzt, ein »cvs diff« aufgrund der
Option »-u« standardmäßig »Unified Diffs« erstellt und dass ein
»cvs checkout« die Option »-P« verwendet.
Obwohl dies praktisch ist, wirst du Probleme haben, wenn du vergisst, dass
diese Datei existiert, oder du versuchst, Kommandos auf einer Maschine
auszuführen, auf der diese Datei nicht existiert.
Da der Quelltextbaum aus einer großen Anzahl meist kleiner Dateien besteht, wird das Aktivieren von »soft updates« für die Partition, auf der sich der Quelltextbaum befindet, zu einer deutlich spürbaren Leistungssteigerung führen.
Es ist offensichtlich, dass der Betriebssystemkern eine SEHR hardwareabhängige Komponente des Systems ist. Der Quelltext des Kerns findet sich im Verzeichnis /usr/src/sys. Einige Teile des Kodes des OpenBSD-Betriebssystemkerns werden auf allen Plattformen verwendet, andere sind sehr spezifisch für einen Prozessor oder eine Architektur. Wenn du in das Verzeichnis /usr/src/sys/arch/ schaust, wirst du eventuell Dinge sehen, die etwas verwirrend wirken - zum Beispiel gibt es dort die Verzeichnisse mac68k, m68k und mvme68k. In diesem Fall verwenden die Systeme mvme68k und mac68k den gleichen Prozessor, aber die Maschinen, auf denen sie basieren, sind sehr unterschiedlich, und benötigen daher einen sehr unterschiedlichen Betriebssystemkern (zu einem Computer-Design gehört mehr als nur der Prozessor!). Jedoch gibt es auch Teile des Kerns, die diesen Architekturen gemein sind, und diese Teile werden im Verzeichnis m68k aufbewahrt. Wenn du einfach nur einen Kern erzeugst, so sind diese, den Basis-Architekturen gewidmeten Verzeichnisse, wie m68k, nichts, worüber du dir Gedanken machen musst; du wirst exklusiv mit den Verzeichnissen der wahren »Grundarchitekturen« arbeiten, wie zum Beispiel mvme68k.
Betriebssystemkerne werden basierend auf den Kern-Konfigurationsdateien erzeugt, die sich in dem Verzeichnis befinden, das dem Namensschema /usr/src/sys/arch/<deine Plattform>/conf folgt. Das Erzeugen des Kerns besteht aus dem Verwenden des Programms config(8), dass ein Übersetzungsverzeichnis des Kerns erzeugt und populiert, und zwar folgend dem Schema /usr/src/sys/arch/<deine Plattform>/compile/<KernName>. Für dieses Beispiel nehmen wir an, dass du die i386-Plattform verwendest.
# cd /usr/src/sys/arch/i386/conf
# config GENERIC
# cd ../compile/GENERIC
# make clean && make
[... jede Menge Ausgabe ...]
# make install
Starte an diesem Punkt deine Maschine neu, um den neuen Kern zu aktivieren. Beachte, dass der neue Betriebssystemkern vor dem nächsten Schritt laufen sollte, obwohl es, solltest du obigem Ratschlag gefolgt sein, auf den am nächsten liegenden Schnappschuss upzugraden, nicht ganz so wichtig sein muss. Manchmal jedoch ändern sich die APIs und der alte Kern wird nicht in der Lage sein, neue Anwendungen auszuführen, der neue Kern aber normalerweise die alten unterstützen.
Denke daran, dass du einen Kern ohne root-Zugriff erzeugen kannst, aber du musst root sein, um den Kern zu installieren.
Beachte, dass die Verwendung des Verzeichnisses /usr/obj vorgeschrieben ist. Solltest du diesen Schritt versäumen, bevor du den Rest des Baums erzeugst, so wird sich der Zustand deines src-Baums durchaus verschlimmbessern.# rm -rf /usr/obj/* # cd /usr/src # make obj
# cd /usr/src/etc && env DESTDIR=/ make distrib-dirs
Dies übersetzt und installiert die Werkzeuge des »Userlands« in der passenden Reihenfolge. Dieser Schritt nimmt recht viel Zeit in Anspruch - eine sehr schnelle Maschine kann ihn in unter einer Stunde abschließen, eine sehr langsame Maschine benötigt vielleicht viele Tage. Wenn dieser Schritt abgeschlossen ist, hast du neu übersetzte Binärdatei auf deinem System installiert.# cd /usr/src # make build
Der Releaseprozess verwendet die Binärdateien, die während des obigen Erzeugungsprozesses im Verzeichnis /usr/obj erstellt wurden, sodass du diesen Schritt zuerst erfolgreich abschließen musst, und nichts darf das Verzeichnis /usr/obj in Unordnung bringen. Eine Situation, in der das ein Problem sein könnte, ist, wenn du ein speicherbasiertes Laufwerk als /usr/obj verwendest, für ein klein wenig Extraleistung während des Erzeugungsprozesses, in welchem Falle du sicherlich keinen Systemneustart zwischen »Erzeugung« und »Release« durchführen möchtest.
Der Releaseprozess erfordert zwei Arbeitsverzeichnisse, welche wir DESTDIR und RELEASEDIR nennen werden. Alle Dateien, die Teil einer »sauberen« OpenBSD-Installation sind, werden an ihre richtige Stelle im DESTDIR kopiert. Sie werden dann getar(1)t und im RELEASEDIR platziert. Am Ende des Prozesses wird RELEASEDIR ein vollständiges Release von OpenBSD enthalten. Der Releaseprozess wird ebenfalls den Einhängepunkt /mnt verwenden, sodass dieser Ort für keine anderen Dinge während des Releaseprozesses genutzt werden sollte. Zum Zwecke eines Beispiels werden wir nun DESTDIR mit dem Wert /usr/dest und RELEASEDIR mit /usr/rel verwenden.
Der Releaseprozess bezieht ein Werkzeug mit ein, crunchgen(8), das benutzt wird, um eine einzige ausführbare Datei aus vielen einzelnen ausführbaren Binärdateien zu erzeugen. Der Name, mit dem diese einzelne Binärdatei aufgerufen wird, entscheidet, welche Binärdatei-Komponente ausgeführt wird. Dies ist die Art und Weise, wie individuelle Programme in den RAM-Laufwerkskern gequetscht werden, der auf Systemstartdisketten und anderen Systemstartmedien vorliegt.
Du musst root-Privilegien haben, um ein Release zu erstellen.
Wir leeren nun das DESTDIR und erstellen die Verzeichnisse, sollte dies nötig sein:# export DESTDIR=/usr/dest # export RELEASEDIR=/usr/rel
# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}.old && rm -rf ${DESTDIR}.old &
# mkdir -p ${DESTDIR} ${RELEASEDIR}
Wir erstellen nun das eigentliche Release:
Nachdem das Release erstellt wurde, ist es eine gute Idee, das Release zu überprüfen, um sicherzustellen, dass die tar-Dateien mit dem übereinstimmen, was sich im Verzeichnis DESTDIR befindet. Die Ausgabe dieses Schritts sollte äußerst minimal sein.# cd /usr/src/etc # make release
Du hast nun vollständige und überprüfte Dateisets innerhalb des RELEASEDIR. Diese Dateien können nun verwendet werden, um OpenBSD auf anderen Maschinen zu installieren oder upzugraden.# cd /usr/src/distrib/sets # sh checkflist
Die verbindlichen Anweisungen, wie man ein Release erstellt, finden sich in release(8).
Hinweis: Wenn du die daraus resultierenden Dateien über HTTP für die Upgrade- und Installationsskripte zur Verfügung stellen willst, musst du eine index.txt-Datei hinzufügen, in der eine Liste aller Dateien enthalten ist, die sich in deinem neu erzeugten Release befinden.
Sobald ein komplettes Release erzeugt wurde, kann man diese Dateien für eine Standardinstallation oder das Upgrade einer anderen Maschine nutzen, oder, wenn man eine Maschine auf einen neuen -stable aktualisiert, kann man einfach die tar-Dateien im Wurzelverzeichnis der Zielmaschine auspacken.# /bin/ls -1 >index.txt
Um das Leben der OpenBSD-Anwender zu vereinfachen, wurde eine »Meta-Erzeuger« mit dem Namen Xenocara entwickelt. Dieses System »konvertiert« X zurück in einen großen Baum, der mit einem Arbeitsschritt übersetzt wird. Als zusätzliches Bonbon ist dieser Erzeugungsschritt dem Erzeugungsprozess des Rests von OpenBSD sehr viel ähnlicher, als es die früheren Versionen waren.
Die offiziellen Instruktionen für die Erzeugung von X befinden sich auf deinem System in der Datei /usr/xenocara/README und in release(8).
$ cd /usr $ cvs -qdanoncvs@anoncvs.example.org:/cvs checkout -P xenocara
Wenn du tatsächlich Änderungen am Quelltext vornehmen möchtest, dann wirst du sehr wahrscheinlich einige Pakete zusätzlich installieren müssen. Details hierüber befinden sich in der Datei /usr/xenocara/README.# cd /usr/xenocara # rm -rf /usr/xobj/* # make bootstrap # make obj # make build
Für dieses Beispiel werden wir DESTDIR und RELEASEDIR mit den respektiven Werten /usr/dest und /usr/rel nutzen. Dies muss nach obigem Erzeugungsprozess geschehen.
# export DESTDIR=/usr/dest
# export RELEASEDIR=/usr/rel
# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}- && \
rm -rf ${DESTDIR}- &
# mkdir -p ${DESTDIR} ${RELEASEDIR}
# make release
In der Tat brauchst du ihn wahrscheinlich nicht.
Ein angepasster Kern ist ein Betriebssystemkern, der mit einer anderen Konfigurationsdatei als der bereitgestellten Konfigurationsdatei GENERIC erstellt wurde. Ein angepasster Kern kann auf Quelltext der Aromata -release-, -stable- oder -current basieren, genauso wie der GENERIC es tun kann. Während das Übersetzen deines eigenen GENERIC-Kerns vom OpenBSD-Team unterstützt wird, so wird es die Übersetzung deines selbst angepassten Betriebssystemkerns nicht.
Die standardmäßige OpenBSD-Kernkonfiguration (GENERIC) ist dafür entworfen, für die meisten Leute brauchbar zu sein. Es gibt mehr Leute, die ihr System bei dem Versuch, den Kern zu optimieren, ruiniert haben, als solche, die damit ihre Systemfunktion verbessert haben. Es gibt einige Leute, die glauben, dass du deinen Kern anpassen musst, um die optimale Leistung zu erhalten, doch das stimmt für OpenBSD nicht. Nur die fortgeschrittensten und erfahrensten Anwender mit den anspruchsvollsten Anwendungen müssen sich Gedanken über einen angepassten Kern oder ein angepasstes System machen.
Einige Gründe, warum du vielleicht einen angepassten Kern erzeugen möchtest oder musst:
Einige Gründe, warum du keinen eigenen, angepassten Kern erzeugen solltest:
Das Entfernen von Gerätetreibern mag den Systemstart deines Systems beschleunigen, kann aber die Wiederherstellung erschweren, wenn du ein Problem mit der Hardware hast, und wird meistens falsch gemacht. Das Entfernen der Gerätetreiber wird nicht dazu beitragen, dass dein System spürbar schneller wird, obwohl es einen kleineren Kern erzeugt. Das Entfernen von Debuginformationen und Fehlerüberprüfungsroutinen kann das System spürbar beschleunigen, doch wird es die Untersuchung eines Systems unmöglich machen, wenn etwas schief geht.
Es sei an dieser Stelle noch einmal erwähnt, dass Entwickler normalerweise Fehlerberichte ignorieren, außer wenn sie ebenfalls mit einem GENERIC-Kern hervorgerufen werden können. Du wurdest gewarnt.
Die Generierung des OpenBSD-Betriebssystemkerns wird über Konfigurationsdateien gesteuert, die sich standardmäßig im Verzeichnis /usr/src/sys/arch/<arch>/conf/ befinden. Alle Architekturen haben eine Datei namens GENERIC, die verwendet wird, um den standardmäßigen OpenBSD-Betriebssystemkern für diese Architektur zu erzeugen. Dort können sich ebenfalls andere Konfigurationsdateien befinden, die Kerne erzeugen, die andere Ziele verfolgen, zum Beispiel minimalen Speicherbedarf, Workstations ohne Laufwerke etc.
Die Konfigurationsdatei wird von config(8) verarbeitet, das ein für die Übersetzung gedachtes Verzeichnis in ../compile erstellt und populiert; bei einer typischen Installation wäre es in /usr/src/sys/arch/<arch>/compile/. config(8) erstellt ebenfalls ein Makefile und weitere Dateien, die für eine erfolgreiche Erzeugung des Kerns notwendig sind.
Kern-Konfigurationsoptionen sind Optionen, die du zu deiner Kernkonfiguration hinzufügst und die bestimmte Eigenschaften oder Funktionen des Kerns bereitstellen. Dies erlaubt dir die von dir gewünschte Unterstützung exakt zu definieren und unnötige Geräte außen vor zu lassen. Es gibt eine Vielzahl an Möglichkeiten, deinen Kern auf deine Wünsche abzustimmen. Hier werden wir nur auf einige der am häufigsten benutzten Möglichkeiten eingehen. Lies die Handbuchseite options(4) für eine komplette Liste der Optionen und, da sich diese von Zeit zu Zeit ändern, solltest du sicherstellen, dass es die Handbuchseite für die gleiche Version von OpenBSD ist, die du erzeugst. Du kannst auch die Beispielkonfigurationsdateien zu Rate ziehen, die für deine Architektur zur Verfügung stehen.
Ändere, entferne oder füge niemals Optionen hinzu, wenn du keinen triftigen Grund dazu hast! Editiere nicht die Konfigurationsdatei GENERIC!! Die einzige Kernkonfiguration, die vom OpenBSD-Team unterstützt wird, ist der GENERIC-Kern, der eine Kombination der Optionen in /usr/src/sys/arch/<arch>/conf/GENERIC und /usr/src/sys/conf/GENERIC ist, so, wie sie vom OpenBSD-Team bereit gestellt worden sind (d. h. NICHT verändert). Ein Fehlerbericht, der mit einem modifizierten Kern zustande kam, resultiert meistens darin, dass dir gesagt wird, dass du versuchen sollst, das Problem mit einem GENERIC-Kern zu reproduzieren. Nicht alle Optionen sind untereinander kompatibel und viele Optionen sind notwendig, damit das System läuft. Es gibt keine Garantie, dass ein Kern läuft, nur weil du ihn übersetzen konntest. Es gibt außerdem keine Garantie, dass ein Kern, der »config(8)uriert« werden konnte, auch erzeugt werden kann.
Hier kannst du die plattformspezifischen Konfigurationsdateien sehen:
Wenn du diese Dateien genauer betrachtest, dann wird dir am Anfang eine Zeile ähnlich dieser auffallen:
include "../../../conf/GENERIC"
Das bedeutet, dass ein Verweis auf eine andere Konfigurationsdatei vorhanden
ist, eine, die plattformunabhängige Optionen enthält.
Wenn du also deinen eigenen Kern konfigurieren willst, so stelle sicher, dass
du auch
/sys/conf/GENERIC durchgeschaut hast.
Betriebsystemkern-Konfigurationsoptionen sollten in deiner Kernkonfigurationsdatei in folgenden Formaten angeführt werden:
option Nameoder
Um beispielsweise die Option »DEBUG« in den Kern einzubringen, füge eine Zeile wie die folgende ein:option Name=Wert
Die Optionen im OpenBSD-Kern werden in Übersetzer-Präprozessoroptionen transformiert, weshalb die Angabe einer Option wie DEBUG den Quelltext mit der Option -DDEBUG übersetzen wird, entsprechend einem #define DEBUG im Kern.option DEBUG
Manchmal möchtest du vielleicht Optionen deaktivieren, die bereits definiert sind, typischerweise in der Datei src/sys/conf/GENERIC. Obwohl du eine Kopie dieser Datei verändern könntest, ist das Verwenden der Angabe rmoption eine bessere Wahl. Falls du zum Beispiel den im Kern befindlichen Debugger deaktivieren möchtest (nicht empfohlen!), würdest du eine Zeile wie diese:
rmoption DDB
in deine Kernkonfigurationsdatei hinzufügen.
option DDB ist in src/sys/conf/GENERIC definiert, aber die
oben angegebene Zeile rmoption deaktiviert sie wieder.
Noch einmal, bitte lies options(4) für weitere Informationen über die Besonderheiten dieser Optionen. Beachte auch, dass viele dieser Optionen ihre eigenen Handbuchseiten haben - lies immer alles, was über eine Option verfügbar ist, bevor du sie zu deinem Kern hinzufügst oder aus ihm entfernst.
Die zwei Zeilen bezüglich der boca(4)-Karte wurden von den auskommentierten Zeilen in GENERIC kopiert, jedoch wurde der IRQ den eigenen Bedürfnissen angepasst. Der Vorteil der Nutzung einer Hülsendatei ist es, dass Änderungen an GENERIC automatisch aktualisiert werden, und damit im Einklang mit Änderungen am übrigen Quelltext bleiben. Der Nachteil ist, dass man Geräte nicht entfernen kann (obwohl das, generell gesagt, sowieso eine schlechte Idee ist).include "arch/i386/conf/GENERIC" boca0 at isa? port 0x100 irq 10 # BOCA 8-port serial cards com* at boca? slave ?
Der andere Weg, einen angepassten Kern zu generieren, ist, eine Kopie der standardmäßigen GENERIC zu machen, ihr einen anderen Namen zu geben und dann den eigenen Bedürfnissen anzupassen. Der Nachteil dabei ist, dass spätere Updates der Konfigurationsdatei GENERIC manuell in deine Kopie übertragen werden müssen, oder aber du musst deine Konfigurationsdatei neu erstellen.
In alle Fällen gilt, dass du, nachdem du deine angepasste Kernkonfigurationsdatei erstellt hast, config(1) benutzen und dann den Kern wie oben beschrieben erzeugen kannst.
Vollständige Instruktionen zum Erstellen deines eigenen angepassten Kerns finden sich auf der Handbuchseite config(8).
Manchmal wird dir, wenn du dein System startest, auffallen, dass der Betriebssystemkern dein Gerät zwar findet, es aber vielleicht dem falschen IRQ zugewiesen ist. Und vielleicht brauchst du dieses Gerät sofort. Nun, ohne den Kern neu zu bauen kannst du OpenBSDs Systemstart-Kernkonfiguration benutzen. Dies wird dein Problem unmittelbar für jetzt lösen. Startest du neu, so musst du diesen Schritt wiederholen. Dies ist also nur eine vorübergehende Lösung, und du solltest das Problem durch Nutzung von config(8) korrigieren. Dafür benötigt dein Kern jedoch die option BOOT_CONFIG, die in GENERIC gesetzt ist.
Der Großteil dieses Dokumentes kann auf der Handbuchseite boot_config(8) gefunden werden.
Um in die Benutzer-Kern-Konfiguration, kurz UKC (»User Kernel Config«) zu gelangen, musst du den Systemstart mit der Option -c ausführen.
Oder welchen Kern du auch immer starten möchtest. Tust du dies, so wird ein UKC-Prompt erscheinen. Hier kannst du Kommandos direkt an den Kern absetzen, Geräte spezifizieren, die du ändern, deaktivieren oder sogar aktivieren möchtest.boot> boot hd0a:/bsd -c
Hier eine Liste der gängigen Befehle der UKC.
Wenn du deinen Kern fertig konfiguriert hast, nutze quit oder exit und setze den Systemstart fort. Danach solltest du deine Änderung am Kernabbild permanent machen, indem du die Schritte ausführst, die in Mittels config(8) deinen Kern verändern beschrieben sind.
Die Optionen -e und -u von config(8) können äußerst hilfreich sein und wertvolle Zeit sparen, die du mit dem Übersetzen deines Kerns verschwenden würdest. Die Option -e erlaubt dir die Benutzer-Kern-Konfiguration, kurz UKC (»User Kernel Config«), auf einem laufenden System zu nutzen. Diese Änderungen werden dann beim nächsten Systemstart wirksam. Die Option -u testet, ob irgendwelche Änderungen am laufenden Kern während des Systemstarts gemacht wurden, d. h., ob du mittels boot -c die UKC beim Starten benutzt hast.
Das folgende Beispiel zeigt das Deaktivieren der ep*-Geräte im Kern. Zur Sicherheit musst du die Option -o benutzen, die die Änderung in die angegebene Datei schreibt. Zum Beispiel: config -e -o bsd.new /bsd wird die Änderungen in bsd.new schreiben. Das folgende Beispiel verwendet die Option -o nicht, daher werden die Änderungen einfach ignoriert und nicht zurück in die Kernbinärdatei geschrieben. Für weitere Informationen über Fehler- und Warnmeldungen lies die Handbuchseite config(8).
$ sudo config -e /bsd
OpenBSD 5.2 (GENERIC) #278: Wed Aug 1 10:04:16 MDT 2012
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
warning: no output file specified
Enter 'help' for information
ukc> ?
help Command help list
add dev Add a device
base 8|10|16 Base on large numbers
change devno|dev Change device
disable attr val|devno|dev Disable device
enable attr val|devno|dev Enable device
find devno|dev Find device
list List configuration
lines count # of lines per page
show [attr [val]] Show attribute
exit Exit, without saving changes
quit Quit, saving current changes
timezone [mins [dst]] Show/change timezone
bufcachepercent [number] Show/change BUFCACHEPERCENT
nkmempg [number] Show/change NKMEMPAGES
ukc> list
0 video* at uvideo* flags 0x0
1 audio* at uaudio*|sb0|sb*|gus0|pas0|ess*|wss0|wss*|ym*|eap*|envy*|eso*|sv*|n
eo*|cmpci*|clcs*|clct*|auacer*|auglx*|auich*|auixp*|autri*|auvia*|azalia*|fms*|m
aestro*|esa*|yds*|emu* flags 0x0
2 midi* at umidi*|sb0|sb*|ym*|mpu*|mpu*|autri*|eap*|envy* flags 0x0
3 drm* at inteldrm*|radeondrm* flags 0x0
4 inteldrm* at vga0|vga* flags 0x0
5 radeondrm* at vga0|vga* flags 0x0
6 radio* at udsbr*|bktr0|fms* flags 0x0
7 vscsi0 at root flags 0x0
8 softraid0 at root flags 0x0
9 nsphy* at url*|udav*|mos*|axe*|aue*|xe*|ef*|hme*|lii*|bce*|ale*|alc*|age*|jm
e*|et*|nfe*|stge*|vge*|bnx*|bge*|lge*|nge*|msk*|sk*|ste*|se*|sis*|wb*|tl*|vte*|v
r*|pcn*|sf*|ti*|gem*|ne0|ne1|ne2|ne*|ne*|ne*|epic*|sm0|sm*|dc*|dc*|re*|re*|rl*|r
l*|mtd*|fxp*|fxp*|xl*|xl*|ep0|ep*|ep*|ep*|ep*|ep* phy -1 flags 0x0
10 nsphyter* at url*|udav*|mos*|axe*|aue*|xe*|ef*|hme*|lii*|bce*|ale*|alc*|age*
|jme*|et*|nfe*|stge*|vge*|bnx*|bge*|lge*|nge*|msk*|sk*|ste*|se*|sis*|wb*|tl*|vte
*|vr*|pcn*|sf*|ti*|gem*|ne0|ne1|ne2|ne*|ne*|ne*|epic*|sm0|sm*|dc*|dc*|re*|re*|rl
*|rl*|mtd*|fxp*|fxp*|xl*|xl*|ep0|ep*|ep*|ep*|ep*|ep* phy -1 flags 0x0
[...snip...]
ukc> disable ep
95 ep* disabled
96 ep* disabled
281 ep0 disabled
282 ep* disabled
283 ep* disabled
340 ep* disabled
ukc> quit
not forced
Im obigen Beispiel werden alle ep* Geräte im Kern deaktiviert und es wird auch nicht getestet, ob sie überhaupt vorhanden sind. In einigen Situationen, in denen du die UKC beim Systemstart via boot -c benutzt hast, wird die Notwendigkeit bestehen, diese Änderungen dauerhaft einzubringen. Für diesen Zweck musst du die Option -u benutzen. Im folgenden Beispiel wurde der Computer in die UKC gestartet und das Gerät wi(4) deaktiviert. Da diese Änderung mit boot -c NICHT dauerhaft ist, müssen die Änderungen erst geschrieben werden. Dieses Beispiel schreibt die Änderung von boot -c in eine neue Kernbinärdatei namens bsd.new.
$ sudo config -e -u -o bsd.new /bsd
OpenBSD 5.2 (GENERIC) #278: Wed Aug 1 10:04:16 MDT 2012
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Processing history...
161 wi* disabled
162 wi* disabled
417 wi* disabled
Enter 'help' for information
ukc> quit
UKC> verbose autoconf verbose enabled UKC> quit
Nun wirst du äußerst ausführliche Meldungen während des Systemstarts erhalten.
Die meisten Probleme treten aus einem der folgenden Gründe auf:
OpenBSD und andere Programme aus dem Quelltext heraus zu erzeugen ist eine Aufgabe, die die Hardware stärker beansprucht als die meisten anderen, da CPU, Festplatte und Speicher intensiv genutzt werden. Als Ergebnis ist der wahrscheinlichste Zeitpunkt, an dem sich bei Hardware, die ein Problem hat, dieses Problem zeigt, während des Übersetzens. Signal 11 Fehler sind typischerweise durch Hardware-Probleme verursacht, sehr häufig Speicherprobleme, können aber auch CPU-, Mainboard- oder Hitzeprobleme sein. Dein System mag ansonsten sogar sehr stabil sein, sich aber nicht in der Lage befinden, Programme zu übersetzen.
Du wirst es vermutlich am besten finden, wenn du die Komponenten, die die Fehler verursachen, reparierst oder austauschst, da sich Probleme in Zukunft auch auf andere Weise zeigen könnten. Falls du Hardware besitzt, bei der du wirklich den Wunsch verspürst, sie zu nutzen, und die dir keine anderen Probleme bereitet, so installiere einfach einen Schnappschuss oder ein Release.
Siehe die Sig11 FAQ für sehr viel mehr Informationen.
# cd /usr/src
# find . -type l -name obj | xargs rm
# make cleandir
# rm -rf /usr/obj/*
# make obj
# umount /usr/obj
# newfs DeineObjPartition
# mount /usr/obj
durchzuführen als »rm -rf /usr/obj/*«.
Hinweis: Es ist möglich, auf diese Weise ein nicht-funktionales System zu erzeugen. Resultate des Nutzens dieser Option werden vom OpenBSD-Projekt nicht unterstützt.
Schnappschüsse können entfernt werden, wenn sie zu alt werden (oder nicht länger relevant sind), oder wenn ein neues -release naht.
Als Richtlinie modifiziert Software im OpenBSD-Baum keinerlei Dateien in /etc automatisch. Das bedeutet, dass es immer am Administrator liegt, die benötigten Modifikationen dort durchzuführen. Upgrades sind keine Ausnahme. Um Dateien in diesen Verzeichnissen zu aktualisieren, stelle erst einmal fest, welche Änderungen an den Basis- (Distributions) Dateien stattgefunden haben, und führe diese Änderungen erneut durch.
Um zum Beispiel die Dateien im Baum zu sehen, die sich zuletzt geändert haben, führe dies aus:
# cd /usr/src/etc
# ls -lt |more
Um alle Änderungen in /etc zwischen zwei bestimmten Versionen von OpenBSD zu sehen, kannst du CVS verwenden. Um zum Beispiel die Änderungen zwischen 5.1 und 5.2 zu sehen, führe dies aus:
# cd /usr/src/etc
# cvs diff -u -rOPENBSD_5_1 -rOPENBSD_5_2
Um die Änderungen zwischen 5.2 und -current (»HEAD«) zu sehen, benutze:
# cd /usr/src/etc
# cvs diff -u -rOPENBSD_5_2 -rHEAD
Das Skript
/dev/MAKEDEV wird nicht automatisch als Teil des »make build« Prozesses aktualisiert,
jedoch wird es als Teil einer Binär-Aktualisierung installiert.
Als generelle Regel gilt, dass es eine gute Idee ist, dieses Skript zu kopieren
(falls das notwendig ist) und von deinem Quelltextbaum aus aufzurufen, um ein
Upgrade durchzuführen:
# cd /dev
# cp /usr/src/etc/etc.`machine`/MAKEDEV ./
# ./MAKEDEV all
Sobald du die Änderungen ausgemacht hast, füge sie deinem lokalen Baum erneut zu, jegliche lokale Konfiguration, die du gemacht hast, bewahrend.
Typische Änderungen in /etc, auf die zwischen zwei Releases geachtet werden muss, sind unter anderem:
Von Zeit zu Zeit werden Dateien oder Verzeichnisse zu der Datei hierarchy hinzugefügt oder aus ihr entfernt. Ebenfalls können sich Besitzer-Informationen für Teile des Dateisystems ändern. Ein einfacher Weg, um sicherzustellen, dass deine Dateihierarchie auf dem neuesten Stand ist, ist das Verwenden des Werkzeugs mtree(8).
Beziehe zuerst den aktuellsten Quelltext, dann führe Folgendes aus:
# cd /usr/src/etc/mtree
# install -c -o root -g wheel -m 600 special /etc/mtree
# install -c -o root -g wheel -m 444 4.4BSD.dist /etc/mtree
# mtree -qdef /etc/mtree/4.4BSD.dist -p / -u
Deine Dateihierarchie sollte nun auf dem neuesten Stand sein.
Wenn ein Entwickler eine neue Plattform unterstützen will, ist einer der ersten großen Tests eine native Erzeugung des Systems. Das Erzeugen des Systems aus dem Quelltext setzt das Betriebssystem und die Maschine unter hohe Last, was wiederum einen guten Test darstellt, wie gut das System tatsächlich arbeitet. Aus diesem Grund führt OpenBSD den Erzeugungsprozess auf der Plattform aus, für die das Resultat gedacht ist, was auch als »native building« bezeichnet wird. Ohne diese native Übersetzung ist es viel schwerer sicherzustellen, dass die unterschiedlichen Plattformen verlässlich eingesetzt werden können und nicht einfach nur starten.
[FAQ-Index] [Zum Kapitel 4 - Installationsanleitung] [Zum Kapitel 6 - Vernetzung]
![[zurück]](../../images/back.gif){kind=small}
www@openbsd.org