![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ-Index] [Zum Kapitel 4 - Installationsanleitung] [Zum Kapitel 6 - Netzwerk]
,------o-----------o----X 3.5 Stable
| . .
| . ,------o---------o----X 3.6 Stable
| . | . .
| . | . ,----o----------o--> 3.7 Stable
| . | . | . .
| . | . | . ,-----o--> 3.8 Stable
| . | . | . | .
| . | . | . | .
-->3.5Rel----->3.6Rel----->3.7Rel----->3.8Rel----> Current
Zeit --->
-Current ist der Ort, an dem die aktive Arbeit gemacht wird und wird dann das nächste -release von OpenBSD. Alle sechs Monate, wenn eine neue Version von OpenBSD veröffentlicht wird, wird -current markiert (tagged) und wird -release: ein fester Punkt in der Geschichte des Source-Trees. Kein -release wird jemals verändert; es ist das, was auf den CDs und FTP-Servern vorliegt.
-Stable basiert auf -release und ist ein ,branch' des Hauptentwicklungsweges von OpenBSD. Wenn sehr wichtige Korrekturen in -current durchgeführt wurden, werden sie zurück in die -stable-,branches' portiert. Das ist der Grund, warum -stable auch als ,patch branch' bezeichnet wird. In der obigen Illustration sind die vertikalen gepunkteten Linien Fehlerkorrekturen, die in die -stable-,branches' eingefügt wurden. Du wirst auch erkennen, dass der Lebenszyklus des 3.5-stable-,branch' im obigen Beispiel mit Erscheinen des 3.7-release und der 3.6-stable-,branch' mit Erscheinen von 3.8-release beendet war - alte Versionen werden typischerweise noch zwei Releases lang weitergepflegt. Es braucht nunmal Ressourcen und Zeit, ältere Versionen zu pflegen, und obwohl wir das gerne tun würden, konzentrieren wir uns doch lieber auf neue Funktionen. Der -stable-,branch' kann vom Design her sehr leicht aus dem -release-,branch' der selben Version erzeugt werden (z. B. von 3.8-release zu 3.8-stable).
Der -stable-,branch' ist -release plus Patches, die man auf der Errataseite findet, und ein paar einfachen Fixes, die keinen Errata-Eintrag verdienen. Normalerweise ist die Bedienung und der Betrieb von -stable genauso wie der des -release, auf dem er basiert. Wenn die Manualseiten geändert werden müssen, wird es wahrscheinlich nicht in -stable eingefügt werden. Mit anderen Worten, Unterstützung für neue Hardware wird NICHT in -stable eingefügt und neue Funktionen werden nur dann eingefügt, wenn das als sehr wichtig erachtet wird.
An dieser Stelle sei erwähnt, dass der Name ,-stable' nicht ausdrücken soll, dass -current unzuverlässig sei. Stattdessen ändert und entwickelt sich current, während die Funktionsweise von -stable nicht mehr geändert wird, so dass du dein System nicht neu erlernen musst. In der Tat kann es sein, da unsere Bemühungen darin bestehen, OpenBSD zu verbessern, dass du die Zuverlässigkeit von -current besser als bei -stable empfindest.
Warnung: -current ist ein sich bewegendes Ziel. Es ändert sich fast minütlich und kann sich genauso gut mehrere Male in der Zeit ändern, die man braucht, um dem Source-Code zu holen. Obwohl die Entwickler hart daran arbeiten, sicherstellen zu können, dass das System immer compiliert und dass es keine großen Fehler gibt, ist es durchaus möglich, -current-Source herunterzuladen, der nicht compiliert, während es fünf Minuten später wieder einwandfrei funktioniert. Es gibt ebenfalls ,flag days' und große Systemänderungen, die die Entwickler mit Tools navigieren, die nur einmal genutzt werden können, was bedeutet, dass source-basierendes Aktualisieren nicht möglich ist. Wenn du damit nicht umgehen kannst, lass deine Finger von -current.
Die meisten Benutzer sollten also einfach -stable oder -release benutzen. Da das jetzt klar ist, sollte man aber auch wissen, dass viele Leute -current auf Produktionssystemen fahren, und das ist insofern wichtig, weil es hilft, Bugs zu finden und neue Funktionalitäten zu testen. Wenn du aber nicht weißt, wie man sauber Probleme beschreibt, diagnostiziert oder damit umgeht, rede dir (oder jemand anderem) besser nicht ein, du würdest ,dem Projekt helfen', indem du -current benutzt. ,Es funktioniert nicht!' ist keine nützliche Fehlermeldung. ,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, was nicht von -release unterstützt wird (und daher natürlich auch nicht von -stable), oder er möchte eine neue Funktion aus -current benutzen. In diesem Fall hat er die Wahl zwischen -current oder dem Nichtbenutzen seines Gerätes, und dann ist eben das Benutzen von -current oftmals weniger schlimm. Man sollte dann aber auf keinen Fall ein Händchenhalten der Entwickler erwarten, falls es zu Problemen kommt.
Manchmal wird gefragt, ob es einen Weg gibt, genau den Source-Code zu bekommen, der zur Erzeugung eines Snapshot eingesetzt wurde. Die Antwort ist ,Nein'. Erstens ergibt sich daraus kein besonderer Vorteil. Zweitens werden Snapshots nach Bedarf erzeugt, wenn die Zeit es erlaubt oder es genügend Ressourcen gibt. Auf schnellen Plattformen könnten z.B. mehrere Snapshots an einem Tag freigegeben werden. Auf den langsameren kann das schon mal eine ganze Woche dauern. Und das Platzieren einer Markierung (Tag) für jeden Snapshot im Source-Code ist nun wirklich extrem unpraktisch.
Man sollte verstehen, dass der Update-Prozess nur in eine Richtung unterstützt wird: Von älter zu neuer und von -stable zu -current. Du kannst kein 3.8-current (oder einen Snapshot) laufen lassen und dich dann entscheiden, dass dir das zu gefährlich ist, und einfach nach 3.8-stable zurückgehen. Du bist auf dich allein gestellt, wenn du einen anderen Weg wählst als den normalen und unterstützten, nämlich dein System von Grund auf neu zu installieren; erwarte bitte keinerlei Hilfeleistung vom OpenBSD-Entwicklerteam.
Ja, das soll wirklich heißen, dass du lange und intensiv darüber nachdenken sollst, bevor du dich an -current wagst.
Einige Gründe, warum man NICHT vom Source aus erzeugen sollte:
Das OpenBSD-Team stellt neue Snapshots bereit, die auf -current-Code basieren, in einem sehr regulären Zeitrahmen für alle Plattformen bereit. Es ist sehr wahrscheinlich, dass das alles ist, das du benötigst, um -current laufen zu lassen.
Der häufigste Grund, vom Source aus zu erzeugen, ist das Folgen vom -stable-,branch', da das Erzeugen vom Source aus die einzige unterstützte Option ist ...
| Du bist beim | Ziel | Binary-Upgrade auf | dann ... |
| alten -release | neues Release | neuestes Release | Fertig! |
| -release | -stable | neuestes Release | downloade & erzeuge -stable |
| alten -stable | -stable | neuestes Release | downloade & erzeuge -stable |
| -release | -current | aktuellsten Snapshot | (optional) downloade & erzeuge -current |
| alten -current | -current | aktuellsten Snapshot | (optional) downloade & erzeuge -current |
Es ist empfohlen, dass du die Binary unter Verwendung der ,Upgrade'-Option des Installationsmediums verwendest. Wenn das nicht möglich ist, kannst du auch die Binaries entpacken, so wie es hier beschrieben steht. Unabhängig davon musst du den gesamten Upgradeprozess durchführen, einschließlich dem Erzeugen möglicher Benutzer oder notwendiger /etc-Verzeichnisänderungen.
Nach der Entscheidung, welchen AnonCVS-Server du gerne verwenden willst, musst du ein ,checkout' für den Source-Tree durchführen, danach musst du dann den Tree durch das Ausführen von ,updates' pflegen, um aktualisierte Dateien auf deinen lokalen Tree zu ziehen.
Das CVS(1)-Kommando hat viele Optionen, einige von ihnen sind notwendig, um ein ,checkout' und ,update' für einen nutzbaren Tree durchzuführen. Andere Kommandos können dazu führen, dass dein Tree unbrauchbar wird. Diesen Anweisungen hier zu folgen und sie zu verstehen ist wichtig.
-current folgen
In diesem Fall nehmen wir ann, 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, wenn du eine andere Shell nutzen solltest, musst du diese Kommandos dementsprechend anpassen.-Stable folgenUm ein ,checkout' für einen -current-CVS-src-Tree durchzuführen, kannst du folgendes nutzen:
# cd /usr # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT checkout -P srcSobald du einen Tree 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 einen ,checkout' für einen alternativen ,branch' des Trees durchführen willst, wie zum Beispiel dem -stable-,branch', musst du den ,-r'-Modifizierer deinem Checkout nutzen:# cd /usr # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT checkout -rOPENBSD_3_8 -P srcDies wird die src-Datieen vom OPENBSD_3_8-,branch' ziehen, welcher ebenfalls als ,patch branch' oder ,-stable' bekannt ist. Den Code würdest du ähnlich aktualisieren:# cd /usr/src # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT up -rOPENBSD_3_8 -PdTatsächlich ist CVS nett genug, eine Markierung (Tag) an die runtergeladene Dateisystem anzuhängen, so dass du dir den ,-rOPENBSD_3_8'-Teil der Kommandozeile nicht merken musst, CVS wird sich immer daran erinnern, bis du ihn explizit zurücksetzt oder eine neue Markierung unter Verwendung der ,-A'-Option mit ,update' verwendest. Jedoch ist es vermutlich besser, zu viele Informationen in deine CVS-Kommandozeilen zu packen als zu wenig.
Obwohl nur der ,src'-Tree soweit gezeigt wurde, wirst du die gleichen Schritte für ,XF4' und ,ports' durchführen. Da alle Teile von OpenBSD synchron gehalten werden müssen, sollten alle Trees, die du verwendest, zur gleichen Zeit einem ,checkout' und Update unterzogen werden. Du kannst die ,checkouts' in einer Zeile kombinieren (-stable gezeigt):
# cd /usr
# export CVSROOT=anoncvs@anoncvs.example.org:/cvs
# cvs -d$CVSROOT checkout -rOPENBSD_3_8 -P src ports XF4
Jedoch müssen Updates Verzeichnis für Verzeichnis durchgeführt werden.
Zu diesem Zeitpunkt, ob du nun -stable oder -current folgst, solltest du einen einsetzbaren Source-Tree haben. Sei vorsichtig damit, welchen Tree du beziehst -- es ist einfach zu versuchen, -current zu kompilieren, obwohl du auf -stable aus bist.
Um den Source-Tree von der CD in /usr/src zu entpacken (unter der Annahme, dass die CD unter /mnt gemountet wurde):
# cd /usr/src; tar xzf /mnt/src.tar.gz
# cd /usr; tar xzf /mnt/XF4.tar.gz
# tar xzf /mnt/ports.tar.gz
Die zum Download auf den FTP-Servern vorliegenden Quelltextdateien
befinden sich in zwei Dateien, um die Downloadzeit für jene Benutzer
zu minimieren, die nur mit einem Teil des Trees arbeiten wollen. Die
beiden Dateien sind sys.tar.gz, das alle Dateien enthält, um
einen Kernel zu erstellen, und src.tar.gz, das alle anderen
Userlandwerkzeuge mit Ausnahme des Ports-Trees und den X11-Quellen
enthält.
Normalerweise wirst du jedoch beide installieren wollen.
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 XF4.tar.gz
# tar xzf ports.tar.gz
Nicht jeder möchte alle Dateisets extrahieren, doch das System muss synchron gehalten werden: normalerweise müssen alle Teile des Trees eingerichtet werden.
Größtenteils gilt das gleiche für die -d-Option beim ,update'-Kommando -- es erstellt neue Verzeichnisse, die eventuell zum Tree seit deinem ersten ,checkout' hinzugefügt worden sein.
Erfahrene CVS-Anwender wundern sich vielleicht, warum CVSROOT angegeben und in diesem Beispiel genutzt wurde, obwohl cvs(1) sich die Angaben über den Server vom Tree merkt, auf den ein ,checkout' ausgeführt wurde. Das ist korrekt, aber trotzdem gibt es Momente, in denen man den standardmäßigen Anoncvs-Server überschreiben muss, viele Leute empfehlen daher immer das explizite Angeben vom Repository. Es ist an dieser Stelle ebenfalls erwähnenswert, dass, obwohl die CVSROOT-Umgebungsvariable direkt von cvs(1) genutzt werden kann, sie nur genutzt wird, wenn nichts anderes sie überschreibt (z.B. würde cvs(1) einen Fehler ohne dieser haben), wogegen das Angeben in der cvs(1)-Kommandozeile alle anderen Werte überschreibt.
Denke daran, dass in diesem Beispiel ein -Pd als Parameter für das up-Kommando genutzt wurde. Dies ist eine weitere dieser BENÖTIGTEN Optionen, welche es erlaubt, dass neue Verzeichnisse, die bisher nicht in deinem vorherigen ,checkout' existieren, während dem Update-Prozess erstellt werden.
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 veranlasst cvs(1) dazu, den
anoncvs@anoncvs.example.org:/cvs-Server zu verwenden,
normalerweise unnötige Ausgaben aller Operationen zu unterdrücken
(,-q' heißt ,quiet' (ruhig)), dass ein ,cvs up'-Kommando
standardmäßig -Pd nutzt, ein ,cvs diff' standardmäßig
,unified diffs' wegen dem ,-u' bereitstellt und dass ein
,cvs checkout' die ,-P'-Option verwenden wird.
Obwohl diese Datei 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 Source-Tree aus einer großen Anzahl kleiner Dateien besteht, wird das Aktivieren von Softupdates für die Partition, auf der sich der Source-Tree befindet, zu einer deutlich spürbaren Leistungssteigerung führen.
Es ist offensichtlich, dass der Kernel eine SEHR hardwareabhängige Komponente des Systems ist. Der Source für den Kernel ist in dem /usr/src/sys-Verzeichnis. Einige Teile des OpenBSD-Kernel-Codes werden auf allen Plattformen verwendet, andere sind sehr spezifisch für einen Prozessor oder eine Architektur. Wenn du in das /usr/src/sys/arch/-Verzeichnis guckst, wirst du eventuelle Dinge sehen, die etwas verwirrend wirken -- zum Beispiel gibt es dort mac68k-, m68k- und mvme68k-Verzeichnisse. In diesem Fall verwendet sowohl die mvme68k- als auch die mac68k-Systeme den gleichen Prozessor, aber die Maschinen, auf denen sie basieren, sind sehr unterschiedlich, und benötigen daher einen sehr unterschiedlichen Kernel (zu einem Computer-Design gehört mehr als nur der Prozessor!). Jedoch gibt es auch Teile des Kernels die allgemein sind, solche Teile werden in dem m68k-Verzeichnis aufbewahrt. Wenn du einfach einen Kernel erzeugst, musst du dir über Basis-Architektur-Verzeichnisse wie m68k keine Gedanken machen, du wirst ausnahmslos in den ,compound'-Architektur-Verzeichnissen arbeiten, zum Beispiel mvme68k.
Kernel werden basierend auf den Kernel-Konfigurationsdateien erzeugt, welche sich in dem /usr/src/sys/arch/<deine Plattform>/conf-Verzeichnis befinden. Das Erzeugen des Kernels besteht aus dem Verwenden des config(8)-Programms, um eine Kernel-Compilier-Verzeichnis zu erstellen und einzurichten, welches dann /usr/src/sys/arch/<deine Plattform>/compile/<KernelName> genannt wird. 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 depend && make
[...jedemenge Ausgabe...]
# make install
Starte deine Maschine nun neu, um den neuen Kernel zu aktivieren. Bedenke, dass der neue Kernel vor dem nächsten Schritt laufen sollte, wobei es eventuell egal sein kann, wenn du den oben angegeben Ratschlag, auf die am nähesten liegende Binary zu aktualisieren, befolgt hast. Manchmal jedoch ändern sich die APIs und der alte Kernel wird nicht in der Lage sein, neue Applikationen auszuführen, aber der neue Kernel wird normalerweise die alten unterstützen.
Denke daran, dass du einen Kernel ohne root-Zugriff erzeugen kannst, aber du musst root sein, um den Kernel zu installieren.$ cd /irgendwo $ cp /usr/src/sys/arch/i386/conf/GENERIC . $ config -s /usr/src/sys -b . GENERIC $ make clean && make depend && make ... jedemenge Ausgaben ...
Bedenke, dass die Verwendung vom /usr/obj-Verzeichnis notwendig ist. Wenn dieser Schritt vor dem Erzeugen vom Rest des Trees fehlschlägt, ist es wahrscheinlich, dass der restliche Tree deinen src-Tree in schlechter Verfassung belassen wird.# rm -rf /usr/obj/* # cd /usr/src # make obj
# cd /usr/src/etc && env DESTDIR=/ make distrib-dirs
Dies compiliert und installiert die ,userland'-Utilitys in der passenden Reihenfolge. Dieser Schritt nimmt recht viel Zeit in Anspruch -- eine sehr schnelle Maschine kann ihn unter einer Stunde abschließen, eine sehr langsame Maschine benötigt vielleicht mehrere Tage. Wenn dieser Schritt abgeschlosen ist, hast du neu compilierte Binaries auf dein System installiert.# cd /usr/src # make build
Der Releaseprozess verwendet die Binaries, während dem obigen Erzeugungsprozess in dem Verzeichnis /usr/obj erstellt wurden, so dass du diesen Schritt erfolreich abschließen musst, und nichts das /usr/obj-Verzeichnis beeinflusst. Eine Situation, in der das ein Problem sein könnte, ist, wenn du eine memory disk für dein /usr/obj verwendest, um ein wenig Extraleistung während dem Erzeugungsprozess, daher wirst du sicherlich nicht dein System zwischen dem ,Erzeugungs'- und dem ,Release'-Schritt neustarten wollen!
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 in das RELEASEDIR gelegt. Am Ende des Prozesses wird RELEASEDIR ein fertiges OpenBSD-Release enthalten. Der Releaseprozess wird ebenfalls /mnt verwenden, so dass dieser Ort für keine anderen Dinge während dem Releaseprozess genutzt werden sollte. Als Beispiel werden wir nun DESTDIR mit dem Wert /usr/dest und RELEASEDIR mit /usr/rel verwenden.
Der Releaseprozess bezieht einige Utilitys mit ein, welche nicht Teil des Basis-OpenBSD-Systems, crunch und crunchgen(), welche genutzt werden, um eine einzelne ausführbare Datei aus mehreren individuellen Binaries zu erstellen. Der Name, mit der diese einzelne Binary aufgerufen wird, entscheidet, welche Komponenten-Binary ausgeführt wird. Auf diese Weise werden individuelle Programme in den Ramdisk-Kernel gequetscht, der auf Bootdisketten und anderen Bootmedien vorliegt. Diese Utilitys müssen vor dem Beginn des Releaseprozesses erstellt werden. Sie müssen nur ein einziges Mal erzeugt und installiert werden, aber Leute vergessen diesen Schritt häufig, und diese Programme werden schnell erzeugt, so dass einige Leute dazu tendieren, crunch und crunchgen einfach jedes Mal als Teil des Skriptes zu erzeugen, das sie zum Erstellen eines Releases nutzen.
Du musst root-Privilegien haben, um ein Release zu erstellen.
Nun definieren wir unsere DESTDIR- und RELEASEDIR-Umgebungsvariablen:# cd /usr/src/distrib/crunch && make obj depend all install
Wir leeren das DESTDIR und erstellen die Verzeichnisse, wenn das notwendig ist:# 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:
Es ist eine gute Idee, nachdem das Release erstellt wurde, das Release zu überprüfen, ob die Tar-Dateien mit dem übereinstimmen, was im DESTDIR-Verzeichnis liegt. Die Ausgabe von diesem Schritt sollte sehr gering sein.# cd /usr/src/etc # make release
Du hast nun vollständige und überprüfte Dateisets in dem RELEASEDIR. Diese Dateien können nun verwendet werden, um OpenBSD auf anderen Maschinen zu installieren oder zu aktualisieren.# cd /usr/src/distrib/sets # sh checkflist
Die maßgeblichen Anweisungen, wie man ein Release erstellt, sind 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.
# /bin/ls -1 >index.txt
nur i386: Die i386-Plattform setzt voraus, dass die Packages tcl und tk vor dem Erzeugen von X installiert sein müssen (sie können im Ports-Tree unter /usr/ports/lang/tcl/8.4/ und /usr/ports/x11/tk/8.4/ gefunden werden. Das tk-Package wird als Abhängigkeit von tcl installiert). Wie sonst auch ist das Installieren eines Packages schneller als das Installieren dieser Applikationen vom Source aus. Das Fehlschlagen beim Erzeugen dieser Packages vor dem Erzeugen von X ist recht frustrierend, da das System für einige Zeit laufen wird, bevor es wegen einem Fehler aufhört.
Um X unter Verwendung des ,Schattenverzeichnisses' /usr/Xbld zu kompilieren, verwende die folgenden Schritte, um neue Binaries in die passenden Verzeichnisse zu kopieren:
# rm -rf /usr/Xbld # mkdir -p /usr/Xbld # cd /usr/Xbld # lndir ../XF4 [...jede Menge Ausgabe...] # make build [...jede Menge Ausgabe...]
Für dieses Beispiel werden wir DESTDIR und RELEASEDIR jeweils mit den Werten /usr/Xbld/dest und /usr/Xbld/rel nutzen. Dies muss vor dem obigen Erzeugungsprozess gemacht werden.
# export DESTDIR=/usr/Xbld/dest # export RELEASEDIR=/usr/Xbld/rel # cd /usr/Xbld # rm -rf dest # mkdir dest rel # make release
Falls du vor hast, sowohl einen ,build' und ein Release von X zu erstellen, kannst du ein anderes make(1)-,target', ,b-r', nutzen, welches dann zuerst die ,build'- und danach die Release-Schritte durchläuft. Das ,b-r'-,target' nimmt an, dass DESTDIR und RELEASEDIR die Unterverzeichnisse ,rel' und ,dest' sind, die unter deinem ,build'-Unterverzeichnis liegen:
# rm -rf /usr/Xbld # mkdir -p /usr/Xbld /usr/Xbld/dest /usr/Xbld/rel # cd Xbld # lndir ../XF4 [...jede Menge AUsgabe...] # make b-r [...jede Menge Ausgabe...]
Eigentlich brauchst du ihn vermutlich nicht.
Ein angepasster Kernel ist ein Kernel, der mit einer anderen Konfigurationsdatei als der bereitgestellten GENERIC-Konfigurationsdatei erstellt wurde. Ein angepasster Kernel kann auf -release-, -stable- oder -current-Code basieren, genauso wie der GENERIC es tun kann. Während das Kompilieren deines eigenen GENERIC-Kernels vom OpenBSD-Team unterstützt ist, ist es das Kompilieren eines selbst angepassten Kernels nicht.
Die standardmäßige OpenBSD-Kernelkonfiguration (GENERIC) ist dafür ausgerichtet, für die meisten Leute einsetzbar zu sein. Mehrere Leute haben beim Versuch, das System zu optimieren, ihr System zerschossen, statt die Systemleistung zu verbessern. Es gibt Leute, die meinen, dass du deinen Kernel anpassen musst, um die optimale Leistung zu erhalten, doch das stimmt nicht für OpenBSD. Nur die fortgeschrittensten und erfahrensten Anwender mit den anspruchsvollsten Applikationen müssen sich Gedanken über einen angepassten Kernel oder ein angepasstes System machen.
Einige Gründe warum du vielleicht einen angepassten Kernel erzeugen möchtest:
Einige Gründe, warum du keinen eigenen angepassten Kernel erzeugen solltest:
Das Entfernen von Gerätetreibern mag den Bootprozess von deinem System beschleunigen, aber wird den Wiederherstellungsprozess erschweren, wenn du ein Problem mit der Hardware hast, und wird meistens falsch durchgeführt. Das Entfernen der Gerätetreiber wird nicht dazu beitragen, dass dein System spürbar schneller wird, obwohl es einen kleineren Kernel erzeugt. ,Debugging'-Informationen und Fehlerüberprüfungsroutinen zu entfernen, 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-Kernel hervorgerufen werden können. Du wurdest gewarnt.
Die OpenBSD Kernelgenerierung wird über Konfigurationsdateien verwaltet, die sich standardmäßig im /usr/src/sys/arch/<arch>/conf/-Verzeichnis befinden. Alle Architekturen haben eine Datei, GENERIC, die verwendet wird, um den Standard-OpenBSD-Kernel für diese Architektur zu erzeugen. Dort können sich ebenfalls andere Konfigurationsdateien befinden, die Kernel erzeugen, die andere Ziele verfolgen, zum Beispiel minimalen RAM, ,diskless workstations', etc.
Die Konfigurationsdatei wird von config(8) verarbeitet, das ein Compilationsverzeichnis in ../compile erstellt und einrichtet; bei einer typischen Installation wäre es in /usr/src/sys/arch/<arch>/compile/. config(8) erstellt ebenfalls eine Makefile und weitere Dateien, die für eine erfolgreiche Erstellung des Kernels notwendig sind.
Kernelkonfigurationsoptionen bieten dir die Möglichkeit, zusätzliche Unterstützung zu deinem Kernel hinzuzufügen. Dies erlaubt dir nur die von dir gewünschten Geräte zu unterstützen. Es gibt eine Vielzahl an Möglichkeiten, deinen Kernel auf deine Wünsche abzustimmen. Hier werden wir nur auf einige der am häufigsten benutzten Möglichkeiten eingehen. Siehe die options(4)-Manualseite für eine komplette Liste der Optionen und, da diese sich von Zeit zu Zeit ändert, solltest du sicherstellen, dass du auch eine Manualseite für die gleiche Version von OpenBSD verwendest, das 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 GENERIC-Konfigurationsdatei!! Die einzige Kernelkonfiguration, die vom OpenBSD-Team unterstützt wird, ist der GENERIC-Kernel, die 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). Das Berichten eines Fehlers, der mit einem modifizierten Kernel zustande kam, resultiert meistens darin, dass dir gesagt wird, dass du versuchen sollst, das Problem mit einem GENERIC-Kernel zu reproduzieren. Nicht alle Optionen sind kompatibel untereinander und viele Optionen sind notwendig, damit das System läuft. Es besteht keine Garantie, dass ein Kernel läuft, nur weil du ihn kompilieren konntest. Es besteht außerdem keine Garantie, dass ein Kernel, der ,config(1)uriert' werden kann, auch erzeugt werden kann.
Hier kannst du die plattformspezifischen Konfigurationsdateien sehen:
Wenn du diese Dateien genauer betrachtest, dann wird dir am Anfang eine Zeile wie diese auffallen:
include "../../../conf/GENERIC"
Dies bedeutet, dass ein Verweis auf eine andere
Konfigurationsdatei vorhanden ist, eine, die plattformunabhängige
Optionen beinhaltet. Wenn du also deinen eigenen Kernel konfigurieren willst,
stelle sicher, dass du auch
/sys/conf/GENERIC
beachtet hast.
Kernelkonfigurationsoptionen sollten in deiner Kernelkonfigurationsdatei im Format von:
option Nameoder
angeführt sein. Um beispielsweise die ,DEBUG'-Option in den Kernel zu bringen, füge eine Zeile wie die folgende ein:option Name=Wert
Die Optionen im OpenBSD-Kernel werden in Compilerpräprozessoroptionen übersetzt, daher würde eine Option wie DEBUG den Quelltext mit der Option -DDEBUG kompilieren, was einem #define DEBUG im Kernel entspricht.option DEBUG
Ab und zu möchtest du vielleicht Optionen deaktivieren, die bereits definiert wurden, typischerweise in der Datei ,src/sys/conf/GENERIC'. Obwohl du eine Kopie dieser Datei verändern könntest, ist das Verwenden der rmoption-Angabe eine bessere Wahl. Falls du zum Beispiel den im Kernel befindlichen Debugger deaktivieren möchtest (nicht empfohlen!), würdest du eine Zeile wie diese:
rmoption DDB
in deine Kernelkonfigurationsdatei hinzufügen. option DDB
ist in src/sys/conf/GENERIC definiert, aber die oben angegebene
rmoption-Zeile deaktiviert sie wieder.
Noch einmal, bitte siehe options(4) für weitere Informationen über die Spezifikationen dieser Optionen. Bedenke auch, dass viele dieser Optionen ihre eigenen Manualseiten haben - lies immer alles, was über eine Option verfügbar ist, bevor du sie zu deinem Kernel hinzufügst oder aus ihm entfernst.
Die zwei Zeilen bezüglich der boca(4)-Karte werden von den auskommentierten Zeilen in GENERIC kopiert und der IRQ nach eigenen Bedürfnissen angepasst. Der Vorteil der Nutzung dieser ,wrapper'-Datei ist, dass alle anderen Änderungen in der GENERIC automatisch aktualisiert werden, ohne dass irgendein anderer Quelltext aktualisiert werden müsste. Der Nachteil ist, dass man keine Devices entfernen kann (obwohl das normalerweise sowieso eine schlechte Idee ist).include "arch/i386/conf/GENERIC" boca0 at isa? port 0x100 irq 10 # BOCA 8-port serial cards pccom* at boca? slave ?
Ein anderer Weg, einen angepassten Kernel zu generieren, ist, eine Kopie der standardmäßigen GENERIC zu machen, ihr einen anderen Namen zu geben und dann nach eigenen Bedürfnissen anzupassen. Der Nachteil dabei ist, dass spätere Updates für die GENERIC-Konfigurationsdatei in deine Kopie übertragen werden müssen oder aber du musst deine Konfigurationsdatei erneut erstellen.
Verwende in beiden Fällen, nachdem du deine angepasste Kernelkonfigurationsdatei erstellt hast, config(1) und erstelle den Kernel, wie es oben beschrieben wird.
Vollständige Instruktionen zum Erstellen deines eigenen angepassten Kernels sind in der afterboot(8)-Manualseite.
Manchmal findet der Kernel beim Booten dein Gerät, aber eventuell den falschen IRQ. Und vielleicht brauchst du dieses Gerät sofort. Nun, ohne den Kernel neu zu bauen, kannst du mit der OpenBSD-eigenen Bootzeit-Konfiguration dieses Problem lösen. Dies wird aber dein Problem nur einmal lösen. Wenn du rebootest, dann musst du diese Prozedur wiederholen. Daher ist dies nur als vorübergehende Lösung gedacht und du solltest das Problem mittels config(8) beheben. Dein Kernel wird dennoch option BOOT_CONFIG benötigen, die GENERIC bereits beinhaltet.
Den Großteil dieses Dokumentes kannst du in der Manualseite boot_config(8) finden.
Um in die Benutzerkernelkonfiguration (User Kernel Config) oder UKC zu gelangen, musst du die -c-Option beim Hochfahren verwenden.
Oder welchen Kernel du auch immer laden willst. So kommst du in die UKC. Hier kannst du Befehle ausführen, die kernelspezifische Geräte ändern oder deaktivieren.boot> boot hd0a:/bsd -c
Hier eine Liste der gängigen Befehle in der UKC.
Wenn du einmal deinen Kernel konfiguriert hast, dann steige mit quit oder exit aus UKC aus und setze das Starten fort. Danach solltest du deine Änderung am Kernelimage dauerhaft machen, indem du die Schritte gemäß Mittels config(8) deinen Kernel verändern ausführst.
Die -e- und -u-Optionen von config(8) können sehr hilfreich sein und Zeit sparen, die du mit dem Neukompilieren von Kerneln verschwenden würdest. Die -e-Option erlaubt dir die UKC auf einem laufenden System zu benutzen. Die Änderungen werden dann beim nächsten Reboot wirksam. Die -u-Option testet, ob irgendwelche Änderungen am laufenden Kernel während des Bootens gemacht wurden. D.h., ob du mittels boot -c die UKC beim Starten benutzt hast.
Das folgende Beispiel zeigt das Deaktivieren des ep*-Gerätes im Kernel. Zur Sicherheit musst du die -o-Option benutzen, die die Änderung in die angegebene Datei schreibt. config -e -o bsd.new /bsd zum Beispiel wird die Änderungen in bsd.new schreiben. Das folgende Beispiel verwendet die -o-Option nicht, daher werden die Änderungen einfach ignoriert und nicht in eine Kernelbinärdatei geschrieben. Für weitere Informationen über Fehler- und Warnmeldungen siehe die config(8)-Manualseite.
$ sudo config -e /bsd
OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
warning: no output file specified
Enter 'help' für 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, mitout saving changes
quit Quit, saving current changes
timezone [mins [dst]] Show/change timezone
nmbclust [number] Show/change NMBCLUSTERS
cachepct [number] Show/change BUFCACHEPERCENT
nkmempg [number] Show/change NKMEMPAGES
shmseg [number] Show/change SHMSEG
shmmaxpgs [number] Show/change SHMMAXPGS
ukc> list
0 audio* at sb0|sb*|gus0|pas0|sp0|ess*|wss0|wss*|ym*|eap*|eso*|sv*|neo*|cmpci*|clcs*|clct*|auich*|autri*|auvia*|fms*|uaudio*|maestro*|esa*|yds*|emu* flags 0x0
1 midi* at sb0|sb*|opl*|opl*|opl*|opl*|ym*|mpu*|autri* flags 0x0
2 nsphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|ep*|ep* phy -1 flags 0x0
3 nsphyter* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|ep*|ep* phy -1 flags 0x0
4 qsphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|ep*|ep* phy -1 flags 0x0
5 inphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|ep*|ep* phy -1 flags 0x0
6 iophy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|ep*|ep* phy -1 flags 0x0
7 eephy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|ep*|ep* phy -1 flags 0x0
8 exphy* at aue*|xe*|ef*|gx*|stge*|bge*|nge*|sk*|ste*|sis*|sf*|wb*|tx*|tl*|vr*|ne0|ne1|ne2|ne*|ne*|ne*|dc*|dc*|rl*|fxp*|fxp*|xl*|xl*|ep0|ep0|ep0|ep*|ep*|ep*|ep*|ep* phy -1 flags 0x0
[...snip...]
--- more ---
[snip]
ukc> disable ep
67 ep0 disabled
68 ep* disabled
69 ep* disabled
155 ep0 disabled
156 ep0 disabled
157 ep* disabled
158 ep* disabled
210 ep* disabled
ukc> quit
not forced
Im obigen Beispiel werden alle ep* Geräte im Kernel deaktiviert und auch nicht abgefragt. In einigen Situationen, in denen du die UKC beim Booten mittels boot -c benutzt hast, willst du diese Änderungen dauerhaft niederschreiben. Dafür brauchst du die -u Option. Im folgenden Beispiel wurde die UKC gestartet und das wi(4) Gerät deaktiviert. Da diese Änderung mit boot -c NICHT dauerhaft ist, müssen die Änderungen erst geschrieben werden. Dieses Beispiel schreibt die Änderung in boot -c in eine neue Kernelbinärdatei namens bsd.new.
$ sudo config -e -u -o bsd.new /bsd
OpenBSD 3.8 (GENERIC) #138: Sat Sep 10 15:41:37 MDT 2005
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Processing history...
105 wi* disabled
106 wi* disabled
Enter 'help' for information
ukc> quit
UKC> verbose autoconf verbose enabled UKC> quit
Nun werden dir extrem viele ,verbose' Nachrichten beim Booten gegeben.
OpenBSD und andere Programme vom Source aus erzeugen ist eine Aufgabe, die die Hardware stärker beansprucht als die meisten anderen, da intensive Verwendung der CPU, Festplatte und des Speichers vorliegt. Als Ergebnis, wenn du Hardware hast, die einen Fehler hat, ist der wahrscheinlichste Zeitpunkt, dass sich das Problem bemerkbar macht, beim Kompilieren. 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, aber nicht in der Lage, Programme zu kompilieren.
Du wirst es vermutlich am besten finden, wenn du die Komponente, die die Fehler verursacht, reparierst oder austauschst, da Probleme sich auf andere Art und Weise in Zukunft zeigen könnten. Falls du Hardware hast, die du wirklich verwenden willst und sie dir sonst keine weiteren Probleme bereitet, installiere einfach einen Snapshot oder ein Release.
Siehe 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 ein kaputtes (broken) System auf diesem Wege zu erzeugen. Die Resultate aus diesen Optionen wird vom OpenBSD-Projekt nicht unterstützt.
Snapshots können entfernt werden, wenn sie zu alt werden (oder nicht länger relevant sind) oder wenn ein neues -release naht.
OpenBSD unterstützt nun zwei Compiler tree-intern, gcc v3.3.5, das von den meisten Plattformen genutzt wird, aber ebenfalls gcc v2.95.3, das von einigen wenigen Plattformen genutzt wird, die bisher noch nicht konvertiert wurden, oder aber niemals konvertiert werden, da Unterstützung vom gcc3 fehlt oder aber gcc3 eine schlechte Leistung erbringt.
Die zwei Compiler befinden sich an zwei unterschiedlichen Teilen des Trees:
Weil das Upgraden von einem Compiler in etwa ein Huhn-oder-Ei-Problem ist, benötigen Änderungen der tree-internen Compiler ein wenig Extra-Aufmerksamkeit. Du musst den Compiler zweimal erzeugen -- der erste ,build' erzeugt einen Compiler, der neuen Code erzeugt, aber mit Code arbeitet, der vom alten Compiler erzeugt wurde, der zweilte ,build' macht ihn vollständig zum einen Compiler. Generell wirst du wohl die folgende Prozedur durchführen:
Falls deine Plattform gcc 2.95.3 verwendet:
# rm -r /usr/obj/gnu/egcs/gcc/*
# cd /usr/src/gnu/egcs/gcc
- or -
Falls deine Plattform gcc 3.3.5 verwendet:
# rm -r /usr/obj/gnu/usr.bin/gcc/*
# cd /usr/src/gnu/usr.bin/gcc
Gemeinsame ,build'-Prozedur für v3.3.5 und v2.95.3
# make -f Makefile.bsd-wrapper clean
# make -f Makefile.bsd-wrapper obj
# make -f Makefile.bsd-wrapper depend
# make -f Makefile.bsd-wrapper
# make -f Makefile.bsd-wrapper install
# make -f Makefile.bsd-wrapper clean
# make -f Makefile.bsd-wrapper depend
# make -f Makefile.bsd-wrapper
# make -f Makefile.bsd-wrapper install
Und führe anschließend ein normales make build durch.
Als Richtlinie modifiziert Software im OpenBSD-Tree keine Dateien automatisch in /etc. 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 Tree zu sehen, die zu letzt geändert wurden, 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 3.7 und 3.8 zu sehen, führe dies aus:
# cd /usr/src/etc
# cvs diff -u -rOPENBSD_3_7 -rOPENBSD_3_8
Um die Änderungen zwischen 3.8 und -current (,HEAD') zu sehen,
führe dies aus:
# cd /usr/src/etc
# cvs diff -u -rOPENBSD_3_8 -rHEAD
Das
/dev/MAKEDEV-Skript
wird nicht automatisch als Teil des ,make build'-Prozesses
aktualisiert, jedoch wird es als Teil eines Binary
updates installiert.
Als generelle Regel sei zu sagen, dass es eine gute Idee ist, dieses
Skript zu kopieren (falls das notwendig ist) und von deinem
Source-Tree 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 Tree erneut zu, jegliche lokale Konfiguration, die du gemacht hast, bewahrend.
Typische /etc-Änderungen, 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 Datei-Hierarchie auf dem neuesten Stand ist, ist das Verwenden von dem mtree(8)-Utility.
Beziehe zuerst den aktuellsten Source, 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 Datei-Hierarchie sollte nun auf dem neuesten Stand sein.
[FAQ-Index] [Zum Kapitel 4 - Installationsanleitung] [Zum Kapitel 6 - Netzwerk]
![[zurück]](../../images/back.gif){kind=small}
www@openbsd.org