OpenBSD: Paketverwaltung und Software-Installation

OpenBSD verwaltet Base-System und zusätzliche Software getrennt. Das Base-System gehört zur OpenBSD-Release; zusätzliche Software kommt über das Package-System hinzu. Offizielle Packages werden bei der Installation kryptografisch geprüft.

Systemkonfiguration erklärt die grundlegende Einrichtung nach der Installation. Hier geht es um Installation, Abfrage, Entfernung und Aktualisierung von Software mit pkg_add, pkg_info und pkg_delete.

Base-System und Packages

Das Base-System ist keine Sammlung besonderer Packages, sondern Bestandteil der OpenBSD-Release. Dazu gehören Kernel, Systemprogramme, Bibliotheken, Daemons, Dokumentation und – abhängig von der gewählten Installation – weitere Sets wie Compiler oder X11-Komponenten.

Software außerhalb des Base-Systems wird als Package installiert:

/usr/bin/vi             # Base-System Editor (enthalten)
/usr/local/bin/vim      # Package vim (nach Installation)
/usr/sbin/httpd         # Base-System HTTP-Server (enthalten)
/usr/local/sbin/nginx   # Package nginx (nach Installation)

Package-Dateien liegen überwiegend unter /usr/local. Je nach Package kommen Dateien an anderen vorgesehenen Stellen hinzu – etwa rc-Skripte unter /etc/rc.d oder Laufzeitdaten unter /var. Den installierten Package-Zustand hält OpenBSD unter /var/db/pkg fest. Die Trennung von Base-System und Packages ist damit eine Verwaltungsgrenze, keine absolute Dateisystemgrenze.

Die Update-Strategie spiegelt diese Trennung:

• sysupgrade aktualisiert das Base-System
• pkg_add -u aktualisiert installierte Packages
• Kein Vermischen beider Systeme

pkg_add - Software installieren

Das Tool pkg_add installiert Software aus OpenBSD-Repositories. Die Installation lädt Pakete, prüft Signaturen und installiert Dependencies automatisch.

Einfache Installation

Ein Package installieren:

$ doas pkg_add nginx
quirks-7.194 signed on 2026-06-10T19:46:25Z
nginx-1.30.2:bzip2-1.0.8p0: ok
nginx-1.30.2:pcre2-10.44: ok
nginx-1.30.2: ok
The following new rcscripts were installed: /etc/rc.d/nginx
See rcctl(8) for details.
New and changed readme(s):
	/usr/local/share/doc/pkg-readmes/nginx

quirks enthält Sonderregeln und Kompatibilitätswissen für die Package-Tools und wird von pkg_add aktuell gehalten. Dependencies wie bzip2 und pcre2 werden automatisch mitinstalliert. Die Meldung zu rcscripts zeigt den neuen Dienst; Details folgen im geplanten Artikel Dienste und Daemons.
New and changed readme(s) verweist auf paketspezifische Hinweise unter /usr/local/share/doc/pkg-readmes/.

Package mit Rückfragen:

$ doas pkg_add vim
quirks-7.194 signed on 2026-06-10T19:46:25Z
Ambiguous: choose package for vim
a	0: <None>
	1: vim-9.2.357
	2: vim-9.2.357-gtk3
	3: vim-9.2.357-gtk3-lua
	4: vim-9.2.357-gtk3-perl-python3-ruby
	5: vim-9.2.357-gtk3-python3
	6: vim-9.2.357-lua
	7: vim-9.2.357-perl-python3-ruby
	8: vim-9.2.357-python3
	9: vim-9.2.357-ruby
Your choice: 1
vim-9.2.357:libsodium-1.0.22: ok
vim-9.2.357:libiconv-1.19: ok
vim-9.2.357:gettext-runtime-1.0: ok
vim-9.2.357: ok

Mehrere Varianten existieren – mit verschiedenen Feature-Sets (GTK3-GUI, Lua, Python3, Ruby) oder ohne X11 für Server. Die Auswahl erfolgt interaktiv oder via explizitem Package-Namen:

$ doas pkg_add vim-9.2.357-lua

Paket-Suche

Verfügbare Packages durchsuchen:

$ pkg_info -Q rsync
debug-rsync-3.4.4
debug-rsync-3.4.4-minimal
rsync-3.4.4
rsync-3.4.4-minimal

Der Parameter -Q durchsucht Package-Namen. Teilstring-Suche funktioniert – py, python, python3 finden entsprechende Pakete.
Debug-Varianten enthalten zusätzliche Symbole für die Fehleranalyse und sind für den normalen Betrieb nicht relevant.

Detaillierte Paket-Informationen:

$ pkg_info -Q nginx
nginx-1.30.2 (installed)
nginx-cache_purge-1.30.2
nginx-headers-more-1.30.2
nginx-lua-1.30.2
nginx-stream-1.30.2
[... weitere Modul-Varianten ...]

Der Zusatz “(installed)” kennzeichnet bereits installierte Packages.

Detaillierte Informationen zu einem Package liefert pkg_info ohne Parameter -Q — siehe Abschnitt pkg_info - Installierte Software auflisten.

Dependencies automatisch installieren

Package-Manager löst Abhängigkeiten automatisch:

$ doas pkg_add mariadb-server
quirks-7.194 signed on 2026-06-10T19:46:25Z
mariadb-server-11.4.10p0v1:lz4-1.10.0: ok
mariadb-server-11.4.10p0v1:xz-5.8.3: ok
mariadb-server-11.4.10p0v1:zstd-1.5.7p0: ok
mariadb-server-11.4.10p0v1:mariadb-client-11.4.10p0v1: ok
mariadb-server-11.4.10p0v1:coreutils-9.10: ok
mariadb-server-11.4.10p0v1:p5-DBI-1.648: ok
mariadb-server-11.4.10p0v1:p5-DBD-MariaDB-1.23: ok
mariadb-server-11.4.10p0v1:curl-8.20.0: ok
[... weitere Dependencies ...]
mariadb-server-11.4.10p0v1: ok
Running tags: ok
The following new rcscripts were installed: /etc/rc.d/mysqld
See rcctl(8) for details.
New and changed readme(s):
	/usr/local/share/doc/pkg-readmes/mariadb-server

pkg_add ermittelt die deklarierten Abhängigkeiten und installiert fehlende Dependencies. Direkt angeforderte Packages gelten als manuell installiert; reine Dependencies als automatisch installiert. Dieser Unterschied wird beim späteren Aufräumen mit pkg_delete -a wichtig.

README-Hinweise unter /usr/local/share/doc/pkg-readmes/ sollten vor der Inbetriebnahme gelesen werden.

Mehrere Packages gleichzeitig

Liste installieren:

$ doas pkg_add git htop rsync curl
quirks-7.194 signed on 2026-06-10T19:46:25Z
git-2.53.0:cvsps-2.1p3: ok
git-2.53.0:gitwrapper-0.125: ok
git-2.53.0:p5-Error-0.17030: ok
git-2.53.0:p5-Time-TimeDate-2.33: ok
git-2.53.0:p5-Mail-Tools-2.21p0: ok
git-2.53.0: ok
htop-3.4.1:libb2-0.98.1v0: ok
htop-3.4.1:sqlite3-3.51.3: ok
htop-3.4.1:python-3.13.13: ok
[... weitere Dependencies ...]
htop-3.4.1: ok
Ambiguous: choose package for rsync
a	0: <None>
	1: rsync-3.4.4
	2: rsync-3.4.4-minimal
Your choice: 2
rsync-3.4.4-minimal: ok
Running tags: ok
The following new rcscripts were installed: /etc/rc.d/gitdaemon /etc/rc.d/rsyncd
See rcctl(8) for details.
New and changed readme(s):
	/usr/local/share/doc/pkg-readmes/git
	/usr/local/share/doc/pkg-readmes/glib2

Bereits passende installierte Packages müssen nicht erneut installiert werden. Bei mehreren passenden Varianten kann eine Auswahl erforderlich sein. Ein Fehler löst keinen globalen Rollback aus: Bereits erfolgreich installierte Packages oder Dependencies bleiben installiert.

Repository-Struktur

OpenBSD nutzt offizielle Mirrors für Package-Distribution. Die Mirror-URL wird automatisch aus /etc/installurl gelesen:

$ cat /etc/installurl
https://cdn.openbsd.org/pub/OpenBSD

Diese Datei wird während der Installation mit dem gewählten Installationsserver angelegt. Manuelle Anpassung ist möglich, falls ein anderer Mirror verwendet werden soll.

Mirror-Liste

Offizielle Mirrors sind auf der OpenBSD-Website dokumentiert: https://www.openbsd.org/ftp.html ↗

Deutsche Mirrors (Auswahl):

https://ftp.spline.de/pub/OpenBSD/              # Berlin
https://ftp.halifax.rwth-aachen.de/pub/OpenBSD/ # Aachen
https://artfiles.org/openbsd/                   # Hamburg
https://ftp.hostserver.de/pub/OpenBSD/          # Frankfurt
https://mirror.junda.nl/pub/OpenBSD/            # Falkenstein

Mirror ändern:

$ echo "https://ftp.hostserver.de/pub/OpenBSD" | doas tee /etc/installurl
https://ftp.hostserver.de/pub/OpenBSD
$ cat /etc/installurl
https://ftp.hostserver.de/pub/OpenBSD

Die Pipe mit tee schreibt die URL mit Root-Rechten in die Datei. Die nächste Package-Installation nutzt den neuen Mirror. Kein Cache-Clear oder System-Neustart notwendig.

Package-Struktur im Repository

Packages liegen unter snapshots oder Release-Versionsnummer:

https://cdn.openbsd.org/pub/OpenBSD/7.9/packages/amd64/

Die URL-Komponenten:

• 7.9 - OpenBSD-Version (Current Release)
• packages - Binäre Packages (vs. Sets)
• amd64 - Architektur (Intel/AMD 64-Bit)

Snapshots nutzen aktuellere Packages:

https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/

Snapshot-Packages gehören zum Snapshot-Zweig und müssen zusammen mit einem dazu passenden Snapshot-Base-System verwendet werden. Release-Packages und Snapshot-Packages sollten nicht miteinander vermischt werden.

Signaturverifikation

Offizielle Packages tragen eine kryptografische Signatur. Die Package-Tools prüfen diese Signatur bei der Installation automatisch mit den passenden öffentlichen Schlüsseln aus /etc/signify. Die Prüfung stellt sicher, dass das Package aus der erwarteten signierten Quelle stammt und seit der Signierung nicht verändert wurde.

Automatische Prüfung

Die Signatur-Prüfung erfolgt transparent:

$ doas pkg_add nginx
quirks-7.194 signed on 2026-06-10T19:46:25Z
nginx-1.30.2: ok

Die sichtbare Zeile signed on... gehört hier zu quirks; nicht jede Package-Prüfung erzeugt eine eigene solche Zeile.

Im normalen Betrieb akzeptiert pkg_add keine Packages ohne vertrauenswürdige Signatur. Für bewusst als vertrauenswürdig behandelte lokale oder unsignierte Packages existieren jedoch ausdrücklich vorgesehene Ausnahmen.

Eine gültige Signatur belegt Herkunft und Integrität, nicht den Audit-Status des Inhalts. Da Packages bei der Installation Aktionen mit Systemrechten ausführen können, bleibt eine vertrauenswürdige Quelle entscheidend.

Öffentliche Schlüssel

Signatur-Prüfung nutzt öffentliche Schlüssel aus /etc/signify:

$ ls /etc/signify
openbsd-72-base.pub       openbsd-75-base.pub       openbsd-78-base.pub
openbsd-72-fw.pub         openbsd-75-fw.pub         openbsd-78-fw.pub
openbsd-72-pkg.pub        openbsd-75-pkg.pub        openbsd-78-pkg.pub
openbsd-72-syspatch.pub   openbsd-75-syspatch.pub   openbsd-78-syspatch.pub
[... ältere Release-Versionen ...]
openbsd-79-base.pub       openbsd-80-base.pub
openbsd-79-fw.pub         openbsd-80-fw.pub
openbsd-79-pkg.pub        openbsd-80-pkg.pub
openbsd-79-syspatch.pub   openbsd-80-syspatch.pub

Die Schlüssel sind Release-spezifisch:

• base.pub - Base-System-Updates
• pkg.pub - Package-Signaturen
• fw.pub - Firmware-Updates
• syspatch.pub - Security-Patches

OpenBSD-Releases enthalten neben den aktuellen auch die Schlüssel des nächsten Releases. Die bereits vorhandenen openbsd-80-* Keys ermöglichen damit die Verifikation entsprechend signierter 8.0-Artefakte und setzen die Vertrauenskette beim Upgrade fort.

Vorhandene ältere Schlüssel bedeuten nicht, dass OpenBSD System-Downgrades unterstützt.

Vertrauensmodell

Die öffentlichen Schlüssel unter /etc/signify gehören zum Base-System. Für Release-Dateien wie bsd.rd wird SHA256.sig mit dem passenden base.pub-Schlüssel geprüft; die enthaltenen Prüfsummen verifizieren anschließend die Release-Dateien.

Packages verwenden ihre eigene Signatur und den passenden pkg.pub-Schlüssel. Diese Prüfung übernimmt pkg_add vor der Installation.

Damit sind drei unterschiedliche Begriffe auseinanderzuhalten:

• Release-Signatur: signierte Prüfsummen für Release-Artefakte
• Package-Signatur: kryptografische Signatur eines Package-Archivs
• Update-Signatur: technische Kennung eines Packages für die Update-Logik; siehe pkg_info -S

Die Schlüssel ermöglichen die Verifikation entsprechender Artefakte; unterstützte Upgrade-Pfade sind davon unabhängig.

pkg_info - Installierte Software auflisten

Das Tool pkg_info zeigt Package-Informationen. Ohne Package-Namen listet es installierte Packages; mit einem Namen kann es auch Informationen zu einem verfügbaren Package aus dem Repository liefern.

Alle installierten Packages

Liste aller installierten Packages:

$ pkg_info
bzip2-1.0.8p0       block-sorting file compressor, unencumbered
coreutils-9.10      file, shell and text manipulation utilities
curl-8.20.0         transfer files with FTP, HTTP, HTTPS, etc.
git-2.53.0          distributed version control system
htop-3.4.1          interactive process viewer
mariadb-client-11.4.10p0v1 multithreaded SQL database (client)
mariadb-server-11.4.10p0v1 multithreaded SQL database (server)
nginx-1.30.2        robust and small HTTP server and mail proxy server
python-3.13.13      interpreted object-oriented programming language
rsync-3.4.4-minimal mirroring/synchronization over low bandwidth links
vim-9.2.357         vi clone with many additional features
[... weitere installierte Packages ...]

Die Ausgabe nennt Package-Namen, Version und Kurzbeschreibung. Dependencies (wie libiconv, p5-* Module) erscheinen ebenfalls.

Paket-Details

Detaillierte Informationen zu einem Package:

$ pkg_info nginx-1.30.2
Information for inst:nginx-1.30.2

Comment:
robust and small HTTP server and mail proxy server

Description:
This is the stable branch of nginx, as distributed by nginx.org.
nginx provides FastCGI and reverse HTTP proxying, with or without caching,
including simple load balancing and fault tolerance.
It has a modular architecture.  Filters include gzipping, byte ranges,
chunked responses, and SSI.  Multiple SSI inclusions within a single page
can be processed in parallel if they are handled by FastCGI or proxied
servers.  SSL and TLS SNI are supported.

Maintainer: Robert Nagy <robert@openbsd.org>
WWW: https://nginx.org/

Die Ausgabe enthält:

• Comment - Zweck des Paketes
• Description - Beschreibung
• Maintainer - Verantwortlicher Port-Maintainer
• WWW - Upstream-Projekt-URL

Package-Größe

Speicherplatz-Verbrauch eines installierten Packages:

$ pkg_info -s nginx
Information for inst:nginx-1.30.2
Size: 1395276

Die Größe wird in Bytes angegeben (hier ca. 1.4 MB).

Update-Signatur

Update-Signatur eines installierten Packages anzeigen:

$ pkg_info -S nginx
Information for inst:nginx-1.30.2
Signature: nginx-1.30.2,15,@pcre2-10.44,c.103.0,crypto.57.2,pcre2-8.0.7,ssl.60.2,z.7.2

pkg_info -S zeigt keine kryptografische Signatur, sondern die Update-Signatur: eine Kennung aus Package-Version, Runtime-Abhängigkeiten und benötigten Shared-Library-Versionen. Die Package-Tools nutzen sie bei der Update-Auswahl.

Abhängigkeiten auflisten

Dependencies eines installierten Packages:

$ pkg_info -f postgresql-server | grep @depend
@depend databases/postgresql,-main:postgresql-client-=18.4:postgresql-client-18.4
@depend textproc/icu4c,-main:icu4c-*:icu4c-78.3v0
@depend textproc/libxml:libxml-*:libxml-2.15.3

Das Package benötigt postgresql-client in exakter Version (=18.4), icu4c und libxml in beliebiger aktueller Version (-*).

Welche Packages benötigen ein bestimmtes Package:

$ pkg_info -R mariadb-client
Information for inst:mariadb-client-11.4.10p0v1

Required by:
mariadb-server-11.4.10p0v1
p5-DBD-MariaDB-1.23

Die Ausgabe listet alle Packages die mariadb-client als Dependency haben. Hilfreich vor Deinstallation – zeigt betroffene Packages.

Dateien eines Packages

Liste aller Dateien eines Packages:

$ pkg_info -L nginx
Information for inst:nginx-1.30.2

Files:
/etc/rc.d/nginx
/usr/local/sbin/nginx
/usr/local/man/man8/nginx.8
/usr/local/share/nginx/nginx.conf
/usr/local/share/nginx/html/index.html
/usr/local/share/doc/pkg-readmes/nginx
[... weitere Dateien ...]

Zeigt alle installierten Dateien, Konfigurationen und Dokumentation. Nützlich um zu prüfen wo ein Package Dateien ablegt.

Datei zu Package zuordnen

Herausfinden welches Package eine Datei installiert hat:

$ pkg_info -E /usr/local/bin/vim
/usr/local/bin/vim: vim-9.2.357
vim-9.2.357         vi clone with many additional features

Die Option -E sucht nach exaktem Pfad. Funktioniert nur für bereits installierte Dateien. Die Ausgabe zeigt Package-Namen und Beschreibung. Nützlich bei unbekannten Binaries oder Konfigurationsdateien.

pkg_delete - Software entfernen

Das Tool pkg_delete entfernt installierte Packages inklusive aller Dateien. Konfigurationsdateien bleiben optional erhalten.

Einzelnes Paket entfernen

Package deinstallieren:

$ doas pkg_delete nginx
nginx-1.30.2: ok
Read shared items: ok

pkg_delete entfernt Dateien anhand des registrierten Package-Zustands. Über gespeicherte Prüfsummen erkennt es lokal veränderte Dateien und lässt sie im Normalfall bestehen. Wichtige Konfigurationen sollten trotzdem unabhängig gesichert sein. Read shared items gehört zur Prüfung gemeinsam genutzter Package-Bestandteile.

Abhängigkeits-Prüfung

Package mit Dependencies deinstallieren:

$ doas pkg_delete mariadb-client
can't delete mariadb-client-11.4.10p0v1 without deleting mariadb-server-11.4.10p0v1 p5-DBD-MariaDB-1.23
Delete them as well ? [y/N/a] a
p5-DBD-MariaDB-1.23:mariadb-server-11.4.10p0v1: ok
p5-DBD-MariaDB-1.23: ok
mariadb-client-11.4.10p0v1: ok
Read shared items: ok
--- -mariadb-server-11.4.10p0v1 -------------------
You should also run /usr/sbin/userdel _mysql
You should also run /usr/sbin/groupdel _mysql

Die Meldung zeigt abhängige Packages und fragt ob diese ebenfalls entfernt werden sollen:

• y - Ja, diese Packages löschen (bei weiteren Konflikten wird erneut gefragt)
• N - Nein, Abbruch ohne Änderungen (Standard)
• a - All, diese und alle weiteren Konflikte automatisch mit “yes” beantworten

Im normalen Löschvorgang bleiben angelegte System-Benutzer oder -Gruppen erhalten; die Ausgabe nennt die nötigen Cleanup-Schritte. Mit pkg_delete -c lassen sich zusätzlich registrierte Konfigurationen, Benutzer und Gruppen entfernen.

Verwaiste Dependencies aufräumen

Nach Deinstallationen bleiben automatisch installierte Dependencies zurück. Diese löschen:

$ doas pkg_delete -a
p5-Clone-0.47:p5-DBI-1.648: ok
p5-Clone-0.47:p5-SQL-Statement-1.414: ok
p5-Clone-0.47: ok
lua-5.1.5p8:luajit-2.1.1772619647: ok
lua-5.1.5p8: ok
lzo2-2.10p2: ok
coreutils-9.10: ok
p5-Net-Daemon-0.49:p5-PlRPC-0.2020p0: ok
p5-Net-Daemon-0.49: ok
p5-Params-Util-1.102: ok
libxml-2.15.3: ok
findutils-4.10.0p0: ok
snappy-1.1.10p2: ok
p5-MLDBM-2.05p0: ok
p5-FreezeThaw-0.5001p0: ok
p5-Math-Base-Convert-0.11p0: ok
zstd-1.5.7p0: ok
lz4-1.10.0: ok
p5-Module-Runtime-0.018: ok
Running tags: ok
Read shared items: ok
--- -libxml-2.15.3 -------------------
You should also remove /var/db/xmlcatalog

pkg_delete -a entfernt automatisch installierte Packages, die nicht mehr benötigt werden; manuell installierte Packages bleiben erhalten. Ein direkt mit pkg_add htop installiertes Package gilt als manuell, pkg_add -a htop markiert es dagegen nicht als manuell installiert.

Manche Packages hinterlassen Datenbanken oder Katalogdateien, die separat entfernt werden müssen.

Updates und System-Wartung

OpenBSD unterscheidet zwischen Base-System-Updates und Package-Updates. Beide erfolgen getrennt über verschiedene Tools.

Package-Updates

Alle installierten Packages aktualisieren:

$ doas pkg_add -u
quirks-7.194 signed on 2026-06-10T19:46:25Z

Der Befehl prüft quirks, dann alle installierten Packages. Wenn keine Updates verfügbar sind, endet er ohne weitere Ausgabe.

Bei verfügbaren Updates erfolgt automatische Installation:

$ doas pkg_add -u
quirks-7.147 signed on 2025-12-14T12:31:29Z
nginx-1.26.3->1.28.0p1: ok
vim-9.1.1650->9.1.1706-no_x11: ok

(Beispiel aus OpenBSD 7.8 — Versionsnummern und Package-Namen variieren je nach Release)

Einzelnes Package aktualisieren:

$ doas pkg_add -u vim

Das angegebene Package und erforderliche Dependencies werden auf passende Updates geprüft. Dabei ersetzt pkg_add das installierte Package kontrolliert durch einen passenden Nachfolger und berücksichtigt den Abhängigkeitsgraphen.

Base-System-Updates

Verfügbare Patches auflisten ohne zu installieren:

$ doas syspatch -c
002_smtpd
003_vmd

syspatch -c eignet sich auch für cron — gibt nur Ausgabe wenn Patches ausstehen.

Patches installieren:

$ doas syspatch

Get/Verify syspatch79-002_smtpd.tgz 100% |***...***|   313 KB    00:00
Installing patch 002_smtpd
Get/Verify syspatch79-003_vmd.tgz 100% |***...***|   114 KB    00:00
Installing patch 003_vmd
Errata can be reviewed under /var/syspatch

Die Patches werden heruntergeladen, geprüft und installiert. Bei Kernel-Patches erscheint reboot to load the new kernel; der neue Kernel wird erst nach einem Neustart verwendet. Userland-Dateien werden ohne Systemneustart ersetzt, laufende Prozesse können abhängig vom Patch aber einen Neustart des betroffenen Dienstes erfordern.

Installierte Patches anzeigen:

$ doas syspatch -l
002_smtpd
003_vmd

System-Upgrade zwischen Major-Releases

OpenBSD bietet mehrere Methoden für Major-Release-Upgrades (7.8 → 7.9). Die Wahl hängt von den Anforderungen an Kontrolle und Automatisierung ab.

Automatisches Upgrade mit sysupgrade

Die einfachste Methode für System-Upgrades:

$ doas sysupgrade

sysupgrade lädt und verifiziert die Dateien der neuen Release und bereitet den automatisierten Upgrade-Lauf vor. Nach dem Neustart führt der Installer das Upgrade aus und startet das neue System.

Nach dem Neustart weiter mit Nach dem Upgrade.

Interaktives Upgrade über bsd.rd

Das interaktive Upgrade erlaubt eine eigene Set-Auswahl und eignet sich damit, wenn eine bewusst reduzierte Installation beibehalten werden soll.

Vorbereitung

1. Installer-Kernel und Signatur-Datei downloaden:

Die Dateien liegen auf den OpenBSD-Mirrors. Für amd64-Systeme:

$ cd /tmp
$ ftp https://cdn.openbsd.org/pub/OpenBSD/7.9/amd64/bsd.rd
$ ftp https://cdn.openbsd.org/pub/OpenBSD/7.9/amd64/SHA256.sig

Für andere Architekturen die passende Plattform wählen (arm64, i386, etc.). Die vollständige Liste der verfügbaren Architekturen findet sich auf:

https://cdn.openbsd.org/pub/OpenBSD/7.9/ ↗

2. bsd.rd verifizieren:

Der Signatur-Key für 7.9 liegt bereits im laufenden System:

$ cd /tmp
$ signify -C -p /etc/signify/openbsd-79-base.pub -x SHA256.sig bsd.rd
Signature Verified
bsd.rd: OK

Nur bei erfolgreicher Verifikation weitermachen. Fehlgeschlagene Verifikation deutet auf manipulierte oder korrupte Dateien hin.

3. Installer-Kernel ins Root-Dateisystem kopieren:

$ doas cp /tmp/bsd.rd /bsd.rd

Upgrade durchführen

System neu starten und beim Boot-Prompt den Installer-Kernel laden:

boot> boot /bsd.rd

Der OpenBSD-Installer startet und fragt nach der gewünschten Aktion. (U)pgrade wählen für System-Upgrade.

Set-Auswahl

Der Installer führt durch bekannte Schritte — Tastaturlayout, Root-Disk, Mirror-Auswahl. Der Ablauf entspricht dem Installations-Dialog, siehe Installation und erste Schritte. Der relevante Schritt ist die Set-Auswahl:

Select sets by entering a set name, a file name pattern or 'all'.
De-select sets by prepending a '-', e.g.: '-game*'. Selected sets are
labelled '[X]'.

[X] bsd          [X] base79.tgz   [X] game79.tgz   [X] xfont79.tgz
[X] bsd.mp       [X] comp79.tgz   [X] xbase79.tgz  [X] xserv79.tgz
[X] bsd.rd       [X] man79.tgz    [X] xshare79.tgz
Set name(s)? (or 'abort' or 'done') [done]

[X] markiert Sets die installiert werden, [ ] übersprungene Sets.

Für minimale Server-Installationen X11 und Games abwählen:

Set name(s)? -g* -x*

Die Sets wechseln von [X] zu [ ]. Mit done bestätigen und das Upgrade startet.

Der Installer lädt nur die ausgewählten Sets, verifiziert sie und installiert sie. Damit bleibt der installierte Softwareumfang auf die bewusst ausgewählten Sets beschränkt.

Nach dem Upgrade

Beim ersten Start verarbeitet OpenBSD Änderungen an der Basissystem-Konfiguration mit sysmerge. Bleiben Konflikte offen, kann anschließend ein manueller Lauf erforderlich sein:

$ doas sysmerge

Nach einem Release-Upgrade müssen außerdem die releasespezifischen Upgrade-Hinweise der neuen OpenBSD-Version abgearbeitet werden. Dazu können geänderte Konfigurationen, zu entfernende alte Dateien oder besondere Package-Migrationen gehören.

Anschließend werden die installierten Packages auf den zum neuen System passenden Stand gebracht:

$ doas pkg_add -u
quirks-7.147->7.194: ok
curl-8.16.0->8.20.0: ok
curl-8.20.0:ngtcp2-1.16.0->1.22.1: ok
python-3.12.11->3.13.13 forward dependencies:
| Dependency of py3-packaging-25.0 on python->=3.12,<3.13 doesn't match
| Dependency of glib2-2.84.4 on python->=3.12,<3.13 doesn't match
Merging py3-packaging-25.0->26.0 (ok)
Merging glib2-2.84.4->2.86.5 (ok)
[... weitere Updates ...]
vim-9.1.1706-no_x11->9.2.357: ok
Running tags: ok

Binary-Patches für das laufende Release werden unabhängig davon mit syspatch verwaltet, wie im Abschnitt Binary-Patches mit syspatch beschrieben.

Nicht mehr benötigte Packages aufräumen:

Bei Updates können alte Shared Libraries in .libs-*-Stub-Packages erhalten bleiben, solange andere Packages sie noch benötigen. Das sind keine liegengebliebenen Dateien, sondern gezielt erhaltene Kompatibilitäts-Packages.

$ doas pkg_delete -a
.libs-libsodium-1.0.20: ok
.libs-python-3.12.11: ok

pkg_delete -a entfernt solche Kompatibilitäts-Packages erst, wenn sie nicht mehr benötigt werden.

Manuelles Upgrade

OpenBSD dokumentiert zusätzlich ein vollständig manuelles Upgrade-Verfahren. Es bietet weitgehende Kontrolle, ist aber fehleranfälliger und gehört deshalb nicht in den normalen Ablauf dieses Grundlagenartikels.

Die vollständige Anleitung findet sich im separaten Artikel Manual System-Upgrade (geplant).

Verwendete Informationen

Diese Anleitung bezieht sich auf:

• OpenBSD: 7.8, 7.9
• Architektur: amd64 (primär), allgemeine Konzepte gelten für alle Plattformen
• Kontext: Server- und Desktop-Installation
• Stand: August 2026

Der nächste Artikel behandelt die Sicherheitsarchitektur – pledge, unveil und weitere Security-Mechanismen des Systems.