Der OpenBSD-Installer ist textbasiert, die Zahl der Fragen überschaubar und für viele davon existiert eine sinnvolle Vorgabe. Hinter diesem knappen Ablauf steckt jedoch mehr, als Dateien von einem Installationsmedium auf eine Festplatte zu kopieren.
Bereits vor dem ersten Boot stellt sich die Frage, ob dem Installationsimage vertraut werden kann. Während der Installation läuft mit bsd.rd bereits ein OpenBSD-System, das Hardware erkennt, Netzwerkinterfaces konfiguriert und Datenträger bearbeitet. Aus den Antworten des Installers entstehen anschließend Konfigurationsdateien, Dateisysteme, Benutzerkonten und andere Bestandteile des späteren Systems.
Auch die Meldung über eine erfolgreich abgeschlossene Installation ist noch nicht das Ende: Beim ersten Start kann OpenBSD einmalige Arbeiten ausführen, und ein frisch installiertes Release besitzt nicht zwangsläufig bereits alle inzwischen veröffentlichten Errata-Patches.
Wir installieren im Folgenden OpenBSD 7.9 auf amd64 und betrachten dabei nicht nur, was im Installer einzugeben ist, sondern auch, was diese Entscheidungen im späteren System bewirken.
Download und Verifikation
Für amd64 stellt OpenBSD unter anderem install79.img für USB-Sticks und andere Datenträger sowie install79.iso für optische und virtuelle Laufwerke bereit. Beide vollständigen Installationsimages enthalten neben dem Installationssystem auch die Base- und X-Sets des Releases.
Bevor wir davon booten, prüfen wir das Image.
mkdir -p ~/iso/openbsd/7.9/amd64
cd ~/iso/openbsd/7.9/amd64
wget https://cdn.openbsd.org/pub/OpenBSD/7.9/amd64/install79.img
wget https://cdn.openbsd.org/pub/OpenBSD/7.9/amd64/SHA256.sig
wget https://cdn.openbsd.org/pub/OpenBSD/7.9/openbsd-79-base.pub
Die drei Dateien erfüllen unterschiedliche Aufgaben. install79.img ist das Installationsimage. SHA256.sig enthält die signierten Prüfsummen der Release-Dateien. Der öffentliche Release-Schlüssel wird benötigt, um deren Signatur zu prüfen.
Mit signify(1) lässt sich die Signatur prüfen und gleichzeitig das Image gegen die authentifizierte Prüfsumme kontrollieren:
$ signify -C -p openbsd-79-base.pub -x SHA256.sig install79.img
Signature Verified
install79.img: OK
Die beiden Erfolgsmeldungen beantworten zwei miteinander verbundene Fragen. Die Signatur bestätigt die Authentizität der verwendeten Prüfsummen gegenüber dem verwendeten öffentlichen Schlüssel. Die anschließende Prüfung bestätigt, dass install79.img zu seiner authentifizierten Prüfsumme passt.
Eine bloße SHA256-Prüfung reicht dafür nicht aus. Sie kann feststellen, ob ein Image zu einer bestimmten Prüfsumme passt, beantwortet aber nicht die Frage, woher diese Prüfsumme stammt.
Woher wissen wir, dass der Schlüssel stimmt?
Damit verschiebt sich die Vertrauensfrage um eine Ebene.
Auf einer bestehenden OpenBSD-Installation befinden sich die vorgesehenen Release-Schlüssel unter /etc/signify/. Bei einer Erstinstallation muss der öffentliche Schlüssel selbst aus einer vertrauenswürdigen Quelle stammen oder unabhängig mit den vom OpenBSD-Projekt veröffentlichten Angaben verglichen werden.
Ein Dateiname wie openbsd-79-base.pub macht eine Datei für sich genommen noch nicht zu einem vertrauenswürdigen Schlüssel.
Installationsmedium erstellen
Das verifizierte install79.img kann direkt auf einen USB-Stick geschrieben werden:
# dd if=~/iso/openbsd/7.9/amd64/install79.img of=/dev/sdX bs=1M
/dev/sdX ist nur ein Platzhalter. dd überschreibt das angegebene Ziel ohne Rückfrage. Vor dem Schreiben muss deshalb geprüft werden, welches Gerät tatsächlich dem USB-Stick entspricht.
Der Stick muss vorher nicht formatiert werden. Das Image enthält bereits die benötigte Datenträgerstruktur.
Bei einer virtuellen Maschine kann stattdessen install79.iso als virtuelles Installationsmedium eingebunden werden.
Mit bsd.rd läuft bereits OpenBSD
Nach dem Start vom Installationsmedium lädt das System bsd.rd. Dabei handelt es sich um einen Kernel mit integrierter RAM-Disk, der eine kompakte Umgebung für Installation, Upgrade und Wartungsarbeiten bereitstellt.
Dieser Punkt ist wichtig für das Verständnis des gesamten Installationsvorgangs: Während der Installation läuft bereits OpenBSD.
Der Kernel erkennt Hardware und bindet passende Treiber ein. Das Installationssystem kann Netzwerkinterfaces konfigurieren, Datenträger untersuchen, Dateisysteme erzeugen und einhängen, Dateien aus dem Netzwerk beziehen und Programme ausführen. Was ihm gegenüber dem später installierten System vor allem fehlt, ist ein dauerhafter eigener Systemzustand auf dem Zieldatenträger.
Genau diesen Zustand erzeugt der Installer.
Bild: OpenBSD 7.9 hat bereits Hardware erkannt, bevor der eigentliche Installationsdialog beginnt.
Nach der Initialisierung erscheint:
Welcome to the OpenBSD/amd64 7.9 installation program.
(I)nstall, (U)pgrade, (A)utoinstall or (S)hell?
Die Möglichkeiten sind:
- (I)nstall – Neuinstallation
- (U)pgrade – Upgrade einer vorhandenen Installation
- (A)utoinstall – automatisierte Installation
- (S)hell – Shell des Installationssystems
Für unsere Neuinstallation wählen wir I.
Der Installer weist außerdem auf eine praktische Eigenschaft dieser Umgebung hin:
At any prompt except password prompts you can escape to a shell by
typing '!'. Default answers are shown in []'s and are selected by
pressing RETURN.
Mit ! lässt sich an fast jedem Prompt vorübergehend in eine Shell derselben laufenden bsd.rd-Umgebung wechseln. Dort können beispielsweise Hardware, Netzwerk oder Datenträger untersucht werden. Mit exit geht es anschließend im Installer weiter.
Ein Abbruch des Installers mit Control-C ist davon zu unterscheiden. Der Installer warnt ausdrücklich davor, dass dadurch ein bereits teilweise verändertes System in einem inkonsistenten Zustand zurückbleiben kann.
Während des Starts kann außerdem die Meldung:
WARNING: CHECK AND RESET THE DATE!
erscheinen. Eine offensichtlich falsche Systemzeit sollte korrigiert werden, bevor Arbeiten ausgeführt werden, die einen korrekten Zeitbezug voraussetzen. Die dauerhafte Zeitsynchronisation behandeln wir bei der späteren Systemkonfiguration.
Tastaturlayout
Der erste interaktive Dialog fragt nach dem Tastaturlayout. ? beziehungsweise L zeigt die verfügbaren Layouts.
Bild: Auswahl von de.nodead während unserer Installation.
Für deutsche Tastaturen stehen unter anderem de und de.nodead zur Verfügung. Welche Variante sinnvoll ist, hängt von der persönlichen Arbeitsweise ab.
Hostname und Netzwerk
Der Installer fragt zunächst nach einem kurzen Hostnamen:
System hostname? (short form, e.g. 'foo')
Aus dieser Antwort entsteht später unter anderem /etc/myname.
Anschließend werden die vom Kernel erkannten Netzwerkinterfaces angeboten. In unserer virtuellen Maschine erscheint beispielsweise vio0; auf anderer Hardware können je nach Treiber andere Namen auftauchen.
IPv4 und IPv6 werden getrennt konfiguriert:
IPv4 address for vio0? (or 'autoconf' or 'none') [autoconf]
IPv6 address for vio0? (or 'autoconf' or 'none') [autoconf]
Die beiden Fragen betreffen eigenständige Protokollkonfigurationen. Die Unterschiede zwischen der automatischen IPv4- und IPv6-Konfiguration behandeln wir im Netzwerkkapitel ausführlicher.
Bei automatischer IPv4-Konfiguration kann auf dem installierten System beispielsweise folgende Datei entstehen:
/etc/hostname.vio0:
inet autoconf
Eine statische IPv4-Konfiguration könnte entsprechend lauten:
/etc/hostname.em0:
inet 192.168.1.10 255.255.255.0
Eine statische Default-Route wird getrennt davon über /etc/mygate konfiguriert.
Wichtig ist die zeitliche Reihenfolge: Das Netzwerk wird nicht erst nach der Installation aktiv. bsd.rd konfiguriert das Interface bereits im laufenden Installationssystem. Nur dadurch können beispielsweise Sets über HTTP bezogen werden. Aus den währenddessen getroffenen Entscheidungen erzeugt der Installer anschließend die persistente Netzwerkkonfiguration für das Zielsystem.
Beim späteren Boot verarbeitet netstart(8) diese Konfiguration.
Auch IP-Konnektivität und Namensauflösung sind getrennte Funktionen. Ein korrekt konfiguriertes Interface bedeutet nicht automatisch, dass DNS funktioniert. Diese Unterscheidung werden wir beim ersten Boot noch einmal sehen.
Root, Benutzer und SSH
Während der Installation werden mehrere Entscheidungen über administrative Zugänge getroffen. Sie gehören zusammen, sind aber nicht dasselbe.
Zunächst erhält der lokale Root-Account ein Passwort:
Password for root account? (will not echo)
Password for root account? (again)
Danach fragt der Installer, ob sshd(8) standardmäßig gestartet werden soll:
Start sshd(8) by default? [yes]
Ein vorhandener Root-Account und ein laufender SSH-Daemon bedeuten noch nicht, dass sich root über SSH anmelden darf.
Der Installer bietet außerdem an, einen regulären Benutzer anzulegen:
Setup a user? (enter a lower-case loginname, or 'no') [no]
Dieser Benutzer wird Mitglied der Gruppe wheel. Danach folgt die getrennte Entscheidung über Root-Anmeldungen per SSH:
WARNING: root is targeted by password guessing attacks, pubkeys are safer.
Allow root ssh login? (yes, no, prohibit-password) [no]
Bild: Benutzeranlage und die davon getrennte Entscheidung über Root-Anmeldungen per SSH.
wheel bedeutet allerdings nicht automatisch, dass der Benutzer doas(1) verwenden darf. Die Autorisierung erfolgt über /etc/doas.conf, und diese Datei legt der Installer nicht automatisch an.
Nach dem ersten Login kann beispielsweise folgende einfache Policy eingerichtet werden:
$ su -
Password:
# echo "permit persist :wheel" > /etc/doas.conf
# exit
$ doas whoami
root
Die Gruppe wheel ist hier eine Eigenschaft, auf die die doas-Regel Bezug nimmt. Die eigentliche Autorisierung entsteht erst durch diese Regel.
X Window System
Auf amd64 fragt der Installer:
Do you expect to run the X Window System? [yes]
Diese Frage entscheidet nicht, welche X-Sets installiert werden. Sie betrifft die vorgesehene Verwendung eines lokalen X-Servers.
Bei yes folgt zusätzlich:
Do you want the X Window System to be started by xenodm(1)? [no]
Damit sind drei Entscheidungen auseinanderzuhalten:
- X-Sets auf dem System installieren
- einen lokalen X-Server vorsehen
xenodm(1)beim Boot starten
Gerade bei Servern ist diese Trennung wichtig. Ob X-Sets benötigt werden, lässt sich nicht allein aus der Frage ableiten, ob eine grafische Oberfläche verwendet wird.
Serielle Konsole
Der Installer kann die Standardkonsole auf eine serielle Schnittstelle umstellen:
Change the default console to com0? [no]
Das ist insbesondere bei headless betriebenen Maschinen oder Systemen mit serieller Remote-Konsole relevant. Für Systeme mit normaler lokaler oder virtueller Konsole bleibt die Vorgabe no häufig passend.
Eine serielle Konsole kann auch später über /etc/boot.conf eingerichtet werden. Die Details behandeln wir bei der Boot-Konfiguration.
Zeitzone
Die Zeitzone wird während der Installation beispielsweise mit:
What timezone are you in? ('?' for list) [Europe/Berlin]
festgelegt.
In unserer Installation wurde Europe/Berlin als Vorgabe angeboten. Der angezeigte Default gehört zum konkreten Installationslauf und ist keine allgemeine Aussage darüber, welche Zeitzone der Installer auf jedem System vorschlägt.
Datenträger und Verschlüsselung
Der Installer zeigt die erkannten Datenträger:
Available disks are: sd0.
Which disk is the root disk? ('?' for details) [sd0]
Vor der weiteren Datenträgeraufteilung fragt der OpenBSD-7.9-Installer in unserem Installationslauf nach einer möglichen Verschlüsselung des Root-Datenträgers:
Encrypt the root disk with a (p)assphrase or (k)eydisk? [no]
Bei einer Passphrase muss das verschlüsselte Volume beim Boot entsperrt werden, bevor auf das darin liegende System zugegriffen werden kann. Das schützt insbesondere Daten auf einem ausgeschalteten oder entwendeten Datenträger.
MBR, GPT und Disklabel
Auf amd64 begegnen uns bei der Datenträgerkonfiguration mehrere Ebenen.
Der Installer fragt in unserer Installation anschließend:
Use (W)hole disk MBR, whole disk (G)PT or (E)dit? [whole]
MBR beziehungsweise GPT beschreiben dabei die äußere Datenträgerstruktur. Innerhalb des für OpenBSD vorgesehenen Bereichs verwendet OpenBSD zusätzlich ein eigenes Disklabel.
Das Disklabel beschreibt die OpenBSD-internen Partitionen. Typischerweise enthält a das Root-Dateisystem und b Swap. Der Eintrag c besitzt eine besondere Bedeutung: Er repräsentiert den gesamten Datenträger und ist keine weitere normale Dateisystempartition.
Der Installer kann ein automatisches Layout erzeugen:
Use (A)uto layout, (E)dit auto layout, or create (C)ustom layout? [a]
Bild: Automatisch erzeugtes Disklabel unserer 32-GB-Installation.
In dieser Installation entstehen getrennte Bereiche unter anderem für /, Swap, /tmp, /var, /usr, /usr/X11R6, /usr/local, /usr/src, /usr/obj und /home.
Diese konkrete Aufteilung ist kein festes OpenBSD-Standardlayout. Das Auto-Layout hängt unter anderem von der Größe des Datenträgers ab. Auf einer anderen Platte kann der Vorschlag deshalb anders aussehen.
Getrennte Dateisysteme schaffen zugleich Systemgrenzen. Ein volles /var muss beispielsweise nicht den für / reservierten Platz verbrauchen. Später können die einzelnen Dateisysteme außerdem unterschiedliche Mount-Eigenschaften erhalten.
Im Screenshot fällt auch /usr/X11R6 auf. Seine Existenz im Disklayout bedeutet nicht, dass später zwingend X-Sets installiert werden. Datenträgerlayout und Softwareauswahl sind zwei getrennte Entscheidungen.
Die Sets des Base Systems
OpenBSD verteilt sein Base System in sogenannten Sets. Sie gehören zum jeweiligen Release und sind nicht mit zusätzlichen Packages aus der Ports/Packages Collection zu verwechseln.
OpenBSD 7.9 verwendet auf amd64 unter anderem:
- bsd – GENERIC-Kernel
- bsd.mp – Multiprozessor-Kernel
- bsd.rd – RAM-Disk-Kernel für Installation und Wartung
- base79.tgz – grundlegendes Base System
- comp79.tgz – Compiler, Header und Entwicklungswerkzeuge
- man79.tgz – Manual Pages
- game79.tgz – textbasierte Spiele
- xbase79.tgz – X11-Basisbibliotheken und Utilities
- xfont79.tgz – X11-Fonts
- xserv79.tgz – X11-Server
- xshare79.tgz – gemeinsame X11-Dateien, Manpages, Locale-Daten und Includes
bsd und base79.tgz sind für die Installation erforderlich. OpenBSD empfiehlt insbesondere neuen Benutzern, alle Sets zu installieren.
Was bedeutet minimal auf einem Server?
Auf einem öffentlich erreichbaren Server ist es sinnvoll, die tatsächlich benötigte Systembasis zu kennen.
Nicht installierter Base-System-Code gehört nicht zur laufenden Systembasis und benötigt auf diesem System keine eigenen Base-System-Patches. Daraus folgt jedoch nicht automatisch, dass ein Server ohne grafische Oberfläche alle X-Sets entbehren kann.
Die X-Sets erfüllen unterschiedliche Aufgaben. xserv79.tgz enthält X-Server, während xbase79.tgz auch Bibliotheken enthält, die von Programmen ohne eigene grafische Oberfläche benötigt werden können.
Für die Sicherheitsbetrachtung müssen deshalb mehrere Fragen getrennt werden: Ist eine Komponente installiert? Wird sie gestartet? Ist sie selbst aus dem Netzwerk erreichbar? Oder wird sie von einem erreichbaren Prozess zur Verarbeitung von Daten verwendet?
Ein bewusst reduzierter Produktionsserver kann eine kleinere Systembasis besitzen. Die Auswahl sollte aber aus seinem konkreten Einsatzzweck und den tatsächlichen Abhängigkeiten entstehen – nicht allein aus der Kategorie „Server“.
Auch eine Maschine, auf der Ports gebaut werden, besitzt andere Anforderungen als ein Produktionsserver, der fertige Binärpakete verwendet. Beim Bauen aus dem Ports-Tree hängt der benötigte Systemumfang vom jeweiligen Port und seinen Abhängigkeiten ab. Manche Ports kommen ohne X11-Komponenten aus, andere benötigen X11-Bibliotheken oder weitere Bestandteile. Ein bewusst reduzierter Produktionsserver ist deshalb nicht automatisch eine geeignete Buildumgebung.
Sets auswählen
Der Installer erlaubt, einzelne Sets oder Muster aus der Auswahl zu entfernen.
In unserer Beispielinstallation entfernen wir:
-x*
und anschließend:
-g*
Bild: Konkrete Set-Auswahl unserer Installation mit -x* und -g*. Sie ist keine allgemeine Empfehlung für jeden Server.
Sets vom Installationsmedium oder aus dem Netzwerk
Bei install79.img und install79.iso befinden sich die Release-Sets bereits auf dem vollständigen Installationsmedium. Wurde dieses Image vor dem Boot erfolgreich verifiziert, liegen die eingebetteten Sets innerhalb dieses bereits geprüften Artefakts.
Alternativ kann der Installer die Sets beispielsweise über HTTP beziehen:
Location of sets? (cd0 disk http nfs or 'done') [done]
Welcher Default dort erscheint, hängt vom bisherigen Installationsweg und den verfügbaren Quellen ab.
Bei einer HTTP-Installation werden die Sets erst vom bereits laufenden Installationssystem geladen. Der Installer prüft die zugehörigen Signaturen und Prüfsummen, bevor er sie installiert.
Bild: Download, Verifikation und Installation der Sets über HTTP.
Der Unterschied ist klein, aber wichtig: Beim vollständigen Installationsimage beginnt die Vertrauenskette mit unserer Prüfung vor dem Boot. Bei über das Netzwerk bezogenen Sets prüft anschließend der bereits laufende und zuvor vertrauenswürdig gestartete Installer die neu empfangenen Daten.
Bei einer Mirror-Installation wird die gewählte OpenBSD-Quelle außerdem in /etc/installurl gespeichert. Sie wird später unter anderem von pkg_add(1), syspatch(8) und sysupgrade(8) als Ausgangspunkt verwendet.
Abschluss der Installation
Nach der Installation der Sets speichert der Installer die Konfiguration, erzeugt benötigte Device Nodes und richtet das Zielsystem für den Boot ein.
In unserer OpenBSD-7.9-Installation erscheint unter anderem:
Saving configuration files... done.
Making all device nodes... done.
Multiprocessor machine; using bsd.mp instead of bsd.
fw_update: add intel; update none
Relinking to create unique kernel... done.
Bild: Abschlussphase mit Kernel-Auswahl, Firmware-Prüfung und Kernel-Relinking.
Auf dem Multiprozessorsystem wird bsd.mp als /bsd eingerichtet. Außerdem führt OpenBSD Firmware-Arbeiten aus und relinkt den Kernel. Die Details des Kernel Address Randomized Link, KARL, behandeln wir später bei den Sicherheitsmechanismen.
Schließlich meldet der Installer:
CONGRATULATIONS! Your OpenBSD install has been successfully completed!
Die Installation ist damit erfolgreich abgeschlossen. Das bedeutet allerdings noch nicht, dass alle einmaligen Initialisierungsarbeiten des neuen Systems bereits ausgeführt wurden.
Der erste Boot
Nach dem Neustart übernimmt erstmals das installierte System.
OpenBSD verwendet /etc/rc.firsttime für Arbeiten, die genau beim ersten Start ausgeführt werden sollen. rc(8) verarbeitet diese Datei einmal und entfernt sie anschließend.
Unsere Beispielinstallation vom 9. Juni 2026 zeigt dabei einen interessanten Fehler:
Bild: Erster Boot am 9. Juni 2026 mit rc.firsttime, fehlgeschlagenem Firmware-Abruf und anschließendem normalen Systemstart.
running rc.firsttime
fw_update: failed
Cannot fetch http://firmware.openbsd.org/firmware/7.9/SHA256.sig
error: firmware.openbsd.org: no address associated with name
fw_update kann den Hostnamen des Firmware-Servers hier nicht auflösen. Der Bootvorgang läuft trotzdem weiter.
Das Beispiel zeigt, warum bei der Fehlersuche präzise unterschieden werden muss. Ein funktionierendes Netzwerkinterface bedeutet noch nicht, dass auch DNS funktioniert. Und eine fehlgeschlagene First-Boot-Aktion bedeutet nicht zwangsläufig, dass das gesamte System nicht bootfähig ist.
Entscheidend ist immer, welcher Vorgang gescheitert ist und welche Aufgabe er für das System erfüllt.
Errata und syspatch
Bei dieser Installation am 9. Juni 2026 meldet der erste Boot anschließend zwei zu diesem Zeitpunkt verfügbare binäre Patches:
Checking for available binary patches...
Run syspatch(8) to install:
002_smtpd
003_vmd
Diese Nummern dokumentieren den Patchstand zu diesem Zeitpunkt. Sie sind keine Aussage darüber, welche Errata-Patches heute für OpenBSD 7.9 verfügbar sind.
Ein gerade frisch installiertes Release kann bereits bekannte Korrekturen vermissen. Darin liegt kein Widerspruch: Das Installationsmedium enthält den veröffentlichten Release-Stand. Nach dessen Veröffentlichung können Fehler oder Sicherheitsprobleme bekannt und korrigiert worden sein.
OpenBSD dokumentiert solche relevanten Korrekturen als Errata.
Ein einzelnes Erratum bezeichnet eine bekanntgemachte Korrektur; Errata ist die Mehrzahl beziehungsweise die Sammlung dieser Korrekturen. Der Patch ist die technische Änderung. syspatch(8) verwaltet die entsprechenden binären Base-System-Patches auf unterstützten Releases.
Die beim Boot gefundenen Patches werden nicht automatisch installiert:
$ doas syspatch
Installierte Patches zeigt:
$ syspatch -l
Noch verfügbare Patches lassen sich mit:
$ syspatch -c
anzeigen.
Vor dem Ersetzen von Dateien legt syspatch Rollback-Daten unter /var/syspatch ab.
Bei einem bewusst reduzierten System bleibt auch hier die Set-Auswahl relevant: Fehlt ein Set, wird nicht allein wegen eines dafür veröffentlichten Patches der zugehörige Base-System-Code installiert.
Base System und Packages
syspatch pflegt das OpenBSD Base System. Zusätzliche Software aus der Ports/Packages Collection besitzt einen getrennten Verwaltungsweg.
Binärpakete werden mit pkg_add(1) installiert:
$ doas pkg_add paketname
Bereits installierte Packages können beispielsweise mit:
$ doas pkg_add -u
aktualisiert werden.
Diese Trennung ist mehr als eine unterschiedliche Befehlsoberfläche. Base System und zusätzliche Packages sind unterschiedliche Bestandteile des OpenBSD-Systems und besitzen eigene Lebenszyklen.
Die Paketverwaltung behandeln wir deshalb im folgenden Verlauf der Grundlagenserie ausführlicher.
Was der Installer hinterlässt
Nach Installation und erstem Boot sind die Dialogfragen verschwunden. Ihre Ergebnisse bleiben als Systemzustand erhalten.
Je nach gewählter Konfiguration gehören dazu beispielsweise:
/etc/myname/etc/hostname.*/etc/mygate/etc/resolv.conf/etc/installurl/etc/fstab- Benutzerkonten
- MBR- oder GPT-Strukturen
- das OpenBSD Disklabel
- Dateisysteme und Swap
- Kernel und Boot-Komponenten
- die ausgewählten Base-System-Sets
- gegebenenfalls zusätzliche Firmware
Damit lässt sich die OpenBSD-Installation besser als Erzeugung eines persistenten Systemzustands verstehen denn als Kopieren einiger Archive.
Wir sind mit einem externen, verifizierten Installationsmedium gestartet. bsd.rd stellte zunächst ein flüchtiges laufendes OpenBSD bereit. Der Installer hat unsere Entscheidungen anschließend in einen persistenten Zustand auf dem Zielsystem übersetzt. Beim ersten Boot wurden einmalige Arbeiten ausgeführt, und mit syspatch kann das Base System anschließend auf den aktuellen Errata-Stand des Releases gebracht werden.
Damit ist die Grundlage geschaffen. Im nächsten Schritt geht es nicht mehr darum, OpenBSD auf die Maschine zu bekommen, sondern das entstandene System für seine konkrete Aufgabe zu konfigurieren.
Verwendete Informationen
Diese Anleitung bezieht sich auf:
- OpenBSD: 7.8 und 7.9
- Installationsbeispiel und Screenshots: OpenBSD 7.9 auf amd64
- Beispielinstallation: 9. Juni 2026
- Kontext: Grundlagen für Server- und allgemeine Installationen
- Stand: August 2026
