[OpenBSD]

[FAQ-Index] [Zum Kapitel 4 - Installationsanleitung] [Zum Kapitel 6 - Netzwerk]

5 - Das System aus dem Quelltext erzeugen

Inhaltsverzeichnis


5.1 - OpenBSDs Flavors

Es gibt drei Flavors von OpenBSD: Grafisch sieht die Entwicklung dieser Flavors ungefähr so aus:
,------o-----------o----X 3.9 Stable | . . | . ,------o---------o----X 4.0 Stable | . | . . | . | . ,----o----------o--> 4.1 Stable | . | . | . . | . | . | . ,-----o--> 4.2 Stable | . | . | . | . | . | . | . | . -->3.9Rel----->4.0Rel----->4.1Rel----->4.2Rel----> Current Zeit --->

-Current ist der Ort, an dem die aktive Arbeit gemacht wird. Aus diesem Flavor wird dann das nächste -release von OpenBSD. Alle sechs Monate, wenn eine neue Version von OpenBSD veröffentlicht wird, wird -current markiert und somit -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 Patchbranch 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.9-stable-Branchs im obigen Beispiel mit Erscheinen des 4.1-release und der 4.0-stable-Branch mit Erscheinen von 4.2-release beendet war - alte Versionen werden typischerweise noch zwei Releases lang weitergepflegt. Es braucht nunmal Ressourcen und Zeit, ältere Versionen zu pflegen - 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 4.2-release zu 4.2-stable).

Der -stable-Branch besteht aus -release und weiteren Patches, die man auf der Errataseite findet. Die Bedienung und der Betrieb von -stable ist genauso wie im -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 und neue Funktionen werden NICHT in -stable eingefügt.

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: Du musst somit dein System nicht neu erlernen, Konfigurationsdateien ändern und wirst auch keine Probleme damit haben, deinem System weitere Anwendungen hinzuzufügen.

Auf Grund unserer Bemühungen, OpenBSD zu verbessern, ist es unser Ziel, dass -current zuverlässiger, sicherer und selbstverständlich funktionsreicher als -stable ist. Grob gesagt ist die »beste« Version von OpenBSD -current.

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 den Quelltext zu holen. Obwohl die Entwickler hart daran arbeiten, sicherstellen zu können, dass das System immer kompiliert und dass es keine großen Fehler gibt, ist es durchaus möglich, -current-Quelltext herunterzuladen, der nicht kompiliert, während es fünf Minuten später wieder einwandfrei funktioniert. Es gibt ebenfalls Flagdays und große Systemänderungen, die die Entwickler mit Tools navigieren, die nur einmal genutzt werden können. Das bedeutet, dass eine quelltextbasierte Aktualisierung 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 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 selbstverständlich auch nicht von -stable). Es könnte auch sein, dass er eine neue Funktion aus -current benutzen möchte. 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.

Snapshots

Zwischen den formalen Veröffentlichungen neuer Versionen von OpenBSD werden Snapshots über die FTP-Seiten verfügbar gemacht. Wie der Name schon sagt, sind das Versionen vom Code, der gerade zu eben diesem Zeitpunkt aktuell war, als der Übersetzer des Snapshots sich eine Kopie des Source-Codes für eben diese Plattform gemacht hat. Denke bitte daran, dass es auf einigen Plattformen auch einige TAGE sein können, bis der Snapshot dann auch kompiliert und zur Verfügung gestellt wird. Es gibt auch keinerlei Garantien, dass die Snapshots funktionsfähig oder auch nur installationsfähig sind. Oftmals werden Snapshots dann erzeugt, wenn es eine Änderung gibt, die getestet werden muss. Bei einigen Plattformen werden Snapshots auf fast täglicher Basis erstellt, andere sind weniger regelmäßig. Wenn du unbedingt -current benutzen willst, ist ein aktueller Snapshot oft das Einzige, was du dazu brauchst, und das Upgraden auf den aktuellen Snapshot ist auch eine Voraussetzung, um -current zu erzeugen.

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 Quelltext ist nun wirklich extrem unpraktisch. Der dritte Grund ist, dass Snapshots oft experimentellen Code beinhalten, der noch nicht in den Tree eingebunden wurde.

Upgrade oder Update

Du wirst oft sehen, dass über das »Upgraden« und »Updaten« von OpenBSD-Installationen geschrieben wird. Obwohl beide Wörter ungefähr die gleiche Bedeutung haben, werden sie in Verbindung mit OpenBSD unterschiedlich eingesetzt.

Upgraden ist die Installation einer neueren OpenBSD-Version, die über neue Funktionen verfügt: zum Beispiel ein Wechsel von v4.1 auf v4.2 oder vom Snapshot am 12. Juni auf den Snapshot am 20. Juni. Wenn du upgradest, wirst du dich normalerweise an die Anleitungen in Der Entwicklung von -current folgen oder im Falle eines Releasewechsels an die Upgradeanleitung halten, um benötigte Änderungen durchzuführen, damit die upgegradete Version von OpenBSD eingesetzt werden kann.
Updaten bedeutet Patches in ein System einzuspielen, um die Lauffähigkeit zu verbessern OHNE die grundlegenden Funktionen oder die Binärkompatibilität zu verändern. Entweder folgst du hierbei den Anweisungen wie man Patches in OpenBSD einfügt oder wie man -stable folgt. Wenn du dein System »updatest«, dann wechselst es von -release auf -stable (oder auf ein gepatchtes -release) der gleichen OpenBSD-Version (zum Beispiel von 4.2-release auf 4.2-stable). Später kannst du dann auf eine neuere -stable-Version der gleichen OpenBSD-Version updaten. Der Updatevorgang geht normalerweise leicht vonstatten, da keine /etc-Dateien oder andere Systemkonfigurationen geändert werden müssen.

Du könntest also ein System von CD installieren (zum Beispiel 4.1-release), dann ein paar Mal auf 4.1-stable updaten, dann auf 4.2-release per CD upgraden, wieder ein paar Mal updaten und dann wieder auf die nächste OpenBSD-Version upgraden.

Die Dinge synchron halten

Es ist wichtig zu verstehen, dass OpenBSD ein Betriebssystem ist und als ganzes gesehen werden muss, nicht ein Kernel mit einem Schwanz an Applikationen, die drangehängt sind. Du musst sicherstellen, dass dein Kernel, dein Userland (die unterstützenden Werkzeuge und Dateien) und dein Ports-Tree alle synchronisiert sind, oder es werden unangenehme Dinge passieren. Oder anders ausgedrückt (da es immer wieder Leute gibt, die das versuchen), kannst du keine brandneuen Ports auf einem System laufen lassen, das einen Monat alt ist oder einen Kernel aus -current neu erzeugen und dann erwarten, dass er mit einem release-Userland zusammenarbeitet. Ja, das heißt, dass du dein System auf aktuellem Stand halten musst, wenn du ein neues Programm laufen lassen willst, das z. B. erst heute in den Ports-Tree eingefügt wurde. Tut uns erneut leid, aber OpenBSD hat nunmal nur sehr begrenzte Ressourcen, sodass wir sowas nicht ändern können.

Man sollte verstehen, dass der Upgradevorgang nur in eine Richtung unterstützt wird: von älter zu neuer und von -stable zu -current. Du kannst kein 4.2-current (oder einen Snapshot) laufen lassen und dich dann entscheiden, dass dir das zu gefährlich ist, und einfach nach 4.2-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.

5.2 - Warum sollte ich mein System vom Quelltext aus erzeugen?

Eigentlich brauchst du das vermutlich nicht.

Einige Gründe, warum man NICHT vom Source aus erzeugen sollte:

Einige Gründe, warum du tatsächlich vom Source aus erzeugen möchtest oder musst:

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.

5.3 - OpenBSD vom Quelltext aus erzeugen

5.3.1 - Überblick über den Erzeugungsprozess

OpenBSD vom Source aus zu erzeugen beinhaltet einige Schritte: Es gibt ein paar weitere Schritte, die einige Benutzer eventuell durchführen möchten, abhängig von dem Verwendungszweck der Erzeugung und ob X installiert ist:

5.3.2 - Zur nächstliegenden Binary aktualisieren oder diese installieren

Der erste Schritt beim Erzeugen vom Source aus besteht darin, sicherzustellen, dass du die verfügbare Binary, die am nächsten an deinem Ziel liegt, installiert hast. Verwende diese Tabelle, um zu sehen wo du bist, wo du hingehen möchtest und mit welcher Binary du starten solltest:

Du bist beim Ziel Binary-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 Snapshot (optional) downloade u. erzeuge -current
alten -current -current aktuellsten Snapshot (optional) downloade u. erzeuge -current

Es ist empfohlen, dass du die Binary unter Verwendung der Upgradeoption des Installationsmediums verwendest. Wenn das nicht möglich ist, kannst du auch die Binarys 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.

5.3.3 - Den passenden Quelltext runterladen

OpenBSD-Source wird unter Verwendung vom Versionskontrollsystem CVS verwaltet, und cvs(1) wird genutzt, um eine Kopie des gewünschten Sources auf deine lokale Maschine zum Compilieren zu ziehen. Dies kann unter Verwendung eines AnonCVS-Servers geschehen (einer Maschine, die eine öffentlich zugängliche Kopie vom gesamten CVS-Repository hält, das vom OpenBSD-Projekt genutzt wird) oder von einem lokalen CVS-Repository, das du unter Verwendung von CVSup oder CVSync pflegst, welche als Packages vorliegen. CVSup kann ebenfalls in einem ,checkout-Mode genutzt werden, aber das wird an dieser Stelle nicht behandelt. Wenn du mehrere Maschinen hast, auf denen du den Source-Code-Tree bewahren willst, kann es für dich durchaus nützlich sein, ein lokales CVS-Repository zu führen, erstellt und gepflegt unter Verwendung von CVSup oder CVSync.

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 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, wenn du eine andere Shell nutzen solltest, musst du diese Kommandos dementsprechend anpassen.

Um 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 src

Sobald 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

-Stable folgen
Wenn du einen Checkout für einen alternativen Branch des Trees durchführen willst, wie zum Beispiel dem -stable-Branch, musst du die Option -r während des Checkouts nutzen: # cd /usr # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT checkout -rOPENBSD_4_2 -P src Dies wird die src-Dateien vom OPENBSD_4_2-Branch ziehen, welcher ebenfalls als Patchbranch 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_4_2 -Pd Tatsächlich ist CVS nett genug, eine Markierung (Tag) an die runtergeladene Dateien anzuhängen, sodass du dir -rOPENBSD_4_2 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 nur der src-Tree so weit 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 Trees, die du verwendest, zur gleichen Zeit einem Checkout und Update unterzogen werden. Du kannst die Checkouts in einer Zeile kombinieren (-stable gezeigt): # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cd /usr # cvs -d$CVSROOT checkout -rOPENBSD_4_2 -P src ports # cd /usr/src # cvs -d$CVSROOT checkout -rOPENBSD_4_2 -P xenocara 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.

Den Tree vorladen: src.tar.gz, sys.tar.gz

Obwohl du den gesamten Source-Tree von einem AnonCVS-Server herunterladen kannst, ist es möglich, eine Menge Zeit und Bandbreite zu sparen, indem du deinen Source-Tree mit den Quelltextdateien von der OpenBSD-CD oder einem FTP-Server »vorladen«. Dies ist insbesondere dann der Fall, wenn du -stable einsetzt, da nur wenige Dateien zwischen dieser Version und dem -release, auf dem es basiert, geändert werden.

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 # 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 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 # tar xzf ../xenocara.tar.gz # cd /usr # 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.

Allgemeine CVS-Tipps

Wie zuvor schon beschrieben, gibt es einige Optionen, die notwendig sind, um einen gültigen src-Tree in OpenBSD zu erhalten. Die obige Option -P ist eine solche: Es entfernt (prunes) Verzeichnisse, die leer sind. Über die Jahre wurden Verzeichnisse im OpenBSD-Source-Tree erstellt und gelöscht, und ab und zu werden die Namen von alten Verzeichnissen als Dateinamen genutzt. Ohne dieser Option -P wird dein gerade erst mit »checkout« heruntergeladene Tree NICHT erfolgreich kompilieren.

Größtenteils gilt das Gleiche für die -d-Option beim Updatekommando - es erstellt neue Verzeichnisse, die eventuell zum Tree seit deinem ersten Checkout hinzugefügt worden sein. Für ein erfolgreiches Update musst du die Optionen -Pd verwenden.

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.

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 ruhig [quiet]), dass das Kommando ,cvs up' standardmäßig -Pd nutzt, ein ,cvs diff' standardmäßig Unified Diffs wegen dem -u bereitstellt und dass ein ,cvs checkout' die Option -P 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.

5.3.4 - Einen Kernel erzeugen

Wir nehmen an, dass du einen standardmäßigen (GENERIC oder GENERIC.MP) Kernel an dieser Stelle erzeugen möchtest. Normalerweise ist es genau das, was du machen möchtest. Ziehe nicht in Betracht, einen angepassten Kernel zu erzeugen, wenn du noch nicht über den standardmäßigen Erzeugungsprozess hinaus bist.

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-Architekturverzeichnissen 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 [... jede Menge Ausgabe ...] # make install
Ersetze i386 in der ersten Zeile mit deinem Plattformnamen. Das machine(1)-Kommando kann dir sagen, was dein Plattformname ist, sodass eine offensichtliche Generalisierung das Nutzen des Kommandos ,cd /usr/src/sys/arch/`machine`/conf' statt der ersten Zeile ist.

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.

Variationen zu dem obigen Prozess: nur lesbarer Source-Tree

Manchmal möchtest du vielleicht sicherstellen, dass dein /usr/src/sys-Verzeichnis nicht modifiziert wird. Dies kann durch das Verwenden des folgenden Prozesses realisiert werden:
$ cd /irgendwo $ cp /usr/src/sys/arch/i386/conf/GENERIC . $ config -s /usr/src/sys -b . GENERIC $ make clean && make depend && make ... jede Menge Ausgabe ...
Denke daran, dass du einen Kernel ohne root-Zugriff erzeugen kannst, aber du musst root sein, um den Kernel zu installieren.

5.3.5 - Das Userland erzeugen

Es existiert ein bestimmter Prozess, der von OpenBSD verwendet wird. Prozesse, die unter anderen Betriebssystemen, mit denen du vertraut bist, genutzt werden, werden vermutlich nicht unter OpenBSD funktionieren, und du wirst ausgelacht werden, wenn du fragst, warum.

5.4 - Ein Release erstellen

Was ist ein Release und warum würde ich eines erstellen wollen?

Ein Release ist ein kompletter Satz an Dateien, die verwendet werden können, um OpenBSD auf einem anderen Rechner zu installieren. Wenn du nur einen Computer hast, auf dem OpenBSD läuft, hast du wirklich keinen Grund, ein Release zu erstellen, da der obige Erzeugungsprozess alles macht, was du brauchst. Eine Beispielanwendung für den Releaseprozess wäre das Erzeugen von -stable auf einer schnellen Maschine und dann das Erstellen von einem Release, das auf all deinen Maschinen in deinem Büro installiert werden kann.

Der Releaseprozess verwendet die Binarys, während dem obigen Erzeugungsprozess in dem Verzeichnis /usr/obj erstellt wurden, sodass du diesen Schritt erfolgreich 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, sodass 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 Binarys 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 RAM-Disk-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, sodass 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.

Ein Release erstellen

Zu aller erst, falls es auf dieser Maschine noch nicht geschehen ist, erzeuge crunch und crunchgen:
# cd /usr/src/distrib/crunch && make obj depend all install
Nun definieren wir unsere DESTDIR- und RELEASEDIR-Umgebungsvariablen:
# export DESTDIR=/usr/dest # export RELEASEDIR=/usr/rel
Wir leeren das DESTDIR und erstellen die Verzeichnisse, wenn das notwendig ist:
# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}.old && rm -rf ${DESTDIR}.old & # mkdir -p ${DESTDIR} ${RELEASEDIR}
RELEASEDIR muss normalerweise nicht vor dem Beginn des Releaseprozesses leer sein, jedoch könnten alte Dateien herumliegen bleiben, wenn sich Releasedateien oder ihre Namen geändert haben. Eventuell möchtest du das Verzeichnis vor dem Beginn ebenfalls löschen.

Wir erstellen nun das eigentliche Release:

# cd /usr/src/etc # make 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/distrib/sets # sh checkflist
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.

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

5.5 - X erzeugen (4.2 Xenocara)

Hinweis: Die folgende Anleitung gilt für OpenBSD 4.2 und später. Wenn du X für 4.1 oder früher erzeugen möchtest (du solltest wirklich upgraden!), kannst du die frühere Anleitung im cvsweb finden.

Beginnend mit X.org v7 stellte X auf ein System zur »modularen Übersetzung« um, das zur Folge hatte, dass der X.org-Quelltext in über dreihundert mehr oder weniger unabhängige Pakete zerlegt wurde.

Um das Leben der OpenBSD-Anwender zu vereinfachen, wurde eine »Meta-Übersetzung« mit dem Namen Xenocara entwickelt. Dieses System »konvertiert« X zurück in einen großen Tree, der in einem Prozess übersetzt wird. Ein zusätzlicher Bonus ist, dass dieser Übersetzungsprozess dem Übersetzungsprozess aller anderen OpenBSD-Komponenten ähnlicher ist, als es die vorherigen Versionen waren.

Die offiziellen Schritte für die Übersetzung von X gefinden sich in der Datei /usr/src/xenocara/README auf deinem System und in release(8).

Den Quelltext beziehen

Der »übliche« Ort für den xenocara-Sourcetree ist /usr/src/xenocara und der Quelltext selbst befinden sich im xenocara-Modul in CVS. Ein Checkout wird demnach wie folgt durchgeführt:
$ cd /usr/src $ cvs -qdanoncvs@anoncvs.example.org:/cvs checkout -P xenocara

Xenocara übersetzen

Für die Übersetzung des standardmäßigen Xenocara-Trees (wie von OpenBSD unterstützt) werden keine weiteren Werkzeuge benötigt.
# cd /usr/src/xenocara # make bootstrap # make obj # make build
Wenn du tatsächlich Änderungen am Quelltext vornehmen möchtest, dann musst du sehr wahrscheinlich einige Packages installieren. Details hierüber befinden sich in der Datei /usr/src/xenocara/README.

Ein Release erstellen

Dies ist dem Hauptsystem-Releaseprozess sehr ähnlich. Nach dem erfolgreichen Erzeugen von X wirst du DESTDIR und RELEASEDIR aus dem gleichen Grund wie weiter oben erzeugen. RELEASEDIR kann das gleiche Verzeichnis sein wie das Hauptsystem-RELEASEDIR, aber DESTDIR wird in diesem Prozess gelöscht und wieder erstellt. Wenn es vorsichtig angestellt wird, ist dies kein Problem, aber separate DESTDIRs zu verwenden, kann ,sicherer' sein.

Für dieses Beispiel werden wir DESTDIR und RELEASEDIR jeweils mit den Werten /usr/dest und /usr/rel nutzen. Dies muss vor dem obigen Erzeugungsprozess gemacht werden.

# export DESTDIR=/usr/dest # export RELEASEDIR=/usr/rel # test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}- && \ rm -rf ${DESTDIR}- & # mkdir -p ${DESTDIR} ${RELEASEDIR} # make release
Wenn dieser Prozess abgeschlossen ist, wirst du ein Set der Releasedateien in $RELEASEDIR haben.

5.6 - Warum brauche ich einen selbsterstellten Kernel?

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. Debuginformationen 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.

5.7 - Einen angepassten Kernel erzeugen

Es wird angenommen, dass du das vorherige gelesen hast und wirklich auf Schmerzen stehst. Es wird des Weiteren angenommen, dass du ein Ziel hast, das man weder durch das Nutzen einer Bootzeit-Konfiguration (UKC>) noch durch config(8)urieren eines GENERIC-Kernels erreicht werden kann. Wenn diesen beiden Annahmen falsch sind, solltest du beim Verwenden von GENERIC bleiben. Wirklich.

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 ein 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(8)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      Name
oder
option      Name=Wert
angeführt sein. Um beispielsweise die DEBUG-Option in den Kernel zu bringen, füge eine Zeile wie die folgende ein:
option DEBUG
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.

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.

Einen angepassten Kernel erzeugen

In diesem Fall werden wir einen Kernel erzeugen, der die boca(4)-ISA-Multiport serielle Karte unterstützt. Diese Karte ist nicht im GENERIC-Kernel, da er mit anderen Treibern in Konflikt gerät. Eine anderer häufiger Grund, einen angepassten Kernel zu erzeugen, wäre RAIDframe, das zu groß ist, um in einem Serienkernel zu sein. Es gibt zwei typische Wege, einen angepassten Kernel zu erzeugen: die GENERIC-Konfigurationsdatei unter anderem Namen zu kopieren und zu editieren oder eine Wrapperdatei zu erstellen, die den Standard-GENERIC-Kernel einbindet und du alle Optionen angibst, die du benötigst, die nicht in GENERIC sind. In diesem Fall sieht unsere Wrapperdatei beispielsweise so aus:
include "arch/i386/conf/GENERIC" boca0 at isa? port 0x100 irq 10 # BOCA 8-port serial cards pccom* at boca? slave ?
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 Wrapperdatei 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).

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.

5.8 - Konfiguration zur Bootzeit

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.

boot> boot hd0a:/bsd -c
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.

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.

5.9 - Mittels config(8) deinen Kernel verändern

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 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007 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, 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 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007 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

5.10 - Ausführlichere Nachrichten während des Bootens erhalten

Ausführlichere Nachrichten zu erhalten, kann sehr hilfreich sein, wenn man versucht, Probleme während des Bootens zu beheben. Wenn du ein Bootproblem hast, obwohl ein Diskettenboot keine hat, und mehr Informationen erhalten möchtest, starte einfach neu. Wenn du beim boot>-Prompt angelangt bist, boote mit boot -c. Dies bring dich in den UKC>, wo du dann Folgendes eingibst:
UKC> verbose autoconf verbose enabled UKC> quit

Nun werden dir sehr ausführliche Nachrichten beim Booten gegeben.

5.11 - Häufige Probleme beim Kompilieren und Erzeugen des Systems

Wenn Probleme während der Erzeugung des Systems auftreten, dann liegt das meist daran, dass die zuvor genannten Schritte nicht richtig befolgt wurden. Ab und zu kann es echte Probleme bei der Übersetzung von -current mit einem aktuellen Snapshot geben - bei -release oder -stable ist es aber fast immer ein Fehler des Anwenders.

Die meisten Probleme treten aus einem der folgenden Gründe auf:

Es gibt aber noch einige weitere Probleme, die auftreten könnten:

5.11.1 - Das Erzeugen bricht mit einem Signal-11-Fehler ab

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.

5.11.2 - »make build« schlägt mit »cannot open output file snake: is a directory« fehl

Dies ist das Resultat von zwei separaten Fehlern: Es ist wichtig, den Instruktionen sorgfältig zu folgen, wenn du deinen Tree herunterlädst und erzeugst.

5.11.3 - Mein System ohne IPv6 läuft nicht!

Stimmt. Bitte mach keine Modifikationen am Basis-System, von denen du nicht weißt, wie sie sich auswirken. Eine ,kleine' Änderung im Kernel kann große Auswirkungen für den gesamten Rest des Systems haben. Bitte lies das hier erneut.

5.11.4 - Hoppla! Ich habe vergessen, zuerst das /usr/obj-Verzeichnis zu erstellen!

Durch das Ausführen von ,make build' vor ,make obj' wirst du mit Objektdateien da stehen, die in deiem /usr/src-Verzeichnis herumliegen. Das ist eine schlechte Sache. Wenn du vermeiden willst, deinen gesamten Src-Tree erneut zu beziehen, kannst du Folgendes versuchen, um die Obj-Dateien zu entfernen: # cd /usr/src # find . -type l -name obj | xargs rm # make cleandir # rm -rf /usr/obj/* # make obj

5.11.5 - Tipp: Lege /usr/obj auf seine eigene Partition

Wenn du häuft erzeugst, wirst du es vielleicht als schneller empfinden, wenn du /usr/obj auf seine eigene Partition legst. Der Nutzen ist einfach, es ist typischerweise schneller: # umount /usr/obj # newfs DeineObjPartition # mount /usr/obj durchzuführen als ,rm -rf /usr/obj/*'.

5.11.6 - Wie verhindere ich das Erzeugen von bestimmten Teilen des Trees?

Manchmal möchtest du das Erzeugen von bestimmten Teilen des Trees verhindern, normalerweise, weil du einen Ersatz für eine mitgelieferte Applikation durch Packages hast oder weil du ein ,kleineres' Release aus welchem Grund auch immer haben willst. Die Lösung hierfür ist, die SKIPDIR-Option von /etc/mk.conf zu verwenden.

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.

5.11.7 - Wo kann ich mehr über den Erzeugungsprozess erfahren?

Hier sind einige andere Ressourcen:

5.11.8 - Ich sehe keine Snapshots auf den FTP-Seiten. Wo sind sie geblieben?

Snapshots können entfernt werden, wenn sie zu alt werden (oder nicht länger relevant sind) oder wenn ein neues -release naht.

5.11.9 - Wie führe ich ein Bootstrap für eine neue Version des Kompilers (gcc) aus?

Du solltest wirklich einfach den aktuellsten Snapshot installieren.

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 - oder - 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.

5.11.10 - Was ist der beste Weg, um /etc, /var und /dev zu aktualisieren?

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 4.1 und 4.2 zu sehen, führe dies aus: # cd /usr/src/etc # cvs diff -u -rOPENBSD_4_1 -rOPENBSD_4_2 Um die Änderungen zwischen 4.2 und -current (HEAD) zu sehen, führe dies aus: # cd /usr/src/etc # cvs diff -u -rOPENBSD_4_2 -rHEAD Das /dev/MAKEDEV-Skript wird nicht automatisch als Teil des Prozesses ,make build' 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:

Diese Änderungen werden in upgrade42.html (um zum 4.2-Release zu gelangen) oder current.html (um zu -current zu gelangen).

5.11.11 - Gibt es einen einfachen Weg, um alle Dateihierarchien zu ändern?

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.

5.11.12 - Kann ich cross-compilen? Warum nicht?

Es befinden sich Werkzeuge im System, mit denen man cross-compilen kann - für Entwickler, die an einer neuen Portierung arbeiten. Sie sind aber nicht für den allgemeinen Einsatz gedacht.

Wenn ein Entwickler eine neue Plattform unterstützen will, ist eine der ersten großen Tests eine native Übersetzung des Systems. Diese Übersetzungsphase 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 wird OpenBSD auf der jeweiligen Plattform übersetzt, 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 booten.

[FAQ-Index] [Zum Kapitel 4 - Installationsanleitung] [Zum Kapitel 6 - Netzwerk]

[zurück] www@openbsd.org
$OpenBSD: faq5.html,v 1.100 2007/11/19 10:43:15 tobias Exp $