Ubuntu Manpage: mkosi – Maßgeschneiderte Betriebssystemabbilder bauen

BEZEICHNUNG

       mkosi – Maßgeschneiderte Betriebssystemabbilder bauen

ÜBERSICHT

       mkosi [Optionen…] summary

       mkosi [Optionen…] cat-config

       mkosi [Optionen…] build [Befehlszeile…]

       mkosi [Optionen…] shell [Befehlszeile…]

       mkosi [Optionen…] boot [Nspawn-Einstellungen…]

       mkosi [Optionen…] vm [Vmm-Parameter…]

       mkosi [Optionen…] ssh [Befehlszeile…]

       mkosi [Optionen…] journalctl [Befehlszeile…]

       mkosi [Optionen…] coredumpctl [Befehlszeile…]

       mkosi [Optionen…] sysupdate [Befehlszeile…]

       mkosi [Optionen…] sandbox [Befehlszeile…]

       mkosi [Optionen…] clean

       mkosi [Optionen…] serve

       mkosi [Optionen…] burn <Gerät>

       mkosi [Optionen…] bump

       mkosi [Optionen…] genkey

       mkosi [Optionen…] documentation [Handbuch]

       mkosi [Optionen…] completion [Shell]

       mkosi [Optionen…] dependencies

       mkosi [Optionen…] help

BESCHREIBUNG

mkosi ist ein Werkzeug zum leichten Bau angepasster Betriebssystemabbilder. Es ist eine kunstvolle Hülle
für dnf, apt(8), pacman(8) und zypper(8), die Plattenabbilder mit einer Reihe von Schnickschnack
erstellen können.

Unterbefehle
Die folgenden Unterbefehle werden erkannt:

summary
Zeigt eine menschenlesbare Zusammenfassung aller für den Bau des Abbilds verwandten Optionen an.
Dies wird die Befehlszeile und die Konfigurationsdateien auswerten, aber nur ausgeben, wofür es
konfiguriert ist und nicht wirklich etwas bauen oder ausführen.

cat-config
Gibt die Namen und Inhalte aller geladenen Konfigurationsdateien aus. mkosi lädt einen Schwung
Dateien aus verschiedenen Orten und dieser Befehl erleichtert es herauszufinden, was wo
konfiguriert ist.

build Baut das Abbild basierend auf den auf der Befehlszeile und in den Konfigurationsdateien
übergebenen Einstellungen. Dieser Befehl ist die Vorgabe, falls kein Unterbefehl explizit
angegeben ist. Alle nach dem Unterbefehl angegeben Befehlszeilenargumente werden direkt an das
Bauskript übergeben, falls eines definiert ist.

shell Dies baut das Abbild, falls es noch nicht gebaut ist, und ruft dann systemd-nspawn(1) auf, um eine
interaktive Shell im Abbild auszuführen. Dafür muss das System nicht gestartet werden, es ist eher
wie eine bessere chroot(8). Nach dem Unterbefehl shell kann eine optionale Befehlszeile angegeben
werden, die anstelle der Shell in dem Container aufgerufen werden soll. Verwenden Sie -f, um das
Abbild bedingungslos vor dem Erlangen der Shell neuzubauen, siehe unten. Dieser Befehl muss als
root ausgeführt werden.

boot Ähnlich wie shell, startet systemd(1) im Abbild mittels systemd-nspawn(1) anstatt eine Shell zu
öffnen. Nach dem Unterbefehl boot kann eine optionale Befehlszeile angegeben werden, die
zusätzliche Nspawn-Optionen sowie Argumente enthalten kann, die an die Kernelbefehlszeile des
Init-Systems im Abbild übergeben werden.

vm Ähnlich wie boot, verwendet aber den konfigurierten Monitor für virtuelle Maschinen (standardmäßig
qemu), um das Abbild zu starten, d.h. anstelle einer Container-Virtualisierung wird eine
Virtualisierung einer virtuellen Maschine verwandt. Wie zusätzliche Befehlszeilenargumente
interpretiert werden hängt von dem konfigurierten Monitor für virtuelle Maschinen ab. Siehe
VirtualMachineMonitor= für weitere Informationen.

ssh Wenn das Abbild mit der Option Ssh=yes gebaut wird, verbindet dieser Befehl die gestartete
virtuelle Maschine mittels SSH. Stellen Sie sicher, dass mkosi ssh mit der gleichen Konfiguration
wie mkosi build ausgeführt wird, so dass es die notwendigen Informationen hat, um sich mit der
laufenden virtuellen Maschine mittels SSH zu verbinden. Insbesondere wird der private
SSH-Schlüssel aus der Einstellung SshKey= verwandt, um sich mit der virtuellen Maschine zu
verbinden. Verwenden Sie mkosi genkey, um automatisch einen Schlüssel und ein Zertifikat zu
erstellen, das von mkosi aufgenommen wird. Alle nach dem Unterbefehl ssh übergebene Argumente
werden als Argumente an den Aufruf von ssh(1) übergeben. Um sich mit einem Container zu verbinden,
verwenden Sie machinectl login oder machinectl shell.

Die Option Machine= kann dazu verwandt werden, der Maschine beim Systemstart einen angepassten
Rechnernamen zu geben, der später für einen ssh(1)-Zugang verwandt werden kann (z.B. mkosi
--machine=meinemaschine vm gefolgt von mkosi --machine=meinemaschine ssh).

journalctl
Verwendet journalctl(1), um das Journal innerhalb des Abbildes zu untersuchen. Alle nach dem
Unterbefehl journalctl angegebenen Argumente werden an den Aufruf von journalctl(1) angehängt.

coredumpctl
Verwendet coredumpctl(1), um nach Speicherabbilder innerhalb des Abbilds zu suchen. Alle nach dem
Unterbefehl coredumpctl angegebenen Argumente werden an den Aufruf von coredumpctl(1) angehängt.

sysupdate
Ruft systemd-sysupdate(8) auf, wobei die Option --transfer-source= auf das Ausgabeverzeichnis und
die Option --definitions= auf das mit SysupdateDirectory= konfigurierte Verzeichnis gesetzt ist.
Alle nach dem Unterbefehl sysupdate festgelegten Argumente werden direkt an den Aufruf von
systemd-sysupdate(8) weitergegeben.

sandbox
Ruft beliebige Befehle innerhalb der gleichen Sandbox auf, die zur Ausführung anderer Unterbefehle
wie boot, shell, vm und weiteren verwandt wird. Dies bedeutet, dass /usr durch /usr vom
Werkzeugbaum ersetzt wird, falls einer verwandt wird, während ansonsten alles andere am Ort
verbleibt. Falls kein Befehl bereitgestellt wird, wird $SHELL oder bash(1), falls $SHELL nicht
gesetzt ist, ausgeführt.

clean Entfernt aus vorherigen Bauläufen erstellte Bauartefakte. Falls mit -f kombiniert, werden auch
inkrementelle Bauzwischenspeicher-Abbilder entfernt. Falls -f zweimal angegeben ist, werden
sämtliche Paketzwischenspeicher entfernt.

serve Dies baut das Abbild, falls es noch nicht gebaut wurde und liefert dann das Ausgabeverzeichnis
(d.h. normalerweise mkosi.output/, s.u.) über einen kleinen eingebauten HTTP-Server, der auf Port
8081 auf Anfragen wartet, aus. Kombinieren Sie dies mit -f, um das Abbild bedingungslos
neuzubauen, bevor es ausgeliefert wird. Dieser Befehl ist für das Testen netzwerkbasierten
Erwerbens von Betriebssystemabbildern nützlich, beispielsweise mittels machinectl pull-raw … und
machinectl pull-tar ….

burn <device>
Dies baut das Abbild, falls es noch nicht gebaut wurde und schreibt es dann auf das angegebene
Blockgerät. Die Partitionsinhalte werden unverändert geschrieben, aber die GPT-Partitionstabelle
wird korrigiert, so dass sie auf die Sektor- und Blockgrößen des angegebenen Mediums passt.

bump Erhöht die Version des Abbildes aus mkosi.version und schreibt die resultierende
Versionszeichenkette nach mkosi.version. Dies ist zur Implementierung eines einfachen
Versionierungsschematas nützlich: jedes Mal, wenn dieser Unterbefehl aufgerufen wird, wird die
Version als Vorbereitung für den nächsten Bau erhöht. Beachten Sie, dass --auto-bump/-B zum
automatischen Erhöhen der Version nach jedem erfolgreichen Bau verwandt werden kann.

genkey Erstellt ein Paar von SecureBoot-Schlüsseln zur Verwendung mit den Optionen
SecureBootKey=/--secure-boot-key= und SecureBootCertificate=/--secure-boot-certificate=.

documentation
Zeigt die Dokumentation von mkosi. Falls kein Argument angegeben ist, wird die Handbuchseite
mkosi(1) angezeigt, aber die Argumente mkosi, mkosi-initrd, initrd, mkosi-sandbox, sandbox,
mkosi.news und news werden unterstützt und zeigen die Handbuchseiten für mkosi(1),
mkosi-initrd(1), mkosi-sandbox(1) bzw. die NEWS-Datei von mkosi an.

Standardmäßig wird dieser Unterbefehl verschiedene Arten zur Ausgabe der Dokumentation
ausprobieren, eine bestimmte Option kann mit der Option --doc-format ausgewählt werden. Paketierer
von Distributionen wird empfohlen, eine Datei mkosi.1 in das Verzeichnis mkosi/resources des
Python-Pakets abzulegen, falls sie dort fehlt, sowie sie im geeigneten Suchpfad für Handbuchseiten
zu installieren. Die Handbuchseite kann aus der Markdown-Datei mkosi/resources/man/mkosi.1.md zum
Beispiel mittels pandoc -t man -s -o mkosi.1 mkosi.1.md erstellt werden.

completion
Erstellt Shell-Vervollständigungen für die als Argument übergebene Shell und gibt diese auf der
Standardausgabe aus. Es werden die Argumente bash, fish und zsh verstanden.

dependencies
Gibt die Liste der von mkosi zum Bauen und Starten von Abbildern benötigten Pakete aus.

Diese Liste kann direkt an einen Paketverwalter weitergeleitet werden, um die Pakete zu
installieren. Falls beispielsweise das Wirtsystem den dnf-Paketverwalter verwendet, könnten die
Pakete wie folgt installiert werden:

mkosi dependencies | xargs -d '\n' dnf install

help Dieser Unterbefehl ist identisch zum nachfolgend dokumentierten Schalter --help: Er zeigt eine
kurze Erklärung zur Verwendung.

Reine Befehlszeilenoptionen
Diese Einstellungen können nicht mittels der Konfigurationsdateien konfiguriert werden.

--force, -f
Ersetzt beim Bau eines Abbildes die Ausgabedatei, falls sie bereits existiert. Standardmäßig
verweigert mkosi eine Aktion, wenn ein Abbild gebaut wird und ein Ausgabeartefakt bereits
existiert. Geben Sie diese Option einmal an, um alle Bauartefakte aus einem vorherigen Lauf vor
dem Neubau des Abbildes zu entfernen. Falls inkrementelle Bauten aktiviert sind, wird zweimalige
Angabe sicherstellen, dass inkrementelle Zwischenspeicherdateien auch entfernt werden, bevor der
Neubau eingeleitet wird. Falls ein Paketzwischenspeicher verwandt wird (siehe auch den
nachfolgenden Abschnitt Dateien) wird die dreimalige Angabe sicherstellen, dass auch der
Paketzwischenspeicher entfernt wird, bevor der Neubau eingeleitet wird. Für die Aktion clean hat
diese Option eine leicht andere Auswirkung: Standardmäßig wird der Unterbefehl nur Bauartefakte
aus dem vorherigen Lauf entfernen, durch einmalige Angabe werden auch die inkrementellen
Zwischenspeicherdateien gelöscht, bei doppelter Angabe wird auch der Paketzwischenspeicher
entfernt.

--directory=, -C
Akzeptiert einen Pfad zu einem Verzeichnis. Vor allen anderen Aktivitäten wechselt mkosi in dieses
Verzeichnis. Beachten Sie, dass in diesem Verzeichnis nach den verschiedenen Konfigurationsdateien
gesucht wird, daher ist die Verwendung dieser Option ein wirksammes Mittel, ein Projekt zu bauen,
das sich in einem bestimmten Verzeichnis befindet.

--debug
Aktiviert zusätzliche Fehlersuchausgaben.

--debug-shell
Falls die Ausführung eines Befehls in dem Abbild fehlschlägt, wird mkosi eine interaktive Shell in
dem Abbild starten, um ein weitere Fehlersuche zu ermöglichen.

--debug-workspace
Löscht, wenn angegeben, das Arbeitsbereichsverzeichnis nicht und seine Lage wird protokolliert,
wenn sich mkosi beendet.

--debug-sandbox
Führt mkosi-sandbox(1) mit strace(1) aus.

--version
Zeigt die Paketversion.

--help, -h
Zeigt einen kurzen Hinweis zum Aufruf.

--genkey-common-name=
Allgemeiner Name, der bei der Erzeugung von Schlüsseln mittels des Befehls genkey von mkosi
verwandt wird. Standardmäßig mkosi of %u, wobei %u auf den Benutzernamen des Benutzer, der mkosi
aufruft, erweitert wird.

--genkey-valid-days=
Anzahl an Tagen, die Schlüssel gültig bleiben sollen, wenn Schlüssel mit dem Befehl genkey von
mkosi erstellt werden. Standardmäßig zwei Jahre (730 Tage).

--auto-bump=, -B
Falls angegeben wird nach jedem erfolgreichen Bau in Vorbereitung des nächsten Baus die Version
auf eine ähnliche Art wie beim Unterbefehl bump erhöht. Dies ist für einfaches, lineares
Versionsmanagement nützlich: jeder Bau in einer Reihe wird eine um eins gegenüber dem vorherigen
Bau erhöhte Versionsnummer haben.

--doc-format
Das Format, in dem die Dokumentation angezeigt werden soll. Unterstützt die Werte markdown, man,
pandoc, system und auto. Im Falle von markdown wird die Dokumentation im usrpünglichen
Markdown-Format angezeigt. man zeigt die Dokumentation im Handbuchseitenformat, falls dies
verfügbar ist. pandoc erstellt das Handbuchseitenformat dynamisch, falls pandoc(1) verfügbar ist.
system zeigt die systemweite Handbuchseite für mkosi, die nicht zwingend der Version entspricht,
die Sie verwenden, abhängig davon, wie mkosi installiert wurde. auto (die Vorgabe) wird alle
Methoden in der Reihenfolge man, pandoc, markdown, system ausprobieren.

--json Zeigt die zusammenfassende Ausgabe als JSON-SEQ.

--wipe-build-dir, -w
Vernichtet vor dem Bau des Abbildes das Bauverzeichnis, falls eines konfiguriert ist.

Unterstützte Ausgabeformate
Die folgenden Ausgabeformate werden unterstützt:

• Rohes GPT-Plattenabbild, mittels systemd-repart(8) erstellt (Platte)

• Einfaches Verzeichnis, enthält den Betriebssystembaum (Verzeichnis)

• TAR-Archiv (tar)

• CPIO-Archiv (cpio)

Das Ausgabeformat kann auch auf none gesetzt werden, wenn Sie möchten, dass mkosi überhaupt kein Abbild
erstellt. Dies kann nützlich sein, falls Sie das Abbild nur dazu verwenden möchten, eine andere Ausgabe
in den Bauskripten zu erstellen (z.B. ein RPM zu bauen).

Wenn ein GPT-Plattenabbild erstellt wird, können Repart-Partitionsdefinitionsdateien in mkosi.repart/
abgelegt werden, um das erstellte Plattenabbild zu konfigurieren.

Es wird nachdrücklich empfohlen, mkosi auf einem Dateisystem auszuführen, das Reflinks unterstützt, wie
xfs(5) und btrfs(5) und alle zusammengehörigen Verzeichnisse auf dem gleichen Dateisystem zu behalten.
Dies ermöglicht es mkosi, Abbilder sehr schnell durch Verwendung von Reflinks zur Durchführung von
Kopieren-Beim-Schreiben-Aktionen zu erstellen.

Konfigurationseinstellungen
Die folgenden Einstellungen können über Konfigurationsdateien (der Syntax mit EineEinstellung=Wert) und
auf der Befehlszeile (der Syntax mit --Eine-Einstellung=Wert) gesetzt werden. Für einige
Befehlszeilenparameter ist auch eine Abkürzung mit einem Buchstaben erlaubt. In den Konfigurationsdateien
muss die Einstellung in dem korrekten Abschnitt erfolgen, daher sind die Einstellungen nachfolgend gemäß
des Abschnittes gruppiert.

Die Konfiguration wird in der folgenden Reihenfolge ausgewertet:

• Die Befehlszeilenargumente werden ausgewertet.

• mkosi.local.conf oder mkosi.local wird ausgewertet, falls es existiert. Diese Datei oder das
Verzeichnis sollte in .gitignore (oder äquivalent) sein und ist für lokale Konfiguration gedacht.

• Alle Vorgabepfade (abhängig von der Option) werden konfiguriert, falls der entsprechende Pfad
existiert.

• mkosi.conf wird ausgewertet, falls es in dem mit --directory= konfigurierten Verzeichnis liegt oder im
aktuellen Verzeichnis, falls --directory= nicht verwandt wird.

• mkosi.conf.d/ wird im gleichen Verzeichnis ausgewertet, falls sie existiert. Jedes Verzeichnis und jede
Datei mit der Endung .conf in mkosi.conf.d/ wird ausgewertet. Jedes Verzeichnis in mkosi.conf.d wird
ausgewertet, als ob es ein normales Verzeichnis auf der obersten Ebene wäre.

• Falls irgendwelche Profile definiert sind, werden deren Konfiguration aus dem Verzeichnis
mkosi.profiles/ ausgewertet.

• Unterabbilder werden aus dem Verzeichnis mkosi.images ausgewertet, falls es existiert.

Beachten Sie, dass die über die Befehlszeile konfigurierten Einstellungen immer die über
Konfigurationsdateien konfigurierte Einstellungen außer Kraft setzen. Falls die gleiche Einstellung mehr
als einmal mittels Konfigurationsdateien konfiguriert ist, setzen spätere Zuweisungen frühere außer
Kraft, sofern die Einstellungen nicht eine Sammlung an Werten akzeptierten. Auch werden Einstellungen,
die aus mkosi.local oder mkosi.local.conf gelesen werden Einstellungen von anderen Konfigurationsdateien,
die später ausgewertet werden, außer Kraft setzen, allerdings nicht solche, die auf der Befehlszeile
angegeben werden.

Für Einstellungen, die einen einzelnen Wert akzeptieren, kann die leere Zuweisung (EineEinstellung= oder
--eine-einstellung=) zum Außerkraftsetzen einer vorherigen Einstellung und zum Zurücksetzen auf die
Vorgabewerte verwandt werden.

Einstellungen, die eine Sammlung von Werten akzeptieren, werden zusammengeführt, indem neue Werte an die
bereits konfigurierten Werte angehängt werden. Durch Zuweisung einer leeren Zeichenkette zu einer solchen
Einstellung werden alle vorher zugewiesenen Werte entfernt und auch alle konfigurierten Standardwerte
außer Kraft gesetzt. Die auf der Befehlszeile angegebenen Werte werden nach allen Werten aus den
Konfigurationsdateien angehängt.

Um Konfigurationsdateien bedingt einzubinden, kann der Abschnitt [Match] verwandt werden. Ein Abschnitt
[Match] besteht aus einzelnen Bedingungen. Bedingungen können ein Weiterleitungssymbol (|) nach dem
Gleichheitszeichen verwenden (…=|…). Dadurch wird die Bedingung eine auslösende Bedingung. Die
Konfigurationsdatei wird eingebunden, falls das logische UND aller nicht auslösenden Bedingungen und das
logische ODER aller auslösenden Bedingungen erfüllt wird. Um das Ergebnis einer Bedingung zu negieren,
stellen Sie dem Argument ein Ausrufezeichen voran. Falls einem Argument ein Weiterleitungssymbol und ein
Ausrufezeichen vorangestellt wird, muss das Weiterleitungssymbol zuerst angegeben werden und anschließend
das Ausrufezeichen.

Beachten Sie, dass die Bedingungen in [Match] mit den aktuellen Werten einer bestimmten Einstellung
verglichen werden und keine Änderungen an Einstellungen berücksichtigen, die in Konfigurationsdateien
bereits erfolgten, aber noch nicht ausgewertet wurden (auf der Befehlszeile angegebene Einstellungen
werden berücksichtigt). Beachten Sie auch, dass das Prüfen der Übereinstimmung mit einer Einstellung und
das anschließende Ändern in einer anderen Konfigurationsdatei zu unerwarteten Ergebnissen führen kann.

Der Abschnitt [Match] in einer Datei mkosi.conf in einem Verzeichnis gilt für das gesamte Verzeichnis.
Falls die Bedingungen nicht erfüllt sind, wird das gesamte Verzeichnis übersprungen. Die Abschnitte
[Match] von Dateien in mkosi.conf.d/ und mkosi.local.conf gelten nur für die Datei selbst.

Falls es mehrere Abschnitte [Match] in der gleichen Konfigurationsdatei gibt, muss jede erfüllt werden,
damit die Konfigurationsdatei eingebunden wird. Insbesondere gelten auslösende Bedingungen nur für den
aktuellen Abschnitt [Match] und werden zwischen mehreren Abschnitten [Match] zurückgesetzt. In dem
folgenden Beispiel erfolgt nur eine Übereinstimmung, falls das Ausgabeformat entweder disk oder directory
ist und die Architektur entweder x86-64 oder arm64 ist:

[Match]
Format=|disk
Format=|directory

[Match]
Architecture=|x86-64
Architecture=|arm64

Der Abschnitt [TriggerMatch] kann zur Anzeige von auslösenden Übereinstimmungsabschnitten verwandt
werden. Diese sind zu auslösenden Bedingungen identisch, außer dass sie für den gesamten
Übereinstimmungsabschnitt statt nur einer einzelnen Bedingung gelten. Beispielsweise stimmt folgendes
überein, falls die Distribution debian und die Veröffentlichung bookworm ist oder falls die Distribution
ubuntu und die Veröffentlichung noble ist.

[TriggerMatch]
Distribution=debian
Release=bookworm

[TriggerMatch]
Distribution=ubuntu
Release=noble

Die Semantik von Bedingungen in [TriggerMatch]-Abschnitten ist identisch zu [Match], d.h. alle normalen
Bedingungen werden durch ein logisches UND und alle auslösenden Bedingungen werden durch ein logisches
ODER zusammengefasst. Beim Mischen von [Match]- und [TriggerMatch]-Abschnitten wird eine Übereinstimmung
erreicht, wenn alle [Match]-Abschnitte übereinstimmen und mindestens ein [TriggerMatch]-Abschnitt
übereinstimmt. Die Abwesenheit eines Übereinstimmungsabschnittes wird als true ausgewertet. Logisch
bedeutet dies:

(⋀ᵢ Matchᵢ) ∧ (⋁ᵢ TriggerMatchᵢ)

Befehlszeilenoptionen, die kein Argument akzeptieren, werden ohne = in ihrer langen Version angezeigt. In
der Konfigurationsdatei sollten sie mit einem logischen Argument angegeben werden: entweder 1, yes oder
true zum aktivieren oder 0, no, false zum deaktivieren.

Abschnitt [Distribution]
Distribution=, --distribution=, -d
Die im Abbild zu installierende Distribution. Akzeptiert eines der folgenden Argumente: fedora,
debian, kali, ubuntu, arch, opensuse, mageia, centos, rhel, rhel-ubi, openmandriva, rocky, alma,
azure oder custom. Falls nicht angegeben ist die Vorgabe die Distribution des Wirtsystems oder
custom, falls die Distribution des Wirtsystems keine unterstützte Distribution ist..TP Release=,
--release=, -r Die Veröffentlichung der im Abbild zu installierenden Distribution. Die genaue
Syntax des akzeptierten Arguments hängt von der verwandten Distribution ab und ist entweder eine
numerische Zeichenkette (im Falle von Fedora Linux, CentOS, …, z.B. 29) oder ein Versionsname der
Distribution (im Falle von Debian, Kali, Ubuntu, …, z.B. artful). Standardmäßig die neuste Version
der ausgewählten Distribution oder die Version, die auf der Wirtmaschine läuft, falls sie mit
einer konfigurierten Distribution übereinstimmt.

Architecture=, --architecture=
Die Architektur für die das Abbild gebaut wird. Die tatsächlich unterstützten Architekturen hängen
von der verwandten Distribution ab und ob ein startfähiges Abbild erbeten wird. Beim Bau für eine
fremde Architektur müssen Sie auch den Benutzermodus-Emulator für diese Architektur installieren
und registrieren.

Pro gebautem Abbild kann eine der folgenden Architekturen festgelegt werden: alpha, arc, arm,
arm64, ia64, loongarch64, mips64-le, mips-le, parisc, ppc, ppc64, ppc64-le, riscv32, riscv64,
s390, s390x, tilegx, x86, x86-64.

Mirror=, --mirror=, -m
Der Spiegel für das Herunterladen der Distributionspakete. Erwartet eine Spiegel-URL als Argument.
Falls nicht angegeben wird der Standard-Spiegel für die Distribution verwandt.

Die Standard-Spiegel für jede Distribution sind wie folgt (sofern nicht angegeben, wird der
gleiche Spiegel für alle Architekturen verwandt):

X86-64 Aarch64
───────────────────────────────────────────────────────────────────────────────────
Debian http://deb.debian.org/debian
Arch https://geo.mirror.pkgbuild.com http://mirror.archlinuxarm.org
OpenSUSE http://download.opensuse.org
kali http://http.kali.org/kali
Ubuntu http://archive.ubuntu.com http://ports.ubuntu.com
Centos https://mirrors.centos.org
Rocky https://mirrors.rockylinux.org
Alma https://mirrors.almalinux.org
Fedora https://mirrors.fedoraproject.org
RHEL-ubi https://cdn-ubi.redhat.com
Mageia https://www.mageia.org
Openmandriva http://mirrors.openmandriva.org
azure https://packages.microsoft.com/

LocalMirror=, --local-mirror=
Der Spiegel wird als ein lokaler, einfacher und direkter Spiegel anstelle der Verwendung als
Präfix für die volle Reihe von Depots, die normalerweise von Distributionen angeboten werden,
verwandt. Nützlich beim Bau vollständig ohne Netzanbindung mit einem einzelnen Depot. Wird für
deb-, rpm- und pacman-basierte Distributionen unterstützt. Setzt --mirror= außer Kraft, aber nur
für lokale mkosi-Bauten, es wird nicht im letztendlichen Abbild konfiguriert, stattdessen wird
--mirror= (oder das Standard-Depot) innerhalb des letztendlichen Abbilds konfiguriert.

RepositoryKeyCheck=, --repository-key-check=
Steuert die Signatur-/Schlüsselüberprüfung bei der Verwendung von Depots, standardmäßig aktiviert.
Die Deaktivierung ist bei der Kombination mit --local-mirror= und der ausschließlichen Verwendung
eines lokalen Depots aus einem lokalen Dateisystem nützlich.

RepositoryKeyFetch=, --repository-key-fetch=
Steuert, ob mkosi die Distributions-GPG-Schlüssel aus der Ferne abholt. Auf Ubuntu standardmäßig
aktiviert, wenn kein Werkzeugbaum verwandt wird oder wenn der Ubuntu-Werkzeugbaum zum Bau von
Arch-Linux- oder RPM-basierte-Distributionen verwandt wird. Auf allen anderen Distributionen
standardmäßig deaktiviert. Wenn deaktiviert, müssen die Distributions-GPG-Schlüssel für die
Zieldistribution lokal auf dem Rechner zusammen mit dem Paketverwalter für diese Distribution
installiert sein.

Diese Einstellung ist nur für Distributionen implementiert, die dnf, pacman(8) oder zypper(8) als
ihren Paketverwalter verwenden. Für andere Distributionen wird der Distributions-GPG-Schlüssel
immer lokal nachgeschlagen, unabhängig vom Wert dieser Einstellung. Um die
Distributions-GPG-Schlüssel für Distributionen zur Verfügung zu stellen, ohne diese Einstellung zu
aktivieren, muss das entsprechende Paket auf dem Wirt installiert sein. Dabei handelt es sich
typischwerweise um entweder archlinux-keyring, debian-keyring, kali-archive-keyring,
ubuntu-keyring oder distribution-gpg-keys (für RPM-basierte Distributionen).

Repositories=, --repositories=
Aktiviert standardmäßig deaktivierte Paket-Depots. Dies kann zur Aktivierung der EPEL-Depots für
CentOS oder anderer Komponenten der Debian/Kali/Ubuntu-Depots verwandt werden.

Abschnitt [Output]
Format=, --format=, -t
Das zu erstellende Abbild-Format. Entweder directory (zur direkten Erstellung eines
Betriebssystemabbildes im lokalen Verzeichnis), tar (ähnlich, es wird aber ein Tarball des
Betriebssystemabbildes erstellt), cpio (ähnlich, es wird aber ein Cpio-Archiv erstellt), disk (ein
Blockgerät-Betriebssystemabbild mit einer GPT-Partitionstabelle), uki (ein vereinigtes
Kernel-Abbild mit einem Betriebssystemabbild im PE-Abschnitt .initrd), esp (uki aber in einem
Platten-Abbild mit nur einer ESP-Partition eingehüllt), oci (ein mit der OCI-Abbildspezifikation
kompatibles Verzeichnis),sysext, confext, portable, addon oder none (das Betriebssystem-Abbild ist
nur als Bau-Artefakt zur Erstellung eines weiteren Artefaktes gedacht).

Falls das Ausgabeformat disk verwandt wird, wird das Plattenabbild mittels systemd-repart(8)
erstellt. Die zu verwendenden Repart-Partitions-Definitionsdateien können mittels der Einstellung
RepartDirectories= oder mittels mkosi.repart/ konfiguriert werden. Wenn Verity-Partitionen mittels
der Einstellung Verity= von systemd-repart(8) konfiguriert werden, wird mkosi automatisch den
Root-Hash der Verity-Hash-Partition aus der JSON-Ausgabe von systemd-repart(8) auswerten und ihn
in die Kernel-Befehlszeile jedes durch mkosi gebauten vereinigten Kernel-Abbildes aufnehmen.

Falls das Format none verwandt wird, werden die Ausgaben von vorherigen Bauten nicht entfernt,
aber Bereinigungsskripte (siehe CleanScripts=) werden weiterhin ausgeführt. Dies ermöglicht das
erneute Ausführen von Bauskripten (siehe BuildScripts=), ohne die Ergebnisse eines vorherigen Baus
zu entfernen.

ManifestFormat=, --manifest-format=
Den oder die zu erstellende Manifestformattyp oder -typen. Eine Kommata-getrennte Liste, die aus
json (das Standard-JSON-Ausgabeformat, das die zu installierenden Pakete beschreibt), changelog
(ein menschenlesbares Textformat, das zum Ermitteln von Unterschieden entwickelt wurde) besteht.
Standardmäßig wird kein Manifest erstellt.

Output=, --output=, -o
Für die erstellte Ausgabedatei oder das Ausgabeverzeichnis zu verwendender Name. Standardmäßig
image oder, falls ImageId= verwandt wird, wird dieser als standardmäßiger Ausgabename verwandt,
optional wird die mit ImageVersion= angegebene Version angehängt oder der Name des Abbildes wird
gegenüber ImageId bevorzugt, falls ein bestimmtes Abbild aus mkosi.images gebaut wird. Beachten
Sie, dass diese Option nicht die Konfiguration des Ausgabeverzeichnisses ermöglicht, verwenden Sie
dafür OutputDirectory=.

Beachten Sie, dass dies nur den Ausgabepräfix festlegt, der vollständige Ausgabename kann abhängig
von dem festgelegten Ausgabeformat, der verwandten Komprimierung und Abbildversion
image_7.8.raw.xz sein.

CompressOutput=, --compress-output=
Konfiguriert die Komprimierung für das resultierende Abbild oder Archiv. Das Argument kann
entweder ein logischer Wert oder ein Komprimierungsalgorithmus (xz(1), zstd(1)) sein.
Standardmäßig wird die Komprimierung zstd(1) sein, außer bei CentOS und abgeleiteten
Distributionen bis Version 8, wo die Vorgabe xz(1) ist und bei OCI-Abbildern, wo die Vorgabe
gzip(1) ist. Beachten Sie, dass das Abbild nicht direkt gestartet werden kann, wenn Komprimierung
auf Plattenabbildtypen angewendet wird, sondern erst eine Dekomprimierung erfolgen muss. Das
bedeutet auch, dass die Unterbefehle shell, boot, vm bei der Verwendung dieser Option nicht
verfügbar sind. Impliziert für tar, cpio, uki, esp, oci und addon.

CompressLevel=, --compress-level=
Konfiguriert die zu verwendende Komprimierungsstufe. Akzeptiert eine Ganzzahl. Die möglichen Werte
hängen von der verwandten Komprimierung ab.

OutputDirectory=, --output-directory=, -O
Pfad zu einem Verzeichnis, in dem alle erstellten Artefakte abgelegt werden sollen. Falls dies
nicht angegeben ist und das Verzeichnis mkosi.output/ im lokalen Verzeichnis existiert, dann wird
dies automatisch für diesen Zweck verwandt.

OutputMode=, --output-mode=
Dateizugriffsmodus, der bei der Erstellung der Ausgabe-Abbild-Datei verwandt wird. Akzeptiert
einen Zugriffsmodus in oktaler Notation. Falls nicht gesetzt, wird die aktuelle Systemvorgabe
verwandt.

ImageVersion=, --image-version=
Konfiguriert die Abbild-Version. Dies akzeptiert jede Zeichenkette, es wird aber empfohlen, eine
Reihe von durch Punkten getrennte Komponenten festzulegen. Die Version kann auch durch Lesen einer
Datei mkosi.version (in diesem Fall kann sie bequem mit dem Unterbefehl bump oder der Option
--auto-bump verwaltet werden) oder durch Lesen der Standardausgabe, falls diese ausführbar ist
(siehe den nachfolgenden Abschnitt Skripte), konfiguriert werden. Wenn dies angegeben ist, wird
die festgelegte Abbildversion in den standardmäßigen Ausgabedateinamen aufgenommen, d.h. anstelle
von image.raw wird die Vorgabe image_0.1.raw für Version 0.1 des Abbildes oder ähnlich lauten. Die
Version wird auch mittels $IMAGE_VERSION an alle aufgerufenen Bauskripte übergeben (das könnte
nützlich sein, um es in /usr/lib/os-release oder ähnliche einzubauen, insbesondere in das darin
befindliche Feld IMAGE_VERSION=).

ImageId=, --image-id=
Konfiguriert den Abbildkennzeichner. Dies akzeptiert eine formlose Zeichenkette, die zur
Kennzeichnung des Abbilds verwandt werden soll. Falls gesetzt, wird danach die
Standard-Ausgabedatei benannt (möglicherweise mit angehängter Version). Der Kennzeichner wird auch
mittels $IMAGE_ID an alle aufgerufenen Bauskripte übergeben. Die Abbildkennzeichnung wird
automatisch zu /usr/lib/os-release hinzugefügt.

SplitArtifacts=, --split-artifacts
Die Artekfattypen, die aus dem endgültigen Abbild herausgenommen werden sollen. Eine
Kommata-getrennte Liste, die aus uki, kernel, initrd und partitions besteht. Beim Bauen eines
selbststartenden Abbildes entsprechen kernel und initrd ihren im Abbild (oder dem UKI) gefundenen
Artefakten, während uki das gesamte UKI herauskopiert.

Beim Bau eines Plattenabbildes und wenn partitions angegeben ist, wird --split=yes an
systemd-repart(8) übergeben, damit dies getrennte Partitionsdateien für jede konfigurierte
Partition schreibt. Lesen Sie die
https://www.freedesktop.org/software/systemd/man/systemd-repart.html#--split=BOOL Handbuchseite
für weitere Informationen. Dies ist für A/B-Aktualisierungsszenarien nützlich, bei denen ein
bestehendes Plattenabbild mit einer neuen Version einer Wurzel- oder /usr-Partition zusammen mit
der zugehörigen Verity-Partition und einem vereinigten Kernel erweitert werden soll. Standardmäßig
werden uki, kernel und initrd rausgetrennt.

RepartDirectories=, --repart-directory=
Pfade zu Verzeichnissen, die Partitionsdefinitionsdateien von systemd-repart(8) enthalten, die
verwandt werden, wenn mkosi systemd-repart(8) beim Bau eines Plattenabbildes aufruft. Falls
mkosi.repart/ im lokalen Verzeichnis existiert, wird es für diesen Zweck auch verwandt. Beachten
Sie, dass mkosi Repart mit --root= aufruft, um die Wurzel auf die Wurzel des Abbildes zu setzen,
daher werden alle Quellpfade CopyFiles= in Partitionsdefinitionsdateien relativ zum
Wurzelverzeichnis des Abbildes sein.

SectorSize=, --sector-size=
Setzt die Standardsektorgröße, die systemd-repart(8) zum Bau eines Plattenabilds benutzt, außer
Kraft.

Overlay=, --overlay
Bei der Verwendung zusammen mit BaseTrees= wird die Ausgabe nur aus Änderungen an den angegebenen
Basisbäumen bestehen. Jeder Basisbaum wird als untere Lage in einer Overlayfs-Struktur angehängt
und die Ausgabe wird die obere Lage, die am Anfang leer ist. Daher werden Dateien, die sich
gegenüber dem Basisbaum nicht ändern, nicht in der abschließenden Ausgabe enthalten sein.

Diese Option kann dazu verwandt werden, Systemd Systemerweiterungen oder portable Dienste zu
erstellen.

Seed=, --seed=
Akzeptiert eine UUID oder den besonderen Wert random als Argument. Setzt den von systemd-repart(8)
beim Bau des Plattenabbildes verwandten Zufallsstartwert außer Kraft. Dies ist zur Erstellung
wiederholbarer Bauten nützlich, bei denen vorhersehbare UUIDs und andere Partitionsmetadaten bei
jedem Bau abgeleitet werden können sollen. Falls nicht explizit angegeben und die Datei mkosi.seed
im lokalen Verzeichnis existiert, wird daraus die zu verwendende UUID gelesen. Andernfalls wird
eine zufällige UUID verwandt.

CleanScripts=, --clean-script=
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als Bereinigungsskripte für
dieses Abbild verwandt werden. Siehe den Abschnitt Skripte für weitere Informationen.

Abschnitt [Content]
Packages=, --package=, -p
Installiert die angegebenen Distributionspakete (z.B. RPM, deb, …) in dem Abbild. Akzeptiert eine
Kommata-getrennte Liste von Paketangaben. Diese Option kann mehrfach verwandt werden; dann werden
die angegebenen Paketlisten kombiniert. Verwenden Sie BuildPackages=, um Pakete anzugeben, die nur
in einer Überlagerung installiert werden, die eingehängt wird, wenn die Vorbereitungsskripte mit
dem Argument build ausgeführt werden und wenn die Bauskripte ausgeführt werden.

Die Arten und Syntax der erlaubten Paketangaben hängen von dem Paketinstallationsprogramm ab
(z.B. dnf für rpm(8)-basierte Distributionen oder apt(8) für deb(5)-basierte Distributionen), kann
aber Paketnamen, Paketnamen mit Versionen und/oder Architektur, Paketnamen-Globs, Paketgruppen und
virtuelle Bereitstellungen (»provides«), einschließlich Dateipfaden, enthalten.

Siehe PackageDirectories= zu Informationen darüber, wie lokale Pakete zur Installation mit
Packages= verfügbar gemacht werden können.

Beispiel: Bei der Verwendung einer Distribution, die dnf verwendet, würde die nachfolgende
Konfiguration das Paket meson(1) (in der neusten Version), die 32-bit-Version des Pakets
libfdisk-devel, alle verfügbaren Pakete, deren Namen mit git- beginnt, ein systemd-RPM aus dem
lokalen Dateisystem, eines der Pakete, das /usr/bin/ld bereitstellt, die Pakete in der Gruppe
Development Tools und das Paket, das das Python-Modul mypy(1) enthält, installieren.

Packages=meson
libfdisk-devel.i686
git-*
/usr/bin/ld
@development-tools
python3dist(mypy)

BuildPackages=, --build-package=
Ähnlich wie Packages=, konfiguriert aber Pakete, die nur in eine Überlagerung installiert werden,
die oberhalb des Abbildes verfügbar gemacht wird, um Skripte vorzubereiten, die mit dem Argument
build ausgeführt werden, sowie den Bauskripten. Diese Option sollte zum Aufführen von Paketen
verwandt werden, die Header-Dateien, Compiler, Bausysteme, Linker und andere Bauwerkzeuge
enthalten, die die Skripte mkosi.build zur Ausführung benötigen. Beachten Sie, dass die hier
aufgeführten Pakete im endgültigen Abbild nicht enthalten sein werden.

VolatilePackages=, --volatile-package=
Ähnlich zu Packages=, aber Pakete, die mit dieser Einstellung konfiguriert sind, werden nicht
zwischengespeichert, wenn Incremental= aktiviert ist und werden nach der Ausführung aller
Bauskripte installiert.

Insbesondere kann diese Einstellung zur Installation von Paketen verwandt werden, die sich oft
ändern oder die durch ein Bauskript gebaut werden.

PackageDirectories=, --package-directory=
Legt Verzeichnisse fest, die zusätzliche Pakete enthalten, die während des Baus verfügbar gemacht
werden sollen. mkosi wird ein lokales Depot mit allen Paketen aus diesen Verzeichnissen erstellen
und es beim Installieren von Paketen oder Ausführen von Skripten verfügbar machen. Falls das
Verzeichnis mkosi.packages/ im lokalen Verzeichnis gefunden wird, wird es auch für diesen Zweck
verwandt.

VolatilePackageDirectories=, --volatile-package-directory=
Ähnlich zu PackageDirectories=, aber sämtliche Änderungen an den Paketen in diesen Verzeichnissen
werden die zwischengespeicherten Abbilder nicht für ungültig erklären, falls Incremental=
aktiviert ist.

Zusätzlich können Bauskripte weitere Pakete zu den lokalen Depots hinzufügen, indem sie gebaute
Pakete in $PACKAGEDIR ablegen. Die in $PACKAGEDIR abgelegten Pakete werden von allen gebauten
Abbildern gemeinsam benutzt und sind daher zur Installation in allen Abbildern mittels
VolatilePackages= verfügbar.

WithRecommends=, --with-recommends=
Konfiguriert, ob empfohlene Pakete oder schwache Abhängigkeiten installiert werden, abhängig
davon, wie sie vom verwandten Paketverwalter benannt werden. Standardmäßig werden empfohlene
Pakete nicht installiert. Dies wird nur von Paketverwaltern unterstützt, die dieses Konzept
unterstützen. Derzeit sind dies apt(8), dnf(8) und zypper(8).

WithDocs=, --with-docs
Bindet Dokumentation in das Abbild ein. Standardmäßig aktiviert. Wenn deaktiviert, wird die
Dokumentation in das Abbild nicht aufgenommen, falls der zugrundeliegende Paketverwalter das
unterstützt. Die Umgebungsvariable $WITH_DOCS wird an die Skripte mkosi.build mit 0 oder 1
weitergegeben, abhängig davon, ob diese Option aktiviert oder deaktiviert ist.

BaseTrees=, --base-tree=
Akzeptiert eine Komma-getrennte Liste von Pfaden zu Verwendung als Basisbäume. Bei der Verwendung
werden diese Basisbäume in die Betriebssystembäume kopiert und formen die Basisdistribution
anstelle der normalen Installation. Es werden nur zusätzliche Pakete ergänzend zu den bereits in
den Basisbäumen installierten Paketen installiert. Beachten Sie, dass das Basisabbild weiterhin
die Paketverwaltermetadaten durch Setzen von CleanPackageMetadata=no (siehe CleanPackageMetadata=)
enthalten muss, damit das korrekt funktioniert.

Anstelle eines Verzeichnisses kann eine Tar-Datei oder ein Plattenabbild bereitgestellt werden. In
diesem Fall wird es in den Betriebssystembaum entpackt. Dieser Betriebsmodus erlaubt das explizite
Setzen von Berechtigungen und Dateieigentümerschaften, insbesondere für Projekte, die in einem
Versionsverwaltungssystem wie git(1) gespeichert sind, das die Metadaten für die
Dateieigentümerschaft und den Zugriffsmodus für übergebene Dateien vollständig beibehält.

SkeletonTrees=, --skeleton-tree=
Akzeptiert eine Kommata-getrennte Liste von Doppelpunkt-getrennten Pfadpaaren. Der erste Pfad
jedes Paares bezieht sich auf ein Verzeichnis, das vor Aufruf des Paketverwalters in den
Betriebssystembaum kopiert werden soll. Der zweite Pfad in jedem Paar bezieht sich auf das
Zielverzeichnis innerhalb des Abbildes. Falls der zweite Pfad nicht bereit gestellt wird, wird das
Verzeichnis auf das Wurzelverzeichnis des Abbildes kopiert. Der zweite Pfad wird immer als ein
absoluter Pfad interpretiert. Verwenden Sie dies, um Dateien und Verzeichnisse in den
Betriebssystembaum einzufügen, bevor der Paketverwalter irgendwelche Pakete installiert. Falls das
Verzeichnis mkosi.skeleton/ in dem lokalen Verzeichnis gefunden wird, wird es auch für diesen
Zweck mit dem Wurzelverzeichnis als Ziel verwandt (siehe auch den nachfolgenden Abschnitt
Dateien).

Beachten Sie, dass die Gerüstbäume zwischengespeichert werden und alle Änderungen an den
Gerüstbäumen, nachdem ein zwischengespeichertes Abbild gebaut wurde (bei der Verwendung von
Incremental=), nur angewandt werden, wenn das zwischengespeicherte Abbild neu gebaut wird (durch
Verwendung von -ff oder der Ausführung von mkosi -f clean).

Gemäß der obigen Basisbaumlogik kann anstelle eines Verzeichnisses auch eine Tar-Datei
bereitgestellt werden. mkosi.skeleton.tar wird automatisch verwandt, falls es im lokalen
Verzeichnis gefunden wird.

Um zusätzliche Paketverwalter-Konfigurationsdateien wie zusätzliche Depots hinzuzufügen, verwenden
Sie SandboxTrees=, da mkosi die Paketverwalter von außerhalb (und nicht innerhalb) des Abbildes
aufruft und daher sämtliche mittels SkeletonTrees= bereitgestellte Konfigurationsdateien nicht
wirksam werden, wenn mkosi den Paketverwalter zur Installation von Paketen aufruft.

ExtraTrees=, --extra-tree=
Akzeptiert eine Kommata-getrennte Liste von Doppelpunkt-getrennten Pfadpaaren. Der erste Pfad
jedes Paares bezieht sich auf ein Verzeichnis, das vom Wirtsystem in das Abbild kopiert werden
soll. Der zweite Pfad in jedem Paar bezieht sich auf das Zielverzeichnis innerhalb des Abbildes.
Falls der zweite Pfad nicht bereit gestellt wird, wird das Verzeichnis auf das Wurzelverzeichnis
des Abbildes kopiert. Der zweite Pfad wird immer als ein absoluter Pfad interpretiert. Verwenden
Sie dies, um beliebige, mit der Distribution ausgelieferte Standardkonfigurationsdateien außer
Kraft zu setzen. Falls das Verzeichnis mkosi.extra/ in dem lokalen Verzeichnis gefunden wird, wird
es auch für diesen Zweck mit dem Wurzelverzeichnis als Ziel verwandt (siehe auch den nachfolgenden
Abschnitt Dateien).

Gemäß der obigen Basisbaumlogik kann anstelle eines Verzeichnisses auch eine Tar-Datei
bereitgestellt werden. mkosi.extra.tar wird automatisch verwandt, falls es im lokalen Verzeichnis
gefunden wird.

RemovePackages=, --remove-package=
Akzeptiert eine Kommata-getrennte Liste von Spezifikation von zu entfernenden Paketen, im gleichen
Format wie Packages=. Die Entfernung erfolgt als einer der letzten Schritte. Dieser Schritt wird
übersprungen, falls CleanPackageMetadata=no verwandt wird.

RemoveFiles=, --remove-files=
Akzeptiert eine Kommata-getrennte Liste von Globs. Dateien im Abbild, die auf die Globs passen,
werden am Ende vollständig entfernt.

CleanPackageMetadata=, --clean-package-metadata=
Aktiviert/Deaktivert das Entfernen der Paketverwalter-Datenbanken und Depot-Metadaten am Ende der
Installation. Kann als true, false oder (die Vorgabe) auto angegeben werden. Bei auto werden die
Paketverwalter-Datenbanken und Depot-Metadaten entfernt, falls das Programm des entsprechenden
Paketverwalters am Ende der Installation nicht vorhanden ist.

SourceDateEpoch=, --source-date-epoch=
Akzeptiert einen Zeitstempel in Sekunden seit dem UNIX-Epcoh als Argument. Dateiveränderungszeiten
aller Dateien werden auf diesen Wert befestigt. Die Variable wird auch an systemd-repart(8) und
alle von mkosi ausgeführten Skripte weitergegeben. Falls nicht explizit gesetzt, wird
SOURCE_DATE_EPOCH aus --environment und aus der Umgebung des Wirtsystems in dieser Reihenfolge
ausprobiert. Siehe SOURCE_DATE_EPOCH für weitere Informationen.

SyncScripts=, --sync-script=
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als Synchronisationsskripte
für dieses Abbild verwandt werden. Siehe den Abschnitt Skripte für weitere Informationen.

PrepareScripts=, --prepare-script=
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als Vorbereitungsskripte für
dieses Abbild verwandt werden. Siehe den Abschnitt Skripte für weitere Informationen.

BuildScripts=, --build-script=
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als Bauskripte für dieses
Abbild verwandt werden. Siehe den Abschnitt Skripte für weitere Informationen.

PostInstallationScripts=, --postinst-script=
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als
Post-Installationsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt Skripte für
weitere Informationen.

FinalizeScripts=, --finalize-script=
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als Finalisierungsskripte
für dieses Abbild verwandt werden. Siehe den Abschnitt Skripte für weitere Informationen.

PostOutputScripts=, --postoutput-script
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als Post-Ausgabeskripte für
dieses Abbild verwandt werden. Siehe den Abschnitt Skripte für weitere Informationen.

Bootable=, --bootable=
Akzeptiert einen logischen Wert oder auto. Aktiviert oder deaktiviert die Erstellung eines
startfähigen Abbildes. Falls aktiviert, wird mkosi ein EFI-Systemstartprogramm installieren und
eine ESP-Partition hinzufügen, wenn die Plattenabbildausgabe verwandt wird. Falls das ausgewählte
EFI-Systemstartprogramm (siehe Bootloader=) nicht installiert ist oder keine Kernelabbilder
gefunden werden können, wird der Bau fehlschlagen. auto verhält sich so, als ob die Option
aktiviert wäre, aber der Bau schlägt nicht fehl, falls entweder kein Kernelabbild oder das
ausgewählte EFI-Systemstartprogramm nicht gefunden werden kann. Falls deaktiviert, wird kein
Systemstartprogramm installiert, selbst falls es innerhalb des Abbildes gefunden wird, kein
vereinigtes Kernelabbild wird erstellt und keine ESP-Partition wird zu dem Abbild hinzugefügt,
falls das Plattenausgabeformat verwandt wird.

Bootloader=, --bootloader=
Akzeptiert entweder none, systemd-boot, uki, grub, systemd-boot-signed, uki-signed oder
grub-signed. Standardmäßig systemd-boot. Falls auf none gesetzt, wird kein EFI-Systemstartprogramm
in das Abbild installiert. Falls auf systemd-boot gesetzt, wird systemd-boot(7) installiert und
für jeden installierten Kernel ein UKI erstellt und in EFI/Linux im ESP gespeichert. Falls auf uki
gesetzt, wird ein einzelnes UKI für den neuesten installierten Kernel (demjenigen mit der höchsten
Version), der in EFI/BOOT/BOOTX64.EFI im ESP installiert ist, generiert. Falls auf grub gesetzt,
wird für jeden installierten Kernel ein UKI erstellt und in EFI/Linux im ESP gespeichert. Für
jeden erstellten UKI wird ein Menüeintrag zu der Grub-Konfiguration in grub/grub.cfg im ESP
hinzugefügt, der in den UKI weiterlädt. Zur Anpassung wird ein grub.cfg auch nach
EFI/<Distribution>/grub.cfg aus Kompatibilitätsgründen mit signierten Versionen von Grub
grub/grub.cfg im ESP geschrieben, da diese die Konfiguration von diesem Ort laden.

Die Varianten signed werden nur von Distributionen ausgelieferte, vorab-signierte EFI-Programme
installieren.

Kernel müssen unter /usr/lib/modules/$version mit Namen vmlinux oder vmlinuz im Wurzeldateisystem
abgelegt werden (beispielsweise mittels ExtraTrees=). Das $version lautet genau so, wie das
Make-Ziel kernelversion von Kbuild es erstellt.

BiosBootloader=, --bios-bootloader=
Akzeptiert entweder none oder grub. Standardmäßig none. Falls auf none gesetzt, wird kein
BIOS-Systemstartprogramm installiert. Falls auf grub gesetzt, wird Grub als
BIOS-Systemstartprogramm installiert, falls ein startfähiges Abbild mit der Option Bootable=
erbeten wird. Falls keine Repart-Partitionsdefinitionsdateien konfiguriert sind, wird mkosi eine
Grub-BIOS-Systemstartpartition und eine EFI-Systempartition zu den
Standard-Partitionsdefinitionsdateien hinzufügen.

Beachten Sie, dass diese Option sich nicht mit der Option Bootloader= gegenseitig ausschließt. Es
ist möglich, ein Abbild zu haben, das sowohl unter UEFI als auch BIOS startet, indem sowohl
Bootloader= als auch BiosBootloader= konfiguriert wird.

Die Grub-BIOS-Systemstartpartition sollte die UUID 21686148-6449-6e6f-744e-656564454649 haben und
mindestens 1 MB groß sein.

Selbst wenn kein EFI-Systemstartladeprogramm installiert ist, wird dennoch ein ESP für
BIOS-Systemstarts benötigt, da dort der Kernel, die Initrd und Grub-Module gespeichert werden.

ShimBootloader=, --shim-bootloader=
Akzeptiert entweder none, unsigned oder signed. Standardmäßig none. Falls auf none gesetzt, werden
Shim und MokManager nicht in die ESP installiert. Falls auf unsigned gesetzt, wird mkosi nach
unsignierten Shim- und MokManager-EFI-Programmen suchen und sie installieren. Falls SecureBoot=
aktiviert ist, wird mkosi vor der Installation die unsignierten EFI-Programme signieren. Falls auf
signed gesetzt, wird mkosi nach signierten EFI-Programmen suchen und sie installieren. Selbst wenn
SecureBoot= aktiviert ist, wird mkosi die Programme nicht erneut signieren.

Beachten Sie, dass diese Option nur wirksam wird, wenn ein auf UEFI-Firmware startfähiges Abbild
mittels anderer Optionen angefragt wird (Bootable=, Bootloader=).

Beachten Sie, dass mkosi nur bereits signierte Systemladeprogramme, Kernelabbilddateien und
vereinigte Kernelabbilder installieren wird, wenn diese Option aktiviert ist, da selbstsignierte
Programme von signierten Versionen von Shim nicht akzeptiert würden.

UnifiedKernelImages=, --unified-kernel-images=
Gibt an, ob vereinigte Kernelabbilder verwandt werden sollen, wenn Bootloader= auf systemd-boot
oder grub gesetzt ist. Akzeptiert einen logischen Wert oder auto. Standardmäßig auto. Falls
aktiviert, werden vereinigte Kernelabbilder immer verwandt und der Bau wird fehlschlagen, falls
eine der für den Bau von vereinigten Kernelabbildern benötigten Komponenten fehlt. Falls auf auto
gesetzt, werden vereinigte Kernelabbilder verwandt, falls alle benötigten Komponenten verfügbar
sind. Andernfalls werden stattdessen Typ-1-Einträge, wie in der Systemladerspezifikation
definiert, verwandt. Falls deaktiviert, werden Typ-1-Einträge immer verwandt.

UnifiedKernelImageFormat=, --unified-kernel-image-format=
Akzeptiert einen Dateinamen ohne irgendeine Pfadkomponente, um das Format festzulegen, in dem
vereinigte Kernelabbilder installiert werden sollen. Dies kann sowohl die normalen Kennzeichner
(siehe Kennzeichner) als auch besondere verzögerte Kennzeichner festlegen, die während der
Installation von Dateien expandiert und die nachfolgend beschrieben werden. Das Standardformat für
diesen Parameter lautet &e-&k wobei -&h angehängt wird, falls roothash= oder usrhash= auf der
Kernelbefehlszeile gefunden wird und +&c falls /etc/kernel/tries im Abbild gefunden wird.

Die folgenden Kennzeichner können außerdem verwendet werden:

Kennzeichner Wert
─────────────────────────────────────────────────────
&& &-Zeichen
&e Zugangsmerkmal
&k Kernelversion
&h Wert des Kernelarguments roothash=
oder usrhash=
&c Anzahl der Versuche, die für den
Zähler für Systemstarts verwandt
werden

UnifiedKernelImageProfiles=, --uki-profile=
Baut zusätzliche UKI-Profile. Akzeptiert eine Kommata-getrennte Liste von Pfaden zu
UKI-Profil-Konfigurationsdateien. Diese Option kann mehrfach angegeben werden. Dann wird jede
Konfiguration in das entsprechende UKI-Profil gebaut. Konfigurationsdateien im Verzeichnis
mkosi.uki-profiles/ werden automatisch aufgenommen. Alle konfigurierten UKI-Profile werden als
zusätzliche UKI-Profile für jedes von mkosi gebaute UKI hinzugefügt.

Siehe die Dokumentation für den Abschnitt UKIProfile zu Informationen, welche Einstellungen in
UKI-Profil-Konfigurationsdateien vorgenommen werden können.

Initrds=, --initrd
Verwendet vom Benutzer bereitgestellte Initrd(s). Akzeptiert eine Kommata-getrennte Liste von
Pfaden zu Initrd-Dateien. Diese Option kann mehrfach angewendet werden. Dann werden die
aufgeführten Initrd-Listen kombiniert. Falls keine Initrds angegeben sind und ein startfähiges
Medium erbeten wurde, wird mkosi nach Initrds in einem Unterverzeichnis io.mkosi.initrd des
Artefakt-Verzeichnisses suchen (siehe $ARTIFACTDIR in dem Abschnitt UMGEBUNGSVARIABLEN). Falls
dort keine Initrds gefunden werden, wird mkosi automatisch eine Standard-Initrd bauen.

InitrdPackages=, --initrd-package=
Extra-Pakete, die in die Standard-Initrd installiert werden sollen. Akzeptiert eine
Kommata-getrennte Liste von Paketspezifikationen. Diese Option kann mehrfach angewendet werden.
Dann werden die aufgeführten Paketlisten kombiniert.

InitrdVolatilePackages=, --initrd-volatile-package=
Ähnlich zu VolatilePackages=, außer das es auf die Standard-Initrd angewandt wird.

Devicetree=, --devicetree=
Legt, wenn gesetzt, einen Devicetree-Blob fest, der beim Systemstart anstelle des durch die
Firmware bereitgestellten verwandt werden soll. mkosi wird nach der angegebenen Datei relativ zu
typischen Pfaden suchen, in denen Linux-Distributionen Devicetree-Dateien installieren. Er sollte
typischerweise das Format <Lieferant>/<board>.dtb haben.

MicrocodeHost=, --microcode-host=
Wenn auf true gesetzt, wird nur der Mikrocode für die CPU des Wirtsystems in das Abbild
aufgenommen.

KernelCommandLine=, --kernel-command-line=
Verwendet beim Bau von Abbildern die angegebene Kernelbefehlszeile.

Falls die Wurzel- oder Verity-Partition mit aktiviertem Verity erstellt werden, werden roothash=
bzw. usrhash= automatisch zu der Kernel-Befehlszeile hinzugefügt und root= oder mount.usr= sollten
nicht hinzugefügt werden. Andernfalls, falls der Wert dieser Einstellung die selbstdeutenden
Symbole root=PARTUUID oder mount.usr=PARTUUID enthält, werden diese mit der Partitions-UUID der
Wurzel- bzw. usr-Partition ersetzt. Beispielsweise würde root=PARTUUID durch
root=PARTUUID=58c7d0b2-d224-4834-a16f-e036322e88f7 ersetzt, wobei
58c7d0b2-d224-4834-a16f-e036322e88f7 die Partitions-UUID der Wurzelpartition ist.

KernelModulesInclude=, --kernel-modules-include=
Akzeptiert eine Liste von Mustern regulärer Ausdrücke, die ins Abbild aufzunehmende Kernelmodule
festlegen. Die Muster sollten relativ zum Pfad /usr/lib/modules/<kver>/kernel sein. mkosi prüft
überall im Modulpfad auf Übereinstimmung (z.B. passt i915 auf drivers/gpu/drm/i915.ko). Alle
Module, die auf eines der angegebenen Muster passen, werden im Abbild aufgenommen. Alle Module und
Firmwareabhängigkeiten des übereinstimmenden Moduls werden auch im Abbild aufgenommen.

Falls der besondere Wert default verwandt wird, werden auch die in der Konfiguration mkosi-initrd
definierten Standard-Kernelmodule aufgenommen.

Falls der besondere Wert host verwandt wird, werden auch die auf dem Wirtsystem aktuell geladenen
Module aufgenommen.

Diese Einstellung hat gegenüber KernelModulesExclude= Vorrang und ergibt nur in Kombination mit
ihr Sinn, da standardmäßig alle Kernelmdoule ins Abbild aufgenommen werden.

KernelModulesExclude=, --kernel-modules-exclude=
Akzeptiert eine Liste von Mustern regulärer Ausdrücke, die Module angeben, die vom Abbild
ausgeschlossen werden sollen. Verhält sich zu KernelModulesInclude= identisch, außer dass alle
Module, die mit einem der angegebenen Muster übereinstimmen, vom Abbild ausgeschlossen werden.

KernelModulesInitrd=, --kernel-modules-initrd=
Logischer Wert, standardmäßig aktiviert (true). Falls beim Bau eines Abbildes aktiviert, wird
mkosi eine zusätzliche Initrd für jedes von ihm zusammengebaute vereinigte Kernelabbild erstellen.
Diese Initrd enthält nur Module für die konkrete Kernelversion und wird an die vorab gebaute
Initrd angehängt. Dies ermöglicht es, Kernel-unabhängige Initrds zu erstellen, die mit den
notwendigen Modulen ergänzt werden, wenn das UKI zusammengebaut wird.

KernelModulesInitrdInclude=, --kernel-modules-initrd-include=
Wie KernelModulesInclude=, gilt aber für Kernelmodule, die Teil der Kernelmodul-Initrd sind.

KernelModulesInitrdExclude=, --kernel-modules-initrd-exclude=
Wie KernelModulesExclude=, gilt aber für Kernelmodule, die Teil der Kernelmodul-Initrd sind.

Locale=, --locale=, LocaleMessages=, --locale-messages=, Keymap=, --keymap=, Timezone=, --timezone=,
Hostname=, --hostname=, RootShell=, --root-shell=
Die Einstellungen Locale=, --locale=, LocaleMessages=, --locale-messages=, Keymap=, --keymap=,
Timezone=, --timezone=, Hostname=, --hostname=, RootShell=, --root-shell= entsprechen den
identisch benannten Systemd-firstboot-Optionen. Siehe systemd-firstboot(1) für weitere
Informationen. Ergänzend werden, wo anwendbar, die entsprechenden Systemd-Zugangsberechtigungen
für diese Einstellungen nach /usr/lib/credstore geschrieben, so dass sie selbst dann angewandt
werden, wenn nur /usr im Abbild ausgeliefert wird.

RootPassword=, --root-password=,
Setzt das Root-Passwort des Systems. Falls diese Option nicht verwandt wird, aber eine Datei
mkosi.rootpw im lokalen Verzeichnis gefunden wird, wird das Passwort automatisch daraus gelesen
oder falls die Datei ausführbar ist, wird sie als Skript ausgeführt und stattdessen wird die
Standardausgabe gelesen (siehe den nachfolgenden Abschnitt Scripts). Falls das Passwort mit
hashed: beginnt, wird es als ein bereits gehashtes Passwort betrachtet. Das Root-Passwort wird
auch in /usr/lib/credstore unterhalb der entsprechenden Systemd-Zugangsberechtigung gespeichert,
so dass es selbst dann angewandt wird, wenn nur /usr im Abbild ausgeliefert wird. Um ein
entsperrtes Konto ohne Passwort zu erstellen, verwenden Sie hashed: ohne einen Hash.

Autologin=, --autologin
Aktiviert die automatische Anmeldung für den Benutzer root auf /dev/pts/0 (nspawn), /dev/tty1 und
/dev/hvc0.

MakeInitrd=, --make-initrd
Fügt /etc/initrd-release und /init zum Abbild hinzu, so dass es als ein Initramfs verwandt werden
kann.

Ssh=, --ssh
Falls angegeben wird eine sshd(8)-Socket-Unit und ein passender Dienst im letztendlichen Abbild
installiert, das SSH über Vsock offenlegt. Beim Bau mit dieser Option und dem Betrieb des Abbilds
mittels mkosi vm kann der Befehl mkosi ssh zum Verbinden mit dem Container/der VM mittels SSH
verwandt werden. Beachten Sie, dass Sie weiterhin sicherstellen müssen, dass Openssh im Abbild
installiert ist, damit sich diese Option korrekt verhält. Führen Sie mkosi genkey aus, um
automatisch ein X.509-Zertifikat und private Schlüssel zu erzeugen, die von mkosi zur Aktivierung
vom SSH-Zugriff zu jeder virtuellen Maschine mittels mkosi ssh verwandt werden. Um auf mittels
mkosi boot gestartete Abbilder zuzugreifen, verwenden Sie machinectl(1).

SELinuxRelabel=, --selinux-relabel=
Legt fest, ob Dateien neu markiert werden sollen, um auf die SELinux-Richtlinie des Abbilds zu
passen. Akzeptiert einen logischen Wert oder auto. Standardmäßig auto. Falls deaktiviert, werden
Dateien nicht neu markiert. Falls aktiviert, muss eine SELinux-Richtlinie im Abbild installiert
werden und setfiles(8) verfügbar sein, um Dateien zu markieren. Falls während setfiles(8)
irgendein Fehler auftritt, wird der Bau fehlschlagen. Falls auf auto gesetzt, werden Dateien neu
markiert, falls eine SELinux-Richtlinie im Abbild installiert und setfiles(8) verfügbar ist. Alle
während setfiles(8) aufgetretenen Fehler werden ignoriert.

Beachten Sie, dass bei der nicht privilegierten Ausführung setfiles(8) beim Setzen von allen
Markierungen fehlschlagen wird, die nicht in der SELinux-Richtlinie des Wirtsystems sind. Um
sicherzustellen, dass setfiles(8) ohne Fehler erfolgreich ist, führen Sie mkosi als Root aus oder
bauen Sie von einem Wirtsystem, das die gleichen SELinux-Richtlinie wie im zu bauenden Abbild
verwendet.

MachineId=, --machine-id=
Akzeptiert eine UUID oder den besonderen Wert random. Setzt die Maschinenkennung des Abbildes auf
die angegebene UUID. Falls auf random gesetzt, wird eine zufällige UUID nach /etc/machine-id
geschrieben. Falls nicht explizit angegeben und die Datei mkosi.machine-id im lokalen Verzeichnis
existiert, wird die zu verwendene UUID daraus gelesen. Andernfalls wird uninitialized nach
/etc/machine-id geschrieben.

Abschnitt [Validation]
SecureBoot=, --secure-boot
Signiert systemd-boot(7) (falls es noch nicht signiert ist) und sämtliche vereinigten
Kernelabbilder für UEFI SecureBoot.

SecureBootAutoEnroll=, --secure-boot-auto-enroll=
Einrichtung der automatischen Registrierung der Schlüssel für sicheren Systemstart in virtuellen
Maschinen falls SecureBoot= verwandt wird, wie das in systemd-boot(7) beschrieben wird. Beachten
Sie, dass systemd-boot(7) nur ab Systemd v253 die automatische Registrierung von Schlüsseln für
sicheren Systemstart in virtuellen Maschinen durchführen wird. Um die automatische Registrierung
unter Systemd v252 auf Maschinen ohne Virtualisierung durchzuführen, müssen Sie eine
systemd-boot(7)-Konfigurationsdatei nach /efi/loader/loader.conf mittels eines zusätzlichen Baumes
mit secure-boot-enroll force oder secure-boot-enroll manual darin schreiben. Unter
Systemd-Versionen älter als v252 wird keine automatische Registrierung unterstützt. Standardmäßig
yes.

SecureBootKey=, --secure-boot-key=
Pfad zu der PEM-Datei, die den geheimen Schlüssel zum Signieren des UEFI-Kernelabbilds, falls
SecureBoot= verwandt wird und der PCR-Signaturen, falls SignExpectedPcr= auch verwandt wird,
enthält. Wenn SecureBootKeySource= angegeben ist, hängt der Eingabetyp von der Quelle ab.

SecureBootCertificate=, --secure-boot-certificate=
Pfad zu der X.509-Datei, die das Zertifikat für das signierte UEFI-Kernelabbild enthält, falls
SecureBoot= verwandt wird.

SecureBootSignTool=, --secure-boot-sign-tool
Werkzeug zum Signieren von PE-Programmen für den sicheren Systemstart. Akzeptiert entweder
systemd-sbsign, sbsign oder auto. Standardmäßig auto. Falls auf auto gesetzt, wird (wenn
verfügbar) entweder systemd-sbsign(1) oder sbsign(1) verwandt, wobei systemd-sbsign(1) bevorzugt
wird.

Verity=, --verity=
Ob das Verity-Signieren für Erweiterungsabbilder erzwungen oder deaktiviert wird. Akzeptiert einen
logischen Wert oder auto. Falls aktiviert, muss ein Verity-Schlüssel und -Zertifikat vorhanden
sein und der Bau wird fehlschlagen, falls keine Verity-Partitionen in dem durch systemd-repart(8)
erstellten Abbild erkannt werden. Falls deaktiviert, werden Verity-Partitionen von den durch
systemd-repart(8) erstellten Abbildern ausgeschlossen. Falls auf auto gesetzt und ein
Verity-Schlüssel und -Zertifikat vorhanden sind, wird mkosi sie an systemd-repart(8) weitergeben
und erwartet, dass das erstellte Plattenabbild Verity-Partitionen enthalten wird, aber der Bau
wird nicht fehlschlagen, falls keine Verity-Partitionen in dem durch systemd-repart(8) erstellten
Plattenabbild gefunden werden.

Beachten Sie, dass das explizite Deaktivieren signierter Verity für die Ausgabe disk noch nicht
implementiert ist und derzeit nur für Erweiterungsabbilder funktioniert.

VerityKey=, --verity-key=
Pfad zu der PEM-Datei, die den geheimen Schlüssel zum Signieren der Verity-Signatur enthält, falls
eine Verity-Signaturpartition mit systemd-repart(8) hinzugefügt wird. Wenn VerityKeySource=
festgelegt wird, hängt der Eingabetyp von der Quelle ab.

VerityCertificate=, --verity-certificate=
Pfad zu einer X.509-Datei, die das Zertifikat zum Signieren der Verity-Signatur enthält, falls
eine Verity-Signaturpartition mittels systemd-repart(8) hinzugefügt wird.

SignExpectedPcr=, --sign-expected-pcr
Misst die Komponenten des vereinigten Kernelabbildes (UKI) mittels systemd-measure(1) und bettet
die PCR-Signatur in das vereinigte Kernelabbild ein. Diese Option akzeptiert einen logischen Wert
oder den besonderen Wert auto, der die Vorgabe ist, der identisch zu einem wahren Wert ist, falls
das Programm systemd-measure im PATH ist. Hängt vom aktivierten SecureBoot= und Schlüssel aus
SecureBootKey= ab.

SignExpectedPcrKey=, --sign-expected-pcr-key=
Pfad zu der PEM-Datei, die den geheimen Schlüssel zum Signieren der erwarteten PCR-Signatur
enthält. Wenn VerityKeySource= festgelegt wird, hängt der Eingabetyp von der Quelle ab.

SignExpectedPcrCertificate=, --sign-expected-pcr-certificate=
Pfad zu einer X.509-Datei, die das Zertifikat zum Signieren der erwarteten PCR-Signatur enthält.

SecureBootKeySource=, --secure-boot-key-source=, VerityKeySource=, --verity-key-source=,
SignExpectedPcrKeySource=, --sign-expected-key-source=
Die Quelle des entsprechenden privaten Schlüssels, um OpenSSL-Engines und -Provider zu
unterstützen, z.B. --secure-boot-key-source=engine:pkcs11 oder
--secure-boot-key-source=provider:pkcs11.

SecureBootCertificateSource=, --secure-boot-certificate-source=, VerityCertificateSource=,
--verity-certificate-source=, SignExpectedPcrCertificateSource=, --sign-expected-certificate-source=
Die Quelle der entsprechenden Zertifikate, um OpenSSL-Provider zu unterstützen,
z.B. --secure-boot-certificate-source=provider:pkcs11. Beachten Sie, dass Engines nicht
unterstützt werden.

Passphrase=, --passphrase
Gibt den Pfad zu einer Datei an, die die für die LUKS-Verschlüsselung zu verwendende Passphrase
enthält. Sie sollte die Passphrase wortwörtlich enthalten und nicht mit einem Zeilenumbruch enden
(d.h. in dem gleichen Format sein, wie cryptsetup(8) und /etc/crypttab die Passphrasendatei
erwarten). Die Datei muss den Zugriffsmodus 0600 oder kleiner haben.

Checksum=, --checksum
Erstellt eine Datei <Ausgabe>.SHA256SUMS über alle erstellten Artefakte, nachdem der Bau
abgeschlossen ist.

Sign=, --sign
Signiert nach Fertigstellung die erstellte SHA256SUMS mittels gpg(1).

OpenPGPTool=, --openpgp-tool
Zum Signieren zu verwendende OpenPGP-Implementierung. gpg ist die Vorgabe. Durch Wahl einer
anderen als die Vorgabe wird das Werkzeug für Zustandslose OpenPGP (SOP) zum Signieren der Datei
SHA256SUMS verwandt.

Beispielhaft seien sqop und rsop genannt, aber jede Implementierung von
https://www.openpgp.org/about/sop/, die lokal installiert werden kann, funktioniert.

Key=, --key=
Wählt den für das Signieren der SHA256SUMS zu verwendenden gpg(1)-Schlüssel aus. Dieser Schlüssel
muss bereits im gpg(1)-Schlüsselbund vorhanden sein.

Abschnitt [Build]
ToolsTree=, --tools-tree=
Falls angegeben, werden von mkosi ausgeführte Programme zum Bau und Starten eines Abbilds
innerhalb des angegeben Baums statt im Wirtsystem gesucht. Verwenden Sie diese Option, um den
Abbildbau reproduzierbarer zu machen, indem Sie immer die gleiche Version von Programmen zum Bau
des letztendlichen Abbildes verwenden, anstelle der gerade im Wirtsystem installierten Version.
Falls diese Option nicht verwandt wird, aber das Verzeichnis mkosi.tools/ im lokalen Verzeichnis
gefunden wird, wird es automatisch für diesen Zweck mit dem Wurzelverzeichnis als Ziel verwandt.

Beachten Sie, dass Programme, die in einem der mit ExtraSearchPaths= konfigurierten Pfade gefunden
werden, mit /usr/ vom Werkzeugbaum anstatt vom Wirt ausgeführt werden. Falls die Distribution des
Hauptsystems oder die Veröffentlichung nicht auf die Werkzeugbaum-Distribution bzw.
-Veröffentlichung passt, könnte dies zu Fehlern führen, wenn Programme aus einem der zusätzlichen
Suchpfad ausgeführt werden.

Falls auf default gesetzt, wird mkosi automatisch ein zusätzliches Werkzeugbaumabbild hinzufügen
und es als Werkzeugbaum verwenden.

Die nachfolgende Tabelle zeigt, für welche Distributionen Standard-Werkzeugbaumpakete definiert
sind und welche Pakete in diese Standardwerkzeugbäume aufgenommen werden:

Fedora CentOS Debian Kali Ubuntu Arch openSUSE
────────────────────────────────────────────────────────────────────────────────────────────
acl ✓ ✓ ✓ ✓ ✓ ✓ ✓
apt ✓ ✓ ✓ ✓ ✓ ✓
archlinux-keyring ✓ ✓ ✓ ✓ ✓ ✓
attr ✓ ✓ ✓ ✓ ✓ ✓ ✓
bash ✓ ✓ ✓ ✓ ✓ ✓ ✓
btrfs-progs ✓ ✓ ✓ ✓ ✓ ✓ ✓
ca-certificates ✓ ✓ ✓ ✓ ✓ ✓ ✓
coreutils ✓ ✓ ✓ ✓ ✓ ✓ ✓
cpio ✓ ✓ ✓ ✓ ✓ ✓ ✓
createrepo_c ✓ ✓ ✓ ✓ ✓ ✓ ✓
curl ✓ ✓ ✓ ✓ ✓ ✓ ✓
debian-keyring ✓ ✓ ✓ ✓ ✓ ✓
diffutils ✓ ✓ ✓ ✓ ✓ ✓ ✓
distribution-gpg-keys ✓ ✓ ✓ ✓ ✓ ✓
dnf ✓ ✓ ✓ ✓ ✓ ✓ ✓
dosfstools ✓ ✓ ✓ ✓ ✓ ✓ ✓
e2fsprogs ✓ ✓ ✓ ✓ ✓ ✓ ✓
edk2-ovmf ✓ ✓ ✓ ✓ ✓ ✓ ✓
erofs-utils ✓ ✓ ✓ ✓ ✓ ✓ ✓
findutils ✓ ✓ ✓ ✓ ✓ ✓ ✓
git ✓ ✓ ✓ ✓ ✓ ✓ ✓
grep ✓ ✓ ✓ ✓ ✓ ✓ ✓
grub-tools ✓ ✓ ✓ ✓ ✓ ✓
jq ✓ ✓ ✓ ✓ ✓ ✓ ✓
kali-archive-keyring ✓
kmod ✓ ✓ ✓ ✓ ✓ ✓ ✓
less ✓ ✓ ✓ ✓ ✓ ✓ ✓
mtools ✓ ✓ ✓ ✓ ✓ ✓ ✓
nano ✓ ✓ ✓ ✓ ✓ ✓ ✓
opensc ✓ ✓ ✓ ✓ ✓ ✓ ✓
openssh ✓ ✓ ✓ ✓ ✓ ✓ ✓
openssl ✓ ✓ ✓ ✓ ✓ ✓ ✓
pkcs11-provider ✓ ✓ ✓ ✓ ✓ ✓ ✓
perf ✓ ✓ ✓ ✓ ✓ ✓
sed ✓ ✓ ✓ ✓ ✓ ✓ ✓
pacman ✓ ✓ ✓ ✓ ✓ ✓
policycoreutils ✓ ✓ ✓ ✓ ✓ ✓
qemu ✓ ✓ ✓ ✓ ✓ ✓ ✓
sbsigntools ✓ ✓ ✓ ✓ ✓ ✓ ✓
socat ✓ ✓ ✓ ✓ ✓ ✓ ✓
squashfs-tools ✓ ✓ ✓ ✓ ✓ ✓ ✓
strace ✓ ✓ ✓ ✓ ✓ ✓ ✓
swtpm ✓ ✓ ✓ ✓ ✓ ✓ ✓
systemd ✓ ✓ ✓ ✓ ✓ ✓ ✓
ukify ✓ ✓ ✓ ✓ ✓ ✓ ✓
tar ✓ ✓ ✓ ✓ ✓ ✓ ✓
ubuntu-keyring ✓ ✓ ✓ ✓ ✓ ✓
util-linux ✓ ✓ ✓ ✓ ✓ ✓ ✓
virtiofsd ✓ ✓ ✓ ✓ ✓ ✓ ✓
virt-firmware ✓ ✓ ✓ ✓ ✓ ✓ ✓
xfsprogs ✓ ✓ ✓ ✓ ✓ ✓ ✓
xz ✓ ✓ ✓ ✓ ✓ ✓ ✓
zstd ✓ ✓ ✓ ✓ ✓ ✓ ✓
zypper ✓ ✓ ✓ ✓ ✓

ToolsTreeDistribution=, --tools-tree-distribution=
Setzt die für den Standard-Befehlsbaum zu verwendende Distribution. Standardmäßig die Distribution
des Hauptsystems, außer für Ubuntu, wo die Vorgabe Debian und RHEL, CentOS, Alma und Rocky, wo die
Vorgabe Fedora ist, oder custom, falls die Distribution des Hauptsystems keine unterstützte
Distribution ist.

ToolsTreeRelease=, --tools-tree-release=
Setzt die für den Standard-Werkzeugbaum zu verwendende Distributionsveröffentlichung.
Standardmäßig wird die in mkosi fest eingebaute Standard-Veröffentlichung für die Distribution
verwandt.

ToolsTreeMirror=, --tools-tree-mirror=
Setzt den für den Standardwerkzeugbaum zu verwendenden Spiegel. Standardmäßig wird der
Standardspiegel für die Werkzeugbaumdistribution verwandt.

ToolsTreeRepositories=, --tools-tree-repository
Identisch zu Repositories=, aber für den Standardwerkzeugbaum.

ToolsTreeSandboxTrees=, --tools-tree-sandbox-tree
Identisch zu SandboxTrees=, aber für den Standardwerkzeugbaum.

ToolsTreePackages=, --tools-tree-package=
Zusätzliche Pakete, die in den Standardwerkzeugbaum installiert werden sollen. Akzeptiert eine
Kommata-getrennte Liste von Paketspezifikationen. Diese Option kann mehrfach verwandt werden, dann
werden die angegebenen Paketlisten kombiniert.

ToolsTreePackageDirectories=, --tools-tree-package-directory=
Identisch zu PackageDirectories=, aber für den Standardwerkzeugbaum.

ToolsTreeCertificates=, --tools-tree-certificates=
Legt fest, ob Zertifikate und Schlüssel aus dem Werkzeugbaum verwandt werden sollen. Standardmäßig
aktiviert. Falls aktiviert, werden /etc/pki, /etc/ssl, /etc/ca-certificates und
/var/lib/ca-certificates von dem Werkzeugbaum verwandt. Andernfalls werden diese Verzeichnisse aus
dem Wirtsystem aufgenommen.

ExtraSearchPaths=, --extra-search-path=
Liste von durch Doppelpunkt getrennten Pfaden, in denen vor dem regulären Suchpfad $PATH nach
Werkzeugen gesucht wird.

Incremental=, --incremental=, -i
Akzeptiert entweder strict oder einen logischen Wert als Argument. Aktiviert den inkrementellen
Bau-Modus. In diesem Modus wird direkt nach der Installation aller Betriebssystempakete und der
Ausführung der Vorbereitungsskripte, aber bevor die Skripte mkosi.build (und alles was danach
passiert) aufgerufen werden, eine Kopie des Betriebssystemabbilds erstellt. Bei nachfolgenden
Aufrufen von mkosi mit dem Schalter -i kann dieses zwischengespeicherte Abbild verwandt werden, um
die Betriebssystempaketinstallation zu überspringen und daher dramatisch die Zeitdauer
wiederholter Bauten reduzieren. Beachten Sie, dass es zwar eine rudimentäre
Zwischenspeicher-Entwertung gibt, diese aber weit von perfekt ist. Um einen Neubau eines
zwischengespeicherten Abbilds zu erzwingen, kombinieren Sie -i mit -ff um sicherzustellen, dass
das zwischengespeicherte Abbild zuerst entfernt und dann neu erstellt wird.

Falls auf strict gesetzt, schlägt der Bau fehl, falls kein vorher gebautes und
zwischengespeichertes Abbild existiert.

CacheOnly=, --cache-only=
Akzeptiert entweder auto, metadata, always oder never. Standardmäßig auto. Falls always, wird der
Paketverwalter angewiesen, das Netzwerk nicht zu kontaktieren. Dies stellt eine minimale
Reproduzierbarkeitsstufe bereit, solang der Paketzwischenspeicher bereits vollständig gefüllt ist.
Falls auf metadata gesetzt kann der Paketverwalter weiterhin Pakete herunterladen, aber nicht die
Metadaten des Depots synchronisieren. Falls auf auto gesetzt werden während des Baus die
Paketmetadaten synchronisiert (außer es liegt ein zwischengespeichertes Abbild vor - siehe
Incremental=) und die Pakete heruntergeladen. Falls never, werden die Depot-Metadaten immer
synchronisiert und Pakete können während des Baus heruntergeladen werden.

SandboxTrees=, --sandbox-tree=
Akzeptiert eine Kommata-getrennte Liste von Doppelpunkt-getrennten Pfadpaaren. Der erste Pfad
jedes Paares bezieht sich auf ein Verzeichnis, das in die Mkosi-Sandbox vor Ausführung des
Werkzeugs kopiert werden soll. Falls das Verzeichnis mkosi.sandbox/ in dem lokalen Verzeichnis
gefunden wird, wird es auch für diesen Zweck mit dem Wurzelverzeichnis als Ziel verwandt (siehe
auch den nachfolgenden Abschnitt Dateien).

mkosi wird nach der Paketverwalterkonfiguration und zugehörigen Dateien in den konfigurierten
Sandbox-Bäumen suchen. Falls nicht anders festgelegt, wird es die Konfigurationsdateien aus ihren
kanonischen Orten in /usr oder /etc in den Sandbox-Bäumen verwenden. Beispielsweise wird es nach
/etc/dnf/dnf.conf in Sandbox-Bäumen suchen, falls dnf zur Installation von Paketen verwandt wird.

WorkspaceDirectory=, --workspace-directory=
Pfad zu einem Verzeichnis, in dem temporär während eines Abbild-Baus benötigte Daten gespeichert
werden. Dieses Verzeichnis sollte über genug Platz verfügen, das vollständige Betriebssystemabbild
zu speichern, obwohl in den meisten Modi der tatsächlich verwandte Plattenplatz kleiner ist. Falls
nicht angegeben, wird ein Unterverzeichnis von $XDG_CACHE_HOME (falls gesetzt), $HOME/.cache
(falls gesetzt) oder /var/tmp verwandt.

Nach jedem Bau werden die Daten in diesem Verzeichnis automatisch entfernt. Es ist sicher, die
Inhalte dieses Verzeichnisses manuell zu entfernen, falls der Aufruf von mkosi anormal abgebrochen
wurde (beispielsweise aufgrund eines Neustarts oder Stromausfalls).

CacheDirectory=, --cache-directory=
Akzeptiert einen Pfad zu einem Verzeichnis, das als inkrementelles Zwischenspeicherverzeichnis für
die erstellten inkrementellen Abbilder verwandt wird, wenn die Option Incremental= aktiviert ist.
Falls diese Option nicht verwandt wird, aber das Verzeichnis mkosi.cache/ im lokalen Verzeichnis
gefunden wird, wird es automatisch für diesen Zweck verwandt.

PackageCacheDirectory=, --package-cache-dir
Akzeptiert einen Pfad zu einem Verzeichnis, das als Paketzwischenspeicherverzeichnis für den
eingesetzten Distributionspaketverwalter verwandt wird. Falls nicht gesetzt, aber im lokalen
Verzeichnis ein Verzeichnis mkosi.pkgcache/ gefunden wird, wird dies automatisch für diesen Zweck
verwandt, andernfalls wird ein geeignetes Verzeichnis in dem Home-Verzeichnis des Benutzers oder
des Systems verwandt.

BuildDirectory=, --build-directory=
Akzeptiert einen Pfad zu einem Verzeichnis, das als Bauverzeichnis für Bausysteme verwandt werden
soll, die Bauen in separaten Verzeichnissen unterstützen (wie Meson). Das auf diese Art verwandte
Verzeichnis wird zwischen mehreren Bauten gemeinsam benutzt und ermöglicht es dem Bausystem,
Artefakte (wie Objektdateien, Programmen, …), die bei vorherigen Aufrufen erzeugt wurden,
wiederzuverwenden. Die Bauskripte können den Pfad zu diesem Verzeichnis in der Umgebungsvariable
$BUILDDIR finden. Dieses Verzeichnis wird in das Wurzelverzeichnis des Abbildes eingehängt, wenn
mkosi-chroot während der Ausführung der Bauskripte aufgerufen wird. Falls diese Option nicht
verwandt wird, aber das Verzeichnis mkosi.builddir/ im lokalen Verzeichnis gefunden wird, wird es
automatisch für diesen Zweck verwandt (siehe auch den nachfolgenden Abschnitt Files).

UseSubvolumes=, --use-subvolumes=
Akzeptiert einen logischen Wert oder auto. Aktiviert oder deaktiviert die Verwendung von
btrfs(5)-Teildatenträgern für Verzeichnisbaumausgaben. Falls aktiviert wird mkosi das
Wurzelverzeichnis als btrfs(5)-Teildatenträger erstellen und wo möglich
btrfs(5)-Teildatenträgerschnappschüsse verwenden, um grundlegende oder zwischengespeicherte Bäume
zu kopieren, was viel schneller als rekursive Kopieren ist. Falls explizit aktiviert und btrfs(8)
nicht installiert ist oder Teildatenträger nicht erstellt werden können, wird ein Fehler
ausgelöst. Falls auto, werden ein fehlendes btrfs(8) oder Fehlschläge beim Erstellen von
Teildatenträgern ignoriert.

RepartOffline=, --repart-offline=
Legt fest, ob Plattenabbilder mittels Loopback-Geräten gebaut werden. Standardmäßig aktiviert.
Wenn aktiviert, wird systemd-repart(8) keine Loopback-Geräte zum Bau von Plattenabbildern
verwenden. Wenn deaktiviert, wird systemd-repart(8) immer Loopback-Geräte zum Bau von
Plattenabbildern verwenden.

Beachten Sie, dass mkosi nicht unprivilegiert ausgeführt werden kann, wenn RepartOffline=no
verwandt wird und der Abbild-Bau als Benutzer root außerhalb von Containern und mit auf dem
Wirtsystem verfügbaren Loopack-Geräten erfolgt.

Es gibt derzeit zwei bekannte Szenarien, bei denen RepartOffline=no verwandt werden muss. Das
erste ist der Einsatz von Subvolumes= in einer Repart-Partitionsdefinitionsdatei, da
Teildatenträger nicht ohne Loopback-Geräte erstellt werden können. Das zweite ist bei der
Erstellung eines Systems mit SELinux und einer XFS-Wurzelpartition. Da mkfs.xfs(8) die Befüllung
eines XFS-Dateisystems mit erweiterten Attributen nicht erlaubt, müssen Loopback-Geräte verwandt
werden um sicherzustellen, dass erweiterte SELinux-Attribute im erstellten XFS-Dateisystem landen.

History=, --history=
Akzeptiert einen logischen Wert. Falls aktiviert, wird mkosi Informationen über den jüngsten Bau
in das Unterverzeichnis .mkosi-private (unter dem Verzeichnis, in dem es aufgerufen wurde)
schreiben. Diese Informationen werden dann benutzt, um die Konfiguration des jüngsten Baus
wiederherzustellen, wenn ein Unterbefehl ohne --force ausgeführt wird, der den Bau benötigt.

Beispiel für den Nutzen dieses Vorgehens: Sie führen mkosi -O mein-angepasstes-Ausgabeverzeichnis
-f gefolgt von mkosi vm aus. Dann wird mkosi mit der Information fehlschlagen, dass das Abbild
noch nicht gebaut wurde. Falls Sie mkosi -O mein-angepasstes-Ausgabeverzeichnis --history=yes -f
gefolgt von mkosi vm ausführen, wird es das im vorhergehenden Schritt gebaute Abbild wie erwartet
starten.

BuildSources=, --build-sources=
Akzeptiert eine Kommata-getrennte Liste von Doppelpunkt-getrennten Pfadpaaren. Der erste Pfad
jedes Paars bezieht sich auf ein Verzeichnis, das vom Wirtsystem eingehängt werden soll. Der
zweite Pfad jedes Paars bezieht sich auf das Verzeichnis, wohin das Quellverzeichnis beim
Ausführen der Skripte eingehängt werden soll. Jedem Zielpfad wird /work/src vorangestellt und alle
Bauquellen werden vor dem Einhängen lexikographisch nach ihrem Ziel sortiert, so dass die Pfade
auf der obersten Ebene zuerst eingehängt werden. Falls nicht explizit konfiguriert, wird das
aktuelle Arbeitsverzeichnis nach /work/src eingehängt.

BuildSourcesEphemeral=, --build-sources-ephemeral=
Akzeptiert einen logischen oder den besonderen Wert buildcache. Standardmäßig deaktiviert.
Konfiguriert, ob Änderungen an Quellverzeichnissen, dem Arbeitsverzeichnis und dem mit
BuildSources= konfigurierten Verzeichnis dauerhaft sind. Falls aktiviert, werden nach der
Ausführung aller Skripte eines bestimmten Typs (außer Synchronisationsskripte) alle
Quellverzeichnisse auf ihren Originalzustand zurückgesetzt.

💥💣💥 Falls auf buildcache gesetzt wird die Überlagerung nicht bei der Ausführung von Bauskripten
verworfen, sondern im Bauverzeichnis, konfiguriert mittels BuildDirectory=, gespeichert und bei
nachfolgenden Läufen wiederverwandt. Die Überlagerung wird weiterhin für alle anderen Skripte
verworfen. Diese Option kann für ein fortgeschritteneres Zwischenspeichern bei Bauten verwandt
werden, kann aber zu unerwarteten Zuständen des Bauverzeichnisses führen. Bei der Verwendung
dieser Option muss ein Bauverzeichnis konfiguriert sein. 💥💣💥

Environment=, --environment=
Fügt Variablen zu der Umgebung hinzu, mit der Paketverwalter und die
Vorbereitungs-/Bau-/Postinstall-/Finalisierungsskripte ausgeführt werden. Akzeptiert eine
Leerzeichen-getrennte Liste von Variablenzuweisungen oder nur Variablennamen. In letzterem Falle
werden die Werte dieser Variablen von der Umgebung, aus der mkosi heraus aufgerufen wurde,
durchgereicht. Diese Option kann mehr als einmal angegeben werden. Dann werden alle aufgeführten
Variablen gesetzt. Falls die gleiche Variable zweimal gesetzt wird, setzt letztere Einstellung die
vorhergehende außer Kraft.

EnvironmentFiles=, --env-file=
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Dateien, die Umgebungsvariablendefinitionen
enthalten, die der Skript-Umgebung hinzugefügt werden sollen. Verwendet mkosi.env, falls es im
lokalen Verzeichnis gefunden wird. Diese Variablen werden zuerst aus mkosi.env, falls es
existiert, dann aus den angegebenen Dateien und dann aus den Einstellungen Environment= gelesen.

WithTests=, --without-tests, -T
Falls auf »false« gesetzt (oder wenn die Befehlszeilenoption verwandt wird), wird die
Umgebungsvariable $WITH_TESTS auf 0 gesetzt, wenn die Skripte mkosi.build aufgerufen werden. Dies
ist dafür gedacht, von Bauskripten zur Umgehung von Unit- oder Integrationstest, die normalerweise
während des Quellbauprozesses aufgerufen werden, verwandt zu werden. Beachten Sie, dass diese
Option nur wirksam wird, wenn die mkosi.build-Bauskripte sie respektieren.

WithNetwork=, --with-network=
Wenn »true«, aktiviert Netzwerkverbindungen während der von mkosi.build aufgerufenen Bauskripte.
Standardmäßig werden die Bauskripte mit abgeschaltetem Netzwerk ausgeführt. Die Umgebungsvariable
$WITH_NETWORK wird an die mkosi.build-Bauskripte übergeben um anzuzeigen, ob der Bau mit Netzwerk
erfolgt.

ProxyUrl=, --proxy-url=
Konfiguriert einen Proxy, der für alle ausgehenden Netzwerkverbindungen verwandt werden soll.
Verschiedene Werkzeuge, die mkosi aufruft und für die der Proxy konfiguriert werden kann, sind für
diesen Proxy konfiguriert. mkosi setzt auch verschiedene gut bekannte Umgebungsvariablen, um den
Proxy zur Verwendung mit allen Programmen festzulegen, die es aufruft und die Internetzugriff
benötigen könnten.

ProxyExclude=, --proxy-exclude=
Konfiguriert Rechnernamen, für die Anfragen nicht durch den Proxy gehen sollen. Akzeptiert eine
Kommata-getrennte Liste von Rechnernamen.

ProxyPeerCertificate=, --proxy-peer-certificate=
Konfiguriert eine Datei, die Zertifikate zur Überprüfung des Proxys enthält. Standardmäßig ist das
der systemweite Zertifikaktspeicher.

Derzeit wird das Setzen eines Proxy-Gegenstellen-Zertifikats nur unterstützt, wenn dnf oder dnf5
zum Bau des Abbilds verwandt werden.

ProxyClientCertificate=, --proxy-client-certificate=
Konfiguriert eine Datei, die das zur Authentifizierung des Clients mit dem Proxy verwandte
Zertifikat enthält.

Derzeit wird das Setzen eines Proxy-Client-Zertifikats nur unterstützt, wenn dnf oder dnf5 zum Bau
des Abbilds verwandt werden.

ProxyClientKey=, --proxy-client-key=
Konfiguriert eine Datei, die den privaten Schlüssel für die Authentifizierung des Clients mit dem
Proxy enthält. Die Vorgabe ist das Proxy-Client-Zertifikat, falls eines bereitgestellt wurde.

Derzeit wird das Setzen eines Proxy-Clients nur unterstützt, wenn dnf oder dnf5 zum Bau des
Abbildes verwandt wird.

Abschnitt [Runtime] (früher als Abschnitt [Host] bekannt)
NSpawnSettings=, --settings=
Legt eine Einstellungsdatei .nspawn für systemd-nspawn(1) zur Verwendung in den Unterbefehlen boot
und shell und zum Ablegen neben der erstellten Abbilddatei fest. Dies ist zur Konfiguration der
Umgebung systemd-nspawn(1) bei der Ausführung nützlich. Falls diese Einstellung nicht verwandt
wird, aber eine Datei mkosi.nspawn im lokalen Verzeichnis gefunden wird, wird diese automatisch
für diesen Zweck verwandt.

VirtualMachineMonitor=, --vmm=
Konfiguriert den zu verwendenden Monitor für virtuelle Maschinen. Akzeptiert entweder qemu oder
vmspawn. Standardmäßig qemu.

Falls auf qemu gesetzt, wird das Abbild mit qemu gestartet. Die meisten Ausgabeformate können mit
qemu gestartet werden. Alle nach dem Unterbefehl angegebenen Argumente werden an den Aufruf von
qemu angehängt und als zusätzliche qemu-Befehlszeilenargumente interpretiert.

Falls auf vmspawn gesetzt, wird systemd-vmspawn(1) zum Hochfahren des Abbildes benutzt. vmspawn
unterstützt nur platten- und verzeichnisartige Abbilder. Alle nach dem Unterbefehl angegebenen
Argumente werden an den Aufruf von systemd-vmspawn(1) angehängt und als zusätzliche
Vmspawn-Optionen und Kernelbefehlszeilenargumente interpretiert.

Console=, --console=
Konfiguriert, wie die Konsole der VM eingerichtet werden soll. Akzeptiert entweder interactive,
read-only, native oder gui. Standardmäßig interactive. interactive stellt eine interaktive
Terminalschnittstelle zur VM bereit. read-only ist ähnlich, aber streng schreibgeschützt, d.h. sie
akzeptiert keine Eingabe vom Benutzer. native stellt auch eine TTY-basierte Schnittstelle bereit,
verwendet aber die in qemu eingebaute Implementierung (dadurch ist der Monitor von qemu
verfügbar). gui zeigt die graphische UI von qemu qemu.

CPUs=, --cpus=
Konfiguriert die Anzahl der CPU-Kerne, die dem Gast beim Starten einer virtuellen Maschine
zugewiesen werden sollen. Standardmäßig 2.

Wird dies auf 0 gesetzt, wird die Anzahl der für den mkosi-Prozess verfügbaren CPUs verwandt.

RAM=, --ram=
Konfiguriert die Speichermenge, die einem Gast beim Starten einer virtuellen Maschine zugewiesen
wird. Standardmäßig 2G.

KVM=, --kvm=
Konfiguriert, ob KVM-Beschleunigung beim Starten einer virtuellen Maschine verwandt werden soll.
Akzeptiert einen logischen Wert oder auto. Standardmäßig auto.

Vsock=, --vsock=
Konfiguriert, ob ein Vsock beim Starten einer virtuellen Maschine vorgehalten werden soll.
Akzeptiert einen logischen Wert oder auto. Standardmäßig auto.

VsockConnectionId=, vsock-cid=
Konfiguriert die beim Starten einer virtuellen Maschine zu verwendende Verbindungskennung.
Akzeptiert eine Zahl im Intervall [3, 0xFFFFFFFF) oder hash oder auto. Standardmäßig auto. Wenn
auf hash gesetzt wird die Verbindungskennung von dem vollständigen Pfad zum Abbild abgeleitet.
Wenn auf auto gesetzt, wird mkosi versuchen, automatisch eine freie Verbindungskennung zu finden.
Andernfalls wird die bereitgestellte Nummer unverändert verwandt.

TPM=, --tpm=
Konfiguriert, ob ein virtueller TPM beim Starten einer virtuellen Maschine verwandt werden soll.
Akzeptiert einen logischen Wert oder auto. Standardmäßig auto.

CDROM=, --cdrom=
Konfiguriert, ob das Abbild als CD-ROM-Laufwerk beim Start einer virtuellen Maschine angehängt
werden soll. Akzeptiert einen logischen Wert. Standardmäßig no.

Removable=, --removable=
Konfiguriert, ob das Abbild als entfernbares Gerät beim Start einer virtuellen Maschine angehängt
werden soll. Akzeptiert einen logischen Wert. Standardmäßig no.

Firmware=, --firmware=
Konfiguriert die zu verwendende Firmware. Akzeptiert entweder uefi, uefi-secure-boot, bios, linux
oder auto. Standardmäßig auto. Falls auf uefi gesetzt, wird die OVMF-Firmware ohne Unterstützung
für sicheren Systemstart verwandt. Falls auf uefi-secure-boot gesetzt, wird die OVMF-Firmware mit
Unterstützung für sicheren Systemstart verwandt. Falls auf bios gesetzt, wird die
Standard-SeaBIOS-Firmware verwandt. Falls auf linux gesetzt, wird der direkte Kernelstart
verwandt. Siehe die Option Linux= für weitere Details darüber, welches Kernelabbild mit direktem
Kernelsystemstart verwandt wird. Falls auf auto gesetzt wird falls möglich uefi-secure-boot und
ansonsten linux verwandt.

FirmwareVariables=, --firmware-variables=
Konfiguriert den Pfad zu den zu verwendenden Firmwarevariablendateien der virtuellen Maschine.
Derzeit wird diese Option nur berücksichtigt, wenn die Firmware uefi oder uefi-secure-boot
verwandt wird. Falls nicht angegeben, wird mkosi nach der Standard-Variablen-Datei suchen und
diese stattdessen verwenden.

Falls auf microsoft gesetzt, wird eine Firmwarevariablendatei mit bereits registriertem sicheren
Systemstartzertifikat von Microsoft verwandt.

Falls auf microsoft-mok gesetzt wird eine bereits registrierte Firmware-Variablen-Datei mit dem
»Microsoft secure boot«-Zertifikaten durch eine MokList-Variable erweitert, die das Zertifikat für
den sicheren Systemstart aus SecureBootCertificate= enthält. Dies ist für die gemeinsame
Verwendung von durch die Distribution signierten Shim-Programmen und lokal signierten
EFI-Programmen gedacht.

Falls auf custom gesetzt, wird ein Zertifikat für sicheren Systemstart von SecureBootCertificate=
in die Standard-Firmwarevariablendatei registriert.

virt-fw-vars aus dem Projekt virt-firmware kann zum Anpassen der OVMF-Variablendateien verwandt
werden.

Linux=, --linux=
Setzt das für direkten Kernelsystemstart in qemu zu verwendende Kernelabbild. Falls nicht
angegeben wird mkosi den über die Befehlszeile bereitgestellten Kernel (Option -kernel) oder den
neusten Kernel, der im Abbild installiert wurde, verwenden (oder fehlschlagen, falls kein Kernel
im Abbild installiert wurde).

Beachten Sie, dass bei der Verwendung des Ausgabeformats cpio der direkte Kernelsystemstart
unabhängig von der konfigurierten Firmware verwandt wird. Abhängig von der konfigurierten Firmware
könnte qemu den Kernel selbst starten oder die konfigurierte Firmware verwenden.

Drives=, --drive=
Fügt ein Laufwerk hinzu. Akzeptiert eine Doppelpunkt-getrennte Zeichenkette im Format
<Kennung>:<Größe>[:<Verzeichnis>[:<Optionen>[:<Dateikennung>]]]. Kennung legt die dem Laufwerk
zugeordnete Kennung fest. Diese kann als die Eigenschaft drive= in verschiedenen qemu-Geräten
verwandt werden. Größe legt die Größe des Laufwerks fest. Dies akzeptiert eine Größe in Byte.
Zusätzliche können die Endungen K, M und G zur Festlegung einer Größe in Kilobyte, Megabyte bzw.
Gigabyte verwandt werden. Verzeichnis legt optional das Verzeichnis fest, in dem das dem Laufwerk
zugrunde liegende Verzeichnis erstellt werden soll. Optionen legen optional zusätzliche, durch
Kommata getrennte Eigenschaften fest, die unverändert an die Option -drive von qemu übergeben
werden. Dateikennung legt die Kennung der Datei fest, die dem Laufwerk zugrunde liegt. Laufwerke
mit der gleichen Dateikennung haben eine gemeinsame zugrundeliegende Datei. Das Verzeichnis und
die Größe der Datei wird aus dem ersten Laufwerk mit der angegebenen Dateikennung bestimmt.

Beispielhafte Verwendung:

[Runtime]
Drives=btrfs:10G
ext4:20G
QemuArgs=-device nvme,serial=btrfs,drive=btrfs
-device nvme,serial=ext4,drive=ext4

QemuArgs=
Leerzeichen-begrenzte Liste von zusätzlich beim Aufruf von qemu zu übergebenen Argumenten.

Ephemeral=, --ephemeral
Bei der Verwendung mit den Unterbefehlen shell, boot oder vm führt diese Option den angegebenen
Unterbefehl auf einem temporären Schnappschuss des Ausgabeabbilds aus, das sofort entfernt wird,
wenn der Container sich beendet. Die Vornahme temporärer Schnappschüsse ist auf Dateisystemen
effizienter, die Reflinks nativ unterstützen (btrfs(5) oder xfs(5)), als auf traditionellen, bei
denen das nicht der Fall ist (ext4(5)).

Credentials=, --credential=
Setzt die an systemd-nspawn(1) bzw. der virtuellen Maschine zu übergebenen Zugangsberechtigungen,
wenn mkosi shell/boot oder mkosi vm verwandt wird. Diese Option akzeptiert eine Leerzeichen
getrennte Liste von Werten, die entweder Schlüssel=Wert-Paare oder Pfade sein können. Falls ein
Pfad bereitgestellt wird, wird der Zugangsberechtigungsname der Name der Datei sein, wenn der Pfad
eine Datei ist. Falls die Datei ausführbar ist, wird die Zugangsberechtigung die Ausgabe nach
Ausführen der Datei sein. Andernfalls wird der Wert der Zugangsberechtigung der Inhalt der Datei
sein. Falls der Pfad ein Verzeichnis ist, gilt die gleiche Logik für jede Datei in dem
Verzeichnis.

Beachten Sie, dass die Werte nur als Pfade behandelt werden, falls sie den Begrenzer (=) nicht
enthalten.

KernelCommandLineExtra=, --kernel-command-line-extra=
Setzt zusätzliche Kernelbefehlszeilenargumente, die zur Laufzeit beim Starten des Abbilds an die
Kernelbefehlszeile angehängt werden. Beim Systemstart in einen Container werden diese als
zusätzliche Argumente an systemd(1) übergeben. Beim Systemstart in eine VM werden diese mittels
der SMBIOS-OEM-Zeichenkette io.systemd.stub.kernel-cmdline-extra an die Kernelbefehlszeile
angehängt. Dies wird von systemd-boot(7)/systemd-stub(7) erst ab Version v254 aufgenommen.

RuntimeTrees=, --runtime-tree=
Akzeptiert eine Doppelpunkt-getrennte Liste von Pfaden. Der erste Pfad bezieht sich auf ein in
jede von Mkosi zu startende Maschine (Container oder VM) einzuhängendes Verzeichnis. Der zweite
Pfad bezieht sich auf das Zielverzeichnis innerhalb der Maschine. Falls der zweite Pfad nicht
bereitgestellt wird, wird das Verzeichnis unter /root/src in der Maschine eingehängt. Falls der
zweite Pfad relativ ist, wird er relativ zu /root/src in der Maschine interpretiert.

Für jedes eingehängte Verzeichnis wird die UID und GID des Benutzers, der Mkosi ausführt, auf den
Benutzer root in der Maschine abgebildet. Dies bedeutet, dass alle Dateien und Verzeichnisse so
erscheinen, als ob sie root in der Maschine gehören würden und alle neuen Dateien und
Verzeichnisse, die von root in der Maschine in diesen Verzeichnissen erstellt werden, gehören auf
der Wirtmaschine dem Benutzer, der Mkosi ausführt.

Beachten Sie, dass bei der Verwendung von mkosi vm mit dieser Funktionalität Systemd v254 oder
neuer im Abbild installiert sein muss.

RuntimeSize=, --runtime-size=
Falls angegeben werden Plattenabbilder bis zu der angegebenen Größe vergrößert, wenn sie mit mkosi
boot oder mkosi vm gestartet werden. Akzeptiert eine Größe in Byte. Zusätzlich können die Endungen
K, M und G verwandt werden, um eine Größe in Kilobyte, Megabyte bzw. Gigabyte festzulegen.

RuntimeScratch=, --runtime-scratch=
Akzeptiert einen logischen Wert oder auto. Legt fest, ob ein zusätzlicher Arbeitsbereich unter
/var/tmp eingehängt werden soll. Falls aktiviert, wird ein praktisch unbegrenzter Arbeitsbereich
unter /var/tmp zur Verfügung gestellt, wenn das Abbild mit mkosi vm, mkosi boot oder mkosi shell
gestartet wird.

Beachten Sie, dass bei der Verwendung von mkosi vm mit dieser Funktionalität Systemd v254 oder
neuer im Abbild installiert sein muss.

RuntimeNetwork=, --runtime-network=
Akzeptiert entweder user, interface oder none. Standardmäßig user. Legt das beim Systemstart
einzurichtende Netzwerk fest. user richtet Benutzermodus-Vernetzung ein. interface richtet eine
virtuelle Netzwerkverbindung zwischen dem Wirtrechner und dem Abbild ein. Dies übersetzt sich in
eine Veth-Schnittstelle für mkosi shell und mkosi boot und eine Tap-Schnittstelle für mkosi vm und
mkosi vmspawn.

Beachten Sie, dass bei der Verwendung von interface mkosi nicht automatisch die Schnittstelle des
Wirtsystems konfiguriert. Es wird erwartet, dass auf dem Wirtsystem eine hinreichend neue Version
von systemd-networkd(8) läuft, die automatisch die Schnittstelle des Links auf dem Wirtsystem
konfiguriert.

RuntimeBuildSources=, --runtime-build-sources=
Hängt die mit BuildSources= konfigurierten Bauquellen und das Bauverzeichnis (falls eines
konfiguriert wurde) an die gleichen Orte in /work ein, an der sie eingehängt würden, wenn das
Bauskript ausgeführt würde, wenn mkosi boot oder mkosi vm verwandt würde.

RuntimeHome=, --runtime-home=
Hängt das aktuelle Home-Verzeichnis, von dem aus mkosi läuft, bei der Verwendung von mkosi boot
oder mkosi vm unter /root ein.

UnitProperties=, --unit-property=
Konfiguriert Systemd-Unit-Eigenschaften, die zu den zugewiesenen Systemd-Geltungsbereichen
hinzugewiesen werden sollen, wenn mkosi boot oder mkosi vm verwandt wird. Diese werden direkt an
die Optionen --property von systemd-nspawn(1) bzw. systemd-run(1) übergeben.

SshKey=, --ssh-key=
Pfad zu dem privaten X.509-Schlüssel im PEM-Format, der für die Verbindung zu einer mit mkosi vm
gestarteten virtuellen Maschine verwandt werden soll und die mittels des Befehls mkosi ssh
aktivierten Option Ssh= gebaut wurde. Falls nicht konfiguriert und mkosi.key im aktuellen
Arbeitsverzeichnis existiert, wird dies automatisch für diesen Zweck verwandt. Führen Sie mkosi
genkey aus, um automatisch einen Schlüssel in mkosi.key zu erstellen.

SshCertificate=, --ssh-certificate=
Pfad zu dem X.509-Zertifikat im PEM-Format zur Beistellung als öffentlicher SSH-Schlüssel in durch
mkosi vm gestarteten virtuellen Maschinen. Falls nicht konfiguriert und mkosi.crt im aktuellen
Arbeitsverzeichnis existiert, wird dies automatisch für diesen Zweck verwandt. Führen Sie mkosi
genkey aus, um automatisch ein Zertifikat in mkosi.crt zu erstellen.

Machine=, --machine=
Gibt den beim Starten der Maschine zu verwendenen Maschinennamen an. Kann auch als Referenz auf
ein bestimmtes Abbild beim Betreten mit SSH eines bestimmten Abbildes verwandt werden (z.B. mkosi
--image=meinAbbild ssh).

Beachten Sie, dass Ephemeral= aktiviert sein muss, um mehrere Instanzen des gleichen Abbildes zu
starten.

Register=, --register=
Akzeptiert einen logischen Wert oder auto. Legt fest, ob die VM/der Container mit
systemd-machined(8) registriert werden soll. Falls aktiviert, wird mkosi fehlschlagen, falls es
keine VM/keinen Container mit systemd-machined(8) registrieren kann. Falls deaktiviert, wird mkosi
die VM/den Container nicht mit systemd-machined(8) registrieren. Falls auto, wird mkosi die VM/den
Container mit systemd-machined(8) registrieren, falls dies verfügbar ist. Standardmäßig auto.

ForwardJournal=, --forward-journal=
Legt den Pfad fest, in dem Journalprotokolle aus Containern und virtuellen Maschinen
weitergeleitet werden sollen. Falls der Pfad die Erweiterung .journal enthält, wird dieser als
eine Datei interpretiert, in die das Journal geschrieben werden soll. Andernfalls wird der Pfad
als ein Verzeichnis interpretiert, in das das Journal geschrieben werden soll.

Beachten Sie, dass Systemd v256 oder neuer in der virtuellen Maschine benötigt wird, damit
Protokollweiterleitung funktioniert.

Beachten Sie, dass die Journal-Größe auf 4G beschränkt ist, falls ein Pfad mit der Erweiterung
.journal angegeben wird. Konfigurieren Sie ein Ausgabeverzeichnis anstelle einer Datei, falls ihre
Auslastung mehr als 4G an Journal-Daten erzeugt.

SysupdateDirectory=, --sysupdate-directory=
Pfad zu einem Verzeichnis, das Transferdefinitionsdateien von systemd-sysupdate(8) enthält, die
von mkosi sysupdate verwandt werden. Falls im lokalen Verzeichnis mkosi.sysupdate/ existiert, wird
es automatisch für diesen Zweck verwandt.

Beachten Sie, dass mkosi sysupdate systemd-sysupdate(8) mit --transfer-source= auf das
Ausgabeverzeichnis von mkosi gesetzt aufgerufen wird. Um dies in einer Transferdefinitionsdatei zu
verwenden, setzen Sie PathRelativeTo=explicit, damit die Einstellung Path= für die Transferquelle
relativ zum Ausgabeverzeichnis von mkosi interpretiert wird. Im Allgemeinen reicht es aus,
PathRelativeTo=explicit und Path=/ relativ zu der Transferquelle zu konfigurieren, damit das
Vergleichsmuster relativ zum Ausgabeverzeichnis von mkosi interpretiert wird.

Abschnitt [Match]
Profiles=
Übereinstimmung mit den konfigurierten Profilen.

Distribution=
Übereinstimmung mit der konfigurierten Distribution.

Release=
Übereinstimmung mit der konfigurierten Distributionsveröffentlichung. Falls diese Bedingung
verwandt wird und noch keine Distribution explizit konfiguriert wurde, wird die Distribution und
Veröffentlichung der Wirtmaschine verwandt.

Architecture=
Übereinstimmung mit der konfigurierten Architektur. Falls diese Bedingung verwandt wird und noch
keine Architektur explizit konfiguriert wurde, wird die Architektur des Wirtsystems verwandt.

Repositories=
Übereinstimmung mit Depots, die mit der Einstellung Repositories= aktiviert wurden. Akzeptiert
einen einzelnen Depotnamen.

PathExists=
Diese Bedingung ist erfüllt, wenn der angegebene Pfad existiert. Relative Pfade werden als relativ
zum Elternverzeichnis der Konfigurationsdatei interpretiert, aus der diese Bedingung ausgelesen
wurde.

ImageId=
Übereinstimmung mit der konfigurierten Abbildkennung, Globs werden unterstützt. Falls diese
Bedingung verwandt wird und noch keine Abbildkennung explizit konfiguriert wurde, schlägt diese
Bedingung fehl.

ImageVersion=
Übereinstimmung mit der konfigurierten Abbildversion. Den Abbildversionen können die Operatoren
==, !=, >=, <=, <, > für umfangreiche Versionsvergleiche entsprechend der
UAPI-Gruppenversionsformatspezifikation vorangestellt werden. Falls kein Operator vorangestellt
wird, wird standardmäßig der Gleichheits-Operator angenommen. Falls diese Bedingung verwandt wird
und noch keine Abbildversion explizit konfiguriert wurde, schlägt diese Bedingung fehl.

Bootable=
Übereinstimmung mit dem konfigurierten Wert für die Funktionalität Bootable=. Akzeptiert einen
logischen Wert oder auto.

Format=
Übereinstimmung mit dem konfigurierten Wert für die Option Format=. Akzeptiert ein Ausgabeformat
(siehe die Option Format=).

SystemdVersion=
Übereinstimmung mit der Systemd-Version des Wirtsystems (wie von systemctl --version berichtet).
Den Werten können die Operatoren ==, !=, >=, <=, <, > für umfangreiche Versionsvergleiche
entsprechend der UAPI-Gruppenversionsformatspezifikation vorangestellt werden. Falls kein Operator
vorangestellt wird, wird standardmäßig der Gleichheits-Operator angenommen.

BuildSources=
Akzeptiert einen Bauquellen-Zielpfad (siehe BuildSources=). Diese Übereinstimmung ist erfüllt,
falls eine der konfigurierten Bauquellen diesen Zielpfad verwendet. Enthält beispielsweise eine
Datei mkosi.conf Folgendes:

[Build]
BuildSources=../abc/qed:kernel

Und eine Ergänzung, die folgendes enthält:

[Match]
BuildSources=kernel

Die Ergänzung wird aufgenommen.

Alle an diese Einstellung übergebenen absoluten Pfade werden relativ zum aktuellen
Arbeitsverzeichnis interpretiert.

HostArchitecture=
Übereinstimmung mit der grundständigen Architektur des Wirtrechners. Siehe die Einstellung
Architecture= für eine Liste möglicher Werte.

ToolsTreeDistribution=
Übereinstimmung mit der konfigurierten Werkzeugbaum-Distribution.

ToolsTreeRelease=
Übereinstimmung mit der konfigurierten Werkzeugbaum-Veröffentlichung.

Environment=
Übereinstimmung mit einem bestimmten, mit Environment= konfigurierten Schlüssel/Wert-Paar. Falls
kein Wert bereitgestellt wird, wird überprüft, ob ein angegebener Schlüssel sich in der Umgebung
befindet, unabhängig von seinem Wert.

Diese Tabelle zeigt, welche Übereinstimmer Globs und mächtige Vergleiche unterstützen sowie den
Vorgabewert, gegen den überprüft wird, falls zum Zeitpunkt des Einlesens der Konfigurationsdatei kein
Wert bereitgestellt wurde:

Übereinstimmer Globs Umfangreiche Vorgabe
Vergleiche
─────────────────────────────────────────────────────────────────────────────────────────────
Profiles= no no Übereinstimmung schlägt fehl
Distribution= no no Übereinstimmung mit Distribution des
Wirtsystems
Release= no no Übereinstimmung mit Veröffentlichung des
Wirtsystems
Architecture= no no Übereinstimmung mit Architektur des
Wirtsystems
PathExists= no no n.Z.
ImageId= yes no Übereinstimmung schlägt fehl
ImageVersion= no yes Übereinstimmung schlägt fehl
Bootable= no no Übereinstimmung mit automatischer
Funktionalität
Format= no no Übereinstimmung mit Standardformat
SystemdVersion= no yes n.Z.
BuildSources= no no Übereinstimmung schlägt fehl
HostArchitecture= no no n.Z.
ToolsTreeDistribution= no no Übereinstimmung mit dem
Rückfall-Werkzeugbaum der Distribution
(siehe ToolsTreeDistribution= in [Build])
ToolsTreeRelease= no no Übereinstimmung mit
Standard-Werkzeugbaum-Veröffentlichung
Environment= no no n.Z.

[Include]
Include=, --include=, -I
Bindet zusätzliche Konfiguration aus der angegebenen Datei oder dem angegebenen Verzeichnis ein.
Die zusätzliche Konfiguration wird sofort nach Auswerten dieser Einstellung eingebunden, außer
wenn dies auf der Befehlszeile passiert - dann wird die zusätzliche Konfiguration nach Auswerten
aller Befehlszeilenargumente eingebunden.

Beachten Sie, dass jeder Pfad mit zusätzlicher Konfiguration nur einmal ausgewertet wird, selbst
wenn er mit Include= mehrfach eingebunden ist.

Die eingebauten Konfigurationen für die Vorgabe-Initrd, den Vorgabe-Werkzeugbaum und das
standardmäßige Virtuelle-Maschinenabbild von mkosi können eingebunden werden, indem der wörtliche
Wert mkosi-initrd, mkosi-tools bzw. mkosi-vm eingebunden wird.

Beachten Sie: Einbindenamen, die mit entweder dem wörtlichen mkosi- oder contrib- beginnen, sind
für die Verwendung durch mkosi selbst reserviert.

Abschnitt [Config]
Profiles=, --profile=
Wählt die angegebenen Profile aus. Ein Profil ist eine Konfigurationsdatei oder -verzeichnis in
dem Verzeichnis mkosi.profiles/. Die Konfigurationsdateien und -verzeichnisse werden nach der
Auswertung der Datei mkosi.conf, aber vor allen Ergänzungskonfigurationen in mkosi.conf.d/*.conf
eingebunden.

Dependencies=, --dependency=
Die Abbilder, von denen dieses Abbild abhängt, festgelegt als Kommata-getrennte Liste. Alle in
dieser Option konfigurierten Abbilder werden vor diesem Abbild gebaut.

Wird diese Einstellung für das »Hauptabbild« angegeben, legt sie fest, welche Unterabbilder gebaut
werden sollen. Siehe den Abschnitt Bau mehrerer Abbilder für weitere Informationen.

MinimumVersion=, --minimum-version=
Die minimale Version von mkosi, die zum Bau dieser Konfiguration benötigt wird. Falls mehrfach
angegeben, wird die höchste festgelegte Version verwandt.

ConfigureScripts=, --configure-script=
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als Konfigurationsskripte
für dieses Abbild verwandt werden. Siehe den Abschnitt Skripte für weitere Informationen.

PassEnvironment=, --pass-environment=
Akzeptiert eine Liste von durch Leerzeichen getrennten Umgebungsvariablennamen. Beim Bau mehrerer
Abbilder werden die aufgeführten Umgebungsvariablen an jedes einzelne Unterabbild übergeben, als
ob sie »universelle« Einstellungen wären. Siehe den Abschnitt Bau mehrerer Abbilder für weitere
Informationen.

Abschnitt [UKIProfile]
Der Abschnitt UKIProfile kann in UKI-Profil-Konfigurationsdateien verwandt werden, die an die Einstellung
UnifiedKernelImageProfiles= übergeben werden. Die folgenden Einstellungen können im Abschnitt UKIProfile
festgelegt werden:

Profile=
Der Inhalt des Abschnitts .profile des UKI-Profils. Akzeptiert eine Liste von
Schlüssel/Wert-Paaren, getrennt durch =. Der Schlüssel ID= muss angegeben werden. Siehe die
https://uapi-group.org/specifications/specs/unified_kernel_image/#multi-profile-ukis Spezifikation
für eine vollständige Liste aller möglichen Schlüssel.

Cmdline=
Zusätzliche Kernelbefehlszeilenoptionen für das UKI-Profil. Akzeptiert eine durch Leerzeichen
begrenzte Liste von zusätzlichen Kernelbefehlszeilenargumenten. Beachten Sie, dass der
letztendliche Abschnitt .cmdline eine Kombination des grundlegenden Abschnitts .cmdline und der
mit dieser Option festgelegten zusätzlichen Kernelbefehlszeilenargumente ist.

Kennzeichner
Auf den aktuelle Wert verschiedener Einstellungen kann beim Auswerten mittels Kennzeichner zugegriffen
werden. Um ein wörtliches Zeichen % in einer Konfiguration zu schreiben, ohne es als Kennzeichner zu
behandeln, verwenden Sie %%. Es werden die folgenden Kennzeichner verstanden:

Einstellung Kennzeichner
────────────────────────────────
Distribution= %d
Release= %r
Architecture= %a
Format= %t
Output= %o
OutputDirectory= %O
ImageId= %i
ImageVersion= %v

Es gibt auch von Einstellungen unabhängige Kennzeichner:

Kennzeichner Wert
─────────────────────────────────────────────────────
%C Elternverzeichnis der aktuellen
Konfigurationsdatei
%P Aktuelles Arbeitsverzeichnis
%D Verzeichnis, in dem mkosi aufgerufen
wurde
%I Name des aktuellen Unterabbildes in
mkosi.images

Schließlich gibt es Kennzeichner, die von einer Einstellung abgeleitet werden:

Kennzeichner Wert
─────────────────────────────────────────────────────
%F Das Standarddateisystem der
konfigurierten Distribution

Beachten Sie, dass sich das aktuelle Arbeitsverzeichnis ändert, während mkosi seine Konfiguration
auswertet. Insbesondere ändert mkosi sein Arbeitsverzeichnis jedes Mal, wenn es ein Verzeichnis mit einer
Datei mkosi.conf auswertet, auf dieses Verzeichnis.

Beachten Sie, dass das Verzeichnis, aus dem mkosi heraus aufgerufen wurde, durch das
Befehlszeilenargument --directory= beeinflusst wird.

Die folgende Tabelle zeigt Beispielwerte für die oben aufgeführten Verzeichniskennzeichner:

$D/mkosi.conf $D/mkosi.conf.d/abc/abc.conf $D/mkosi.conf.d/abc/mkosi.conf
_
%C $D $D/mkosi.conf.d $D/mkosi.conf.d/abc
%P $D $D $D/mkosi.conf.d/abc
%D $D $D $D

Unterstützte Distributionen
Für die folgenden Distributionen können Abbilder zur Installation erstellt werden:

• Fedora Linux

• Debian

• Kali Linux

• Ubuntu

• Arch Linux

• openSUSE

• Mageia

• CentOS

• RHEL

• RHEL UBI

• OpenMandriva

• Rocky Linux

• Alma Linux

• Azure Linux

• None (Dazu muss der Benutzer ein bereits gebautes Rootfs bereitstellen)

Theoretisch kann jede Distribution auf dem Wirtrechner zum Bau der Abbilder, die jede andere Distribution
enthalten können, verwandt werden, solange die notwendigen Werkzeuge verfügbar sind. Insbesondere jede
Distribution, die apt(8) paketiert, kann zum Bau von Abbildern von Debian, Kali oder Ubuntu verwandt
werden. Jede Distribution, die dnf(8) paketiert, kann zum Bau von Abbildern von jeder rpm(8)-basierten
Distribution verwandt werden. Jede Distribution, die pacman(8) paketiert, kann zum Bau von Abbildern von
Arch Linux verwandt werden. Jede Distribution, die zypper(8) paketiert, kann zum Bau von Abbildern von
openSUSE verwandt werden. Andere Distributionen und Bauautomatisierungswerkzeuge für eingebettete
Linux-Systeme wie Buildroot, OpenEmbedded und Yocto Project können durch Auswahl der Distribution custom
und der Befüllung des Rootfs mit einer Kombination von Basisbäumen, Gerüstbäumen und
Vorbereitungsskripten verwandt werden.

Derzeit paketiert Fedora Linux alle relevanten Werkzeuge seit Fedora 28.

Beachten Sie, dass Sie Abbilder für RHEL nur auf einem Wirtsystem bauen können, das über ein
RHEL-Abonnement verfügt (das beispielsweise mit dem subscription-manager eingerichtet wurde), wenn Sie
keinen angepassten Spiegel verwenden.

Arbeitsablauf

Arbeitsablauf für mkosi build. Standardwerte bzw. -aufrufe werden in Klammern dargestellt. Beim Bau mit
--incremental erstellt mkosi einen Zwischenspeicher der Distributionsinstallation, falls er nicht bereits
existiert und ersetzt die Distributionsinstallation in sukzessiven Aufrufen durch Daten aus dem
Zwischenspeicher.

1. Wertet Befehlszeilen-Optionen aus

2. Wertet Konfigurationsdateien aus

3. Führt Konfigurationsskripte aus (mkosi.configure)

4. Falls nicht als Root ausgeführt wird, trennt den Benutzernamensraum ab und der in /etc/subuid und
/etc/subgid konfigurierte Subuid-Bereich wird darin abgebildet.

5. Trennt den Einhängenamensraum ab

6. Hängt die folgenden Verzeichnisse schreibgechützt neu ein, falls sie existieren:

• /usr

• /etc

• /opt

• /srv

• /boot

• /efi

• /media

• /mnt

Führen Sie dann für jedes Abbild die folgenden Schritte aus:

1. Kopieren von Sandbox-Bäumen in den Arbeitsbereich

2. Synchronisieren der Depot-Metadaten des Paketverwalters

3. Ausführen der Synchronisierungsskripte (mkosi.sync)

4. Kopieren der Basisbäume (--base-tree=) in das Abbild

5. Wiederverwenden eines zwischengespeicherten Abbilds, falls verfügbar

6. Kopieren eines Schnappschusses der Depot-Metadaten des Paketverwalters in das Abbild

7. Kopieren von Gerüstbäumen (mkosi.skeleton) in das Abbild

8. Installieren der Distribution und Pakete in das Abbild

9. Ausführen der Vorbereitungsskripte auf dem Abbild mit dem Argument final (mkosi.prepare)

10. Installieren der Baupakete in der Überlagerung, falls irgendwelche Bauskripte konfiguriert sind

11. Ausführen der Vorbereitungsskripte auf der Überlagerung mit dem Argument build, falls irgendwelche
Bauskripte konfiguriert sind (mkosi.prepare)

12. Zwischenspeichern des Abbilds, falls konfiguriert (--incremental)

13. Ausführen der Bauskripte auf dem Abbild & der Überlagerung, falls irgendwelche Bauskripte
konfiguriert sind (mkosi.build)

14. Finalisieren des Baus, falls das Ausgabeformat none konfiguriert ist

15. Kopieren der Bauskripteausgaben in das Abbild

16. Kopieren der zusätzlichen Bäume in das Abbild (mkosi.extra)

17. Ausführen der Post-Install-Skripte (mkosi.postinst)

18. Schreiben der für Ssh=, Autologin= und MakeInitrd= benötigten Konfigurationsdateien

19. Installieren von systemd-boot(7) und konfigurieren des sicheren Systemstart, falls konfiguriert
(--secure-boot)

20. Ausführen von systemd-sysusers(8)

21. Ausführen von systemd-tmpfiles(8)

22. Ausführen von systemctl preset-all

23. Ausführen von depmod(8)

24. Ausführen von systemd-firstboot(1)

25. Ausführen vom systemd-hwdb(8)

26. Entfernen von Pakete und Dateien (RemovePackages=, RemoveFiles=)

27. Ausführen von SELinux-Neumarkierung, falls eine SELinux-Richtlinie installiert ist

28. Ausführen von Finalisierungskripten (mkosi.finalize)

29. Erstellen des Vereinigten Kernelabbildes, falls so konfiguriert

30. Erstellen des finalen Ausgabeformats

31. Ausführen der Post-Ausgabe-Skripte (mkosi.postoutput)

Skripte

Um die Anpassung von Abbildern zu erlauben, die nicht mittels der in mkosi eingebauten Funktionalitäten
implementiert werden können, unterstützt mkosi die Ausführung von Skripten zu verschiedenen Zeitpunkten
während des Abbildbauprozesses, die das Abbild nach Bedarf anpassen können. Skripte werden auf dem
Wirtsystem als Root (entweder als echtem Root oder Root innerhalb des Benutzernamensraums, den mkosi bei
dem unprivilegierten Aufruf erstellte) mit einer angepassten Umgebung ausgeführt, um die Veränderung des
Abbildes zu erleichtern. Für jedes Skript werden die konfigurierten Bauquellen (BuildSources=) in das
aktuelle Arbeitsverzeichnis eingehängt, bevor das Skript im aktuellen Arbeitsverzeichnis ausgeführt wird.
$SRCDIR wird so gesetzt, dass es auf das aktuelle Arbeitsverzeichnis zeigt. Die folgenden Skripte werden
unterstützt:

• Falls mkosi.configure (ConfigureScripts=) existiert, wird es vor dem Bau des Abbilds ausgeführt. Dieses
Skript kann zur dynamischen Veränderung der Konfiguration verwandt werden. Es empfängt die
Konfiguration serialisiert als JSON auf der Standardeingabe und sollte die veränderte Konfiguration
serialisiert auf der Standardausgabe ausgeben. Beachten Sie, dass dieses Skript nur ausgeführt wird,
wenn das Abbild gebaut oder gestartet wird (Unterbefehle build, vm, boot und shell). Falls ein
Vorgabe-Werkzeugbaum konfiguriert ist, wird er vor der Ausführung des Konfigurationsskriptes gebaut und
das Konfigurationsskript wird mit vorhandenen Werkzeugen ausgeführt. Das bedeutet auch, dass die durch
das Konfigurationsskript vorgenommenen Änderungen nicht in der Ausgabe von summary sichtbar sein
werden.

• Falls mkosi.sync (SyncScripts=) existiert, wird es vor dem Bau des Abbildes ausgeführt. Dieses Skript
kann zur Aktualisierung verschiedener, während des Baus verwandter Quellen eingesetzt werden. Ein
Anwendungsszenario ist die Ausführung von git pull in verschiedenen Quelldepots vor dem Bau des
Abbildes. Insbesondere gilt die Einstellung BuildSourcesEphemeral= nicht für Synchronisationsskripte,
was bedeutet, dass Synchronisationsskripte zur Aktualisierung von Bauquellen verwandt werden können,
selbst wenn BuildSourcesEphemeral= aktiviert ist.

• Falls mkosi.prepare (PrepareScripts=) existiert, wird es zuerst mit dem Argument final aufgerufen,
direkt nachdem die Software-Pakete installiert sind. Es wird ein zweites Mal mit dem
Befehlszeilenparameter build aufgerufen, direkt nachdem die Baupakete installiert sind und die
Bauüberlagerung oberhalb des Wurzelverzeichnisses des Abbildes eingehängt ist. Dieses Skript hat
Netzwerkzugang und kann zur Installation von Paketen aus weiteren Quellen neben dem Paketverwalter der
Distribution verwandt werden (z.B. pip(1), npm(1), …), nachdem alle Software-Pakete installiert
wurden, aber bevor das Abbild zwischengespeichert wird (falls der inkrementelle Modus aktiviert wurde).
Im Gegensatz zur einer Allzweckinstallation ist die Installtion von Paketen in das System (pip install,
npm install -g) anstelle in $SRCDIR sicher, da das Bauabbild nur für ein einzelnes Projekt verwandt
wird und leicht entsorgt und neugebaut werden kann, und es daher kein Risiko von in Konflikt stehenden
Abhängigkeiten und kein Risiko der Verunreinigung des Wirtsystems gibt.

• Falls mkosi.build (BuildScripts=) existiert, wird es ausgeführt, wenn die Bauüberlagerung oberhalb des
Wurzelverzeichnisses des Abbildes eingehängt wurde. Bei der Ausführung der Bauskripte zeigt $DESTDIR
auf ein Verzeichnis, in dem die Skripte alle erstellten Dateien ablegen sollen, die dann im Abbild
landen sollen. Beachten Sie, dass die Bausysteme, die auf make(1),automake(1) und meson(1) basieren, im
Allgemeinen $DESTDIR berücksichtigen und damit der Bau von source-Bäumen sehr natürlich vonstatten
geht. Nach der Ausführung des Bauskripts wird der Inhalt von $DESTDIR in das Abbild kopiert.

• Falls mkosi.postinst (PostInstallationScripts=) existiert, wird es nach der Installation der
(optionalen) Bau- und Zusatzbäume ausgeführt. Dieses Skript kann zur Veränderung des Abbilds ohne jede
Beschränkung verwandt werden, nachdem alle Softwarepakete und Bauquellen installiert wurden.

• Falls mkosi.finalize (FinalizeScripts=) existiert, wird es als letzter Schritt der Vorbereitung des
Abbildes ausgeführt.

• Falls mkosi.postoutput (PostOutputScripts=) existiert, wird es direkt nach der Erstellung aller
Ausgabedateien ausgeführt, bevor sie abschließend in das Ausgabeverzeichnis geschoben werden. Dies kann
zur Erstellung zusätzlicher oder alternativer Ausgaben verwandt werden, z.B. SHA256FILES oder
SBOM-Listen.

• Falls mkosi.clean (CleanScripts=) existiert, wird es direkt nach der Bereinigung eines vorherigen Baus
ausgeführt. Ein Bereinigungsskript kann sämtliche Ausgaben bereinigen, die mkosi nicht kennt (z.B.
Artefakte von SplitArtifacts=partitions oder RPMs, die in einem Bauskript erstellt wurden). Beachten
Sie, dass dieses Skript den Werkzeugbaum nicht verwendet, selbst wenn einer konfiguriert ist.

• Falls mkosi.version existiert und ausführbar ist, wird sie während der Auswertung der Konfiguration
ausgeführt und füllt ImageVersion= mit der Ausgabe auf der Standardausgabe. Dies kann für externe
Versionverfolgung verwandt werden, z.B. mit git describe oder date '+%Y-%m-%d'. Beachten Sie, dass
dieses Skript auf dem Hauptsystem ohne irgendeine Sandbox ausgeführt wird.

• Falls mkosi.version existiert und ausführbar ist, wird sie während der Auswertung der Konfiguration
ausgeführt und füllt RootPassword= mit der Ausgabe auf der Standardausgabe. Dies kann zur Erstellung
eines zufälligen Passworts verwandt werden. Um sich daran zu erinnern, kann es auf der
Standardfehlerausgabe ausgegeben werden oder durch Lesen von $MKOSI_CONFIG in einem anderen Skript
(z.B. mkosi.postoutput) ermittelt werden. Beachten Sie, dass dieses Skript auf dem Hauptsystem ohne
irgendeine Sandbox ausgeführt wird.

Falls ein Skript die Erweiterung .chroot verwendet, wird mkosi ein chroot(8) mittels mkosi-chroot (siehe
unten) durchführen, bevor das Skript ausgeführt wird. Falls beispielsweise mkosi.postinst.chroot
existiert, wird mkosi ein chroot(8) in das Abbild durchführen und das Skript als Postinstallationsskript
ausführen.

Anstatt eines Skripts in einer einzelnen Datei wird mkosi auch alle Dateien in lexikographischer
Reihenfolge aus geeignet benannten Verzeichnissen .d lesen, z.B. alle Dateien in einem Verzeichnis
mkosi.build.d würden als Bauskripte verwandt. Folgende Verzeichnisse werden unterstützt:

• mkosi.sync.d,

• mkosi.prepare.d,

• mkosi.build.d,

• mkosi.postinst.d,

• mkosi.finalize.d,

• mkosi.postoutput.d und

• mkosi.clean.d.

Dies kann mit der Erweiterung .chroot kombiniert werden, z.B. würde mkosi.build.d/01-foo.sh ohne Wechsel
mittels chroot(8) in das Abbild ausgeführt und mkosi.build.d/02-bar.sh.chroot würde nach dem zuerst
erfolgten chroot(8) in das Abbild ausgeführt.

Von mkosi ausgeführte Skripte erhalten die folgenden Umgebungsvariablen:

• $ARCHITECTURE enthält die Architektur aus der Einstellung Architecture=. Falls Architecture= nicht
gesetzt ist, wird es die native Architektur der Wirtmaschine erhalten. Siehe die Dokumentation von
Architecture= für mögliche Werte dieser Variablen.

• $QEMU_ARCHITECTURE enthält die Architektur aus $ARCHITECTURE in dem von qemu verwandten Format.
Nützlich, um das Programm von Qemu zu finden (qemu-system-$QEMU_ARCHITECTURE).

• $DISTRIBUTION enthält die Distribution aus der Einstellung Distribution=.

• $RELEASE enthält die Veröffentlichung aus der Einstellung Release=.

• $DISTRIBUTION_ARCHITECTURE enthält die Architektur aus $ARCHITECTURE in dem von der konfigurierten
Distribution verwandten Format.

• $PROFILES enthält die Profile aus der Einstellung Profiles= als eine Kommata-getrennte Zeichenkette.

• $CACHED= wird auf 1 gesetzt, falls ein zwischengespeichertes Abbild verfügbar ist, ansonsten auf 0.

• $CHROOT_SCRIPT enthält den Pfad zu dem laufenden Skript, relativ zum Wurzelverzeichnis des Abbildes.
Der primäre Anwendungsfall für diese Variable ist in der Kombination mit dem Skript mkosi-chroot. Siehe
die nachfolgende Beschreibung von mkosi-chroot für weitere Informationen.

• $SRCDIR enthält den Pfad zu dem Verzeichnis, aus dem mkosi heraus aufgerufen wurde, wobei alle
konfigurierten Bauquellen oben auf eingehängt sind. $CHROOT_SRCDIR enthält den Wert, den $SRCDIR nach
Aufruf von mkosi-chroot haben wird.

• $BUILDDIR ist nur definiert, falls mkosi.builddir existiert und auf das zu verwendende Bauverzeichnis
zeigt. Dies ist für alle Bausysteme, die Bauen außerhalb des Bau-Baums unterstützen, nützlich, um
bereits gebaute Artefakte von einem vorherigen Durchlauf wiederzuverwenden. $CHROOT_BUILDDIR enthält
den Wert, den $BUILDDIR nach Aufruf von mkosi-chroot haben wird.

• $DESTDIR ist ein Verzeichnis, in das sämtliche installierte und durch ein Bauskript erstellte Software
abgelegt werden kann. Diese Variable wird nur gesetzt, wenn ein Bauskript ausgeführt wird.
$CHROOT_DESTDIR enthält den Wert, den $DESTDIR nach Aufruf von mkosi-chroot haben wird.

• $OUTPUTDIR zeigt auf das Vorbereitungsverzeichnis, das zum Speichern der während des Baus erstellten
Bauartefakte verwandt wird. $CHROOT_OUTPUTDIR enthält den Wert, den $OUTPUTDIR nach Aufruf von
mkosi-chroot haben wird.

• $PACKAGEDIR zeigt auf das Verzeichnis, das das lokale Paketdepot enthält. Bauskripte können weitere
Pakete zum lokalen Depot hinzufügen, indem sie Pakete nach $PACKAGEDIR schreiben.

• $ARTIFACTDIR zeigt auf das Verzeichnis, das zur Weitergabe von Bauartefakten verwandt wird, die während
des Baus erstellt wurden und die für die Verwendung durch Mkosi bereitgestellt werden. Dies ist ähnlich
zu PACKAGEDIR, ist aber für Artefakte gedacht, die keine vom Paketverwalter verstandenen Pakete sein
können, z.B. Initrds, die durch andere Initrd-Generatoren neben Mkosi erstellt wurden. Bauskripte
können weitere Artekfakte zu dem Verzeichnis hinzufügen, indem sie sie in $ARTIFACTDIR ablegen. Dateien
in diesem Verzeichnis sind für den aktuellen Bau verfügbar und werden nicht wie die Inhalte von
$OUTPUTDIR herauskopiert.

mkosi wird auch bestimmte Unterverzeichnisse eines Artefaktverzeichnisses verwenden, um ihre Inhalte
automatisch in bestimmten Schritten zu verwenden. Derzeit werden die folgenden zwei Unterverzeichnisse
in dem Artefaktverzeichnis durch Mkosi verwandt:

• io.mkosi.microcode: Alle Dateien in diesem Verzeichnis werden als Microcode-Dateien verwandt, d.h.
sie werden an die Initrds in lexikographischer Reihenfolge angehängt.

• io.mkosi.initrd: Alle Dateien in diesem Verzeichnis werden als Initrds verwandt und in
lexikographischer Reihenfolge aneinandergehängt.

Es wird empfohlen, dass Benutzer von $ARTIFACTDIR Dinge für ihre eigene Verwendung in ähnlichen
Verzeichnissen mit eigenem Namensraum ablegen, z.B. lokal.mein.Namensraum.

• $BUILDROOT ist das Wurzelverzeichnis des gebauten Abbilds, optional mit der Bauüberlagerung oben auf
eingehängt, abhängig vom Skript, das ausgeführt wird.

• $WITH_DOCS ist entweder 0 oder 1, abhängig davon, ob der Bau eines Abbildes mit oder ohne Dokumentation
angefordert wurde (WithDocs=yes). Ein Bauskript sollte die Installation sämtlicher Paketdokumentationen
nach $DESTDIR unterdrücken, falls $WITH_DOCS auf 0 gesetzt ist.

• $WITH_TESTS ist entweder 0 oder 1, abhängig davon, ob ein Bau mit oder ohne laufende Test-Suite
angefordert wurde (WithTests=no). Ein Bauskript sollte die Ausführung jeder Einheiten- oder
Integrationstests unterlassen, falls $WITH_TESTS auf 0 gesetzt ist.

• $WITH_NETWORK ist entweder 0 oder 1, abhängig davon, ob ein Bau mit oder ohne Netzwerkanbindung
ausgeführt wird (WithNetwork=no). Ein Bauskript sollte sämtliche Netzwerkkommunikation unterlassen,
falls $WITH_NETWORK auf 0 gesetzt ist.

• $SOURCE_DATE_EPOCH wird definiert falls erbeten (SourceDateEpoch=TIMESTAMP,
Environment=SOURCE_DATE_EPOCH=TIMESTAMP oder die Umgebungsvariable auf dem Wirtsystem
$SOURCE_DATE_EPOCH). Dies ist nützlich, um Bauten wiederholbar zu machen. Siehe SOURCE_DATE_EPOCH zu
weiteren Informationen.

• $MKOSI_UID bzw. $MKOSI_GID sind die UID bzw. GID des Benutzers, der mkosi aufrief.

• $MKOSI_CONFIG ist eine Datei, die eine JSON-Zusammenfassung der Einstellungen des aktuellen Abbildes
enthält. Diese Datei kann innerhalb von Skripten ausgewertet werden, um Zugriff auf alle Einstellungen
des aktuellen Abbildes zu erhalten.

• $IMAGE_ID enthält den Kennzeichner aus der Einstellung ImageId= oder --image-id=.

• $IMAGE_VERSION enthält die Version aus der Einstellung ImageVersion= oder --image-version=.

In dieser Tabelle können Sie ersehen, welches Skript welche Umgebungsvariable erhält:

Variable configure sync prepare build postinst finalize postoutput clean
_
ARCHITECTURE ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
QEMU_ARCHITECTURE ✓
DISTRIBUTION ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
DISTRIBUTION_ARCHITECTURE ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
RELEASE ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
PROFILES ✓ ✓ ✓ ✓ ✓ ✓ ✓
CACHED ✓
CHROOT_SCRIPT ✓ ✓ ✓ ✓
SRCDIR ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
CHROOT_SRCDIR ✓ ✓ ✓ ✓
BUILDDIR ✓ ✓ ✓
CHROOT_BUILDDIR ✓
DESTDIR ✓
CHROOT_DESTDIR ✓
OUTPUTDIR ✓ ✓ ✓ ✓
CHROOT_OUTPUTDIR ✓ ✓
BUILDROOT ✓ ✓ ✓ ✓
PACKAGEDIR ✓ ✓ ✓ ✓
ARTIFACTDIR ✓ ✓ ✓ ✓
WITH_DOCS ✓ ✓
WITH_TESTS ✓ ✓
WITH_NETWORK ✓ ✓ ✓ ✓
SOURCE_DATE_EPOCH ✓ ✓ ✓ ✓ ✓
MKOSI_UID ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
MKOSI_GID ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
MKOSI_CONFIG ✓ ✓ ✓ ✓ ✓ ✓ ✓
IMAGE_ID ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
IMAGE_VERSION ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Zusätzlich werden bei der Skript-Ausführung einige Skripte über den $PATH verfügbar gemacht, um häufige
Anwendungsfälle zu vereinfachen.

• mkosi-chroot: Dieses Skript wird ein chroot(8) in das Abbild durchführen und den angegebenen Befehl
ausführen. Zusätzlich zum chroot(8) in das Abbild wird es auch verschiedene Dateien und Verzeichnisse
in das Abbild einhängen ($SRCDIR, $DESTDIR, $BUILDDIR, $OUTPUTDIR, $CHROOT_SCRIPT) und die
entsprechenden Umgebungsvariablen ändern, um auf die Orte innerhalb des Abbilds zu zeigen. Es wird auch
APIVFS-Dateisysteme einhängen (/proc, /dev, …), um sicherzustellen, dass in der Chroot ausgeführte
Skripte und Werkzeuge korrekt funktionieren. Falls erbeten leitet es auch /etc/resolv.conf vom Wirt in
die Chroot weiter, so dass DNS-Auflösung innerhalb der Chroot funktioniert. Nachdem sich der Befehl
mkosi-chroot beendet, werden verschiedene Einhängepunkte bereinigt.

Verwenden Sie beispielsweise folgendes, um ls(1) innerhalb des Abbilds aufzurufen:

mkosi-chroot ls …

Um das gesamte Skript innerhalb des Abbildes auszuführen, fügen Sie die Endung .chroot zu dem Namen
hinzu (mkosi.build.chroot anstatt mkosi.build, usw.).

• Für alle unterstützten Paketverwalter (dnf, rpm(8), apt(8), dpkg(1), pacman(8), zypper(8)) werden
Skripte mit dem gleichen Namen in $PATH abgelegt, um sicherzustellen, dass diese Befehle auf dem
Wurzelverzeichnis des Abbildes mit der vom Benutzer bereitgestellten Konfiguration anstelle auf dem
Wirtsystem agieren. Dies bedeutet, dass Sie aus einem Skript z.B. dnf install vim durchführen können,
um Vim in das Abbild zu installieren.

Zusätzlich werden mkosi-install, mkosi-reinstall, mkosi-upgrade und mkosi-remove die entsprechende
Aktion des Paketverwalters, der zum Baus des Abbilds verwandt wird, aufrufen.

• git(1) wird automatisch mit safe.directory=* aufgerufen, um Berechtigungsfehler bei der Ausführung als
Benutzer root in einem Benutzernamensraum zu vermeiden.

• Beim Aufruf außerhalb des Abbildes werden useradd(8) und groupadd(8) automatisch mit --root=$BUILDROOT
aufgerufen.

Wenn Skripte ausgeführt werden, werden alle noch schreibbaren Verzeichnisse schreibgeschützt gemacht
(/home, /var, /root, …) und nur die minimale Menge an Verzeichnissen, die schreibbar bleiben müssen,
bleiben schreibbar. Dies dient dazu sicherzustellen, dass die Skripte nicht das Wirtsystem durcheinander
bringen können, wenn mkosi als Root ausgeführt wird.

Beachten Sie, dass alle Quellverzeichnisse bei der Ausführung der Skripte flüchtig werden, was bedeutet,
das alle Änderungen an den Quellverzeichnissen während der Ausführung der Skripte verworfen werden, wenn
die Skripte mit der Ausführung fertig sind. Verwenden Sie die Ausgabe-, Bau- oder
Zwischenspeicherverzeichnisse, falls Sie Daten zwischen Bauten weiternutzen wollen.

Dateien

Um den Bau von Abbildern für Entwicklungsversionen Ihrer Projekte zu erleichtern, kann mkosi
Konfigurationsdaten aus dem lokalen Verzeichnis unter der Annahme, dass es im einen Quell-Baum aufgerufen
wurde, lesen. Insbesondere werden die folgenden Dateien verwandt, falls sie im lokalen Verzeichnis
existieren:

• Das Verzeichnis mkosi.skeleton/ oder das Archiv mkosi.skeleton.tar können zum Einfügen von Dateien in
das Abbild verwandt werden. Die Dateien werden vor der Installation der Distributionspakete in das
Abbild kopiert. Dies ermöglicht die frühe Bereitstellung von Dateien, beispielsweise zur Konfiguration
des Paketverwalters oder um Systemd-Voreinstellungen zu setzen.

Bei der Verwendung des Verzeichnisses werden Dateieigentümerschaften nicht erhalten: alle kopierten
Dateien werden root gehören. Um Eigentümerschaften beizubehalten, verwenden Sie ein Tar-Archiv.

• Das Verzeichnis mkosi.extra/ oder das Archiv mkosi.extra.tar können zum Einfügen zusätzlicher Dateien
in das Abbild verwandt werden, ergänzend zu den Inhalten der Distributionen. Sie sind ähnlich zu
mkosi.skeleton/ und mkosi.skeleton.tar, aber die Dateien werden in den Verzeichnisbaum des Abbildes
kopiert, nachdem das Betriebssystem installiert wurde.

Bei der Verwendung des Verzeichnisses werden Dateieigentümerschaften nicht erhalten: alle kopierten
Dateien werden root gehören. Um Eigentümerschaften beizubehalten, verwenden Sie ein Tar-Archiv.

• Das Verzeichnis mkosi.sandbox/ oder das Archiv mkosi.sandbox.tar können zur Konfiguration des
Paketverwalters verwandt werden, ohne dass diese Dateien in das Abbild eingefügt werden. Falls die
Dateien in das Abbild eingefügt werden sollten, sollte stattdessen mkosi.skeleton/ und
mkosi.skeleton.tar verwandt werden.

Bei der Verwendung des Verzeichnisses werden Dateieigentümerschaften nicht erhalten: alle kopierten
Dateien werden root gehören. Um Eigentümerschaften beizubehalten, verwenden Sie ein Tar-Archiv.

• Die Nspawn-Einstellungsdatei mkosi.nspawn wird an den gleichen Ort wie die Ausgabeabbilddatei kopiert,
falls sie existiert. Dies ist nützlich, da Nspawn nach Einstellungsdateien neben den von ihm
gestarteten Abbildern nach zusätzlichen Container-Laufzeiteinstellungen sucht.

• Das Verzeichnis mkosi.cache/ wird automatisch als Paket-Herunterlade-Zwischenspeicher verwandt, falls
es existiert, um wiederholte Läufe des Werkzeugs zu beschleunigen.

• Das Verzeichnis mkosi.builddir/ wird automatisch als Bauverzeichnis außerhalb des Quellbaums verwandt,
falls es existiert und falls die Baubefehle in den Skripten mkosi.build dies unterstützen. Insbesondere
wird dieses Verzeichnis in den Bau-Container eingehängt und die Umgebungsvariable $BUILDDIR darauf
gesetzt, wenn die Bauskripte aufgerufen werden. Ein Bauskript kann dann dieses Verzeichnis als
Bauverzeichnis verwenden, für automake(1)- oder ninja(1)-artige Bauten außerhalb des Quellbaums. Dies
beschleunigt den Bau deutlich, insbesondere wenn mkosi im inkrementellen Modus (-i) verwandt wird;
nicht nur das Abbild und die Bau-Überlagerung, sondern auch der Baubaum wird zwischen nachfolgenden
Aufrufen wiederverwandt. Beachten Sie, dass die Umgebungsvariable $BUILDDIR nicht gesetzt wird, falls
dieses Verzeichnis nicht existiert und es den Bauskripten überlassen bleibt zu entscheiden, ob im
Quellbaum oder außerhalb des Quellbaums gebaut und welches Verzeichnis verwandt wird.

• Die Datei mkosi.rootpw kann zur Bereitstellung des Passworts für den Benutzer root des Abbildes
verwandt werden. Falls dem Passwort hashed: vorangestellt ist, wird es als bereits gehashtes Paswort
betrachtet. Dem Passwort darf optional ein Zeilenumbruchzeichen folgen, das implizit entfernt wird. Die
Datei muss den Zugriffsmodus 0600 oder geringer haben. Falls diese Datei nicht existiert, wird das
Vorgabepasswort der Distribution gesetzt (normalerweise bedeutet dies, dass der Zugriff auf den
Benutzer root blockiert ist).

• Die Datei mkosi.passphrase stellt die Passphrase bereit, die bei der Auswahl der LUKS-Verschlüsselung
verwandt werden soll. Sie sollte die Passphrase wortwörtlich enthalten und nicht auf einem
Zeilenumbruch enden (d.h. im gleichen Format wie cryptsetup(8) und /etc/crypttab die Passphrasendatei
erwarten). Die Datei muss den Zugriffsmodus 0600 oder geringer haben.

• Die Dateien mkosi.crt und mkosi.key enthalten ein X.509-Zertifikat und den privaten PEM-Schlüssel, die
verwandt werden, wenn Signaturen benötigt werden (UEFI SecureBoot, Verity, …).

• Das Verzeichnis mkosi.output/ wird zum Speichern aller Bauartefakte verwandt.

• Das Verzeichnis mkosi.credentials/ wird als Quelle zusätzlicher Zugangsberechtigungen ähnlich zu der
Option Credentials= verwandt. Für jede Datei in dem Verzeichnis wird der Dateiname als
Zugangsberechtigungsname verwandt und die Dateiinhalte werden der Zugangsberechtigungswert oder, falls
die Datei ausführbar ist, wird mkosi die Datei ausführen und die Ausgabe auf der Standardausgabe wird
als Zugangsberechtigungswert verwandt. Die Ausgabe auf der Standardfehlerausgabe wird ignoriert. Mit
Credentials= konfigurierte Zugangsberechtigungen haben Vorrang vor Dateien in mkosi.credentials.

• Das Verzeichnis mkosi.repart/ wird als Quelle für systemd-repart(8)-Partitionsdefinitionsdateien
verwandt, die an systemd-repart(8) beim Bau eines Abbilds übergeben werden. Falls es nicht existiert
und die Einstellung RepartDirectories= nicht konfiguriert ist, wird mkosi folgende
Partitionsdefinitionsdateien als Voreinstellung verwenden:

00-esp.conf (falls ein startfähiges Abbild erstellt wird):

[Partition]
Type=esp
Format=vfat
CopyFiles=/boot:/
CopyFiles=/efi:/
SizeMinBytes=512M
SizeMaxBytes=512M

05-bios.conf (falls ein BIOS-startfähiges Abbild erstellt wird):

[Partition]
# UUID der Grub-BIOS-Systemstartpartition, die Grub bei GPTs benötigt,
# um sich selbst dort einzubetten.
Type=21686148-6449-6e6f-744e-656564454649
SizeMinBytes=1M
SizeMaxBytes=1M

10-root.conf

[Partition]
Type=root
Format=<Standarddateisystem-der-Distribution>
CopyFiles=/
Minimize=guess

Beachten Sie, dass keine der Vorgabe-Partitionsdefinitionen verwandt wird, falls entweder mkosi.repart/
gefunden oder RepartDirectories= verwandt wird.

Alle diese Dateien sind optional.

Beachten Sie, dass der Ort aller dieser Dateien auch mittels Aufruf von Befehlszeilenschaltern und als
Einstellungen in mkosi.conf konfiguriert werden kann, falls für ein Projekt die Vorgabeeinstellungen
nicht akzeptabel sind.

ZWISCHENSPEICHERUNG

mkosi unterstützt drei verschiedene Zwischenspeicher zur Beschleunigung von wiederholenden Neubauten von
Abbildern. Konkret:

1. Der Paketzwischenspeicher des Paketverwalters der Distribution kann zwischen Bauten
zwischengespeichert werden. Dies wird mit der Option --cache-directory= oder dem Verzeichnis
mkosi.cache/ konfiguriert. Diese Form des Zwischenspeicherns verlässt sich auf den Paketverwalter der
Distribution und speichert Distributionspakete (RPM, DEB, …) nach ihrem Herunterladen, aber bevor sie
entpackt werden, zwischen.

2. Falls mittels --incremental der inkrementelle Modus aktiviert ist, werden zwischengespeicherte Kopien
des abschließenden Abbildes und Bauüberlagerungen erstellt, direkt vor dem Hereinkopieren der
Bauquellen (für Bau-Überlagerungen) oder vor dem Hereinkopieren von durch mkosi.build erstellten
Artefakten (für das abschließende Abbild). Diese Art der Zwischenspeicherung erlaubt das Umgehen des
zeitaufwändigen Schritts des Paket-Entpackens der Distributions-Paketverwalter, ist aber nur wirksam,
falls die Liste der zu verwendenden Pakete stabil bleibt, sich die Bauquellen und deren Skripte aber
regelmäßig ändern. Beachten Sie, dass dieser Zwischenspeicher manuell geleert werden muss: immer, wenn
die Paketliste geändert wird, müssen die zwischengespeicherten Abbilder manuell vor dem nächsten
Neubau mittels des Schalters -f entfernt werden.

3. Schließlich können zwischen mehreren Bauten das Verzeichnis der Bauartefakte mittels des
Verzeichnisses mkosi.builddir/ gemeinsam verwandt werden. Dieses Verzeichnis ermöglicht es Systemen
wie Meson, bereits kompilierte Quellen aus einem vorherigen Bau zu verwenden und damit den Bauprozess
eines Bauskriptes mkosi.build zu beschleunigen.

Der Paketzwischenspeicher und der inkrementelle Modus sind in jedem Fall nützlich. Der abschließende
Zwischenspeicher ist nur anwendbar, wenn mkosi mit einem Quellbaum und Bauskript verwandt wird. Sind alle
drei zusammen aktiviert, dann ist die Durchlaufzeit für Abbildbauten minimal, da nur die Quelldateien neu
kompiliert werden müssen.

Bau mehrerer Abbilder

       Falls das Verzeichnis mkosi.images/ existiert, wird  mkosi  einzelne  Unterabbild-Konfigurationen  daraus
       laden   und   jede   davon   bauen.   Abbildkonfigurationen   können  entweder  Verzeichnisse  sein,  die
       mkosi-Konfigurationsdateien enthalten, oder reguläre Dateien mit der Erweiterung .conf.

       Wenn Abbildkonfigurationen in  mkosi.images/  gefunden  werden,  wird  mkosi  die  in  den  Einstellungen
       Dependencies= des Hauptabbilds festgelegten Abbilder und alle ihre Abhängigkeiten (oder alle davon, falls
       keine  Abbilder explizit mit Dependencies= in der Hauptabbildkonfiguration konfiguriert wurden) bauen. Um
       Abhängigkeiten zwischen Unterabbildern hinzuzufügen, kann auch  die  Einstellung  Dependencies=  verwandt
       werden. Unterabbilder werden immer vor dem Hauptabbild gebaut.

       Wenn Abbilder definiert sind, wird mkosi zuerst die Hauptabbildkonfiguration (Konfiguration außerhalb des
       Verzeichnisses  mkosi.images/)  einlesen,  gefolgt  von  der  Abbild-spezifischen  Konfiguration. Mehrere
       »allgemeine«  Einstellungen  gelten  für  das  Hauptabbild  und  seine  Unterabbilder  und   können   für
       Unterabbilder nicht separat konfiguriert werden. Die folgenden Einstellungen sind allgemein und können in
       Unterabbildern nicht konfiguriert werden:

       • Architecture=

       • BuildDirectory=

       • BuildSources=

       • BuildSourcesEphemeral=

       • CacheDirectory=

       • CacheOnly=

       • Distribution=

       • ExtraSearchPaths=

       • Incremental=

       • LocalMirror=

       • Mirror=

       • OutputDirectory=

       • OutputMode=

       • PackageCacheDirectory=

       • PackageDirectories=

       • Profiles=

       • ProxyClientCertificate=

       • ProxyClientKey=

       • ProxyExclude=

       • ProxyPeerCertificate=

       • ProxyUrl=

       • Release=

       • RepartOffline=

       • Repositories=

       • RepositoryKeyCheck=

       • SandboxTrees=

       • SourceDateEpoch=

       • ToolsTree=

       • ToolsTreeCertificates=

       • UseSubvolumes=

       • SecureBootCertificate=

       • SecureBootCertificateSource=

       • SecureBootKey=

       • SecureBootKeySource=

       • VerityCertificate=

       • VerityCertificateSource=

       • VerityKey=

       • VerityKeySource=

       • SignExpectedPcrCertificate=

       • SignExpectedPcrCertificateSource=

       • SignExpectedPcrKey=

       • SignExpectedPcrKeySource=

       • VolatilePackageDirectories=

       • WithNetwork=

       • WithTests

       • WorkspaceDirectory=

       Es  gibt  auch  Einstellungen, die an Unterabbilder weitergegeben werden, aber außer Kraft gesetzt werden
       können. Für diese Einstellungen haben Werte, die explizit im Unterabbild konfiguriert werden Vorrang  vor
       Werten, die auf der Befehlszeile oder in der Konfiguration des Hauptabbildes konfiguriert werden. Derzeit
       werden  die  folgenden Einstellungen an Unterabbilder weitergegeben, können dort aber außer Kraft gesetzt
       werden:

       • ImageId=

       • ImageVersion=

       • SectorSize=

       Abbilder können sich auf Ausgaben von Abbildern beziehen, von denen sie abhängen. Insbesondere wird mkosi
       für die folgenden Optionen nur prüfen, ob die Eingabe genau vor dem Bau des Abbildes existiert:

       • BaseTrees=

       • ExtraTrees=

       • Initrds=

       Um sich auf die Ausgaben von den Abhängigkeiten eines Abbildes zu  beziehen,  konfigurieren  Sie  einfach
       jede  dieser  Optionen  mit einem relativen Pfad zu der zu verwendenden Ausgabe in dem Ausgabeverzeichnis
       der Abhängigkeit. Oder verwenden Sie den Kennzeichner %O, um sich auf das Ausgabeverzeichnis zu beziehen.

       Ein gutes Beispiel, wie mehrere Abbilder gebaut werden können, kann in dem  Depot  von  Systemd  gefunden
       werden.

UMGEBUNGSVARIABLEN

       • $MKOSI_LESS  setzt  Optionen  für less(1) außer Kraft, wenn es durch mkosi zur seitenweisen Darstellung
         der Ausgabe verwandt wird.

       • $MKOSI_DNF kann dazu verwandt werden, das als dnf verwandte Programm außer Kraft zu setzen.  Diese  ist
         besonders für die Auswahl zwischen dnf und dnf5 nützlich.

       • $EPEL_MIRROR  kann  zum  Außerkraftsetzen  des  Ortes des Standard-Spiegels für das Epel-Depot verwandt
         werden,  wenn  Mirror=  eingesetzt  wird.  Standardmäßig  schaut   mkosi   nach   dem   Epel-Depot   im
         Unterverzeichnis  fedora  des  Elternverzeichnisses  des  in  Mirror=  festgelegten Spiegels. Falls der
         Spiegel beispielsweise auf https://mirror.net/centos-stream gesetzt ist, wird mkosi nach dem Epel-Depot
         in https://mirror.net/fedora/epel suchen.

       • SYSEXT_SCOPE und CONFEXT_SCOPE können zum Außerkraftsetzen des Vorgabewertes der  entsprechenden  Datei
         extension-release  beim  Bau  einer  Systemerweiterung  oder Konfigurationserweiterung verwandt werden.
         Standardmäßig wird der Wert auf initrd system portable gesetzt.

BEISPIELE

       Ein rohes GPT-Abbild mit ext4(5) als image.raw erstellen und ausführen:

              # mkosi -p systemd --incremental boot

       Ein startfähiges GPT-Abbild als foobar.raw erstellen und ausführen:

              $ mkosi -d fedora -p kernel-core -p systemd -p systemd-boot -p udev -o foobar.raw
              # mkosi --output foobar.raw boot
              $ mkosi --output foobar.raw vm

       Ein »Fedora Linux«-Abbild in einem einfachen Verzeichnis erstellen und ausführen:

              # mkosi --distribution fedora --format directory boot

       Ein  komprimiertes  Abbild  image.raw.xz  mit  installiertem  SSH  erstellen  und  eine   Prüfsummendatei
       hinzufügen:

              $ mkosi --distribution fedora --format disk --checksum --compress-output --package=openssh-clients

       Innerhalb  eines Quellverzeichnis eines automake(1)-basierenden Projekts mkosi so konfigurieren, dass der
       einfache Aufruf von mkosi ohne Parameter ein Betriebssystemabbild erstellt, das eine gebaute Version  des
       Projekts in seinem aktuellen Zustand enthält:

              $ cat >mkosi.conf <<EOF
              [Distribution]
              Distribution=fedora

              [Output]
              Format=disk

              [Content]
              Packages=kernel,systemd,systemd-udev,openssh-clients,httpd
              BuildPackages=make,gcc,libcurl-devel
              EOF
              $ cat >mkosi.build <<EOF
              #!/bin/sh

              if [ "$container" != "mkosi" ]; then
                  exec mkosi-chroot "$CHROOT_SCRIPT" "$@"
              fi

              cd $SRCDIR
              ./autogen.sh
              ./configure --prefix=/usr
              make -j `nproc`
              make install
              EOF
              $ chmod +x mkosi.build
              # mkosi --incremental boot
              # systemd-nspawn -bi image.raw

   Verschiedene Arten, mit vm zu starten
       Die  leichteste Art, eine virtuelle Maschine zu starten, ist ein Abbild mit den benötigten Komponenten zu
       bauen und mkosi qemu mit allen korrekten Optionen aufzurufen:

              $ mkosi -d fedora \
                  --autologin \
                  -p systemd-udev,systemd-boot,kernel-core \
                  build
              $ mkosi -d fedora vm
              …
              fedora login: root (automatic login)
              [root@fedora ~]#

       Standardmäßig wird nur  mit  einer  Textkonsole  gestartet.  In  diesem  Modus  verwenden  Meldungen  vom
       Systemstartprogramm,  dem Kernel und systemd(1) und später die getty(8)-Anmeldeaufforderung und die Shell
       das gleiche Terminal. Ein Umschalten zwischen der qemu-Konsole und  dem  Überwachungsprogramm  ist  durch
       Eingabe  von  Strg-a  c  möglich.  Das  qemu-Überwachungsprogramm  kann  beispielsweise  zum Einschleusen
       bestimmter Tastendrücke oder zum schnellen Herunterfahren der Maschine verwandt werden.  Alternativ  kann
       die Maschine mittels Strg-a x heruntergefahren werden.

       Um mit einem graphischen Fenster zu starten, fügen Sie --console=gui hinzu:

              $ mkosi -d fedora --console=gui qemu

       Ein  Kernel  kann  direkt  durch  mkosi vm -kernel … -initrd … -append '…' gestartet werden. Dies ist ein
       bisschen schneller, da kein Systemstartprogramm verwandt wird und es ist auch leichter, mit verschiedenen
       Kerneln und Kernel-Befehlszeilen zu experiementieren. Beachten Sie, dass trotz seines Namens  die  Option
       -append  von  qemu  die  im  Kernel eingebettete Standardbefehlszeile und sämtliche vorherige Angaben von
       -append ersetzt.

       Das UKI wird auch in das Ausgabeverzeichnis kopiert und kann direkt gestartet werden:

              $ mkosi vm -kernel mkosi.output/fedora~38/image.efi

       Beim Systemstart unter Verwendung eines externen Kernels wird der Kernel nicht in  dem  Abbild  benötigt,
       aber die Kernelmodule sollten installiert sein.

       Es  ist  auch  möglich,  einen direkten Kernelsystemstart in ein Systemstartprogramm durchzuführen. Dabei
       wird ausgenutzt, dass systemd-boot(7) ein gültiges UEFI-Programm ist:

              $ mkosi vm -kernel /usr/lib/systemd/boot/efi/systemd-bootx64.efi

       In diesem Szenario wird der Kernel aus dem ESP mittels systemd-boot(7) geladen.

ANFORDERUNGEN

mkosi wird für verschiedene Distributionen paketiert: Debian, Kali, Ubuntu, Arch Linux, Fedora Linux,
OpenMandriva, Gentoo. Beachten Sie, dass seit der letzten Veröffentlichung einige Zeit vergangen ist und
die von den Distributionen ausgelieferten Pakete stark veraltet sind. Daher wird derzeit empfohlen, mkosi
aus Git heraus auszuführen, bis eine neue Veröffentlichung stattfand.

mkosi benötigt einen Kernel, der mount_setattr() bereitstellt, was in 5.12. eingeführt wurde.

mkosi benötigt derzeit Systemd 254, um startfähige Plattenabbilder zu bauen.

Werden keine Distributionspakete verwandt, müssen Sie sicherstellen, dass die notwendigen Abhängigkeiten
installiert sind. Unter Fedora Linux benötigen Sie beispielsweise:

# dnf install btrfs-progs apt dosfstools mtools edk2-ovmf e2fsprogs squashfs-tools gnupg python3 tar xfsprogs xz zypper sbsigntools

Unter Debian/Kali/Ubuntu könnte es notwendig sein, die Pakete ubuntu-keyring, ubuntu-archive-keyring,
kali-archive-keyring und/oder debian-archive-keyring explizit zu installieren, zusätzlich zu apt(8),
abhängig davon, was für eine Art von Distributionsabbildern Sie bauen möchten.

Beachten Sie, dass die minimal notwendige Python-Version 3.9 ist.

mkosi benötigt unbeschränkte Möglichkeiten, Namensräume zu erstellen und darin zu agieren. Einige
Distributionen beschränken die Erstellung von oder Capabilities in Benutzernamensräumen, wodurch mkosi
nicht richtig funktioniert.

Für Informationen zu Ubuntu, das solche Einschränkungen mittels AppArmor implementiert, siehe
https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces. Für andere Systeme,
untersuchen Sie die Sysctls kernel.unprivileged_userns_clone oder user.max.user_namespace.

Für Ubuntu können Sie die Beschränkung für mkosi aufheben, indem Sie den nachfolgendne Schnippsel
anpassen, dass er auf Ihr Programm mkosi zeigt, ihn nach /etc/apparmor.d/pfad.zu.mkosi kopieren und dann
systemctl reload apparmor ausführen:

abi <abi/4.0>,

include <tunables/global>

/pfad/zu/mkosi flags=(default_allow) {
userns,
}

Häufig gestellte Fragen (FAQ)

       • Warum funktioniert auf Debian/Kali/Ubuntu KVM mit mkosi vm nicht?

         Während  es  bei  anderen  Distributionen  kein  Problem  gibt,  auf /dev/kvm zuzugreifen, ist es unter
         Debian/Kali/Ubuntu nur für Benutzer in der Gruppe kvm erlaubt. Da mkosi einen  Benutzernamensraum  beim
         Betrieb  ohne  Privilegien  abtrennt,  verliert  es  den  Zugriff  auf  die Gruppe kvm, selbst wenn der
         aufrufende Benutzer in der Gruppe kvm war, denn zum Zeitpunkt, zu dem qemu gestartet wird, gibt es  auf
         /dev/kvm keinen Zugriff mehr. Um das zu umgehen, können Sie die Berechtigungen auf den Geräteknoten auf
         0666  ändern,  was  ausreicht,  damit  KVM  ohne  Privilegien funktioniert. Damit diese Änderungen über
         Neustarts hinweg erhalten bleibt, kopieren Sie  /usr/lib/tmpfiles.d/static-nodes-permissions.conf  nach
         /etc/tmpfiles.d/static-nodes-permissions.conf und ändern Sie den Modus von /dev/kvm von 0660 auf 0666.

       • Wie füge ich zu einem Abbild einen normalen Benutzer hinzu?

         Sie können den nachfolgenden Schnipsel in ein post-installation-Skript hinzufügen:

                useradd --create-home --user-group $USER --password "$(openssl passwd -stdin -6 <$USER_PASSWORD_FILE)"

         Beachten  Sie,  dass seit Systemd v256 systemd-homed-firstboot.service(1) die Erstellung eines normalen
         Benutzers beim ersten  Systemstart  anfragt,  falls  es  aktiviert  ist  und  keine  normalen  Benutzer
         existieren.

       • Warum sehe ich beim Bau von Abbildern Fehler beim chown(1) von Dateien?

         Erfolgt  die  Ausführung  nicht  als  Root,  kann  Ihr  Benutzer keine Eigentümerschaft von Dateien für
         beliebige Eigentümer ändern. Verschiedene Distributionen liefern immer noch Dateien  in  ihren  Paketen
         aus,  die  nicht  dem  Benutzer  root  gehören. Erfolgt die Ausführung nicht als Root, bildet mkosi den
         aktuellen Benutzer beim Aufruf des Paketverwalters auf root ab, was bedeutet,  dass  die  Änderung  der
         Eigentümerschaft  auf root funktionieren wird, aber die Änderung der Eigentümerschaft auf jeden anderen
         Benutzer oder jede andere Gruppe fehlschlagen wird.

         Beachten Sie, dass die Aufrufe von chown(1) nur bei  der  Ausführung  von  Paketverwaltern  unterdrückt
         werden,  aber  nicht  bei der Ausführung von Skripten. Falls dies z.B. für ein Bauskript benötigt wird,
         können Sie die Variable MKOSI_CHROOT_SUPPRESS_CHOWN auf den Wert true (1, yes,  true)  setzen,  um  die
         Aufrufe von chown(1) in den Skripten mkosi-chroot und .chroot zu unterdrücken.

         Falls  dieses  Verhalten  dazu  führt,  dass  sich in Ihrem Abbild betriebene Anwendungen nicht korrekt
         verhalten, könnten Sie mkosi als Root ausführen, wodurch  dieses  Problem  vermieden  wird.  Falls  der
         Betrieb   von   mkosi   als  Root  nicht  gewünscht  ist,  können  Sie  alternativ  unshare  --map-auto
         --map-current-user --setuid 0 --setgid 0 verwenden, um Root in einem Benutzernamensraum  mit  mehr  als
         einem  Benutzer  zu  werden,  unter  der  Annahme,  dass  die  UID/GID-Abbildungen  in  /etc/subuid und
         /etc/subgid korrekt konfiguriert sind. Beachten Sie, dass der Betrieb  von  mkosi  als  Root  oder  mit
         unshare  bedeutet,  dass  alle  von  mkosi erzeugten Ausgabedateien nicht mehr ihrem aktuellen Benutzer
         gehören.

         Für systemd(1)-Dienste, die Verzeichnisse in /var benötigen,  die  dem  Benutzer  und  der  Gruppe  des
         Dienstes  gehören  können  diese Verzeichnisse in Paketen ausgeliefert oder mittels systemd-tmpfiles(8)
         erstellt  werden.  Beachten  Sie,  das  die  Verwendung  von  StateDirectory=,   CacheDirectory=   oder
         LogsDirectory=  in  der  Dienstedatei  eine  Alternative  dazu darstellt. Dies weist systemd(1) an, die
         Verzeichnisse zu erstellen, wenn es erstmalig den Dienst startet.

         Alternativ können die Direktiven z oder Z für  systemd-tmpfiles(8)  verwandt  werden,  um  verschiedene
         Verzeichnisse  und Dateien mittels chown(1) auf den Eigentümer umzuschreiben, wenn das System erstmalig
         startet.

       • Warum sagt portablectl inspect <Abbild>/systemd-dissect  <Abbild>  das  mein  portierbarer  Dienst  gar
         keiner sei?

         systemd-dissect(1)  und portablectl inspect prüfen auf PORTABLE_PREFIXES= in os-release(5) und erkennen
         den portierbaren Dienst nicht als solchen, wenn der Schlüssel fehlt. Es wird dann ein x unter Use as im
         Falle von systemd-dissect(1) oder n/a unter Portable Service für portablectl(1) angezeigt.

         Da es keine gute Voreinstellung für diesen Schlüssel gibt und das erstellte  portierbare  Diensteabbild
         sich weiterhin korrekt anhängt, selbst wenn der Schlüssel nicht gesetzt ist, wird mkosi keinen setzen.

         Sie können in der Datei os-release(5) selbst in einem Postinst-Skript PORTABLE_PREFIXES= setzen.

REFERENZEN

       •

         Primäres Mkosi-Git-Depot auf GitHub

       •

         mkosi — A Tool for Generating OS Images  Einleitende Blog-Veröffentlichung von Lennart Poettering

       •

         The mkosi OS generation tool  LWN-Artikel

SIEHE AUCH

       systemd-nspawn(1), systemd-repart(8), dnf(8)

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

       Diese  Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer
       bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte  eine  E-Mail  an  die
       Mailingliste der Übersetzer: debian-l10n-german@lists.debian.org.

                                                                                                        mkosi(1)