.\" -*- coding: UTF-8 -*-
'\" t
.\" Automatically generated by Pandoc 3.1.12.1
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH mkosi 1 "" "" ""
.SH BEZEICHNUNG
mkosi \[en] Maßgeschneiderte Betriebssystemabbilder bauen
.SH ÜBERSICHT
\f[CR]mkosi [Optionen…] summary\fR
.PP
\f[CR]mkosi [Optionen…] cat\-config\fR
.PP
\f[CR]mkosi [Optionen…] build [Befehlszeile…]\fR
.PP
\f[CR]mkosi [Optionen…] shell [Befehlszeile…]\fR
.PP
\f[CR]mkosi [Optionen…] boot [Nspawn\-Einstellungen…]\fR
.PP
\f[CR]mkosi [Optionen…] vm [Vmm\-Parameter…]\fR
.PP
\f[CR]mkosi [Optionen…] ssh [Befehlszeile…]\fR
.PP
\f[CR]mkosi [Optionen…] journalctl [Befehlszeile…]\fR
.PP
\f[CR]mkosi [Optionen…] coredumpctl [Befehlszeile…]\fR
.PP
\f[CR]mkosi [Optionen…] sysupdate [Befehlszeile…]\fR
.PP
\f[CR]mkosi [Optionen…] sandbox [Befehlszeile…]\fR
.PP
\f[CR]mkosi [Optionen…] clean\fR
.PP
\f[CR]mkosi [Optionen…] serve\fR
.PP
\f[CR]mkosi [Optionen…] burn <Gerät>\fR
.PP
\f[CR]mkosi [Optionen…] bump\fR
.PP
\f[CR]mkosi [Optionen…] genkey\fR
.PP
\f[CR]mkosi [Optionen…] documentation [Handbuch]\fR
.PP
\f[CR]mkosi [Optionen…] completion [Shell]\fR
.PP
\f[CR]mkosi [Optionen…] dependencies\fR
.PP
\f[CR]mkosi [Optionen…] help\fR
.SH BESCHREIBUNG
\f[B]mkosi\f[R] ist ein Werkzeug zum leichten Bau angepasster
Betriebssystemabbilder. Es ist eine kunstvolle Hülle für \f[B]dnf\f[R],
\f[B]apt\f[R](8), \f[B]pacman\f[R](8) und \f[B]zypper\f[R](8), die
Plattenabbilder mit einer Reihe von Schnickschnack erstellen können.
.SS Unterbefehle
Die folgenden Unterbefehle werden erkannt:
.TP 
\f[CR]summary\fR
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.\fR
.TP 
\f[CR]cat\-config\fR
Gibt die Namen und Inhalte aller geladenen Konfigurationsdateien
aus. \f[B]mkosi\f[R] lädt einen Schwung Dateien aus verschiedenen Orten und
dieser Befehl erleichtert es herauszufinden, was wo konfiguriert ist.\fR
.TP 
\f[CR]build\fR
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.
.TP 
\f[CR]shell\fR
Dies baut das Abbild, falls es noch nicht gebaut ist, und ruft dann
\f[CB]systemd\-nspawn\f[R](1) auf, um eine interaktive Shell im Abbild
auszuführen. Dafür muss das System nicht gestartet werden, es ist eher wie
eine bessere \f[B]chroot\f[R](8). Nach dem Unterbefehl \f[CR]shell\f[R] kann
eine optionale Befehlszeile angegeben werden, die anstelle der Shell in dem
Container aufgerufen werden soll. Verwenden Sie \f[CR]\-f\f[R], um das Abbild
bedingungslos vor dem Erlangen der Shell neuzubauen, siehe unten. Dieser
Befehl muss als \f[CR]root\f[R] ausgeführt werden.\fR
.TP 
\f[CR]boot\fR
Ähnlich wie \f[CR]shell\f[R], startet \f[CB]systemd\f[R](1) im Abbild
mittels \f[B]systemd\-nspawn\f[R](1) anstatt eine Shell zu öffnen. Nach dem
Unterbefehl \f[CR]boot\f[R] kann eine optionale Befehlszeile angegeben
werden, die zusätzliche Nspawn\-Optionen sowie Argumente enthalten kann, die
an die \f[I]Kernelbefehlszeile\f[R] des Init\-Systems im Abbild übergeben
werden.\fR
.TP 
\f[CR]vm\fR
Ähnlich wie \f[CR]boot\f[R], verwendet aber den konfigurierten Monitor für
virtuelle Maschinen (standardmäßig \f[CR]qemu\f[R]), 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 \f[CR]VirtualMachineMonitor=\f[R]
für weitere Informationen.\fR
.TP 
\f[CR]ssh\fR
Wenn das Abbild mit der Option \f[CR]Ssh=yes\f[R] gebaut wird, verbindet
dieser Befehl die gestartete virtuelle Maschine mittels SSH. Stellen Sie
sicher, dass \f[CR]mkosi ssh\f[R] mit der gleichen Konfiguration wie
\f[CR]mkosi build\f[R] 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 \f[CR]SshKey=\f[R] verwandt, um sich mit der virtuellen Maschine
zu verbinden. Verwenden Sie \f[CR]mkosi genkey\f[R], um automatisch einen
Schlüssel und ein Zertifikat zu erstellen, das von \f[B]mkosi\f[R]
aufgenommen wird. Alle nach dem Unterbefehl \f[CR]ssh\f[R] übergebene
Argumente werden als Argumente an den Aufruf von \f[B]ssh\f[R](1)
übergeben. Um sich mit einem Container zu verbinden, verwenden Sie
\f[CR]machinectl login\f[R] oder \f[CR]machinectl shell\f[R].\fR
.RS
.PP
Die Option \f[CR]Machine=\f[R] kann dazu verwandt werden, der Maschine beim
Systemstart einen angepassten Rechnernamen zu geben, der später für einen
\f[B]ssh\f[R](1)\-Zugang verwandt werden kann (z.B.\ \f[CR]mkosi
\-\-machine=meinemaschine vm\f[R] gefolgt von \f[CR]mkosi
\-\-machine=meinemaschine ssh\f[R]).\fR
.RE
.TP 
\f[CR]journalctl\fR
Verwendet \f[B]journalctl\f[R](1), um das Journal innerhalb des Abbildes zu
untersuchen. Alle nach dem Unterbefehl \f[B]journalctl\f[R] angegebenen
Argumente werden an den Aufruf von \f[B]journalctl\f[R](1) angehängt.\fR
.TP 
\f[CR]coredumpctl\fR
Verwendet \f[B]coredumpctl\f[R](1), um nach Speicherabbilder innerhalb des
Abbilds zu suchen. Alle nach dem Unterbefehl \f[B]coredumpctl\f[R]
angegebenen Argumente werden an den Aufruf von \f[B]coredumpctl\f[R](1)
angehängt.\fR
.TP 
\f[CR]sysupdate\fR
Ruft \f[B]systemd\-sysupdate\f[R](8) auf, wobei die Option
\f[CR]\-\-transfer\-source=\f[R] auf das Ausgabeverzeichnis und die Option
\f[CR]\-\-definitions=\f[R] auf das mit \f[CR]SysupdateDirectory=\f[R]
konfigurierte Verzeichnis gesetzt ist. Alle nach dem Unterbefehl
\f[CR]sysupdate\f[R] festgelegten Argumente werden direkt an den Aufruf von
\f[B]systemd\-sysupdate\f[R](8) weitergegeben.\fR
.TP 
\f[CR]sandbox\fR
Ruft beliebige Befehle innerhalb der gleichen Sandbox auf, die zur
Ausführung anderer Unterbefehle wie \f[CR]boot\f[R], \f[CR]shell\f[R],
\f[CR]vm\f[R] und weiteren verwandt wird. Dies bedeutet, dass
\f[CR]/usr\f[R] durch \f[CR]/usr\f[R] vom Werkzeugbaum ersetzt wird, falls
einer verwandt wird, während ansonsten alles andere am Ort verbleibt. Falls
kein Befehl bereitgestellt wird, wird \f[CR]$SHELL\f[R] oder
\f[B]bash\f[R](1), falls \f[CR]$SHELL\f[R] nicht gesetzt ist, ausgeführt.\fR
.TP 
\f[CR]clean\fR
Entfernt aus vorherigen Bauläufen erstellte Bauartefakte. Falls mit
\f[CR]\-f\f[R] kombiniert, werden auch inkrementelle
Bauzwischenspeicher\-Abbilder entfernt. Falls \f[CR]\-f\f[R] zweimal angegeben
ist, werden sämtliche Paketzwischenspeicher entfernt.\fR
.TP 
\f[CR]serve\fR
Dies baut das Abbild, falls es noch nicht gebaut wurde und liefert dann das
Ausgabeverzeichnis (d.h. normalerweise \f[CR]mkosi.output/\f[R], s.u.) über
einen kleinen eingebauten HTTP\-Server, der auf Port 8081 auf Anfragen
wartet, aus. Kombinieren Sie dies mit \f[CR]\-f\f[R], um das Abbild
bedingungslos neuzubauen, bevor es ausgeliefert wird. Dieser Befehl ist für
das Testen netzwerkbasierten Erwerbens von Betriebssystemabbildern nützlich,
beispielsweise mittels \f[CR]machinectl pull\-raw …\f[R] und \f[CR]machinectl
pull\-tar …\f[R].\fR
.TP 
\f[CR]burn <device>\fR
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.
.TP 
\f[CR]bump\fR
Erhöht die Version des Abbildes aus \f[CR]mkosi.version\f[R] und schreibt
die resultierende Versionszeichenkette nach \f[CR]mkosi.version\f[R]. 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
\f[CR]\-\-auto\-bump\f[R]/\f[CR]\-B\f[R] zum automatischen Erhöhen der Version
nach jedem erfolgreichen Bau verwandt werden kann.\fR
.TP 
\f[CR]genkey\fR
Erstellt ein Paar von SecureBoot\-Schlüsseln zur Verwendung mit den Optionen
\f[CR]SecureBootKey=\f[R]/\f[CR]\-\-secure\-boot\-key=\f[R] und
\f[CR]SecureBootCertificate=\f[R]/\f[CR]\-\-secure\-boot\-certificate=\f[R].\fR
.TP 
\f[CR]documentation\fR
Zeigt die Dokumentation von \f[B]mkosi\f[R]. Falls kein Argument angegeben
ist, wird die Handbuchseite \f[B]mkosi\f[R](1) angezeigt, aber die Argumente
\f[CR]mkosi\f[R], \f[CR]mkosi\-initrd\f[R], \f[CR]initrd\f[R],
\f[CR]mkosi\-sandbox\f[R], \f[CR]sandbox\f[R], \f[CR]mkosi.news\f[R] und
\f[CR]news\f[R] werden unterstützt und zeigen die Handbuchseiten für
\f[B]mkosi\f[R](1), \f[B]mkosi\-initrd\f[R](1), \f[B]mkosi\-sandbox\f[R](1)
bzw. die NEWS\-Datei von \f[B]mkosi\f[R] an.\fR
.RS
.PP
Standardmäßig wird dieser Unterbefehl verschiedene Arten zur Ausgabe der
Dokumentation ausprobieren, eine bestimmte Option kann mit der Option
\f[CR]\-\-doc\-format\f[R] ausgewählt werden. Paketierer von Distributionen
wird empfohlen, eine Datei \f[CR]mkosi.1\f[R] in das Verzeichnis
\f[CR]mkosi/resources\f[R] 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
\f[CR]mkosi/resources/man/mkosi.1.md\f[R] zum Beispiel mittels \f[CR]pandoc
\-t man \-s \-o mkosi.1 mkosi.1.md\f[R] erstellt werden.\fR
.RE
.TP 
\f[CR]completion\fR
Erstellt Shell\-Vervollständigungen für die als Argument übergebene Shell und
gibt diese auf der Standardausgabe aus. Es werden die Argumente
\f[CR]bash\f[R], \f[CR]fish\f[R] und \f[CR]zsh\f[R] verstanden.\fR
.TP 
\f[CR]dependencies\fR
Gibt die Liste der von \f[B]mkosi\f[R] zum Bauen und Starten von Abbildern
benötigten Pakete aus.\fR
.RS
.PP
Diese Liste kann direkt an einen Paketverwalter weitergeleitet werden, um
die Pakete zu installieren. Falls beispielsweise das Wirtsystem den
\f[B]dnf\f[R]\-Paketverwalter verwendet, könnten die Pakete wie folgt
installiert werden:
.IP
.EX
mkosi dependencies \f[B]|\f[R] xargs \-d \[aq]\[rs]n\[aq] dnf install\fR
.EE
.RE
.TP 
\f[CR]help\fR
Dieser Unterbefehl ist identisch zum nachfolgend dokumentierten Schalter
\f[CR]\-\-help\f[R]: Er zeigt eine kurze Erklärung zur Verwendung.\fR
.SS "Reine Befehlszeilenoptionen"
Diese Einstellungen können nicht mittels der Konfigurationsdateien
konfiguriert werden.
.TP 
\f[CR]\-\-force\f[R], \f[CR]\-f\fR
Ersetzt beim Bau eines Abbildes die Ausgabedatei, falls sie bereits
existiert. Standardmäßig verweigert \f[B]mkosi\f[R] 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 \f[B]Dateien\f[R]) wird die dreimalige Angabe
sicherstellen, dass auch der Paketzwischenspeicher entfernt wird, bevor der
Neubau eingeleitet wird. Für die Aktion \f[CR]clean\f[R] 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.\fR
.TP 
\f[CR]\-\-directory=\f[R], \f[CR]\-C\fR
Akzeptiert einen Pfad zu einem Verzeichnis. Vor allen anderen Aktivitäten
wechselt \f[B]mkosi\f[R] 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.\fR
.TP 
\f[CR]\-\-debug\fR
Aktiviert zusätzliche Fehlersuchausgaben.
.TP 
\f[CR]\-\-debug\-shell\fR
Falls die Ausführung eines Befehls in dem Abbild fehlschlägt, wird
\f[B]mkosi\f[R] eine interaktive Shell in dem Abbild starten, um ein weitere
Fehlersuche zu ermöglichen.
.TP 
\f[CR]\-\-debug\-workspace\fR
Löscht, wenn angegeben, das Arbeitsbereichsverzeichnis nicht und seine Lage
wird protokolliert, wenn sich \f[B]mkosi\f[R] beendet.\fR
.TP 
\f[CR]\-\-debug\-sandbox\fR
Führt \f[B]mkosi\-sandbox\f[R](1) mit \f[B]strace\f[R](1) aus.\fR
.TP 
\f[CR]\-\-version\fR
Zeigt die Paketversion.
.TP 
\f[CR]\-\-help\f[R], \f[CR]\-h\fR
Zeigt einen kurzen Hinweis zum Aufruf.
.TP 
\f[CR]\-\-genkey\-common\-name=\fR
Allgemeiner Name, der bei der Erzeugung von Schlüsseln mittels des Befehls
\f[CR]genkey\f[R] von \f[B]mkosi\f[R] verwandt wird. Standardmäßig
\f[CR]mkosi of %u\f[R], wobei \f[CR]%u\f[R] auf den Benutzernamen des
Benutzer, der \f[B]mkosi\f[R] aufruft, erweitert wird.\fR
.TP 
\f[CR]\-\-genkey\-valid\-days=\fR
Anzahl an Tagen, die Schlüssel gültig bleiben sollen, wenn Schlüssel mit dem
Befehl \f[CR]genkey\f[R] von \f[B]mkosi\f[R] erstellt werden. Standardmäßig
zwei Jahre (730 Tage).\fR
.TP 
\f[CR]\-\-auto\-bump=\f[R], \f[CR]\-B\fR
Falls angegeben wird nach jedem erfolgreichen Bau in Vorbereitung des
nächsten Baus die Version auf eine ähnliche Art wie beim Unterbefehl
\f[CR]bump\f[R] 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.\fR
.TP 
\f[CR]\-\-doc\-format\fR
Das Format, in dem die Dokumentation angezeigt werden soll. Unterstützt die
Werte \f[CR]markdown\f[R], \f[CR]man\f[R], \f[CR]pandoc\f[R],
\f[CR]system\f[R] und \f[CR]auto\f[R]. Im Falle von \f[CR]markdown\f[R] wird
die Dokumentation im usrpünglichen Markdown\-Format angezeigt. \f[CR]man\f[R]
zeigt die Dokumentation im Handbuchseitenformat, falls dies verfügbar
ist. \f[CR]pandoc\f[R] erstellt das Handbuchseitenformat dynamisch, falls
\f[CB]pandoc\f[R](1) verfügbar ist. \f[CR]system\f[R] zeigt die systemweite
Handbuchseite für \f[B]mkosi\f[R], die nicht zwingend der Version
entspricht, die Sie verwenden, abhängig davon, wie \f[B]mkosi\f[R]
installiert wurde. \f[CR]auto\f[R] (die Vorgabe) wird alle Methoden in der
Reihenfolge \f[CR]man\f[R], \f[CR]pandoc\f[R], \f[CR]markdown\f[R],
\f[CR]system\f[R] ausprobieren.\fR
.TP 
\f[CR]\-\-json\fR
Zeigt die zusammenfassende Ausgabe als JSON\-SEQ.
.TP 
\f[CR]\-\-wipe\-build\-dir\f[R], \f[CR]\-w\fR
Vernichtet vor dem Bau des Abbildes das Bauverzeichnis, falls eines
konfiguriert ist.
.SS "Unterstützte Ausgabeformate"
Die folgenden Ausgabeformate werden unterstützt:
.IP \[bu] 2
Rohes \f[I]GPT\f[R]\-Plattenabbild, mittels \f[B]systemd\-repart\f[R](8)
erstellt (\f[I]Platte\f[R])\fR
.IP \f[R]\[bu]\fR 2
Einfaches Verzeichnis, enthält den Betriebssystembaum
(\f[I]Verzeichnis\f[R])\fR
.IP \f[R]\[bu]\fR 2
TAR\-Archiv (\f[I]tar\f[R])\fR
.IP \f[R]\[bu]\fR 2
CPIO\-Archiv (\f[I]cpio\f[R])\fR
.PP
Das Ausgabeformat kann auch auf \f[I]none\f[R] gesetzt werden, wenn Sie
möchten, dass \f[B]mkosi\f[R] ü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).\fR
.PP
Wenn ein \f[I]GPT\f[R]\-Plattenabbild erstellt wird, können
Repart\-Partitionsdefinitionsdateien in \f[CR]mkosi.repart/\f[R] abgelegt
werden, um das erstellte Plattenabbild zu konfigurieren.\fR
.PP
Es wird nachdrücklich empfohlen, \f[B]mkosi\f[R] auf einem Dateisystem
auszuführen, das Reflinks unterstützt, wie \f[V]xfs\f[R](5) und
\f[V]btrfs\f[R](5) und alle zusammengehörigen Verzeichnisse auf dem gleichen
Dateisystem zu behalten. Dies ermöglicht es \f[B]mkosi\f[R], Abbilder sehr
schnell durch Verwendung von Reflinks zur Durchführung von
Kopieren\-Beim\-Schreiben\-Aktionen zu erstellen.\fR
.SS Konfigurationseinstellungen
Die folgenden Einstellungen können über Konfigurationsdateien (der Syntax
mit \f[CR]EineEinstellung=Wert\f[R]) und auf der Befehlszeile (der Syntax
mit \f[CR]\-\-Eine\-Einstellung=Wert\f[R]) 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.\fR
.PP
Die Konfiguration wird in der folgenden Reihenfolge ausgewertet:
.IP \[bu] 2
Die Befehlszeilenargumente werden ausgewertet.
.IP \[bu] 2
\f[CR]mkosi.local.conf\f[R] oder \f[CR]mkosi.local\f[R] wird ausgewertet,
falls es existiert. Diese Datei oder das Verzeichnis sollte in
\&\f[CR].gitignore\f[R] (oder äquivalent) sein und ist für lokale
Konfiguration gedacht.\fR
.IP \f[R]\[bu]\fR 2
Alle Vorgabepfade (abhängig von der Option) werden konfiguriert, falls der
entsprechende Pfad existiert.
.IP \[bu] 2
\f[CR]mkosi.conf\f[R] wird ausgewertet, falls es in dem mit
\f[CR]\-\-directory=\f[R] konfigurierten Verzeichnis liegt oder im aktuellen
Verzeichnis, falls \f[CR]\-\-directory=\f[R] nicht verwandt wird.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]mkosi.conf.d/\f[R] wird im gleichen Verzeichnis ausgewertet, falls sie
existiert. Jedes Verzeichnis und jede Datei mit der Endung \f[CR].conf\f[R]
in \f[CR]mkosi.conf.d/\f[R] wird ausgewertet. Jedes Verzeichnis in
\f[CR]mkosi.conf.d\f[R] wird ausgewertet, als ob es ein normales Verzeichnis
auf der obersten Ebene wäre.\fR
.IP \f[R]\[bu]\fR 2
Falls irgendwelche Profile definiert sind, werden deren Konfiguration aus
dem Verzeichnis \f[CR]mkosi.profiles/\f[R] ausgewertet.\fR
.IP \f[R]\[bu]\fR 2
Unterabbilder werden aus dem Verzeichnis \f[CR]mkosi.images\f[R]
ausgewertet, falls es existiert.\fR
.PP
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 \f[CR]mkosi.local\f[R] oder
\f[CR]mkosi.local.conf\f[R] gelesen werden Einstellungen von anderen
Konfigurationsdateien, die später ausgewertet werden, außer Kraft setzen,
allerdings nicht solche, die auf der Befehlszeile angegeben werden.\fR
.PP
Für Einstellungen, die einen einzelnen Wert akzeptieren, kann die leere
Zuweisung (\f[CR]EineEinstellung=\f[R] oder \f[CR]\-\-eine\-einstellung=\f[R])
zum Außerkraftsetzen einer vorherigen Einstellung und zum Zurücksetzen auf
die Vorgabewerte verwandt werden.\fR
.PP
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.
.PP
Um Konfigurationsdateien bedingt einzubinden, kann der Abschnitt
\f[CR][Match]\f[R] verwandt werden. Ein Abschnitt \f[CR][Match]\f[R] besteht
aus einzelnen Bedingungen. Bedingungen können ein Weiterleitungssymbol
(\f[CR]|\f[R]) nach dem Gleichheitszeichen verwenden
(\f[CR]…=|…\f[R]). 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.\fR
.PP
Beachten Sie, dass die Bedingungen in \f[CR][Match]\f[R] 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.\fR
.PP
Der Abschnitt \f[CR][Match]\f[R] in einer Datei \f[CR]mkosi.conf\f[R] in
einem Verzeichnis gilt für das gesamte Verzeichnis. Falls die Bedingungen
nicht erfüllt sind, wird das gesamte Verzeichnis übersprungen. Die
Abschnitte \f[CR][Match]\f[R] von Dateien in \f[CR]mkosi.conf.d/\f[R] und
\f[CR]mkosi.local.conf\f[R] gelten nur für die Datei selbst.\fR
.PP
Falls es mehrere Abschnitte \f[CR][Match]\f[R] 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 \f[CR][Match]\f[R] und werden
zwischen mehreren Abschnitten \f[CR][Match]\f[R] zurückgesetzt. In dem
folgenden Beispiel erfolgt nur eine Übereinstimmung, falls das Ausgabeformat
entweder \f[CR]disk\f[R] oder \f[CR]directory\f[R] ist und die Architektur
entweder \f[CR]x86\-64\f[R] oder \f[CR]arm64\f[R] ist:\fR
.IP
.EX
\f[B][Match]\f[R]
Format=|disk
Format=|directory\fR

\f[B][Match]\f[R]
Architecture=|x86\-64
Architecture=|arm64\fR
.EE
.PP
Der Abschnitt \f[CR][TriggerMatch]\f[R] 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
\f[CR]debian\f[R] und die Veröffentlichung \f[CR]bookworm\f[R] ist oder
falls die Distribution \f[CR]ubuntu\f[R] und die Veröffentlichung
\f[CR]noble\f[R] ist.\fR
.IP
.EX
\f[B][TriggerMatch]\f[R]
Distribution=debian
Release=bookworm\fR

\f[B][TriggerMatch]\f[R]
Distribution=ubuntu
Release=noble\fR
.EE
.PP
Die Semantik von Bedingungen in \f[CR][TriggerMatch]\f[R]\-Abschnitten ist
identisch zu \f[CR][Match]\f[R], d.h. alle normalen Bedingungen werden durch
ein logisches UND und alle auslösenden Bedingungen werden durch ein
logisches ODER zusammengefasst. Beim Mischen von \f[CR][Match]\f[R]\- und
\f[CR][TriggerMatch]\f[R]\-Abschnitten wird eine Übereinstimmung erreicht,
wenn alle \f[CR][Match]\f[R]\-Abschnitte übereinstimmen und mindestens ein
\f[CR][TriggerMatch]\f[R]\-Abschnitt übereinstimmt. Die Abwesenheit eines
Übereinstimmungsabschnittes wird als true ausgewertet. Logisch bedeutet
dies:\fR
.IP
.EX
(⋀ᵢ Matchᵢ) ∧ (⋁ᵢ TriggerMatchᵢ)
.EE
.PP
Befehlszeilenoptionen, die kein Argument akzeptieren, werden ohne
\f[CR]=\f[R] in ihrer langen Version angezeigt. In der Konfigurationsdatei
sollten sie mit einem logischen Argument angegeben werden: entweder
\f[CR]1\f[R], \f[CR]yes\f[R] oder \f[CR]true\f[R] zum aktivieren oder
\f[CR]0\f[R], \f[CR]no\f[R], \f[CR]false\f[R] zum deaktivieren.\fR
.SS "Abschnitt [Distribution]"
.TP 
\f[CR]Distribution=\f[R], \f[CR]\-\-distribution=\f[R], \f[CR]\-d\fR
Die im Abbild zu installierende Distribution. Akzeptiert eines der folgenden
Argumente: \f[CR]fedora\f[R], \f[CR]debian\f[R], \f[CR]kali\f[R],
\f[CR]ubuntu\f[R], \f[CR]arch\f[R], \f[CR]opensuse\f[R], \f[CR]mageia\f[R],
\f[CR]centos\f[R], \f[CR]rhel\f[R], \f[CR]rhel\-ubi\f[R],
\f[CR]openmandriva\f[R], \f[CR]rocky\f[R], \f[CR]alma\f[R], \f[CR]azure\f[R]
oder \f[CR]custom\f[R]. Falls nicht angegeben ist die Vorgabe die
Distribution des Wirtsystems oder \f[CR]custom\f[R], falls die Distribution
des Wirtsystems keine unterstützte Distribution ist.\R
.TP 
\f[CR]Release=\f[R], \f[CR]\-\-release=\f[R], \f[CR]\-r\fR
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. \f[CR]29\f[R]) oder ein Versionsname der
Distribution (im Falle von Debian, Kali, Ubuntu, …,
z.B. \f[CR]artful\f[R]). 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.\fR
.TP 
\f[CR]Architecture=\f[R], \f[CR]\-\-architecture=\fR
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.
.RS
.PP
Pro gebautem Abbild kann eine der folgenden Architekturen festgelegt werden:
\f[CR]alpha\f[R], \f[CR]arc\f[R], \f[CR]arm\f[R], \f[CR]arm64\f[R],
\f[CR]ia64\f[R], \f[CR]loongarch64\f[R], \f[CR]mips64\-le\f[R],
\f[CR]mips\-le\f[R], \f[CR]parisc\f[R], \f[CR]ppc\f[R], \f[CR]ppc64\f[R],
\f[CR]ppc64\-le\f[R], \f[CR]riscv32\f[R], \f[CR]riscv64\f[R],
\f[CR]s390\f[R], \f[CR]s390x\f[R], \f[CR]tilegx\f[R], \f[CR]x86\f[R],
\f[CR]x86\-64\f[R].\fR
.RE
.TP 
\f[CR]Mirror=\f[R], \f[CR]\-\-mirror=\f[R], \f[CR]\-m\fR
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.
.RS
.PP
Die Standard\-Spiegel für jede Distribution sind wie folgt (sofern nicht
angegeben, wird der gleiche Spiegel für alle Architekturen verwandt):
.PP
.TS
tab(@);
lw(13.5n) lw(29.5n) lw(27.0n).
T{
T}@T{
X86\-64
T}@T{
Aarch64
T}
_
T{
\f[CR]Debian\fR
T}@T{
\f[R]http://deb.debian.org/debian\fR
T}@T{
T}
T{
\f[CR]Arch\fR
T}@T{
\f[R]https://geo.mirror.pkgbuild.com\fR
T}@T{
\f[R]http://mirror.archlinuxarm.org\fR
T}
T{
\f[CR]OpenSUSE\fR
T}@T{
\f[R]http://download.opensuse.org\fR
T}@T{
T}
T{
\f[CR]kali\fR
T}@T{
\f[R]http://http.kali.org/kali\fR
T}@T{
T}
T{
\f[CR]Ubuntu\fR
T}@T{
\f[R]http://archive.ubuntu.com\fR
T}@T{
\f[R]http://ports.ubuntu.com\fR
T}
T{
\f[CR]Centos\fR
T}@T{
\f[R]https://mirrors.centos.org\fR
T}@T{
T}
T{
\f[CR]Rocky\fR
T}@T{
\f[R]https://mirrors.rockylinux.org\fR
T}@T{
T}
T{
\f[CR]Alma\fR
T}@T{
\f[R]https://mirrors.almalinux.org\fR
T}@T{
T}
T{
\f[CR]Fedora\fR
T}@T{
\f[R]https://mirrors.fedoraproject.org\fR
T}@T{
T}
T{
\f[CR]RHEL\-ubi\fR
T}@T{
\f[R]https://cdn\-ubi.redhat.com\fR
T}@T{
T}
T{
\f[CR]Mageia\fR
T}@T{
\f[R]https://www.mageia.org\fR
T}@T{
T}
T{
\f[CR]Openmandriva\fR
T}@T{
\f[R]http://mirrors.openmandriva.org\fR
T}@T{
T}
T{
\f[CR]azure\fR
T}@T{
\f[R]https://packages.microsoft.com/\fR
T}@T{
T}
.TE
.RE
.TP 
\f[CR]LocalMirror=\f[R], \f[CR]\-\-local\-mirror=\fR
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 \f[B]deb\f[R]\-,
\f[B]rpm\f[R]\- und \f[B]pacman\f[R]\-basierte Distributionen
unterstützt. Setzt \f[CR]\-\-mirror=\f[R] außer Kraft, aber nur für lokale
\f[B]mkosi\f[R]\-Bauten, es wird nicht im letztendlichen Abbild konfiguriert,
stattdessen wird \f[CR]\-\-mirror=\f[R] (oder das Standard\-Depot) innerhalb
des letztendlichen Abbilds konfiguriert.\fR
.TP 
\f[CR]RepositoryKeyCheck=\f[R], \f[CR]\-\-repository\-key\-check=\fR
Steuert die Signatur\-/Schlüsselüberprüfung bei der Verwendung von Depots,
standardmäßig aktiviert. Die Deaktivierung ist bei der Kombination mit
\f[CR]\-\-local\-mirror=\f[R] und der ausschließlichen Verwendung eines lokalen
Depots aus einem lokalen Dateisystem nützlich.\fR
.TP 
\f[CR]RepositoryKeyFetch=\f[R], \f[CR]\-\-repository\-key\-fetch=\fR
Steuert, ob \f[B]mkosi\f[R] 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.\fR
.RS
.PP
Diese Einstellung ist nur für Distributionen implementiert, die
\f[B]dnf\f[R], \f[B]pacman\f[R](8) oder \f[B]zypper\f[R](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 \f[CR]archlinux\-keyring\f[R],
\f[CR]debian\-keyring\f[R], \f[CR]kali\-archive\-keyring\f[R],
\f[CR]ubuntu\-keyring\f[R] oder \f[CR]distribution\-gpg\-keys\f[R] (für
RPM\-basierte Distributionen).\fR
.RE
.TP 
\f[CR]Repositories=\f[R], \f[CR]\-\-repositories=\fR
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.
.SS "Abschnitt [Output]"
.TP 
\f[CR]Format=\f[R], \f[CR]\-\-format=\f[R], \f[CR]\-t\fR
Das zu erstellende Abbild\-Format. Entweder \f[CR]directory\f[R] (zur
direkten Erstellung eines Betriebssystemabbildes im lokalen Verzeichnis),
\f[CR]tar\f[R] (ähnlich, es wird aber ein Tarball des Betriebssystemabbildes
erstellt), \f[CR]cpio\f[R] (ähnlich, es wird aber ein Cpio\-Archiv erstellt),
\f[CR]disk\f[R] (ein Blockgerät\-Betriebssystemabbild mit einer
GPT\-Partitionstabelle), \f[CR]uki\f[R] (ein vereinigtes Kernel\-Abbild mit
einem Betriebssystemabbild im PE\-Abschnitt \f[CR].initrd\f[R]),
\f[CR]esp\f[R] (\f[CR]uki\f[R] aber in einem Platten\-Abbild mit nur einer
ESP\-Partition eingehüllt), \f[CR]oci\f[R] (ein mit der
OCI\-Abbildspezifikation kompatibles Verzeichnis),\f[CR]sysext\f[R],
\f[CR]confext\f[R], \f[CR]portable\f[R], \f[CR]addon\f[R] oder
\f[CR]none\f[R] (das Betriebssystem\-Abbild ist nur als Bau\-Artefakt zur
Erstellung eines weiteren Artefaktes gedacht).\fR
.RS
.PP
Falls das Ausgabeformat \f[CR]disk\f[R] verwandt wird, wird das
Plattenabbild mittels \f[B]systemd\-repart\f[R](8) erstellt. Die zu
verwendenden Repart\-Partitions\-Definitionsdateien können mittels der
Einstellung \f[CR]RepartDirectories=\f[R] oder mittels
\f[CR]mkosi.repart/\f[R] konfiguriert werden. Wenn Verity\-Partitionen
mittels der Einstellung \f[CR]Verity=\f[R] von \f[B]systemd\-repart\f[R](8)
konfiguriert werden, wird \f[B]mkosi\f[R] automatisch den Root\-Hash der
Verity\-Hash\-Partition aus der JSON\-Ausgabe von \f[B]systemd\-repart\f[R](8)
auswerten und ihn in die Kernel\-Befehlszeile jedes durch \f[B]mkosi\f[R]
gebauten vereinigten Kernel\-Abbildes aufnehmen.\fR
.PP
Falls das Format \f[CR]none\f[R] verwandt wird, werden die Ausgaben von
vorherigen Bauten nicht entfernt, aber Bereinigungsskripte (siehe
\f[CR]CleanScripts=\f[R]) werden weiterhin ausgeführt. Dies ermöglicht das
erneute Ausführen von Bauskripten (siehe \f[CR]BuildScripts=\f[R]), ohne die
Ergebnisse eines vorherigen Baus zu entfernen.\fR
.RE
.TP 
\f[CR]ManifestFormat=\f[R], \f[CR]\-\-manifest\-format=\fR
Den oder die zu erstellende Manifestformattyp oder \-typen. Eine
Kommata\-getrennte Liste, die aus \f[CR]json\f[R] (das
Standard\-JSON\-Ausgabeformat, das die zu installierenden Pakete beschreibt),
\f[CR]changelog\f[R] (ein menschenlesbares Textformat, das zum Ermitteln von
Unterschieden entwickelt wurde) besteht. Standardmäßig wird kein Manifest
erstellt.\fR
.TP 
\f[CR]Output=\f[R], \f[CR]\-\-output=\f[R], \f[CR]\-o\fR
Für die erstellte Ausgabedatei oder das Ausgabeverzeichnis zu verwendender
Name. Standardmäßig \f[CR]image\f[R] oder, falls \f[CR]ImageId=\f[R]
verwandt wird, wird dieser als standardmäßiger Ausgabename verwandt,
optional wird die mit \f[CR]ImageVersion=\f[R] angegebene Version angehängt
oder der Name des Abbildes wird gegenüber \f[CR]ImageId\f[R] bevorzugt,
falls ein bestimmtes Abbild aus \f[CR]mkosi.images\f[R] gebaut
wird. Beachten Sie, dass diese Option nicht die Konfiguration des
Ausgabeverzeichnisses ermöglicht, verwenden Sie dafür
\f[CR]OutputDirectory=\f[R].
.RS
.PP
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 \f[CR]image_7.8.raw.xz\f[R] sein.\fR
.RE
.TP 
\f[CR]CompressOutput=\f[R], \f[CR]\-\-compress\-output=\fR
Konfiguriert die Komprimierung für das resultierende Abbild oder Archiv. Das
Argument kann entweder ein logischer Wert oder ein Komprimierungsalgorithmus
(\f[B]xz\f[R](1), \f[B]zstd\f[R](1)) sein. Standardmäßig wird die
Komprimierung \f[B]zstd\f[R](1) sein, außer bei CentOS und abgeleiteten
Distributionen bis Version 8, wo die Vorgabe \f[B]xz\f[R](1) ist und bei
OCI\-Abbildern, wo die Vorgabe \f[B]gzip\f[R](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 \f[CR]shell\f[R],
\f[CR]boot\f[R], \f[CR]vm\f[R] bei der Verwendung dieser Option nicht
verfügbar sind. Impliziert für \f[CR]tar\f[R], \f[CR]cpio\f[R],
\f[CR]uki\f[R], \f[CR]esp\f[R], \f[CR]oci\f[R] und \f[CR]addon\f[R].\fR
.TP 
\f[CR]CompressLevel=\f[R], \f[CR]\-\-compress\-level=\fR
Konfiguriert die zu verwendende Komprimierungsstufe. Akzeptiert eine
Ganzzahl. Die möglichen Werte hängen von der verwandten Komprimierung ab.
.TP 
\f[CR]OutputDirectory=\f[R], \f[CR]\-\-output\-directory=\f[R], \f[CR]\-O\fR
Pfad zu einem Verzeichnis, in dem alle erstellten Artefakte abgelegt werden
sollen. Falls dies nicht angegeben ist und das Verzeichnis
\f[CR]mkosi.output/\f[R] im lokalen Verzeichnis existiert, dann wird dies
automatisch für diesen Zweck verwandt.\fR
.TP 
\f[CR]OutputMode=\f[R], \f[CR]\-\-output\-mode=\fR
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.
.TP 
\f[CR]ImageVersion=\f[R], \f[CR]\-\-image\-version=\fR
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
\f[CR]mkosi.version\f[R] (in diesem Fall kann sie bequem mit dem Unterbefehl
\f[CR]bump\f[R] oder der Option \f[CR]\-\-auto\-bump\f[R] verwaltet werden)
oder durch Lesen der Standardausgabe, falls diese ausführbar ist (siehe den
nachfolgenden Abschnitt \f[B]Skripte\f[R]), konfiguriert werden. Wenn dies
angegeben ist, wird die festgelegte Abbildversion in den standardmäßigen
Ausgabedateinamen aufgenommen, d.h. anstelle von \f[CR]image.raw\f[R] wird
die Vorgabe \f[CR]image_0.1.raw\f[R] für Version \f[CR]0.1\f[R] des Abbildes
oder ähnlich lauten. Die Version wird auch mittels \f[CR]$IMAGE_VERSION\f[R]
an alle aufgerufenen Bauskripte übergeben (das könnte nützlich sein, um es
in \f[CR]/usr/lib/os\-release\f[R] oder ähnliche einzubauen, insbesondere in
das darin befindliche Feld \f[CR]IMAGE_VERSION=\f[R]).\fR
.TP 
\f[CR]ImageId=\f[R], \f[CR]\-\-image\-id=\fR
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
\f[CR]$IMAGE_ID\f[R] an alle aufgerufenen Bauskripte übergeben. Die
Abbildkennzeichnung wird automatisch zu \f[CR]/usr/lib/os\-release\f[R]
hinzugefügt.\fR
.TP 
\f[CR]SplitArtifacts=\f[R], \f[CR]\-\-split\-artifacts\fR
Die Artekfattypen, die aus dem endgültigen Abbild herausgenommen werden
sollen. Eine Kommata\-getrennte Liste, die aus \f[CR]uki\f[R],
\f[CR]kernel\f[R], \f[CR]initrd\f[R] und \f[CR]partitions\f[R] besteht. Beim
Bauen eines selbststartenden Abbildes entsprechen \f[CR]kernel\f[R] und
\f[CR]initrd\f[R] ihren im Abbild (oder dem UKI) gefundenen Artefakten,
während \f[CR]uki\f[R] das gesamte UKI herauskopiert.\fR
.RS
.PP
Beim Bau eines Plattenabbildes und wenn \f[CR]partitions\f[R] angegeben ist,
wird \f[CR]\-\-split=yes\f[R] an \f[B]systemd\-repart\f[R](8) übergeben, damit
dies getrennte Partitionsdateien für jede konfigurierte Partition
schreibt. Lesen Sie die
.UR https://www.freedesktop.org/software/systemd/man/systemd\-repart.html#\-\-split=BOOL
Handbuchseite
.UE
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
\f[CR]/usr\f[R]\-Partition zusammen mit der zugehörigen Verity\-Partition und
einem vereinigten Kernel erweitert werden soll. Standardmäßig werden
\f[CR]uki\f[R], \f[CR]kernel\f[R] und \f[CR]initrd\f[R] rausgetrennt.\fR
.RE
.TP 
\f[CR]RepartDirectories=\f[R], \f[CR]\-\-repart\-directory=\fR
Pfade zu Verzeichnissen, die Partitionsdefinitionsdateien von
\f[CB]systemd\-repart\f[R](8) enthalten, die verwandt werden, wenn
\f[B]mkosi\f[R] \f[CB]systemd\-repart\f[R](8) beim Bau eines Plattenabbildes
aufruft. Falls \f[CR]mkosi.repart/\f[R] im lokalen Verzeichnis existiert,
wird es für diesen Zweck auch verwandt. Beachten Sie, dass \f[B]mkosi\f[R]
Repart mit \f[CR]\-\-root=\f[R] aufruft, um die Wurzel auf die Wurzel des
Abbildes zu setzen, daher werden alle Quellpfade \f[CR]CopyFiles=\f[R] in
Partitionsdefinitionsdateien relativ zum Wurzelverzeichnis des Abbildes
sein.\fR
.TP 
\f[CR]SectorSize=\f[R], \f[CR]\-\-sector\-size=\fR
Setzt die Standardsektorgröße, die \f[B]systemd\-repart\f[R](8) zum Bau eines
Plattenabilds benutzt, außer Kraft.
.TP 
\f[CR]Overlay=\f[R], \f[CR]\-\-overlay\fR
Bei der Verwendung zusammen mit \f[CR]BaseTrees=\f[R] 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.
.RS
.PP
Diese Option kann dazu verwandt werden,
.UR https://uapi\-group.org/specifications/specs/extension_image
Systemd
\f[I]Systemerweiterungen\f[R] oder \f[I]portable Dienste\f[R]
.UE
zu
erstellen\&.\fR
.RE
.TP 
\f[CR]Seed=\f[R], \f[CR]\-\-seed=\fR
Akzeptiert eine UUID oder den besonderen Wert \f[CR]random\f[R] als
Argument. Setzt den von \f[B]systemd\-repart\f[R](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 \f[CR]mkosi.seed\f[R]
im lokalen Verzeichnis existiert, wird daraus die zu verwendende UUID
gelesen. Andernfalls wird eine zufällige UUID verwandt.\fR
.TP 
\f[CR]CleanScripts=\f[R], \f[CR]\-\-clean\-script=\fR
Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als
Bereinigungsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt
\f[B]Skripte\f[R] für weitere Informationen.\fR
.SS "Abschnitt [Content]"
.TP 
\f[CR]Packages=\f[R], \f[CR]\-\-package=\f[R], \f[CR]\-p\fR
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 \f[CR]BuildPackages=\f[R], um Pakete
anzugeben, die nur in einer Überlagerung installiert werden, die eingehängt
wird, wenn die Vorbereitungsskripte mit dem Argument \f[CR]build\f[R]
ausgeführt werden und wenn die Bauskripte ausgeführt werden.\fR
.RS
.PP
Die Arten und Syntax der erlaubten \f[I]Paketangaben\f[R] hängen von dem
Paketinstallationsprogramm ab (z.B.\ \f[B]dnf\f[R] für
\f[B]rpm\f[R](8)\-basierte Distributionen oder \f[B]apt\f[R](8) für
\f[B]deb\f[R](5)\-basierte Distributionen), kann aber Paketnamen, Paketnamen
mit Versionen und/oder Architektur, Paketnamen\-Globs, Paketgruppen und
virtuelle Bereitstellungen (»provides«), einschließlich Dateipfaden,
enthalten.\fR
.PP
Siehe \f[CR]PackageDirectories=\f[R] zu Informationen darüber, wie lokale
Pakete zur Installation mit \f[CR]Packages=\f[R] verfügbar gemacht werden
können.\fR
.PP
\f[B]Beispiel\f[R]: Bei der Verwendung einer Distribution, die \f[B]dnf\f[R]
verwendet, würde die nachfolgende Konfiguration das Paket \f[B]meson\f[R](1)
(in der neusten Version), die 32\-bit\-Version des Pakets
\f[CR]libfdisk\-devel\f[R], alle verfügbaren Pakete, deren Namen mit
\f[CR]git\-\f[R] beginnt, ein \f[B]systemd\f[R]\-RPM aus dem lokalen
Dateisystem, eines der Pakete, das \f[CR]/usr/bin/ld\f[R] bereitstellt, die
Pakete in der Gruppe \f[I]Development Tools\f[R] und das Paket, das das
Python\-Modul \f[B]mypy\f[R](1) enthält, installieren.\fR
.IP
.EX
Packages=meson
         libfdisk\-devel.i686
         git\-*
         /usr/bin/ld
         \[at]development\-tools
         python3dist(mypy)
.EE
.RE
.TP 
\f[CR]BuildPackages=\f[R], \f[CR]\-\-build\-package=\fR
Ähnlich wie \f[CR]Packages=\f[R], 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 \f[CR]build\f[R]
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
\f[CR]mkosi.build\f[R] zur Ausführung benötigen. Beachten Sie, dass die hier
aufgeführten Pakete im endgültigen Abbild nicht enthalten sein werden.\fR
.TP 
\f[CR]VolatilePackages=\f[R], \f[CR]\-\-volatile\-package=\fR
Ähnlich zu \f[CR]Packages=\f[R], aber Pakete, die mit dieser Einstellung
konfiguriert sind, werden nicht zwischengespeichert, wenn
\f[CR]Incremental=\f[R] aktiviert ist und werden nach der Ausführung aller
Bauskripte installiert.\fR
.RS
.PP
Insbesondere kann diese Einstellung zur Installation von Paketen verwandt
werden, die sich oft ändern oder die durch ein Bauskript gebaut werden.
.RE
.TP 
\f[CR]PackageDirectories=\f[R], \f[CR]\-\-package\-directory=\fR
Legt Verzeichnisse fest, die zusätzliche Pakete enthalten, die während des
Baus verfügbar gemacht werden sollen. \f[B]mkosi\f[R] 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 \f[CR]mkosi.packages/\f[R] im lokalen Verzeichnis gefunden
wird, wird es auch für diesen Zweck verwandt.\fR
.TP 
\f[CR]VolatilePackageDirectories=\f[R], \f[CR]\-\-volatile\-package\-directory=\fR
Ähnlich zu \f[CR]PackageDirectories=\f[R], aber sämtliche Änderungen an den
Paketen in diesen Verzeichnissen werden die zwischengespeicherten Abbilder
nicht für ungültig erklären, falls \f[CR]Incremental=\f[R] aktiviert ist.\fR
.RS
.PP
Zusätzlich können Bauskripte weitere Pakete zu den lokalen Depots
hinzufügen, indem sie gebaute Pakete in \f[CR]$PACKAGEDIR\f[R] ablegen. Die
in \f[CR]$PACKAGEDIR\f[R] abgelegten Pakete werden von allen gebauten
Abbildern gemeinsam benutzt und sind daher zur Installation in allen
Abbildern mittels \f[CR]VolatilePackages=\f[R] verfügbar.\fR
.RE
.TP 
\f[CR]WithRecommends=\f[R], \f[CR]\-\-with\-recommends=\fR
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 \f[B]apt\f[R](8), \f[B]dnf\f[R](8) und
\f[B]zypper\f[R](8).
.TP 
\f[CR]WithDocs=\f[R], \f[CR]\-\-with\-docs\fR
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
\f[CR]$WITH_DOCS\f[R] wird an die Skripte \f[CR]mkosi.build\f[R] mit
\f[CR]0\f[R] oder \f[CR]1\f[R] weitergegeben, abhängig davon, ob diese
Option aktiviert oder deaktiviert ist.\fR
.TP 
\f[CR]BaseTrees=\f[R], \f[CR]\-\-base\-tree=\fR
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
\f[CR]CleanPackageMetadata=no\f[R] (siehe \f[CR]CleanPackageMetadata=\f[R])
enthalten muss, damit das korrekt funktioniert.
.RS
.PP
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 \f[B]git\f[R](1) gespeichert sind,
das die Metadaten für die Dateieigentümerschaft und den Zugriffsmodus für
übergebene Dateien vollständig beibehält.\fR
.RE
.TP 
\f[CR]SkeletonTrees=\f[R], \f[CR]\-\-skeleton\-tree=\fR
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 \f[CR]mkosi.skeleton/\f[R] in dem lokalen Verzeichnis gefunden
wird, wird es auch für diesen Zweck mit dem Wurzelverzeichnis als Ziel
verwandt (siehe auch den nachfolgenden Abschnitt \f[B]Dateien\f[R]).\fR
.RS
.PP
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 \f[CR]Incremental=\f[R]), nur angewandt
werden, wenn das zwischengespeicherte Abbild neu gebaut wird (durch
Verwendung von \f[CR]\-ff\f[R] oder der Ausführung von \f[CR]mkosi \-f
clean\f[R]).\fR
.PP
Gemäß der obigen Basisbaumlogik kann anstelle eines Verzeichnisses auch eine
Tar\-Datei bereitgestellt werden. \f[CR]mkosi.skeleton.tar\f[R] wird
automatisch verwandt, falls es im lokalen Verzeichnis gefunden wird.\fR
.PP
Um zusätzliche Paketverwalter\-Konfigurationsdateien wie zusätzliche Depots
hinzuzufügen, verwenden Sie \f[CR]SandboxTrees=\f[R], da \f[B]mkosi\f[R] die
Paketverwalter von außerhalb (und nicht innerhalb) des Abbildes aufruft und
daher sämtliche mittels \f[CR]SkeletonTrees=\f[R] bereitgestellte
Konfigurationsdateien nicht wirksam werden, wenn \f[B]mkosi\f[R] den
Paketverwalter zur Installation von Paketen aufruft.\fR
.RE
.TP 
\f[CR]ExtraTrees=\f[R], \f[CR]\-\-extra\-tree=\fR
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 \f[CR]mkosi.extra/\f[R] in dem
lokalen Verzeichnis gefunden wird, wird es auch für diesen Zweck mit dem
Wurzelverzeichnis als Ziel verwandt (siehe auch den nachfolgenden Abschnitt
\f[B]Dateien\f[R]).\fR
.RS
.PP
Gemäß der obigen Basisbaumlogik kann anstelle eines Verzeichnisses auch eine
Tar\-Datei bereitgestellt werden. \f[CR]mkosi.extra.tar\f[R] wird automatisch
verwandt, falls es im lokalen Verzeichnis gefunden wird.\fR
.RE
.TP 
\f[CR]RemovePackages=\f[R], \f[CR]\-\-remove\-package=\fR
Akzeptiert eine Kommata\-getrennte Liste von Spezifikation von zu
entfernenden Paketen, im gleichen Format wie \f[CR]Packages=\f[R]. Die
Entfernung erfolgt als einer der letzten Schritte. Dieser Schritt wird
übersprungen, falls \f[CR]CleanPackageMetadata=no\f[R] verwandt wird.\fR
.TP 
\f[CR]RemoveFiles=\f[R], \f[CR]\-\-remove\-files=\fR
Akzeptiert eine Kommata\-getrennte Liste von Globs. Dateien im Abbild, die
auf die Globs passen, werden am Ende vollständig entfernt.
.TP 
\f[CR]CleanPackageMetadata=\f[R], \f[CR]\-\-clean\-package\-metadata=\fR
Aktiviert/Deaktiviert das Entfernen der Paketverwalter\-Datenbanken und
Depot\-Metadaten am Ende der Installation. Kann als \f[CR]true\f[R],
\f[CR]false\f[R] oder (die Vorgabe) \f[CR]auto\f[R] angegeben werden. Bei
\f[CR]auto\f[R] werden die Paketverwalter\-Datenbanken und Depot\-Metadaten
entfernt, falls das Programm des entsprechenden Paketverwalters am Ende der
Installation \f[I]nicht\f[R] vorhanden ist.\fR
.TP 
\f[CR]SourceDateEpoch=\f[R], \f[CR]\-\-source\-date\-epoch=\fR
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 \f[B]systemd\-repart\f[R](8) und alle
von \f[B]mkosi\f[R] ausgeführten Skripte weitergegeben. Falls nicht explizit
gesetzt, wird \f[CR]SOURCE_DATE_EPOCH\f[R] aus \f[CR]\-\-environment\f[R] und
aus der Umgebung des Wirtsystems in dieser Reihenfolge ausprobiert. Siehe
.UR https://reproducible\-builds.org/specs/source\-date\-epoch/
SOURCE_DATE_EPOCH
.UE
für weitere Informationen.\fR
.TP 
\f[CR]SyncScripts=\f[R], \f[CR]\-\-sync\-script=\fR
Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als
Synchronisationsskripte für dieses Abbild verwandt werden. Siehe den
Abschnitt \f[B]Skripte\f[R] für weitere Informationen.\fR
.TP 
\f[CR]PrepareScripts=\f[R], \f[CR]\-\-prepare\-script=\fR
Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als
Vorbereitungsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt
\f[B]Skripte\f[R] für weitere Informationen.\fR
.TP 
\f[CR]BuildScripts=\f[R], \f[CR]\-\-build\-script=\fR
Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als
Bauskripte für dieses Abbild verwandt werden. Siehe den Abschnitt
\f[B]Skripte\f[R] für weitere Informationen.\fR
.TP 
\f[CR]PostInstallationScripts=\f[R], \f[CR]\-\-postinst\-script=\fR
Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als
Post\-Installationsskripte für dieses Abbild verwandt werden. Siehe den
Abschnitt \f[B]Skripte\f[R] für weitere Informationen.\fR
.TP 
\f[CR]FinalizeScripts=\f[R], \f[CR]\-\-finalize\-script=\fR
Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als
Finalisierungsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt
\f[B]Skripte\f[R] für weitere Informationen.\fR
.TP 
\f[CR]PostOutputScripts=\f[R], \f[CR]\-\-postoutput\-script\fR
Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als
Post\-Ausgabeskripte für dieses Abbild verwandt werden. Siehe den Abschnitt
\f[B]Skripte\f[R] für weitere Informationen.\fR
.TP 
\f[CR]Bootable=\f[R], \f[CR]\-\-bootable=\fR
Akzeptiert einen logischen Wert oder \f[CR]auto\f[R]. Aktiviert oder
deaktiviert die Erstellung eines startfähigen Abbildes. Falls aktiviert,
wird \f[B]mkosi\f[R] ein EFI\-Systemstartprogramm installieren und eine
ESP\-Partition hinzufügen, wenn die Plattenabbildausgabe verwandt wird. Falls
das ausgewählte EFI\-Systemstartprogramm (siehe \f[CR]Bootloader=\f[R]) nicht
installiert ist oder keine Kernelabbilder gefunden werden können, wird der
Bau fehlschlagen. \f[CR]auto\f[R] 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.\fR
.TP 
\f[CR]Bootloader=\f[R], \f[CR]\-\-bootloader=\fR
Akzeptiert entweder \f[CR]none\f[R], \f[CR]systemd\-boot\f[R],
\f[CR]uki\f[R], \f[CR]grub\f[R], \f[CR]systemd\-boot\-signed\f[R],
\f[CR]uki\-signed\f[R] oder \f[CR]grub\-signed\f[R]. Standardmäßig
\f[CR]systemd\-boot\f[R]. Falls auf \f[CR]none\f[R] gesetzt, wird kein
EFI\-Systemstartprogramm in das Abbild installiert. Falls auf
\f[CR]systemd\-boot\f[R] gesetzt, wird \f[CB]systemd\-boot\f[R](7) installiert
und für jeden installierten Kernel ein UKI erstellt und in
\f[CR]EFI/Linux\f[R] im ESP gespeichert. Falls auf \f[CR]uki\f[R] gesetzt,
wird ein einzelnes UKI für den neuesten installierten Kernel (demjenigen mit
der höchsten Version), der in \f[CR]EFI/BOOT/BOOTX64.EFI\f[R] im ESP
installiert ist, generiert. Falls auf \f[CR]grub\f[R] gesetzt, wird für
jeden installierten Kernel ein UKI erstellt und in \f[CR]EFI/Linux\f[R] im
ESP gespeichert. Für jeden erstellten UKI wird ein Menüeintrag zu der
Grub\-Konfiguration in \f[CR]grub/grub.cfg\f[R] im ESP hinzugefügt, der in
den UKI weiterlädt. Zur Anpassung wird ein grub.cfg auch nach
\f[CR]EFI/<Distribution>/grub.cfg\f[R] aus Kompatibilitätsgründen
mit signierten Versionen von Grub \f[CR]grub/grub.cfg\f[R] im ESP
geschrieben, da diese die Konfiguration von diesem Ort laden.\fR
.RS
.PP
Die Varianten \f[CR]signed\f[R] werden nur von Distributionen ausgelieferte,
vorab\-signierte EFI\-Programme installieren.\fR
.PP
Kernel müssen unter \f[CR]/usr/lib/modules/$version\f[R] mit Namen
\f[CR]vmlinux\f[R] oder \f[CR]vmlinuz\f[R] im Wurzeldateisystem abgelegt
werden (beispielsweise mittels \f[CR]ExtraTrees=\f[R]). Das
\f[CR]$version\f[R] lautet genau so, wie das Make\-Ziel
\f[CR]kernelversion\f[R] von Kbuild es erstellt.
.RE
.TP 
\f[CR]BiosBootloader=\f[R], \f[CR]\-\-bios\-bootloader=\fR
Akzeptiert entweder \f[CR]none\f[R] oder \f[CR]grub\f[R]. Standardmäßig
\f[CR]none\f[R]. Falls auf \f[CR]none\f[R] gesetzt, wird kein
BIOS\-Systemstartprogramm installiert. Falls auf \f[CR]grub\f[R] gesetzt,
wird Grub als BIOS\-Systemstartprogramm installiert, falls ein startfähiges
Abbild mit der Option \f[CR]Bootable=\f[R] erbeten wird. Falls keine
Repart\-Partitionsdefinitionsdateien konfiguriert sind, wird \f[B]mkosi\f[R]
eine Grub\-BIOS\-Systemstartpartition und eine EFI\-Systempartition zu den
Standard\-Partitionsdefinitionsdateien hinzufügen.
.RS
.PP
Beachten Sie, dass diese Option sich nicht mit der Option
\f[CR]Bootloader=\f[R] gegenseitig ausschließt. Es ist möglich, ein Abbild
zu haben, das sowohl unter UEFI als auch BIOS startet, indem sowohl
\f[CR]Bootloader=\f[R] als auch \f[CR]BiosBootloader=\f[R] konfiguriert
wird.\fR
.PP
Die Grub\-BIOS\-Systemstartpartition sollte die UUID
\f[CR]21686148\-6449\-6e6f\-744e\-656564454649\f[R] haben und mindestens 1 MB
groß sein.\fR
.PP
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.
.RE
.TP 
\f[CR]ShimBootloader=\f[R], \f[CR]\-\-shim\-bootloader=\fR
Akzeptiert entweder \f[CR]none\f[R], \f[CR]unsigned\f[R] oder
\f[CR]signed\f[R]. Standardmäßig \f[CR]none\f[R]. Falls auf \f[CR]none\f[R]
gesetzt, werden Shim und MokManager nicht in die ESP installiert. Falls auf
\f[CR]unsigned\f[R] gesetzt, wird \f[B]mkosi\f[R] nach unsignierten Shim\-
und MokManager\-EFI\-Programmen suchen und sie installieren. Falls
\f[CR]SecureBoot=\f[R] aktiviert ist, wird \f[B]mkosi\f[R] vor der
Installation die unsignierten EFI\-Programme signieren. Falls auf
\f[CR]signed\f[R] gesetzt, wird \f[B]mkosi\f[R] nach signierten
EFI\-Programmen suchen und sie installieren. Selbst wenn
\f[CR]SecureBoot=\f[R] aktiviert ist, wird \f[B]mkosi\f[R] die Programme
nicht erneut signieren.\fR
.RS
.PP
Beachten Sie, dass diese Option nur wirksam wird, wenn ein auf UEFI\-Firmware
startfähiges Abbild mittels anderer Optionen angefragt wird
(\f[CR]Bootable=\f[R], \f[CR]Bootloader=\f[R]).\fR
.PP
Beachten Sie, dass \f[B]mkosi\f[R] 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.
.RE
.TP 
\f[CR]UnifiedKernelImages=\f[R], \f[CR]\-\-unified\-kernel\-images=\fR
Gibt an, ob vereinigte Kernelabbilder verwandt werden sollen, wenn
\f[CR]Bootloader=\f[R] auf \f[CR]systemd\-boot\f[R] oder \f[CR]grub\f[R]
gesetzt ist. Akzeptiert einen logischen Wert oder
\f[CR]auto\f[R]. Standardmäßig \f[CR]auto\f[R]. 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 \f[CR]auto\f[R] 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.\fR
.TP 
\f[CR]UnifiedKernelImageFormat=\f[R], \f[CR]\-\-unified\-kernel\-image\-format=\fR
Akzeptiert einen Dateinamen ohne irgendeine Pfadkomponente, um das Format
festzulegen, in dem vereinigte Kernelabbilder installiert werden
sollen. Dies kann sowohl die normalen Kennzeichner (siehe
\f[B]Kennzeichner\f[R]) 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 \f[CR]&e\-&k\f[R] wobei \f[CR]\-&h\f[R] angehängt wird, falls
\f[CR]roothash=\f[R] oder \f[CR]usrhash=\f[R] auf der Kernelbefehlszeile
gefunden wird und \f[CR]+&c\f[R] falls \f[CR]/etc/kernel/tries\f[R] im
Abbild gefunden wird.\fR
.RS
.PP
Die folgenden Kennzeichner können außerdem verwendet werden:
.PP
.TS
tab(@);
l l.
T{
Kennzeichner
T}@T{
Wert
T}
_
T{
\f[CR]&&\fR
T}@T{
\f[CR]&\f[R]\-Zeichen\fR
T}
T{
\f[CR]&e\fR
T}@T{
\f[R]Zugangsmerkmal\fR
T}
T{
\f[CR]&k\fR
T}@T{
\f[R]Kernelversion\fR
T}
T{
\f[CR]&h\fR
T}@T{
Wert des Kernelarguments \f[CR]roothash=\f[R] oder \f[CR]usrhash=\f[R]\fR
T}
T{
\f[CR]&c\fR
T}@T{
\f[R]Anzahl der Versuche, die für den Zähler für Systemstarts verwandt werden\fR
T}
.TE
.RE
.TP 
\f[CR]UnifiedKernelImageProfiles=\f[R], \f[CR]\-\-uki\-profile=\fR
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
\f[CR]mkosi.uki\-profiles/\f[R] werden automatisch aufgenommen. Alle
konfigurierten UKI\-Profile werden als zusätzliche UKI\-Profile für jedes von
\f[B]mkosi\f[R] gebaute UKI hinzugefügt.\fR
.RS
.PP
Siehe die Dokumentation für den Abschnitt \f[CR]UKIProfile\f[R] zu
Informationen, welche Einstellungen in UKI\-Profil\-Konfigurationsdateien
vorgenommen werden können.
.RE
.TP 
\f[CR]Initrds=\f[R], \f[CR]\-\-initrd\fR
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 \f[B]mkosi\f[R] nach Initrds in einem Unterverzeichnis
\f[CR]io.mkosi.initrd\f[R] des Artefakt\-Verzeichnisses suchen (siehe
\f[CR]$ARTIFACTDIR\f[R] in dem Abschnitt
\f[B]UMGEBUNGSVARIABLEN\f[R]). Falls dort keine Initrds gefunden werden,
wird \f[B]mkosi\f[R] automatisch eine Standard\-Initrd bauen.\fR
.TP 
\f[CR]InitrdPackages=\f[R], \f[CR]\-\-initrd\-package=\fR
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.
.TP 
\f[CR]InitrdVolatilePackages=\f[R], \f[CR]\-\-initrd\-volatile\-package=\fR
Ähnlich zu \f[CR]VolatilePackages=\f[R], außer das es auf die
Standard\-Initrd angewandt wird.\fR
.TP 
\f[CR]Devicetree=\f[R], \f[CR]\-\-devicetree=\fR
Legt, wenn gesetzt, einen Devicetree\-Blob fest, der beim Systemstart
anstelle des durch die Firmware bereitgestellten verwandt werden
soll. \f[B]mkosi\f[R] wird nach der angegebenen Datei relativ zu typischen
Pfaden suchen, in denen Linux\-Distributionen Devicetree\-Dateien
installieren. Er sollte typischerweise das Format
\f[CR]<Lieferant>/<board>.dtb\f[R] haben.\fR
.TP 
\f[CR]MicrocodeHost=\f[R], \f[CR]\-\-microcode\-host=\fR
Wenn auf true gesetzt, wird nur der Mikrocode für die CPU des Wirtsystems in
das Abbild aufgenommen.
.TP 
\f[CR]KernelCommandLine=\f[R], \f[CR]\-\-kernel\-command\-line=\fR
Verwendet beim Bau von Abbildern die angegebene Kernelbefehlszeile.
.RS
.PP
Falls die Wurzel\- oder Verity\-Partition mit aktiviertem Verity erstellt
werden, werden \f[CR]roothash=\f[R] bzw. \f[CR]usrhash=\f[R] automatisch zu
der Kernel\-Befehlszeile hinzugefügt und \f[CR]root=\f[R] oder
\f[CR]mount.usr=\f[R] sollten nicht hinzugefügt werden. Andernfalls, falls
der Wert dieser Einstellung die selbstdeutenden Symbole
\f[CR]root=PARTUUID\f[R] oder \f[CR]mount.usr=PARTUUID\f[R] enthält, werden
diese mit der Partitions\-UUID der Wurzel\- bzw. usr\-Partition
ersetzt. Beispielsweise würde \f[CR]root=PARTUUID\f[R] durch
\f[CR]root=PARTUUID=58c7d0b2\-d224\-4834\-a16f\-e036322e88f7\f[R] ersetzt, wobei
\f[CR]58c7d0b2\-d224\-4834\-a16f\-e036322e88f7\f[R] die Partitions\-UUID der
Wurzelpartition ist.\fR
.RE
.TP 
\f[CR]KernelModulesInclude=\f[R], \f[CR]\-\-kernel\-modules\-include=\fR
Akzeptiert eine Liste von Mustern regulärer Ausdrücke, die ins Abbild
aufzunehmende Kernelmodule festlegen. Die Muster sollten relativ zum Pfad
\f[CR]/usr/lib/modules/<kver>/kernel\f[R] sein. \f[B]mkosi\f[R]
prüft überall im Modulpfad auf Übereinstimmung (z.B. passt \f[CR]i915\f[R]
auf \f[CR]drivers/gpu/drm/i915.ko\f[R]). 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.\fR
.RS
.PP
Falls der besondere Wert \f[CR]default\f[R] verwandt wird, werden auch die
in der Konfiguration \f[B]mkosi\-initrd\f[R] definierten
Standard\-Kernelmodule aufgenommen.\fR
.PP
Falls der besondere Wert \f[CR]host\f[R] verwandt wird, werden auch die auf
dem Wirtsystem aktuell geladenen Module aufgenommen.\fR
.PP
Diese Einstellung hat gegenüber \f[CR]KernelModulesExclude=\f[R] Vorrang und
ergibt nur in Kombination mit ihr Sinn, da standardmäßig alle Kernelmdoule
ins Abbild aufgenommen werden.\fR
.RE
.TP 
\f[CR]KernelModulesExclude=\f[R], \f[CR]\-\-kernel\-modules\-exclude=\fR
Akzeptiert eine Liste von Mustern regulärer Ausdrücke, die Module angeben,
die vom Abbild ausgeschlossen werden sollen. Verhält sich zu
\f[CR]KernelModulesInclude=\f[R] identisch, außer dass alle Module, die mit
einem der angegebenen Muster übereinstimmen, vom Abbild ausgeschlossen
werden.\fR
.TP 
\f[CR]KernelModulesInitrd=\f[R], \f[CR]\-\-kernel\-modules\-initrd=\fR
Logischer Wert, standardmäßig aktiviert (true). Falls beim Bau eines
Abbildes aktiviert, wird \f[B]mkosi\f[R] 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.\fR
.TP 
\f[CR]KernelModulesInitrdInclude=\f[R], \f[CR]\-\-kernel\-modules\-initrd\-include=\fR
Wie \f[CR]KernelModulesInclude=\f[R], gilt aber für Kernelmodule, die Teil
der Kernelmodul\-Initrd sind.\fR
.TP 
\f[CR]KernelModulesInitrdExclude=\f[R], \f[CR]\-\-kernel\-modules\-initrd\-exclude=\fR
Wie \f[CR]KernelModulesExclude=\f[R], gilt aber für Kernelmodule, die Teil
der Kernelmodul\-Initrd sind.\fR
.TP 
\f[CR]Locale=\f[R], \f[CR]\-\-locale=\f[R], \f[CR]LocaleMessages=\f[R], \f[CR]\-\-locale\-messages=\f[R], \f[CR]Keymap=\f[R], \f[CR]\-\-keymap=\f[R], \f[CR]Timezone=\f[R], \f[CR]\-\-timezone=\f[R], \f[CR]Hostname=\f[R], \f[CR]\-\-hostname=\f[R], \f[CR]RootShell=\f[R], \f[CR]\-\-root\-shell=\fR
Die Einstellungen \f[CR]Locale=\f[R], \f[CR]\-\-locale=\f[R],
\f[CR]LocaleMessages=\f[R], \f[CR]\-\-locale\-messages=\f[R],
\f[CR]Keymap=\f[R], \f[CR]\-\-keymap=\f[R], \f[CR]Timezone=\f[R],
\f[CR]\-\-timezone=\f[R], \f[CR]Hostname=\f[R], \f[CR]\-\-hostname=\f[R],
\f[CR]RootShell=\f[R], \f[CR]\-\-root\-shell=\f[R] entsprechen den identisch
benannten Systemd\-firstboot\-Optionen. Siehe \f[B]systemd\-firstboot\f[R](1)
für weitere Informationen. Ergänzend werden, wo anwendbar, die
entsprechenden Systemd\-Zugangsberechtigungen für diese Einstellungen nach
\f[CR]/usr/lib/credstore\f[R] geschrieben, so dass sie selbst dann angewandt
werden, wenn nur \f[CR]/usr\f[R] im Abbild ausgeliefert wird.\fR
.TP 
\f[CR]RootPassword=\f[R], \f[CR]\-\-root\-password=\f[R],\fR
Setzt das Root\-Passwort des Systems. Falls diese Option nicht verwandt wird,
aber eine Datei \f[CR]mkosi.rootpw\f[R] 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
\f[B]Scripts\f[R]). Falls das Passwort mit \f[CR]hashed:\f[R] beginnt, wird
es als ein bereits gehashtes Passwort betrachtet. Das Root\-Passwort wird
auch in \f[CR]/usr/lib/credstore\f[R] unterhalb der entsprechenden
Systemd\-Zugangsberechtigung gespeichert, so dass es selbst dann angewandt
wird, wenn nur \f[CR]/usr\f[R] im Abbild ausgeliefert wird. Um ein
entsperrtes Konto ohne Passwort zu erstellen, verwenden Sie
\f[CR]hashed:\f[R] ohne einen Hash.\fR
.TP 
\f[CR]Autologin=\f[R], \f[CR]\-\-autologin\fR
Aktiviert die automatische Anmeldung für den Benutzer \f[CR]root\f[R] auf
\f[CR]/dev/pts/0\f[R] (nspawn), \f[CR]/dev/tty1\f[R] und
\f[CR]/dev/hvc0\f[R].\fR
.TP 
\f[CR]MakeInitrd=\f[R], \f[CR]\-\-make\-initrd\fR
Fügt \f[CR]/etc/initrd\-release\f[R] und \f[CR]/init\f[R] zum Abbild hinzu,
so dass es als ein Initramfs verwandt werden kann.\fR
.TP 
\f[CR]Ssh=\f[R], \f[CR]\-\-ssh\fR
Falls angegeben wird eine \f[B]sshd\f[R](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
\f[CR]mkosi vm\f[R] kann der Befehl \f[CR]mkosi ssh\f[R] 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 \f[CR]mkosi genkey\f[R]
aus, um automatisch ein X.509\-Zertifikat und private Schlüssel zu erzeugen,
die von \f[B]mkosi\f[R] zur Aktivierung vom SSH\-Zugriff zu jeder virtuellen
Maschine mittels \f[CR]mkosi ssh\f[R] verwandt werden. Um auf mittels
\f[CR]mkosi boot\f[R] gestartete Abbilder zuzugreifen, verwenden Sie
\f[B]machinectl\f[R](1).\fR
.TP 
\f[CR]SELinuxRelabel=\f[R], \f[CR]\-\-selinux\-relabel=\fR
Legt fest, ob Dateien neu markiert werden sollen, um auf die
SELinux\-Richtlinie des Abbilds zu passen. Akzeptiert einen logischen Wert
oder \f[CR]auto\f[R]. Standardmäßig \f[CR]auto\f[R]. Falls deaktiviert,
werden Dateien nicht neu markiert. Falls aktiviert, muss eine
SELinux\-Richtlinie im Abbild installiert werden und \f[B]setfiles\f[R](8)
verfügbar sein, um Dateien zu markieren. Falls während \f[B]setfiles\f[R](8)
irgendein Fehler auftritt, wird der Bau fehlschlagen. Falls auf
\f[CR]auto\f[R] gesetzt, werden Dateien neu markiert, falls eine
SELinux\-Richtlinie im Abbild installiert und \f[B]setfiles\f[R](8) verfügbar
ist. Alle während \f[B]setfiles\f[R](8) aufgetretenen Fehler werden
ignoriert.\fR
.RS
.PP
Beachten Sie, dass bei der nicht privilegierten Ausführung
\f[B]setfiles\f[R](8) beim Setzen von allen Markierungen fehlschlagen wird,
die nicht in der SELinux\-Richtlinie des Wirtsystems sind. Um
sicherzustellen, dass \f[B]setfiles\f[R](8) ohne Fehler erfolgreich ist,
führen Sie \f[B]mkosi\f[R] als Root aus oder bauen Sie von einem Wirtsystem,
das die gleichen SELinux\-Richtlinie wie im zu bauenden Abbild verwendet.\fR
.RE
.TP 
\f[CR]MachineId=\f[R], \f[CR]\-\-machine\-id=\fR
Akzeptiert eine UUID oder den besonderen Wert \f[CR]random\f[R]. Setzt die
Maschinenkennung des Abbildes auf die angegebene UUID. Falls auf
\f[CR]random\f[R] gesetzt, wird eine zufällige UUID nach
\f[CR]/etc/machine\-id\f[R] geschrieben. Falls nicht explizit angegeben und
die Datei \f[CR]mkosi.machine\-id\f[R] im lokalen Verzeichnis existiert, wird
die zu verwendende UUID daraus gelesen. Andernfalls wird
\f[CR]uninitialized\f[R] nach \f[CR]/etc/machine\-id\f[R] geschrieben.\fR
.SS "Abschnitt [Validation]"
.TP 
\f[CR]SecureBoot=\f[R], \f[CR]\-\-secure\-boot\fR
Signiert \f[CB]systemd\-boot\f[R](7) (falls es noch nicht signiert ist) und
sämtliche vereinigten Kernelabbilder für UEFI SecureBoot.\fR
.TP 
\f[CR]SecureBootAutoEnroll=\f[R], \f[CR]\-\-secure\-boot\-auto\-enroll=\fR
Einrichtung der automatischen Registrierung der Schlüssel für sicheren
Systemstart in virtuellen Maschinen falls \f[CR]SecureBoot=\f[R] verwandt
wird, wie das in \f[CB]systemd\-boot\f[R](7) beschrieben wird. Beachten Sie,
dass \f[CB]systemd\-boot\f[R](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
\f[CB]systemd\-boot\f[R](7)\-Konfigurationsdatei nach
\f[CR]/efi/loader/loader.conf\f[R] mittels eines zusätzlichen Baumes mit
\f[CR]secure\-boot\-enroll force\f[R] oder \f[CR]secure\-boot\-enroll
manual\f[R] darin schreiben. Unter Systemd\-Versionen älter als v252 wird
keine automatische Registrierung unterstützt. Standardmäßig
\f[CR]yes\f[R].\fR
.TP 
\f[CR]SecureBootKey=\f[R], \f[CR]\-\-secure\-boot\-key=\fR
Pfad zu der PEM\-Datei, die den geheimen Schlüssel zum Signieren des
UEFI\-Kernelabbilds, falls \f[CR]SecureBoot=\f[R] verwandt wird und der
PCR\-Signaturen, falls \f[CR]SignExpectedPcr=\f[R] auch verwandt wird,
enthält. Wenn \f[CR]SecureBootKeySource=\f[R] angegeben ist, hängt der
Eingabetyp von der Quelle ab.\fR
.TP 
\f[CR]SecureBootCertificate=\f[R], \f[CR]\-\-secure\-boot\-certificate=\fR
Pfad zu der X.509\-Datei, die das Zertifikat für das signierte
UEFI\-Kernelabbild enthält, falls \f[CR]SecureBoot=\f[R] verwandt wird.\fR
.TP 
\f[CR]SecureBootSignTool=\f[R], \f[CR]\-\-secure\-boot\-sign\-tool\fR
Werkzeug zum Signieren von PE\-Programmen für den sicheren
Systemstart. Akzeptiert entweder \f[CR]systemd\-sbsign\f[R],
\f[CR]sbsign\f[R] oder \f[CR]auto\f[R]. Standardmäßig \f[CR]auto\f[R]. Falls
auf \f[CR]auto\f[R] gesetzt, wird (wenn verfügbar) entweder
\f[B]systemd\-sbsign\fR(1) oder \f[B]sbsign\f[R](1) verwandt, wobei
\f[B]systemd\-sbsign\f[R](1) bevorzugt wird.\fR
.TP 
\f[CR]Verity=\f[R], \f[CR]\-\-verity=\fR
Ob das Verity\-Signieren für Erweiterungsabbilder erzwungen oder deaktiviert
wird. Akzeptiert einen logischen Wert oder \f[CR]auto\f[R]. Falls aktiviert,
muss ein Verity\-Schlüssel und \-Zertifikat vorhanden sein und der Bau wird
fehlschlagen, falls keine Verity\-Partitionen in dem durch
\f[B]systemd\-repart\f[R](8) erstellten Abbild erkannt werden. Falls
deaktiviert, werden Verity\-Partitionen von den durch
\f[B]systemd\-repart\f[R](8) erstellten Abbildern ausgeschlossen. Falls auf
\f[CR]auto\f[R] gesetzt und ein Verity\-Schlüssel und \-Zertifikat vorhanden
sind, wird \f[B]mkosi\f[R] sie an \f[B]systemd\-repart\f[R](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 \f[B]systemd\-repart\f[R](8) erstellten Plattenabbild gefunden
werden.\fR
.RS
.PP
Beachten Sie, dass das explizite Deaktivieren signierter Verity für die
Ausgabe \f[CR]disk\f[R] noch nicht implementiert ist und derzeit nur für
Erweiterungsabbilder funktioniert.\fR
.RE
.TP 
\f[CR]VerityKey=\f[R], \f[CR]\-\-verity\-key=\fR
Pfad zu der PEM\-Datei, die den geheimen Schlüssel zum Signieren der
Verity\-Signatur enthält, falls eine Verity\-Signaturpartition mit
\f[B]systemd\-repart\f[R](8) hinzugefügt wird. Wenn
\f[CR]VerityKeySource=\f[R] festgelegt wird, hängt der Eingabetyp von der
Quelle ab.\fR
.TP 
\f[CR]VerityCertificate=\f[R], \f[CR]\-\-verity\-certificate=\fR
Pfad zu einer X.509\-Datei, die das Zertifikat zum Signieren der
Verity\-Signatur enthält, falls eine Verity\-Signaturpartition mittels
\f[B]systemd\-repart\f[R](8) hinzugefügt wird.
.TP 
\f[CR]SignExpectedPcr=\f[R], \f[CR]\-\-sign\-expected\-pcr\fR
Misst die Komponenten des vereinigten Kernelabbildes (UKI) mittels
\f[B]systemd\-measure\f[R](1) und bettet die PCR\-Signatur in das vereinigte
Kernelabbild ein. Diese Option akzeptiert einen logischen Wert oder den
besonderen Wert \f[CR]auto\f[R], der die Vorgabe ist, der identisch zu einem
wahren Wert ist, falls das Programm \f[B]systemd\-measure\f[R] im
\f[CR]PATH\f[R] ist. Hängt vom aktivierten \f[CR]SecureBoot=\f[R] und
Schlüssel aus \f[CR]SecureBootKey=\f[R] ab.\fR
.TP 
\f[CR]SignExpectedPcrKey=\f[R], \f[CR]\-\-sign\-expected\-pcr\-key=\fR
Pfad zu der PEM\-Datei, die den geheimen Schlüssel zum Signieren der
erwarteten PCR\-Signatur enthält. Wenn \f[CR]VerityKeySource=\f[R] festgelegt
wird, hängt der Eingabetyp von der Quelle ab.\fR
.TP 
\f[CR]SignExpectedPcrCertificate=\f[R], \f[CR]\-\-sign\-expected\-pcr\-certificate=\fR
Pfad zu einer X.509\-Datei, die das Zertifikat zum Signieren der erwarteten
PCR\-Signatur enthält.
.TP 
\f[CR]SecureBootKeySource=\f[R], \f[CR]\-\-secure\-boot\-key\-source=\f[R], \f[CR]VerityKeySource=\f[R], \f[CR]\-\-verity\-key\-source=\f[R], \f[CR]SignExpectedPcrKeySource=\f[R], \f[CR]\-\-sign\-expected\-key\-source=\fR
Die Quelle des entsprechenden privaten Schlüssels, um OpenSSL\-Engines und
\-Provider zu unterstützen, z.B.\ \f[CR]\-\-secure\-boot\-key\-source=engine:pkcs11\f[R] oder
\f[CR]\-\-secure\-boot\-key\-source=provider:pkcs11\f[R].\fR
.TP 
\f[CR]SecureBootCertificateSource=\f[R], \f[CR]\-\-secure\-boot\-certificate\-source=\f[R], \f[CR]VerityCertificateSource=\f[R], \f[CR]\-\-verity\-certificate\-source=\f[R], \f[CR]SignExpectedPcrCertificateSource=\f[R], \f[CR]\-\-sign\-expected\-certificate\-source=\fR
Die Quelle der entsprechenden Zertifikate, um OpenSSL\-Provider zu
unterstützen, z.B.\ \f[CR]\-\-secure\-boot\-certificate\-source=provider:pkcs11\f[R]. Beachten Sie,
dass Engines nicht unterstützt werden.
.TP 
\f[CR]Passphrase=\f[R], \f[CR]\-\-passphrase\fR
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 \f[B]cryptsetup\f[R](8) und \f[CR]/etc/crypttab\f[R] die
Passphrasendatei erwarten). Die Datei muss den Zugriffsmodus 0600 oder
kleiner haben.\fR
.TP 
\f[CR]Checksum=\f[R], \f[CR]\-\-checksum\fR
Erstellt eine Datei \f[CR]<Ausgabe>.SHA256SUMS\f[R] über alle
erstellten Artefakte, nachdem der Bau abgeschlossen ist.\fR
.TP 
\f[CR]Sign=\f[R], \f[CR]\-\-sign\fR
Signiert nach Fertigstellung die erstellte \f[CR]SHA256SUMS\f[R] mittels
\f[B]gpg\f[R](1).\fR
.TP 
\f[CR]OpenPGPTool=\f[R], \f[CR]\-\-openpgp\-tool\fR
Zum Signieren zu verwendende OpenPGP\-Implementierung. \f[CR]gpg\f[R] ist die
Vorgabe. Durch Wahl einer anderen als die Vorgabe wird das Werkzeug für
Zustandslose OpenPGP (SOP) zum Signieren der Datei \f[CR]SHA256SUMS\f[R]
verwandt.\fR
.RS
.PP
Beispielhaft seien \f[CR]sqop\f[R] und \f[CR]rsop\f[R] genannt, aber jede
Implementierung von https://www.openpgp.org/about/sop/, die lokal
installiert werden kann, funktioniert.\fR
.RE
.TP 
\f[CR]Key=\f[R], \f[CR]\-\-key=\fR
Wählt den für das Signieren der \f[CR]SHA256SUMS\f[R] zu verwendenden
\f[B]gpg\f[R](1)\-Schlüssel aus. Dieser Schlüssel muss bereits im
\f[B]gpg\f[R](1)\-Schlüsselbund vorhanden sein.\fR
.SS "Abschnitt [Build]"
.TP 
\f[CR]ToolsTree=\f[R], \f[CR]\-\-tools\-tree=\fR
Falls angegeben, werden von \f[B]mkosi\f[R] 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 \f[CR]mkosi.tools/\f[R] im lokalen Verzeichnis gefunden wird,
wird es automatisch für diesen Zweck mit dem Wurzelverzeichnis als Ziel
verwandt.\fR
.RS
.PP
Beachten Sie, dass Programme, die in einem der mit
\f[CR]ExtraSearchPaths=\f[R] konfigurierten Pfade gefunden werden, mit
\f[CR]/usr/\f[R] 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.\fR
.PP
Falls auf \f[CR]default\f[R] gesetzt, wird \f[B]mkosi\f[R] automatisch ein
zusätzliches Werkzeugbaumabbild hinzufügen und es als Werkzeugbaum
verwenden.\fR
.PP
Die nachfolgende Tabelle zeigt, für welche Distributionen
Standard\-Werkzeugbaumpakete definiert sind und welche Pakete in diese
Standardwerkzeugbäume aufgenommen werden:\fR
.PP
.TS
tab(@);
lw(22.2n) cw(7.1n) cw(7.1n) cw(7.1n) cw(5.3n) cw(7.1n) cw(5.3n) cw(8.9n).
T{
T}@T{
Fedora
T}@T{
CentOS
T}@T{
Debian
T}@T{
Kali
T}@T{
Ubuntu
T}@T{
Arch
T}@T{
openSUSE
T}
_
T{
\f[CR]acl\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]apt\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}
T{
\f[CR]archlinux\-keyring\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}
T{
\f[CR]attr\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]bash\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]btrfs\-progs\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]ca\-certificates\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]coreutils\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]cpio\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]createrepo_c\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]curl\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]debian\-keyring\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}
T{
\f[CR]diffutils\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]distribution\-gpg\-keys\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]dnf\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]dosfstools\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]e2fsprogs\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]edk2\-ovmf\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]erofs\-utils\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]findutils\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]git\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]grep\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]grub\-tools\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}
T{
\f[CR]jq\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]kali\-archive\-keyring\fR
T}@T{
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}
T{
\f[CR]kmod\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]less\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]mtools\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]nano\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]opensc\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]openssh\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]openssl\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]pkcs11\-provider\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]perf\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]sed\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]pacman\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}
T{
\f[CR]policycoreutils\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]qemu\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]sbsigntools\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]socat\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]squashfs\-tools\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]strace\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]swtpm\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]systemd\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]ukify\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]tar\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]ubuntu\-keyring\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}
T{
\f[CR]util\-linux\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]virtiofsd\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]virt\-firmware\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]xfsprogs\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]xz\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]zstd\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]zypper\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
\f[R]✓\fR
T}
.TE
.RE
.TP 
\f[CR]ToolsTreeDistribution=\f[R], \f[CR]\-\-tools\-tree\-distribution=\fR
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 \f[CR]custom\f[R], falls die Distribution des
Hauptsystems keine unterstützte Distribution ist.\fR
.TP 
\f[CR]ToolsTreeRelease=\f[R], \f[CR]\-\-tools\-tree\-release=\fR
Setzt die für den Standard\-Werkzeugbaum zu verwendende
Distributionsveröffentlichung. Standardmäßig wird die in \f[B]mkosi\f[R]
fest eingebaute Standard\-Veröffentlichung für die Distribution verwandt.
.TP 
\f[CR]ToolsTreeMirror=\f[R], \f[CR]\-\-tools\-tree\-mirror=\fR
Setzt den für den Standardwerkzeugbaum zu verwendenden
Spiegel. Standardmäßig wird der Standardspiegel für die
Werkzeugbaumdistribution verwandt.
.TP 
\f[CR]ToolsTreeRepositories=\f[R], \f[CR]\-\-tools\-tree\-repository\fR
Identisch zu \f[CR]Repositories=\f[R], aber für den Standardwerkzeugbaum.\fR
.TP 
\f[CR]ToolsTreeSandboxTrees=\f[R], \f[CR]\-\-tools\-tree\-sandbox\-tree\fR
Identisch zu \f[CR]SandboxTrees=\f[R], aber für den Standardwerkzeugbaum.\fR
.TP 
\f[CR]ToolsTreePackages=\f[R], \f[CR]\-\-tools\-tree\-package=\fR
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.
.TP 
\f[CR]ToolsTreePackageDirectories=\f[R], \f[CR]\-\-tools\-tree\-package\-directory=\fR
Identisch zu \f[CR]PackageDirectories=\f[R], aber für den
Standardwerkzeugbaum.\fR
.TP 
\f[CR]ToolsTreeCertificates=\f[R], \f[CR]\-\-tools\-tree\-certificates=\fR
Legt fest, ob Zertifikate und Schlüssel aus dem Werkzeugbaum verwandt werden
sollen. Standardmäßig aktiviert. Falls aktiviert, werden
\f[CR]/etc/pki\f[R], \f[CR]/etc/ssl\f[R], \f[CR]/etc/ca\-certificates\f[R]
und \f[CR]/var/lib/ca\-certificates\f[R] von dem Werkzeugbaum
verwandt. Andernfalls werden diese Verzeichnisse aus dem Wirtsystem
aufgenommen.\fR
.TP 
\f[CR]ExtraSearchPaths=\f[R], \f[CR]\-\-extra\-search\-path=\fR
Liste von durch Doppelpunkt getrennten Pfaden, in denen vor dem regulären
Suchpfad \f[CR]$PATH\f[R] nach Werkzeugen gesucht wird.\fR
.TP 
\f[CR]Incremental=\f[R], \f[CR]\-\-incremental=\f[R], \f[CR]\-i\fR
Akzeptiert entweder \f[CR]strict\f[R] 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 \f[CR]mkosi.build\f[R] (und
alles was danach passiert) aufgerufen werden, eine Kopie des
Betriebssystemabbilds erstellt. Bei nachfolgenden Aufrufen von
\f[B]mkosi\f[R] mit dem Schalter \f[CR]\-i\f[R] 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 \f[CR]\-i\f[R] mit \f[CR]\-ff\f[R] um sicherzustellen, dass
das zwischengespeicherte Abbild zuerst entfernt und dann neu erstellt
wird.\fR
.RS
.PP
Falls auf \f[CR]strict\f[R] gesetzt, schlägt der Bau fehl, falls kein vorher
gebautes und zwischengespeichertes Abbild existiert.\fR
.RE
.TP 
\f[CR]CacheOnly=\f[R], \f[CR]\-\-cache\-only=\fR
Akzeptiert entweder \f[CR]auto\f[R], \f[CR]metadata\f[R], \f[CR]always\f[R]
oder \f[CR]never\f[R]. Standardmäßig \f[CR]auto\f[R]. Falls
\f[CR]always\f[R], 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
\f[CR]metadata\f[R] gesetzt kann der Paketverwalter weiterhin Pakete
herunterladen, aber nicht die Metadaten des Depots synchronisieren. Falls
auf \f[CR]auto\f[R] gesetzt werden während des Baus die Paketmetadaten
synchronisiert (außer es liegt ein zwischengespeichertes Abbild vor \- siehe
\f[CR]Incremental=\f[R]) und die Pakete heruntergeladen. Falls
\f[CR]never\f[R], werden die Depot\-Metadaten immer synchronisiert und Pakete
können während des Baus heruntergeladen werden.\fR
.TP 
\f[CR]SandboxTrees=\f[R], \f[CR]\-\-sandbox\-tree=\fR
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 \f[CR]mkosi.sandbox/\f[R] in dem lokalen
Verzeichnis gefunden wird, wird es auch für diesen Zweck mit dem
Wurzelverzeichnis als Ziel verwandt (siehe auch den nachfolgenden Abschnitt
\f[B]Dateien\f[R]).\fR
.RS
.PP
\f[B]mkosi\f[R] 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
\f[CR]/usr\f[R] oder \f[CR]/etc\f[R] in den Sandbox\-Bäumen
verwenden. Beispielsweise wird es nach \f[CR]/etc/dnf/dnf.conf\f[R] in
Sandbox\-Bäumen suchen, falls \f[B]dnf\f[R] zur Installation von Paketen
verwandt wird.\fR
.RE
.TP 
\f[CR]WorkspaceDirectory=\f[R], \f[CR]\-\-workspace\-directory=\fR
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
\f[CR]$XDG_CACHE_HOME\f[R] (falls gesetzt), \f[CR]$HOME/.cache\f[R] (falls
gesetzt) oder \f[CR]/var/tmp\f[R] verwandt.\fR
.RS
.PP
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 \f[B]mkosi\f[R] anormal abgebrochen wurde
(beispielsweise aufgrund eines Neustarts oder Stromausfalls).\fR
.RE
.TP 
\f[CR]CacheDirectory=\f[R], \f[CR]\-\-cache\-directory=\fR
Akzeptiert einen Pfad zu einem Verzeichnis, das als inkrementelles
Zwischenspeicherverzeichnis für die erstellten inkrementellen Abbilder
verwandt wird, wenn die Option \f[CR]Incremental=\f[R] aktiviert ist. Falls
diese Option nicht verwandt wird, aber das Verzeichnis
\f[CR]mkosi.cache/\f[R] im lokalen Verzeichnis gefunden wird, wird es
automatisch für diesen Zweck verwandt.\fR
.TP 
\f[CR]PackageCacheDirectory=\f[R], \f[CR]\-\-package\-cache\-dir\fR
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 \f[CR]mkosi.pkgcache/\f[R] 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.
.TP 
\f[CR]BuildDirectory=\f[R], \f[CR]\-\-build\-directory=\fR
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 \f[CR]$BUILDDIR\f[R] finden. Dieses
Verzeichnis wird in das Wurzelverzeichnis des Abbildes eingehängt, wenn
\f[B]mkosi\-chroot\f[R] während der Ausführung der Bauskripte aufgerufen
wird. Falls diese Option nicht verwandt wird, aber das Verzeichnis
\f[CR]mkosi.builddir/\f[R] im lokalen Verzeichnis gefunden wird, wird es
automatisch für diesen Zweck verwandt (siehe auch den nachfolgenden
Abschnitt \f[B]Files\f[R]).\fR
.TP 
\f[CR]UseSubvolumes=\f[R], \f[CR]\-\-use\-subvolumes=\fR
Akzeptiert einen logischen Wert oder \f[CR]auto\f[R]. Aktiviert oder
deaktiviert die Verwendung von \f[B]btrfs\f[R](5)\-Teildatenträgern für
Verzeichnisbaumausgaben. Falls aktiviert wird \f[B]mkosi\f[R] das
Wurzelverzeichnis als \f[B]btrfs\f[R](5)\-Teildatenträger erstellen und wo
möglich \f[B]btrfs\f[R](5)\-Teildatenträgerschnappschüsse verwenden, um
grundlegende oder zwischengespeicherte Bäume zu kopieren, was viel schneller
als rekursive Kopieren ist. Falls explizit aktiviert und \f[B]btrfs\f[R](8)
nicht installiert ist oder Teildatenträger nicht erstellt werden können,
wird ein Fehler ausgelöst. Falls \f[CR]auto\f[R], werden ein fehlendes
\f[B]btrfs\f[R](8) oder Fehlschläge beim Erstellen von Teildatenträgern
ignoriert.\fR
.TP 
\f[CR]RepartOffline=\f[R], \f[CR]\-\-repart\-offline=\fR
Legt fest, ob Plattenabbilder mittels Loopback\-Geräten gebaut
werden. Standardmäßig aktiviert. Wenn aktiviert, wird
\f[B]systemd\-repart\f[R](8) keine Loopback\-Geräte zum Bau von
Plattenabbildern verwenden. Wenn deaktiviert, wird
\f[B]systemd\-repart\f[R](8) immer Loopback\-Geräte zum Bau von
Plattenabbildern verwenden.\fR
.RS
.PP
Beachten Sie, dass \f[B]mkosi\f[R] nicht unprivilegiert ausgeführt werden
kann, wenn \f[CR]RepartOffline=no\f[R] verwandt wird und der Abbild\-Bau als
Benutzer root außerhalb von Containern und mit auf dem Wirtsystem
verfügbaren Loopack\-Geräten erfolgt.\fR
.PP
Es gibt derzeit zwei bekannte Szenarien, bei denen
\f[CR]RepartOffline=no\f[R] verwandt werden muss. Das erste ist der Einsatz
von \f[CR]Subvolumes=\f[R] 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 \f[B]mkfs.xfs\f[R](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.\fR
.RE
.TP 
\f[CR]History=\f[R], \f[CR]\-\-history=\fR
Akzeptiert einen logischen Wert. Falls aktiviert, wird \f[B]mkosi\f[R]
Informationen über den jüngsten Bau in das Unterverzeichnis
\&\f[CR].mkosi\-private\f[R] (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 \f[CR]\-\-force\f[R] ausgeführt wird, der den Bau benötigt.\fR
.RS
.PP
Beispiel für den Nutzen dieses Vorgehens: Sie führen \f[CR]mkosi \-O
mein\-angepasstes\-Ausgabeverzeichnis \-f\f[R] gefolgt von \f[CR]mkosi vm\f[R]
aus. Dann wird \f[B]mkosi\f[R] mit der Information fehlschlagen, dass das
Abbild noch nicht gebaut wurde. Falls Sie \f[CR]mkosi \-O
mein\-angepasstes\-Ausgabeverzeichnis \-\-history=yes \-f\f[R] gefolgt von
\f[CR]mkosi vm\f[R] ausführen, wird es das im vorhergehenden Schritt gebaute
Abbild wie erwartet starten.\fR
.RE
.TP 
\f[CR]BuildSources=\f[R], \f[CR]\-\-build\-sources=\fR
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 \f[CR]/work/src\f[R]
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 \f[CR]/work/src\f[R] eingehängt.\fR
.TP 
\f[CR]BuildSourcesEphemeral=\f[R], \f[CR]\-\-build\-sources\-ephemeral=\fR
Akzeptiert einen logischen oder den besonderen Wert
\f[CR]buildcache\f[R]. Standardmäßig deaktiviert. Konfiguriert, ob
Änderungen an Quellverzeichnissen, dem Arbeitsverzeichnis und dem mit
\f[CR]BuildSources=\f[R] 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.\fR
.RS
.PP
💥💣💥 Falls auf \f[CR]buildcache\f[R] gesetzt wird die Überlagerung nicht bei
der Ausführung von Bauskripten verworfen, sondern im Bauverzeichnis,
konfiguriert mittels \f[CR]BuildDirectory=\f[R], 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.  💥💣💥\fR
.RE
.TP 
\f[CR]Environment=\f[R], \f[CR]\-\-environment=\fR
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 \f[B]mkosi\f[R] 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.\fR
.TP 
\f[CR]EnvironmentFiles=\f[R], \f[CR]\-\-env\-file=\fR
Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Dateien, die
Umgebungsvariablendefinitionen enthalten, die der Skript\-Umgebung
hinzugefügt werden sollen. Verwendet \f[CR]mkosi.env\f[R], falls es im
lokalen Verzeichnis gefunden wird. Diese Variablen werden zuerst aus
\f[CR]mkosi.env\f[R], falls es existiert, dann aus den angegebenen Dateien
und dann aus den Einstellungen \f[CR]Environment=\f[R] gelesen.\fR
.TP 
\f[CR]WithTests=\f[R], \f[CR]\-\-without\-tests\f[R], \f[CR]\-T\fR
Falls auf »false« gesetzt (oder wenn die Befehlszeilenoption verwandt wird),
wird die Umgebungsvariable \f[CR]$WITH_TESTS\f[R] auf \f[CR]0\f[R] gesetzt,
wenn die Skripte \f[CR]mkosi.build\f[R] 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
\f[CR]mkosi.build\f[R]\-Bauskripte sie respektieren.\fR
.TP 
\f[CR]WithNetwork=\f[R], \f[CR]\-\-with\-network=\fR
Wenn »true«, aktiviert Netzwerkverbindungen während der von
\f[CR]mkosi.build\f[R] aufgerufenen Bauskripte. Standardmäßig werden die
Bauskripte mit abgeschaltetem Netzwerk ausgeführt. Die Umgebungsvariable
\f[CR]$WITH_NETWORK\f[R] wird an die \f[CR]mkosi.build\f[R]\-Bauskripte
übergeben um anzuzeigen, ob der Bau mit Netzwerk erfolgt.\fR
.TP 
\f[CR]ProxyUrl=\f[R], \f[CR]\-\-proxy\-url=\fR
Konfiguriert einen Proxy, der für alle ausgehenden Netzwerkverbindungen
verwandt werden soll. Verschiedene Werkzeuge, die \f[B]mkosi\f[R] aufruft
und für die der Proxy konfiguriert werden kann, sind für diesen Proxy
konfiguriert. \f[B]mkosi\f[R] 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.
.TP 
\f[CR]ProxyExclude=\f[R], \f[CR]\-\-proxy\-exclude=\fR
Konfiguriert Rechnernamen, für die Anfragen nicht durch den Proxy gehen
sollen. Akzeptiert eine Kommata\-getrennte Liste von Rechnernamen.
.TP 
\f[CR]ProxyPeerCertificate=\f[R], \f[CR]\-\-proxy\-peer\-certificate=\fR
Konfiguriert eine Datei, die Zertifikate zur Überprüfung des Proxys
enthält. Standardmäßig ist das der systemweite Zertifikaktspeicher.
.RS
.PP
Derzeit wird das Setzen eines Proxy\-Gegenstellen\-Zertifikats nur
unterstützt, wenn \f[B]dnf\f[R] oder \f[B]dnf5\f[R] zum Bau des Abbilds
verwandt werden.\fR
.RE
.TP 
\f[CR]ProxyClientCertificate=\f[R], \f[CR]\-\-proxy\-client\-certificate=\fR
Konfiguriert eine Datei, die das zur Authentifizierung des Clients mit dem
Proxy verwandte Zertifikat enthält.
.RS
.PP
Derzeit wird das Setzen eines Proxy\-Client\-Zertifikats nur unterstützt, wenn
\f[B]dnf\f[R] oder \f[B]dnf5\f[R] zum Bau des Abbilds verwandt werden.\fR
.RE
.TP 
\f[CR]ProxyClientKey=\f[R], \f[CR]\-\-proxy\-client\-key=\fR
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.
.RS
.PP
Derzeit wird das Setzen eines Proxy\-Clients nur unterstützt, wenn
\f[B]dnf\f[R] oder \f[B]dnf5\f[R] zum Bau des Abbildes verwandt wird.\fR
.RE
.SS "Abschnitt [Runtime] (früher als Abschnitt [Host] bekannt)"
.TP 
\f[CR]NSpawnSettings=\f[R], \f[CR]\-\-settings=\fR
Legt eine Einstellungsdatei \f[CR].nspawn\f[R] für
\f[B]systemd\-nspawn\f[R](1) zur Verwendung in den Unterbefehlen
\f[CR]boot\f[R] und \f[CR]shell\f[R] und zum Ablegen neben der erstellten
Abbilddatei fest. Dies ist zur Konfiguration der Umgebung
\f[B]systemd\-nspawn\f[R](1) bei der Ausführung nützlich. Falls diese
Einstellung nicht verwandt wird, aber eine Datei \f[CR]mkosi.nspawn\f[R] im
lokalen Verzeichnis gefunden wird, wird diese automatisch für diesen Zweck
verwandt.\fR
.TP 
\f[CR]VirtualMachineMonitor=\f[R], \f[CR]\-\-vmm=\fR
Konfiguriert den zu verwendenden Monitor für virtuelle Maschinen. Akzeptiert
entweder \f[CR]qemu\f[R] oder \f[CR]vmspawn\f[R]. Standardmäßig
\f[CR]qemu\f[R].\fR
.RS
.PP
Falls auf \f[CR]qemu\f[R] gesetzt, wird das Abbild mit \f[B]qemu\f[R]
gestartet. Die meisten Ausgabeformate können mit \f[B]qemu\f[R] gestartet
werden. Alle nach dem Unterbefehl angegebenen Argumente werden an den Aufruf
von \f[B]qemu\f[R] angehängt und als zusätzliche
\f[B]qemu\f[R]\-Befehlszeilenargumente interpretiert.\fR
.PP
Falls auf \f[CR]vmspawn\f[R] gesetzt, wird \f[B]systemd\-vmspawn\f[R](1) zum
Hochfahren des Abbildes benutzt. \f[CR]vmspawn\f[R] unterstützt nur platten\-
und verzeichnisartige Abbilder. Alle nach dem Unterbefehl angegebenen
Argumente werden an den Aufruf von \f[B]systemd\-vmspawn\f[R](1) angehängt
und als zusätzliche Vmspawn\-Optionen und Kernelbefehlszeilenargumente
interpretiert.\fR
.RE
.TP 
\f[CR]Console=\f[R], \f[CR]\-\-console=\fR
Konfiguriert, wie die Konsole der VM eingerichtet werden soll. Akzeptiert
entweder \f[CR]interactive\f[R], \f[CR]read\-only\f[R], \f[CR]native\f[R]
oder \f[CR]gui\f[R]. Standardmäßig
\f[CR]interactive\f[R]. \f[CR]interactive\f[R] stellt eine interaktive
Terminalschnittstelle zur VM bereit. \f[CR]read\-only\f[R] ist ähnlich, aber
streng schreibgeschützt, d.h. sie akzeptiert keine Eingabe vom
Benutzer. \f[CR]native\f[R] stellt auch eine TTY\-basierte Schnittstelle
bereit, verwendet aber die in \f[B]qemu\f[R] eingebaute Implementierung
(dadurch ist der Monitor von \f[B]qemu\f[R] verfügbar). \f[CR]gui\f[R] zeigt
die graphische UI von \f[B]qemu\f[R] \f[B]qemu\f[R].\fR
.TP 
\f[CR]CPUs=\f[R], \f[CR]\-\-cpus=\fR
Konfiguriert die Anzahl der CPU\-Kerne, die dem Gast beim Starten einer
virtuellen Maschine zugewiesen werden sollen. Standardmäßig \f[CR]2\f[R].\fR
.RS
.PP
Wird dies auf \f[CR]0\f[R] gesetzt, wird die Anzahl der für den
\f[B]mkosi\f[R]\-Prozess verfügbaren CPUs verwandt.\fR
.RE
.TP 
\f[CR]RAM=\f[R], \f[CR]\-\-ram=\fR
Konfiguriert die Speichermenge, die einem Gast beim Starten einer virtuellen
Maschine zugewiesen wird. Standardmäßig \f[CR]2G\f[R].\fR
.TP 
\f[CR]KVM=\f[R], \f[CR]\-\-kvm=\fR
Konfiguriert, ob KVM\-Beschleunigung beim Starten einer virtuellen Maschine
verwandt werden soll. Akzeptiert einen logischen Wert oder
\f[CR]auto\f[R]. Standardmäßig \f[CR]auto\f[R].\fR
.TP 
\f[CR]Vsock=\f[R], \f[CR]\-\-vsock=\fR
Konfiguriert, ob ein Vsock beim Starten einer virtuellen Maschine
vorgehalten werden soll. Akzeptiert einen logischen Wert oder
\f[CR]auto\f[R]. Standardmäßig \f[CR]auto\f[R].\fR
.TP 
\f[CR]VsockConnectionId=\f[R], \f[CR]vsock\-cid=\fR
Konfiguriert die beim Starten einer virtuellen Maschine zu verwendende
Verbindungskennung. Akzeptiert eine Zahl im Intervall \f[CR][3,
0xFFFFFFFF)\f[R] oder \f[CR]hash\f[R] oder \f[CR]auto\f[R]. Standardmäßig
\f[CR]auto\f[R]. Wenn auf \f[CR]hash\f[R] gesetzt wird die
Verbindungskennung von dem vollständigen Pfad zum Abbild abgeleitet. Wenn
auf \f[CR]auto\f[R] gesetzt, wird \f[B]mkosi\f[R] versuchen, automatisch
eine freie Verbindungskennung zu finden. Andernfalls wird die
bereitgestellte Nummer unverändert verwandt.\fR
.TP 
\f[CR]TPM=\f[R], \f[CR]\-\-tpm=\fR
Konfiguriert, ob ein virtueller TPM beim Starten einer virtuellen Maschine
verwandt werden soll. Akzeptiert einen logischen Wert oder
\f[CR]auto\f[R]. Standardmäßig \f[CR]auto\f[R].\fR
.TP 
\f[CR]CDROM=\f[R], \f[CR]\-\-cdrom=\fR
Konfiguriert, ob das Abbild als CD\-ROM\-Laufwerk beim Start einer virtuellen
Maschine angehängt werden soll. Akzeptiert einen logischen
Wert. Standardmäßig \f[CR]no\f[R].\fR
.TP 
\f[CR]Removable=\f[R], \f[CR]\-\-removable=\fR
Konfiguriert, ob das Abbild als entfernbares Gerät beim Start einer
virtuellen Maschine angehängt werden soll. Akzeptiert einen logischen
Wert. Standardmäßig \f[CR]no\f[R].\fR
.TP 
\f[CR]Firmware=\f[R], \f[CR]\-\-firmware=\fR
Konfiguriert die zu verwendende Firmware. Akzeptiert entweder
\f[CR]uefi\f[R], \f[CR]uefi\-secure\-boot\f[R], \f[CR]bios\f[R],
\f[CR]linux\f[R] oder \f[CR]auto\f[R]. Standardmäßig \f[CR]auto\f[R]. Falls
auf \f[CR]uefi\f[R] gesetzt, wird die OVMF\-Firmware ohne Unterstützung für
sicheren Systemstart verwandt. Falls auf \f[CR]uefi\-secure\-boot\f[R]
gesetzt, wird die OVMF\-Firmware mit Unterstützung für sicheren Systemstart
verwandt. Falls auf \f[CR]bios\f[R] gesetzt, wird die
Standard\-SeaBIOS\-Firmware verwandt. Falls auf \f[CR]linux\f[R] gesetzt, wird
der direkte Kernelstart verwandt. Siehe die Option \f[CR]Linux=\f[R] für
weitere Details darüber, welches Kernelabbild mit direktem Kernelsystemstart
verwandt wird. Falls auf \f[CR]auto\f[R] gesetzt wird falls möglich
\f[CR]uefi\-secure\-boot\f[R] und ansonsten \f[CR]linux\f[R] verwandt.\fR
.TP 
\f[CR]FirmwareVariables=\f[R], \f[CR]\-\-firmware\-variables=\fR
Konfiguriert den Pfad zu den zu verwendenden Firmwarevariablendateien der
virtuellen Maschine. Derzeit wird diese Option nur berücksichtigt, wenn die
Firmware \f[CR]uefi\f[R] oder \f[CR]uefi\-secure\-boot\f[R] verwandt
wird. Falls nicht angegeben, wird \f[B]mkosi\f[R] nach der
Standard\-Variablen\-Datei suchen und diese stattdessen verwenden.\fR
.RS
.PP
Falls auf \f[CR]microsoft\f[R] gesetzt, wird eine Firmwarevariablendatei mit
bereits registriertem sicheren Systemstartzertifikat von Microsoft
verwandt.\fR
.PP
Falls auf \f[CR]microsoft\-mok\f[R] gesetzt wird eine bereits registrierte
Firmware\-Variablen\-Datei mit dem »Microsoft secure boot«\-Zertifikaten durch
eine \f[CR]MokList\f[R]\-Variable erweitert, die das Zertifikat für den
sicheren Systemstart aus \f[CR]SecureBootCertificate=\f[R] enthält. Dies ist
für die gemeinsame Verwendung von durch die Distribution signierten
Shim\-Programmen und lokal signierten EFI\-Programmen gedacht.\fR
.PP
Falls auf \f[CR]custom\f[R] gesetzt, wird ein Zertifikat für sicheren
Systemstart von \f[CR]SecureBootCertificate=\f[R] in die
Standard\-Firmwarevariablendatei registriert.\fR
.PP
\f[CR]virt\-fw\-vars\f[R] aus dem Projekt
.UR https://gitlab.com/kraxel/virt\-firmware
virt\-firmware
.UE
kann zum
Anpassen der OVMF\-Variablendateien verwandt werden.\fR
.RE
.TP 
\f[CR]Linux=\f[R], \f[CR]\-\-linux=\fR
Setzt das für direkten Kernelsystemstart in \f[B]qemu\f[R] zu verwendende
Kernelabbild. Falls nicht angegeben wird \f[B]mkosi\f[R] den über die
Befehlszeile bereitgestellten Kernel (Option \f[CR]\-kernel\f[R]) oder den
neusten Kernel, der im Abbild installiert wurde, verwenden (oder
fehlschlagen, falls kein Kernel im Abbild installiert wurde).\fR
.RS
.PP
Beachten Sie, dass bei der Verwendung des Ausgabeformats \f[CR]cpio\f[R] der
direkte Kernelsystemstart unabhängig von der konfigurierten Firmware
verwandt wird. Abhängig von der konfigurierten Firmware könnte
\f[B]qemu\f[R] den Kernel selbst starten oder die konfigurierte Firmware
verwenden.\fR
.RE
.TP 
\f[CR]Drives=\f[R], \f[CR]\-\-drive=\fR
Fügt ein Laufwerk hinzu. Akzeptiert eine Doppelpunkt\-getrennte Zeichenkette
im Format
\f[CR]<Kennung>:<Größe>[:<Verzeichnis>[:<Optionen>[:<Dateikennung>]]]\f[R].
\f[CR]Kennung\f[R] legt die dem Laufwerk zugeordnete Kennung fest. Diese
kann als die Eigenschaft \f[CR]drive=\f[R] in verschiedenen
\f[B]qemu\f[R]\-Geräten verwandt werden. \f[CR]Größe\f[R] legt die Größe des
Laufwerks fest. Dies akzeptiert eine Größe in Byte. Zusätzliche können die
Endungen \f[CR]K\f[R], \f[CR]M\f[R] und \f[CR]G\f[R] zur Festlegung einer
Größe in Kilobyte, Megabyte bzw. Gigabyte verwandt
werden. \f[CR]Verzeichnis\f[R] legt optional das Verzeichnis fest, in dem
das dem Laufwerk zugrunde liegende Verzeichnis erstellt werden
soll. \f[CR]Optionen\f[R] legen optional zusätzliche, durch Kommata
getrennte Eigenschaften fest, die unverändert an die Option
\f[CR]\-drive\f[R] von \f[B]qemu\f[R] übergeben
werden. \f[CR]Dateikennung\f[R] 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.\fR
.RS
.PP
\f[B]Beispielhafte Verwendung:\fR
.IP
.EX
\f[B][Runtime]\f[R]
Drives=btrfs:10G
       ext4:20G
QemuArgs=\-device nvme,serial=btrfs,drive=btrfs
         \-device nvme,serial=ext4,drive=ext4\fR
.EE
.RE
.TP 
\f[CR]QemuArgs=\fR
Leerzeichen\-begrenzte Liste von zusätzlich beim Aufruf von \f[B]qemu\f[R] zu
übergebenen Argumenten.
.TP 
\f[CR]Ephemeral=\f[R], \f[CR]\-\-ephemeral\fR
Bei der Verwendung mit den Unterbefehlen \f[CR]shell\f[R], \f[CR]boot\f[R]
oder \f[CR]vm\f[R] 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
(\f[B]btrfs\f[R](5) oder \f[B]xfs\f[R](5)), als auf traditionellen, bei
denen das nicht der Fall ist (\f[B]ext4\f[R](5)).\fR
.TP 
\f[CR]Credentials=\f[R], \f[CR]\-\-credential=\fR
Setzt die an \f[B]systemd\-nspawn\f[R](1) bzw. der virtuellen Maschine zu
übergebenen Zugangsberechtigungen, wenn \f[CR]mkosi shell/boot\f[R] oder
\f[CR]mkosi vm\f[R] 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.\fR
.RS
.PP
Beachten Sie, dass die Werte nur als Pfade behandelt werden, falls sie den
Begrenzer (\f[CR]=\f[R]) nicht enthalten.\fR
.RE
.TP 
\f[CR]KernelCommandLineExtra=\f[R], \f[CR]\-\-kernel\-command\-line\-extra=\fR
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
\f[B]systemd\f[R](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
\f[B]systemd\-boot\f[R](7)/\f[B]systemd\-stub\f[R](7) erst ab Version v254
aufgenommen.\fR
.TP 
\f[CR]RuntimeTrees=\f[R], \f[CR]\-\-runtime\-tree=\fR
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 \f[CR]/root/src\f[R] in der
Maschine eingehängt. Falls der zweite Pfad relativ ist, wird er relativ zu
\f[CR]/root/src\f[R] in der Maschine interpretiert.\fR
.RS
.PP
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.
.PP
Beachten Sie, dass bei der Verwendung von \f[CR]mkosi vm\f[R] mit dieser
Funktionalität Systemd v254 oder neuer im Abbild installiert sein muss.\fR
.RE
.TP 
\f[CR]RuntimeSize=\f[R], \f[CR]\-\-runtime\-size=\fR
Falls angegeben werden Plattenabbilder bis zu der angegebenen Größe
vergrößert, wenn sie mit \f[CR]mkosi boot\f[R] oder \f[CR]mkosi vm\f[R]
gestartet werden. Akzeptiert eine Größe in Byte. Zusätzlich können die
Endungen \f[CR]K\f[R], \f[CR]M\f[R] und \f[CR]G\f[R] verwandt werden, um
eine Größe in Kilobyte, Megabyte bzw. Gigabyte festzulegen.\fR
.TP 
\f[CR]RuntimeScratch=\f[R], \f[CR]\-\-runtime\-scratch=\fR
Akzeptiert einen logischen Wert oder \f[CR]auto\f[R]. Legt fest, ob ein
zusätzlicher Arbeitsbereich unter \f[CR]/var/tmp\f[R] eingehängt werden
soll. Falls aktiviert, wird ein praktisch unbegrenzter Arbeitsbereich unter
\f[CR]/var/tmp\f[R] zur Verfügung gestellt, wenn das Abbild mit \f[CR]mkosi
vm\f[R], \f[CR]mkosi boot\f[R] oder \f[CR]mkosi shell\f[R] gestartet wird.
.RS
.PP
Beachten Sie, dass bei der Verwendung von \f[CR]mkosi vm\f[R] mit dieser
Funktionalität Systemd v254 oder neuer im Abbild installiert sein muss.\fR
.RE
.TP 
\f[CR]RuntimeNetwork=\f[R], \f[CR]\-\-runtime\-network=\fR
Akzeptiert entweder \f[CR]user\f[R], \f[CR]interface\f[R] oder
\f[CR]none\f[R]. Standardmäßig \f[CR]user\f[R]. Legt das beim Systemstart
einzurichtende Netzwerk fest. \f[CR]user\f[R] richtet
Benutzermodus\-Vernetzung ein. \f[CR]interface\f[R] richtet eine virtuelle
Netzwerkverbindung zwischen dem Wirtrechner und dem Abbild ein. Dies
übersetzt sich in eine Veth\-Schnittstelle für \f[CR]mkosi shell\f[R] und
\f[CR]mkosi boot\f[R] und eine Tap\-Schnittstelle für \f[CR]mkosi vm\f[R] und
\f[CR]mkosi vmspawn\f[R].\fR
.RS
.PP
Beachten Sie, dass bei der Verwendung von \f[CR]interface\f[R]
\f[B]mkosi\f[R] nicht automatisch die Schnittstelle des Wirtsystems
konfiguriert. Es wird erwartet, dass auf dem Wirtsystem eine hinreichend
neue Version von \f[B]systemd\-networkd\f[R](8) läuft, die automatisch die
Schnittstelle des Links auf dem Wirtsystem konfiguriert.\fR
.RE
.TP 
\f[CR]RuntimeBuildSources=\f[R], \f[CR]\-\-runtime\-build\-sources=\fR
Hängt die mit \f[CR]BuildSources=\f[R] konfigurierten Bauquellen und das
Bauverzeichnis (falls eines konfiguriert wurde) an die gleichen Orte in
\f[CR]/work\f[R] ein, an der sie eingehängt würden, wenn das Bauskript
ausgeführt würde, wenn \f[CR]mkosi boot\f[R] oder \f[CR]mkosi vm\f[R]
verwandt würde.\fR
.TP 
\f[CR]RuntimeHome=\f[R], \f[CR]\-\-runtime\-home=\fR
Hängt das aktuelle Home\-Verzeichnis, von dem aus \f[B]mkosi\f[R] läuft, bei
der Verwendung von \f[CR]mkosi boot\f[R] oder \f[CR]mkosi vm\f[R] unter
\f[CR]/root\f[R] ein.\fR
.TP 
\f[CR]UnitProperties=\f[R], \f[CR]\-\-unit\-property=\fR
Konfiguriert Systemd\-Unit\-Eigenschaften, die zu den zugewiesenen
Systemd\-Geltungsbereichen hinzugewiesen werden sollen, wenn \f[CR]mkosi
boot\f[R] oder \f[CR]mkosi vm\f[R] verwandt wird. Diese werden direkt an die
Optionen \f[CR]\-\-property\f[R] von \f[B]systemd\-nspawn\f[R](1)
bzw. \f[B]systemd\-run\f[R](1) übergeben.\fR
.TP 
\f[CR]SshKey=\f[R], \f[CR]\-\-ssh\-key=\fR
Pfad zu dem privaten X.509\-Schlüssel im PEM\-Format, der für die Verbindung
zu einer mit \f[CR]mkosi vm\f[R] gestarteten virtuellen Maschine verwandt
werden soll und die mittels des Befehls \f[CR]mkosi ssh\f[R] aktivierten
Option \f[CR]Ssh=\f[R] gebaut wurde. Falls nicht konfiguriert und
\f[CR]mkosi.key\f[R] im aktuellen Arbeitsverzeichnis existiert, wird dies
automatisch für diesen Zweck verwandt. Führen Sie \f[CR]mkosi genkey\f[R]
aus, um automatisch einen Schlüssel in \f[CR]mkosi.key\f[R] zu erstellen.\fR
.TP 
\f[CR]SshCertificate=\f[R], \f[CR]\-\-ssh\-certificate=\fR
Pfad zu dem X.509\-Zertifikat im PEM\-Format zur Beistellung als öffentlicher
SSH\-Schlüssel in durch \f[CR]mkosi vm\f[R] gestarteten virtuellen
Maschinen. Falls nicht konfiguriert und \f[CR]mkosi.crt\f[R] im aktuellen
Arbeitsverzeichnis existiert, wird dies automatisch für diesen Zweck
verwandt. Führen Sie \f[CR]mkosi genkey\f[R] aus, um automatisch ein
Zertifikat in \f[CR]mkosi.crt\f[R] zu erstellen.\fR
.TP 
\f[CR]Machine=\f[R], \f[CR]\-\-machine=\fR
Gibt den beim Starten der Maschine zu verwendenden Maschinennamen an. Kann
auch als Referenz auf ein bestimmtes Abbild beim Betreten mit SSH eines
bestimmten Abbildes verwandt werden (z.B. \f[CR]mkosi \-\-image=meinAbbild
ssh\f[R]).\fR
.RS
.PP
Beachten Sie, dass \f[CR]Ephemeral=\f[R] aktiviert sein muss, um mehrere
Instanzen des gleichen Abbildes zu starten.\fR
.RE
.TP 
\f[CR]Register=\f[R], \f[CR]\-\-register=\fR
Akzeptiert einen logischen Wert oder \f[CR]auto\f[R]. Legt fest, ob die
VM/der Container mit \f[B]systemd\-machined\f[R](8) registriert werden
soll. Falls aktiviert, wird \f[B]mkosi\f[R] fehlschlagen, falls es keine
VM/keinen Container mit \f[B]systemd\-machined\f[R](8) registrieren
kann. Falls deaktiviert, wird \f[B]mkosi\f[R] die VM/den Container nicht mit
\f[B]systemd\-machined\f[R](8) registrieren. Falls \f[CR]auto\f[R], wird
\f[B]mkosi\f[R] die VM/den Container mit \f[B]systemd\-machined\f[R](8)
registrieren, falls dies verfügbar ist. Standardmäßig \f[CR]auto\f[R].\fR
.TP 
\f[CR]ForwardJournal=\f[R], \f[CR]\-\-forward\-journal=\fR
Legt den Pfad fest, in dem Journalprotokolle aus Containern und virtuellen
Maschinen weitergeleitet werden sollen. Falls der Pfad die Erweiterung
\&\f[CR].journal\f[R] 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.\fR
.RS
.PP
Beachten Sie, dass Systemd v256 oder neuer in der virtuellen Maschine
benötigt wird, damit Protokollweiterleitung funktioniert.
.PP
Beachten Sie, dass die Journal\-Größe auf \f[CR]4G\f[R] beschränkt ist, falls
ein Pfad mit der Erweiterung \f[CR].journal\f[R] angegeben
wird. Konfigurieren Sie ein Ausgabeverzeichnis anstelle einer Datei, falls
ihre Auslastung mehr als \f[CR]4G\f[R] an Journal\-Daten erzeugt.\fR
.RE
.TP 
\f[CR]SysupdateDirectory=\f[R], \f[CR]\-\-sysupdate\-directory=\fR
Pfad zu einem Verzeichnis, das Transferdefinitionsdateien von
\f[B]systemd\-sysupdate\f[R](8) enthält, die von \f[CR]mkosi sysupdate\f[R]
verwandt werden. Falls im lokalen Verzeichnis \f[CR]mkosi.sysupdate/\f[R]
existiert, wird es automatisch für diesen Zweck verwandt.\fR
.RS
.PP
Beachten Sie, dass \f[CR]mkosi sysupdate\f[R] \f[B]systemd\-sysupdate\f[R](8)
mit \f[CR]\-\-transfer\-source=\f[R] auf das Ausgabeverzeichnis von
\f[B]mkosi\f[R] gesetzt aufgerufen wird. Um dies in einer
Transferdefinitionsdatei zu verwenden, setzen Sie
\f[CR]PathRelativeTo=explicit\f[R], damit die Einstellung \f[CR]Path=\f[R]
für die Transferquelle relativ zum Ausgabeverzeichnis von \f[B]mkosi\f[R]
interpretiert wird. Im Allgemeinen reicht es aus,
\f[CR]PathRelativeTo=explicit\f[R] und \f[CR]Path=/\f[R] relativ zu der
Transferquelle zu konfigurieren, damit das Vergleichsmuster relativ zum
Ausgabeverzeichnis von \f[B]mkosi\f[R] interpretiert wird.\fR
.RE
.SS "Abschnitt [Match]"
.TP 
\f[CR]Profiles=\fR
Übereinstimmung mit den konfigurierten Profilen.
.TP 
\f[CR]Distribution=\fR
Übereinstimmung mit der konfigurierten Distribution.
.TP 
\f[CR]Release=\fR
Ü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.
.TP 
\f[CR]Architecture=\fR
Übereinstimmung mit der konfigurierten Architektur. Falls diese Bedingung
verwandt wird und noch keine Architektur explizit konfiguriert wurde, wird
die Architektur des Wirtsystems verwandt.
.TP 
\f[CR]Repositories=\fR
Übereinstimmung mit Depots, die mit der Einstellung \f[CR]Repositories=\f[R]
aktiviert wurden. Akzeptiert einen einzelnen Depotnamen.\fR
.TP 
\f[CR]PathExists=\fR
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.
.TP 
\f[CR]ImageId=\fR
Ü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.
.TP 
\f[CR]ImageVersion=\fR
Übereinstimmung mit der konfigurierten Abbildversion. Den Abbildversionen
können die Operatoren \f[CR]==\f[R], \f[CR]!=\f[R], \f[CR]>=\f[R],
\f[CR]<=\f[R], \f[CR]<\f[R], \f[CR]>\f[R] 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.\fR
.TP 
\f[CR]Bootable=\fR
Übereinstimmung mit dem konfigurierten Wert für die Funktionalität
\f[CR]Bootable=\f[R]. Akzeptiert einen logischen Wert oder
\f[CR]auto\f[R].\fR
.TP 
\f[CR]Format=\fR
Übereinstimmung mit dem konfigurierten Wert für die Option
\f[CR]Format=\f[R]. Akzeptiert ein Ausgabeformat (siehe die Option
\f[CR]Format=\f[R]).\fR
.TP 
\f[CR]SystemdVersion=\fR
Übereinstimmung mit der Systemd\-Version des Wirtsystems (wie von
\f[CR]systemctl \-\-version\f[R] berichtet). Den Werten können die Operatoren
\f[CR]==\f[R], \f[CR]!=\f[R], \f[CR]>=\f[R], \f[CR]<=\f[R],
\f[CR]<\f[R], \f[CR]>\f[R] für umfangreiche Versionsvergleiche
entsprechend der UAPI\-Gruppenversionsformatspezifikation vorangestellt
werden. Falls kein Operator vorangestellt wird, wird standardmäßig der
Gleichheits\-Operator angenommen.\fR
.TP 
\f[CR]BuildSources=\fR
Akzeptiert einen Bauquellen\-Zielpfad (siehe \f[CR]BuildSources=\f[R]). Diese
Übereinstimmung ist erfüllt, falls eine der konfigurierten Bauquellen diesen
Zielpfad verwendet. Enthält beispielsweise eine Datei \f[CR]mkosi.conf\f[R]
Folgendes:\fR
.RS
.IP
.EX
\f[B][Build]\f[R]
BuildSources=../abc/qed:kernel\fR
.EE
.PP
Und eine Ergänzung, die folgendes enthält:
.IP
.EX
\f[B][Match]\f[R]
BuildSources=kernel\fR
.EE
.PP
Die Ergänzung wird aufgenommen.
.PP
Alle an diese Einstellung übergebenen absoluten Pfade werden relativ zum
aktuellen Arbeitsverzeichnis interpretiert.
.RE
.TP 
\f[CR]HostArchitecture=\fR
Übereinstimmung mit der grundständigen Architektur des Wirtrechners. Siehe
die Einstellung \f[CR]Architecture=\f[R] für eine Liste möglicher Werte.\fR
.TP 
\f[CR]ToolsTreeDistribution=\fR
Übereinstimmung mit der konfigurierten Werkzeugbaum\-Distribution.
.TP 
\f[CR]ToolsTreeRelease=\fR
Übereinstimmung mit der konfigurierten Werkzeugbaum\-Veröffentlichung.
.TP 
\f[CR]Environment=\fR
Übereinstimmung mit einem bestimmten, mit \f[CR]Environment=\f[R]
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.\fR
.PP
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:
.PP
.TS
tab(@);
lw(13.1n) lw(3.5n) lw(9.1n) lw(44.3n).
T{
Übereinstimmer
T}@T{
Globs
T}@T{
Umfangreiche Vergleiche
T}@T{
Vorgabe
T}
_
T{
\f[CR]Profiles=\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]Übereinstimmung schlägt fehl\fR
T}
T{
\f[CR]Distribution=\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]Übereinstimmung mit Distribution des Wirtsystems\fR
T}
T{
\f[CR]Release=\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]Übereinstimmung mit Veröffentlichung des Wirtsystems\fR
T}
T{
\f[CR]Architecture=\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]Übereinstimmung mit Architektur des Wirtsystems\fR
T}
T{
\f[CR]PathExists=\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]n.Z.\fR
T}
T{
\f[CR]ImageId=\fR
T}@T{
\f[R]yes\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]Übereinstimmung schlägt fehl\fR
T}
T{
\f[CR]ImageVersion=\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]yes\fR
T}@T{
\f[R]Übereinstimmung schlägt fehl\fR
T}
T{
\f[CR]Bootable=\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]Übereinstimmung mit automatischer Funktionalität\fR
T}
T{
\f[CR]Format=\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]Übereinstimmung mit Standardformat\fR
T}
T{
\f[CR]SystemdVersion=\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]yes\fR
T}@T{
\f[R]n.Z.\fR
T}
T{
\f[CR]BuildSources=\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]Übereinstimmung schlägt fehl\fR
T}
T{
\f[CR]HostArchitecture=\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]n.Z.\fR
T}
T{
\f[CR]ToolsTreeDistribution=\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]Übereinstimmung mit dem Rückfall\-Werkzeugbaum der Distribution (siehe
\f[CR]ToolsTreeDistribution=\f[R] in \f[CR][Build]\f[R])\fR
T}
T{
\f[CR]ToolsTreeRelease=\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]Übereinstimmung mit Standard\-Werkzeugbaum\-Veröffentlichung\fR
T}
T{
\f[CR]Environment=\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]no\fR
T}@T{
\f[R]n.Z.\fR
T}
.TE
.SS [Include]
.TP 
\f[CR]Include=\f[R], \f[CR]\-\-include=\f[R], \f[CR]\-I\fR
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.
.RS
.PP
Beachten Sie, dass jeder Pfad mit zusätzlicher Konfiguration nur einmal
ausgewertet wird, selbst wenn er mit \f[CR]Include=\f[R] mehrfach
eingebunden ist.\fR
.PP
Die eingebauten Konfigurationen für die Vorgabe\-Initrd, den
Vorgabe\-Werkzeugbaum und das standardmäßige Virtuelle\-Maschinenabbild von
\f[B]mkosi\f[R] können eingebunden werden, indem der wörtliche Wert
\f[CR]mkosi\-initrd\f[R], \f[CR]mkosi\-tools\f[R] bzw. \f[CR]mkosi\-vm\f[R]
eingebunden wird.\fR
.PP
Beachten Sie: Einbindenamen, die mit entweder dem wörtlichen
\f[CR]mkosi\-\f[R] oder \f[CR]contrib\-\f[R] beginnen, sind für die Verwendung
durch \f[B]mkosi\f[R] selbst reserviert.\fR
.RE
.SS "Abschnitt [Config]"
.TP 
\f[CR]Profiles=\f[R], \f[CR]\-\-profile=\fR
Wählt die angegebenen Profile aus. Ein Profil ist eine Konfigurationsdatei
oder \-verzeichnis in dem Verzeichnis \f[CR]mkosi.profiles/\f[R]. Die
Konfigurationsdateien und \-verzeichnisse werden nach der Auswertung der
Datei \f[CR]mkosi.conf\f[R], aber vor allen Ergänzungskonfigurationen in
\f[CR]mkosi.conf.d/*.conf\f[R] eingebunden.\fR
.TP 
\f[CR]Dependencies=\f[R], \f[CR]\-\-dependency=\fR
Die Abbilder, von denen dieses Abbild abhängt, festgelegt als
Kommata\-getrennte Liste. Alle in dieser Option konfigurierten Abbilder
werden vor diesem Abbild gebaut.
.RS
.PP
Wird diese Einstellung für das »Hauptabbild« angegeben, legt sie fest,
welche Unterabbilder gebaut werden sollen. Siehe den Abschnitt \f[B]Bau
mehrerer Abbilder\f[R] für weitere Informationen.\fR
.RE
.TP 
\f[CR]MinimumVersion=\f[R], \f[CR]\-\-minimum\-version=\fR
Die minimale Version von \f[B]mkosi\f[R], die zum Bau dieser Konfiguration
benötigt wird. Falls mehrfach angegeben, wird die höchste festgelegte
Version verwandt.
.TP 
\f[CR]ConfigureScripts=\f[R], \f[CR]\-\-configure\-script=\fR
Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als
Konfigurationsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt
\f[B]Skripte\f[R] für weitere Informationen.\fR
.TP 
\f[CR]PassEnvironment=\f[R], \f[CR]\-\-pass\-environment=\fR
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 \f[B]Bau mehrerer
Abbilder\f[R] für weitere Informationen.\fR
.SS "Abschnitt [UKIProfile]"
Der Abschnitt \f[CR]UKIProfile\f[R] kann in UKI\-Profil\-Konfigurationsdateien
verwandt werden, die an die Einstellung
\f[CR]UnifiedKernelImageProfiles=\f[R] übergeben werden. Die folgenden
Einstellungen können im Abschnitt \f[CR]UKIProfile\f[R] festgelegt
werden:\fR
.TP 
\f[CR]Profile=\fR
Der Inhalt des Abschnitts \f[CR].profile\f[R] des UKI\-Profils. Akzeptiert
eine Liste von Schlüssel/Wert\-Paaren, getrennt durch \f[CR]=\f[R]. Der
Schlüssel \f[CR]ID=\f[R] muss angegeben werden. Siehe die
.UR https://uapi\-group.org/specifications/specs/unified_kernel_image/#multi\-profile\-ukis
Spezifikation
.UE
für eine vollständige Liste aller möglichen
Schlüssel.\fR
.TP 
\f[CR]Cmdline=\fR
Zusätzliche Kernelbefehlszeilenoptionen für das UKI\-Profil. Akzeptiert eine
durch Leerzeichen begrenzte Liste von zusätzlichen
Kernelbefehlszeilenargumenten. Beachten Sie, dass der letztendliche
Abschnitt \f[CR].cmdline\f[R] eine Kombination des grundlegenden Abschnitts
\&\f[CR].cmdline\f[R] und der mit dieser Option festgelegten zusätzlichen
Kernelbefehlszeilenargumente ist.\fR
.SS Kennzeichner
Auf den aktuelle Wert verschiedener Einstellungen kann beim Auswerten
mittels Kennzeichner zugegriffen werden. Um ein wörtliches Zeichen
\f[CR]%\f[R] in einer Konfiguration zu schreiben, ohne es als Kennzeichner
zu behandeln, verwenden Sie \f[CR]%%\f[R]. Es werden die folgenden
Kennzeichner verstanden:\fR
.PP
.TS
tab(@);
l l.
T{
Einstellung
T}@T{
Kennzeichner
T}
_
T{
\f[CR]Distribution=\fR
T}@T{
\f[CR]%d\fR
T}
T{
\f[CR]Release=\fR
T}@T{
\f[CR]%r\fR
T}
T{
\f[CR]Architecture=\fR
T}@T{
\f[CR]%a\fR
T}
T{
\f[CR]Format=\fR
T}@T{
\f[CR]%t\fR
T}
T{
\f[CR]Output=\fR
T}@T{
\f[CR]%o\fR
T}
T{
\f[CR]OutputDirectory=\fR
T}@T{
\f[CR]%O\fR
T}
T{
\f[CR]ImageId=\fR
T}@T{
\f[CR]%i\fR
T}
T{
\f[CR]ImageVersion=\fR
T}@T{
\f[CR]%v\fR
T}
.TE
.PP
Es gibt auch von Einstellungen unabhängige Kennzeichner:
.PP
.TS
tab(@);
l l.
T{
Kennzeichner
T}@T{
Wert
T}
_
T{
\f[CR]%C\fR
T}@T{
\f[R]Elternverzeichnis der aktuellen Konfigurationsdatei\fR
T}
T{
\f[CR]%P\fR
T}@T{
\f[R]Aktuelles Arbeitsverzeichnis\fR
T}
T{
\f[CR]%D\fR
T}@T{
\f[R]Verzeichnis, in dem \f[B]mkosi\f[R] aufgerufen wurde\fR
T}
T{
\f[CR]%I\fR
T}@T{
\f[R]Name des aktuellen Unterabbildes in \f[CR]mkosi.images\fR
T}
.TE
.PP
Schließlich gibt es Kennzeichner, die von einer Einstellung abgeleitet
werden:
.PP
.TS
tab(@);
l l.
T{
Kennzeichner
T}@T{
Wert
T}
_
T{
\f[CR]%F\fR
T}@T{
\f[R]Das Standarddateisystem der konfigurierten Distribution\fR
T}
.TE
.PP
Beachten Sie, dass sich das aktuelle Arbeitsverzeichnis ändert, während
\f[B]mkosi\f[R] seine Konfiguration auswertet. Insbesondere ändert
\f[B]mkosi\f[R] sein Arbeitsverzeichnis jedes Mal, wenn es ein Verzeichnis
mit einer Datei \f[CR]mkosi.conf\f[R] auswertet, auf dieses Verzeichnis.\fR
.PP
Beachten Sie, dass das Verzeichnis, aus dem \f[B]mkosi\f[R] heraus
aufgerufen wurde, durch das Befehlszeilenargument \f[CR]\-\-directory=\f[R]
beeinflusst wird.\fR
.PP
Die folgende Tabelle zeigt Beispielwerte für die oben aufgeführten
Verzeichniskennzeichner:
.PP
.TS
tab(@);
lw(4.7n) lw(13.4n) lw(25.2n) lw(26.7n).
T{
T}@T{
\f[CR]$D/mkosi.conf\fR
T}@T{
\f[CR]$D/mkosi.conf.d/abc/abc.conf\fR
T}@T{
\f[CR]$D/mkosi.conf.d/abc/mkosi.conf\fR
T}
\f[R]_\fR
T{
\f[CR]%C\fR
T}@T{
\f[CR]$D\fR
T}@T{
\f[CR]$D/mkosi.conf.d\fR
T}@T{
\f[CR]$D/mkosi.conf.d/abc\fR
T}
T{
\f[CR]%P\fR
T}@T{
\f[CR]$D\fR
T}@T{
\f[CR]$D\fR
T}@T{
\f[CR]$D/mkosi.conf.d/abc\fR
T}
T{
\f[CR]%D\fR
T}@T{
\f[CR]$D\fR
T}@T{
\f[CR]$D\fR
T}@T{
\f[CR]$D\fR
T}
.TE
.SS "Unterstützte Distributionen"
Für die folgenden Distributionen können Abbilder zur Installation erstellt
werden:
.IP \[bu] 2
\f[I]Fedora Linux\fR
.IP \f[R]\[bu]\fR 2
\f[I]Debian\fR
.IP \f[R]\[bu]\fR 2
\f[I]Kali Linux\fR
.IP \f[R]\[bu]\fR 2
\f[I]Ubuntu\fR
.IP \f[R]\[bu]\fR 2
\f[I]Arch Linux\fR
.IP \f[R]\[bu]\fR 2
\f[I]openSUSE\fR
.IP \f[R]\[bu]\fR 2
\f[I]Mageia\fR
.IP \f[R]\[bu]\fR 2
\f[I]CentOS\fR
.IP \f[R]\[bu]\fR 2
\f[I]RHEL\fR
.IP \f[R]\[bu]\fR 2
\f[I]RHEL UBI\fR
.IP \f[R]\[bu]\fR 2
\f[I]OpenMandriva\fR
.IP \f[R]\[bu]\fR 2
\f[I]Rocky Linux\fR
.IP \f[R]\[bu]\fR 2
\f[I]Alma Linux\fR
.IP \f[R]\[bu]\fR 2
\f[I]Azure Linux\fR
.IP \f[R]\[bu]\fR 2
\f[I]None\f[R] (\f[B]Dazu muss der Benutzer ein bereits gebautes Rootfs
bereitstellen\f[R])\fR
.PP
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
\f[B]apt\f[R](8) paketiert, kann zum Bau von Abbildern von \f[I]Debian\f[R],
\f[I]Kali\f[R] oder \f[I]Ubuntu\f[R] verwandt werden. Jede Distribution, die
\f[B]dnf\f[R](8) paketiert, kann zum Bau von Abbildern von jeder
\f[V]rpm\f[R](8)\-basierten Distribution verwandt werden. Jede Distribution,
die \f[B]pacman\f[R](8) paketiert, kann zum Bau von Abbildern von \f[I]Arch
Linux\f[R] verwandt werden. Jede Distribution, die \f[B]zypper\f[R](8)
paketiert, kann zum Bau von Abbildern von \f[I]openSUSE\f[R] verwandt
werden. Andere Distributionen und Bauautomatisierungswerkzeuge für
eingebettete Linux\-Systeme wie Buildroot, OpenEmbedded und Yocto Project
können durch Auswahl der Distribution \f[CR]custom\f[R] und der Befüllung
des Rootfs mit einer Kombination von Basisbäumen, Gerüstbäumen und
Vorbereitungsskripten verwandt werden.\fR
.PP
Derzeit paketiert \f[I]Fedora Linux\f[R] alle relevanten Werkzeuge seit
Fedora 28.\fR
.PP
Beachten Sie, dass Sie Abbilder für \f[CR]RHEL\f[R] nur auf einem Wirtsystem
bauen können, das über ein \f[CR]RHEL\f[R]\-Abonnement verfügt (das
beispielsweise mit dem \f[CR]subscription\-manager\f[R] eingerichtet wurde),
wenn Sie keinen angepassten Spiegel verwenden.\fR
.SH Arbeitsablauf
Arbeitsablauf für \f[CR]mkosi build\f[R]. Standardwerte bzw. \-aufrufe werden
in Klammern dargestellt. Beim Bau mit \f[CR]\-\-incremental\f[R] erstellt
\f[B]mkosi\f[R] einen Zwischenspeicher der Distributionsinstallation, falls
er nicht bereits existiert und ersetzt die Distributionsinstallation in
sukzessiven Aufrufen durch Daten aus dem Zwischenspeicher.\fR
.IP \f[R]1.\fR 3
Wertet Befehlszeilen\-Optionen aus
.IP 2. 3
Wertet Konfigurationsdateien aus
.IP 3. 3
Führt Konfigurationsskripte aus (\f[CR]mkosi.configure\f[R])\fR
.IP \f[R]4.\fR 3
Falls nicht als Root ausgeführt wird, trennt den Benutzernamensraum ab und
der in \f[CR]/etc/subuid\f[R] und \f[CR]/etc/subgid\f[R] konfigurierte
Subuid\-Bereich wird darin abgebildet.\fR
.IP \f[R]5.\fR 3
Trennt den Einhängenamensraum ab
.IP 6. 3
Hängt die folgenden Verzeichnisse schreibgechützt neu ein, falls sie
existieren:
.RS 4
.IP \[bu] 2
\f[CR]/usr\fR
.IP \f[R]\[bu]\fR 2
\f[CR]/etc\fR
.IP \f[R]\[bu]\fR 2
\f[CR]/opt\fR
.IP \f[R]\[bu]\fR 2
\f[CR]/srv\fR
.IP \f[R]\[bu]\fR 2
\f[CR]/boot\fR
.IP \f[R]\[bu]\fR 2
\f[CR]/efi\fR
.IP \f[R]\[bu]\fR 2
\f[CR]/media\fR
.IP \f[R]\[bu]\fR 2
\f[CR]/mnt\fR
.RE
.PP
Führen Sie dann für jedes Abbild die folgenden Schritte aus:
.IP " 1." 4
Kopieren von Sandbox\-Bäumen in den Arbeitsbereich
.IP " 2." 4
Synchronisieren der Depot\-Metadaten des Paketverwalters
.IP " 3." 4
Ausführen der Synchronisierungsskripte (\f[CR]mkosi.sync\f[R])\fR
.IP "\f[R] 4.\fR" 4
Kopieren der Basisbäume (\f[CR]\-\-base\-tree=\f[R]) in das Abbild\fR
.IP "\f[R] 5.\fR" 4
Wiederverwenden eines zwischengespeicherten Abbilds, falls verfügbar
.IP " 6." 4
Kopieren eines Schnappschusses der Depot\-Metadaten des Paketverwalters in
das Abbild
.IP " 7." 4
Kopieren von Gerüstbäumen (\f[CR]mkosi.skeleton\f[R]) in das Abbild\fR
.IP "\f[R] 8.\fR" 4
Installieren der Distribution und Pakete in das Abbild
.IP " 9." 4
Ausführen der Vorbereitungsskripte auf dem Abbild mit dem Argument
\f[CR]final\f[R] (\f[CR]mkosi.prepare\f[R])\fR
.IP \f[R]10.\fR 4
Installieren der Baupakete in der Überlagerung, falls irgendwelche
Bauskripte konfiguriert sind
.IP 11. 4
Ausführen der Vorbereitungsskripte auf der Überlagerung mit dem Argument
\f[CR]build\f[R], falls irgendwelche Bauskripte konfiguriert sind
(\f[CR]mkosi.prepare\f[R])\fR
.IP \f[R]12.\fR 4
Zwischenspeichern des Abbilds, falls konfiguriert
(\f[CR]\-\-incremental\f[R])\fR
.IP \f[R]13.\fR 4
Ausführen der Bauskripte auf dem Abbild & der Überlagerung, falls
irgendwelche Bauskripte konfiguriert sind (\f[CR]mkosi.build\f[R])\fR
.IP \f[R]14.\fR 4
Finalisieren des Baus, falls das Ausgabeformat \f[CR]none\f[R] konfiguriert
ist\fR
.IP \f[R]15.\fR 4
Kopieren der Bauskripteausgaben in das Abbild
.IP 16. 4
Kopieren der zusätzlichen Bäume in das Abbild (\f[CR]mkosi.extra\f[R])\fR
.IP \f[R]17.\fR 4
Ausführen der Post\-Install\-Skripte (\f[CR]mkosi.postinst\f[R])\fR
.IP \f[R]18.\fR 4
Schreiben der für \f[CR]Ssh=\f[R], \f[CR]Autologin=\f[R] und
\f[CR]MakeInitrd=\f[R] benötigten Konfigurationsdateien\fR
.IP \f[R]19.\fR 4
Installieren von \f[CB]systemd\-boot\f[R](7) und konfigurieren des sicheren
Systemstart, falls konfiguriert (\f[CR]\-\-secure\-boot\f[R])\fR
.IP \f[R]20.\fR 4
Ausführen von \f[B]systemd\-sysusers\fR(8)
.IP \f[R]21.\fR 4
Ausführen von \f[B]systemd\-tmpfiles\fR(8)
.IP \f[R]22.\fR 4
Ausführen von \f[CR]systemctl preset\-all\fR
.IP \f[R]23.\fR 4
Ausführen von \f[B]depmod\fR(8)
.IP \f[R]24.\fR 4
Ausführen von \f[B]systemd\-firstboot\fR(1)
.IP \f[R]25.\fR 4
Ausführen vom \f[B]systemd\-hwdb\fR(8)
.IP \f[R]26.\fR 4
Entfernen von Pakete und Dateien (\f[CR]RemovePackages=\f[R],
\f[CR]RemoveFiles=\f[R])\fR
.IP \f[R]27.\fR 4
Ausführen von SELinux\-Neumarkierung, falls eine SELinux\-Richtlinie
installiert ist
.IP 28. 4
Ausführen von Finalisierungskripten (\f[CR]mkosi.finalize\f[R])\fR
.IP \f[R]29.\fR 4
Erstellen des Vereinigten Kernelabbildes, falls so konfiguriert
.IP 30. 4
Erstellen des finalen Ausgabeformats
.IP 31. 4
Ausführen der Post\-Ausgabe\-Skripte (\f[CR]mkosi.postoutput\f[R])\fR
.SH Skripte
Um die Anpassung von Abbildern zu erlauben, die nicht mittels der in
\f[B]mkosi\f[R] eingebauten Funktionalitäten implementiert werden können,
unterstützt \f[B]mkosi\f[R] 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 \f[B]mkosi\f[R]
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 (\f[CR]BuildSources=\f[R]) in das
aktuelle Arbeitsverzeichnis eingehängt, bevor das Skript im aktuellen
Arbeitsverzeichnis ausgeführt wird. \f[CR]$SRCDIR\f[R] wird so gesetzt, dass
es auf das aktuelle Arbeitsverzeichnis zeigt. Die folgenden Skripte werden
unterstützt:\fR
.IP \f[R]\[bu]\fR 2
Falls \f[CB]mkosi.configure\f[R] (\f[CR]ConfigureScripts=\f[R]) 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 \f[CR]build\f[R],
\f[CR]vm\f[R], \f[CR]boot\f[R] und \f[CR]shell\f[R]). 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
\f[CR]summary\f[R] sichtbar sein werden.\fR
.IP \f[R]\[bu]\fR 2
Falls \f[CB]mkosi.sync\f[R] (\f[CR]SyncScripts=\f[R]) 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 \f[CR]git pull\f[R] in
verschiedenen Quelldepots vor dem Bau des Abbildes. Insbesondere gilt die
Einstellung \f[CR]BuildSourcesEphemeral=\f[R] nicht für
Synchronisationsskripte, was bedeutet, dass Synchronisationsskripte zur
Aktualisierung von Bauquellen verwandt werden können, selbst wenn
\f[CR]BuildSourcesEphemeral=\f[R] aktiviert ist.\fR
.IP \f[R]\[bu]\fR 2
Falls \f[CB]mkosi.prepare\f[R] (\f[CR]PrepareScripts=\f[R]) existiert, wird
es zuerst mit dem Argument \f[CR]final\f[R] aufgerufen, direkt nachdem die
Software\-Pakete installiert sind. Es wird ein zweites Mal mit dem
Befehlszeilenparameter \f[CR]build\f[R] 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. \ \f[B]pip\f[R](1), \f[B]npm\f[R](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
(\f[CR]pip install\f[R], \f[CR]npm install \-g\f[R]) anstelle in
\f[CR]$SRCDIR\f[R] 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.\fR
.IP \f[R]\[bu]\fR 2
Falls \f[CB]mkosi.build\f[R] (\f[CR]BuildScripts=\f[R]) existiert, wird es
ausgeführt, wenn die Bauüberlagerung oberhalb des Wurzelverzeichnisses des
Abbildes eingehängt wurde. Bei der Ausführung der Bauskripte zeigt
\f[CR]$DESTDIR\f[R] 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 \f[B]make\f[R](1),\f[B]automake\f[R](1) und
\f[B]meson\f[R](1) basieren, im Allgemeinen \f[CR]$DESTDIR\f[R]
berücksichtigen und damit der Bau von \f[I]source\f[R]\-Bäumen sehr natürlich
vonstatten geht. Nach der Ausführung des Bauskripts wird der Inhalt von
\f[CR]$DESTDIR\f[R] in das Abbild kopiert.\fR
.IP \f[R]\[bu]\fR 2
Falls \f[CB]mkosi.postinst\f[R] (\f[CR]PostInstallationScripts=\f[R])
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.\fR
.IP \f[R]\[bu]\fR 2
Falls \f[CB]mkosi.finalize\f[R] (\f[CR]FinalizeScripts=\f[R]) existiert,
wird es als letzter Schritt der Vorbereitung des Abbildes ausgeführt.\fR
.IP \f[R]\[bu]\fR 2
Falls \f[CB]mkosi.postoutput\f[R] (\f[CR]PostOutputScripts=\f[R]) 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.\ \f[CR]SHA256FILES\f[R] oder SBOM\-Listen.\fR
.IP \f[R]\[bu]\fR 2
Falls \f[CB]mkosi.clean\f[R] (\f[CR]CleanScripts=\f[R]) existiert, wird es
direkt nach der Bereinigung eines vorherigen Baus ausgeführt. Ein
Bereinigungsskript kann sämtliche Ausgaben bereinigen, die \f[B]mkosi\f[R]
nicht kennt (z.B. Artefakte von \f[CR]SplitArtifacts=partitions\f[R] oder
RPMs, die in einem Bauskript erstellt wurden). Beachten Sie, dass dieses
Skript den Werkzeugbaum nicht verwendet, selbst wenn einer konfiguriert
ist.\fR
.IP \f[R]\[bu]\fR 2
Falls \f[CB]mkosi.version\f[R] existiert und ausführbar ist, wird sie
während der Auswertung der Konfiguration ausgeführt und füllt
\f[CR]ImageVersion=\f[R] mit der Ausgabe auf der Standardausgabe. Dies kann
für externe Versionverfolgung verwandt werden, z.B.\ mit \f[CR]git
describe\f[R] oder \f[CR]date \[aq]+%Y\-%m\-%d\[aq]\f[R]. Beachten Sie, dass
dieses Skript auf dem Hauptsystem ohne irgendeine Sandbox ausgeführt
wird.\fR
.IP \f[R]\[bu]\fR 2
Falls \f[CB]mkosi.version\f[R] existiert und ausführbar ist, wird sie
während der Auswertung der Konfiguration ausgeführt und füllt
\f[CR]RootPassword=\f[R] 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 \f[CR]$MKOSI_CONFIG\f[R] in einem anderen Skript (z.B.\ \f[CR]mkosi.postoutput\f[R]) ermittelt werden. Beachten Sie, dass dieses
Skript auf dem Hauptsystem ohne irgendeine Sandbox ausgeführt wird.\fR
.PP
Falls ein Skript die Erweiterung \f[CR].chroot\f[R] verwendet, wird
\f[B]mkosi\f[R] ein \f[B]chroot\f[R](8) mittels \f[B]mkosi\-chroot\f[R]
(siehe unten) durchführen, bevor das Skript ausgeführt wird. Falls
beispielsweise \f[CR]mkosi.postinst.chroot\f[R] existiert, wird
\f[B]mkosi\f[R] ein \f[B]chroot\f[R](8) in das Abbild durchführen und das
Skript als Postinstallationsskript ausführen.\fR
.PP
Anstatt eines Skripts in einer einzelnen Datei wird \f[B]mkosi\f[R] auch
alle Dateien in lexikographischer Reihenfolge aus geeignet benannten
Verzeichnissen \f[CR].d\f[R] lesen, z.B.\ alle Dateien in einem Verzeichnis
\f[CR]mkosi.build.d\f[R] würden als Bauskripte verwandt. Folgende
Verzeichnisse werden unterstützt:\fR
.IP \f[R]\[bu]\fR 2
\f[CR]mkosi.sync.d\f[R],\fR
.IP \f[R]\[bu]\fR 2
\f[CR]mkosi.prepare.d\f[R],\fR
.IP \f[R]\[bu]\fR 2
\f[CR]mkosi.build.d\f[R],\fR
.IP \f[R]\[bu]\fR 2
\f[CR]mkosi.postinst.d\f[R],\fR
.IP \f[R]\[bu]\fR 2
\f[CR]mkosi.finalize.d\f[R],\fR
.IP \f[R]\[bu]\fR 2
\f[CR]mkosi.postoutput.d\f[R] und\fR
.IP \f[R]\[bu]\fR 2
\f[CR]mkosi.clean.d\f[R].\fR
.PP
Dies kann mit der Erweiterung \f[CR].chroot\f[R] kombiniert werden, z.B.\ würde \f[CR]mkosi.build.d/01\-foo.sh\f[R] ohne Wechsel mittels
\f[B]chroot\f[R](8) in das Abbild ausgeführt und
\f[CR]mkosi.build.d/02\-bar.sh.chroot\f[R] würde nach dem zuerst erfolgten
\f[B]chroot\f[R](8) in das Abbild ausgeführt.\fR
.PP
Von \f[B]mkosi\f[R] ausgeführte Skripte erhalten die folgenden
Umgebungsvariablen:\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$ARCHITECTURE\f[R] enthält die Architektur aus der Einstellung
\f[CR]Architecture=\f[R]. Falls \f[CR]Architecture=\f[R] nicht gesetzt ist,
wird es die native Architektur der Wirtmaschine erhalten. Siehe die
Dokumentation von \f[CR]Architecture=\f[R] für mögliche Werte dieser
Variablen.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$QEMU_ARCHITECTURE\f[R] enthält die Architektur aus
\f[CR]$ARCHITECTURE\f[R] in dem von \f[B]qemu\f[R] verwandten
Format. Nützlich, um das Programm von Qemu zu finden
(\f[CR]qemu\-system\-$QEMU_ARCHITECTURE\f[R]).\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$DISTRIBUTION\f[R] enthält die Distribution aus der Einstellung
\f[CR]Distribution=\f[R].\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$RELEASE\f[R] enthält die Veröffentlichung aus der Einstellung
\f[CR]Release=\f[R].\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$DISTRIBUTION_ARCHITECTURE\f[R] enthält die Architektur aus
\f[CR]$ARCHITECTURE\f[R] in dem von der konfigurierten Distribution
verwandten Format.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$PROFILES\f[R] enthält die Profile aus der Einstellung
\f[CR]Profiles=\f[R] als eine Kommata\-getrennte Zeichenkette.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$CACHED=\f[R] wird auf \f[CR]1\f[R] gesetzt, falls ein
zwischengespeichertes Abbild verfügbar ist, ansonsten auf \f[CR]0\f[R].\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$CHROOT_SCRIPT\f[R] 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 \f[B]mkosi\-chroot\f[R]. Siehe
die nachfolgende Beschreibung von \f[B]mkosi\-chroot\f[R] für weitere
Informationen.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$SRCDIR\f[R] enthält den Pfad zu dem Verzeichnis, aus dem
\f[B]mkosi\f[R] heraus aufgerufen wurde, wobei alle konfigurierten
Bauquellen oben auf eingehängt sind. \f[CR]$CHROOT_SRCDIR\f[R] enthält den
Wert, den \f[CR]$SRCDIR\f[R] nach Aufruf von \f[B]mkosi\-chroot\f[R] haben
wird.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$BUILDDIR\f[R] ist nur definiert, falls \f[CR]mkosi.builddir\f[R]
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. \f[CR]$CHROOT_BUILDDIR\f[R] enthält den Wert, den
\f[CR]$BUILDDIR\f[R] nach Aufruf von \f[B]mkosi\-chroot\f[R] haben wird.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$DESTDIR\f[R] 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. \f[CR]$CHROOT_DESTDIR\f[R] enthält den Wert, den \f[CR]$DESTDIR\f[R]
nach Aufruf von \f[B]mkosi\-chroot\f[R] haben wird.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$OUTPUTDIR\f[R] zeigt auf das Vorbereitungsverzeichnis, das zum
Speichern der während des Baus erstellten Bauartefakte verwandt
wird. \f[CR]$CHROOT_OUTPUTDIR\f[R] enthält den Wert, den
\f[CR]$OUTPUTDIR\f[R] nach Aufruf von \f[B]mkosi\-chroot\f[R] haben wird.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$PACKAGEDIR\f[R] zeigt auf das Verzeichnis, das das lokale Paketdepot
enthält. Bauskripte können weitere Pakete zum lokalen Depot hinzufügen,
indem sie Pakete nach \f[CR]$PACKAGEDIR\f[R] schreiben.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$ARTIFACTDIR\f[R] 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
\f[CR]PACKAGEDIR\f[R], 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
\f[CR]$ARTIFACTDIR\f[R] ablegen. Dateien in diesem Verzeichnis sind für den
aktuellen Bau verfügbar und werden nicht wie die Inhalte von
\f[CR]$OUTPUTDIR\f[R] herauskopiert.\fR
.RS 2
.PP
\f[B]mkosi\f[R] 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:\fR
.IP \f[R]\[bu]\fR 2
\f[CR]io.mkosi.microcode\f[R]: Alle Dateien in diesem Verzeichnis werden als
Microcode\-Dateien verwandt, d.h. sie werden an die Initrds in
lexikographischer Reihenfolge angehängt.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]io.mkosi.initrd\f[R]: Alle Dateien in diesem Verzeichnis werden als
Initrds verwandt und in lexikographischer Reihenfolge aneinandergehängt.\fR
.PP
Es wird empfohlen, dass Benutzer von \f[CR]$ARTIFACTDIR\f[R] Dinge für ihre
eigene Verwendung in ähnlichen Verzeichnissen mit eigenem Namensraum
ablegen, z.B.\ \f[CR]lokal.mein.Namensraum\f[R].\fR
.RE
.IP \f[R]\[bu]\fR 2
\f[CR]$BUILDROOT\f[R] ist das Wurzelverzeichnis des gebauten Abbilds,
optional mit der Bauüberlagerung oben auf eingehängt, abhängig vom Skript,
das ausgeführt wird.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$WITH_DOCS\f[R] ist entweder \f[CR]0\f[R] oder \f[CR]1\f[R], abhängig
davon, ob der Bau eines Abbildes mit oder ohne Dokumentation angefordert
wurde (\f[CR]WithDocs=yes\f[R]). Ein Bauskript sollte die Installation
sämtlicher Paketdokumentationen nach \f[CR]$DESTDIR\f[R] unterdrücken, falls
\f[CR]$WITH_DOCS\f[R] auf \f[CR]0\f[R] gesetzt ist.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$WITH_TESTS\f[R] ist entweder \f[CR]0\f[R] oder \f[CR]1\f[R], abhängig
davon, ob ein Bau mit oder ohne laufende Test\-Suite angefordert wurde
(\f[CR]WithTests=no\f[R]). Ein Bauskript sollte die Ausführung jeder
Einheiten\- oder Integrationstests unterlassen, falls \f[CR]$WITH_TESTS\f[R]
auf \f[CR]0\f[R] gesetzt ist.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$WITH_NETWORK\f[R] ist entweder \f[CR]0\f[R] oder \f[CR]1\f[R],
abhängig davon, ob ein Bau mit oder ohne Netzwerkanbindung ausgeführt wird
(\f[CR]WithNetwork=no\f[R]). Ein Bauskript sollte sämtliche
Netzwerkkommunikation unterlassen, falls \f[CR]$WITH_NETWORK\f[R] auf
\f[CR]0\f[R] gesetzt ist.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$SOURCE_DATE_EPOCH\f[R] wird definiert falls erbeten
(\f[CR]SourceDateEpoch=TIMESTAMP\f[R],
\f[CR]Environment=SOURCE_DATE_EPOCH=TIMESTAMP\f[R] oder die
Umgebungsvariable auf dem Wirtsystem \f[CR]$SOURCE_DATE_EPOCH\f[R]). Dies
ist nützlich, um Bauten wiederholbar zu machen. Siehe
.UR https://reproducible\-builds.org/specs/source\-date\-epoch/
SOURCE_DATE_EPOCH
.UE
\ zu weiteren Informationen.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$MKOSI_UID\f[R] bzw. \f[CR]$MKOSI_GID\f[R] sind die UID bzw. GID des
Benutzers, der \f[B]mkosi\f[R] aufrief.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$MKOSI_CONFIG\f[R] 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.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$IMAGE_ID\f[R] enthält den Kennzeichner aus der Einstellung
\f[CR]ImageId=\f[R] oder \f[CR]\-\-image\-id=\f[R].\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$IMAGE_VERSION\f[R] enthält die Version aus der Einstellung
\f[CR]ImageVersion=\f[R] oder \f[CR]\-\-image\-version=\f[R].\fR
.PP
In dieser Tabelle können Sie ersehen, welches Skript welche
Umgebungsvariable erhält:
.PP
.TS
tab(@);
lw(17.4n) cw(7.8n) cw(4.8n) cw(6.6n) cw(5.4n) cw(7.2n) cw(7.2n) cw(8.4n) cw(5.4n).
T{
Variable
T}@T{
\f[CR]configure\fR
T}@T{
\f[CR]sync\fR
T}@T{
\f[CR]prepare\fR
T}@T{
\f[CR]build\fR
T}@T{
\f[CR]postinst\fR
T}@T{
\f[CR]finalize\fR
T}@T{
\f[CR]postoutput\fR
T}@T{
\f[CR]clean\fR
T}
\f[R]_\fR
T{
\f[CR]ARCHITECTURE\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]QEMU_ARCHITECTURE\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[CR]DISTRIBUTION\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]DISTRIBUTION_ARCHITECTURE\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]RELEASE\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]PROFILES\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]CACHED\fR
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[CR]CHROOT_SCRIPT\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]SRCDIR\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]CHROOT_SRCDIR\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]BUILDDIR\fR
T}@T{
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]CHROOT_BUILDDIR\fR
T}@T{
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[CR]DESTDIR\fR
T}@T{
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[CR]CHROOT_DESTDIR\fR
T}@T{
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[CR]OUTPUTDIR\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]CHROOT_OUTPUTDIR\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]BUILDROOT\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]PACKAGEDIR\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]ARTIFACTDIR\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]WITH_DOCS\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[CR]WITH_TESTS\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[CR]WITH_NETWORK\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]SOURCE_DATE_EPOCH\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]MKOSI_UID\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]MKOSI_GID\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]MKOSI_CONFIG\fR
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]IMAGE_ID\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]IMAGE_VERSION\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
.TE
.PP
Zusätzlich werden bei der Skript\-Ausführung einige Skripte über den
\f[CR]$PATH\f[R] verfügbar gemacht, um häufige Anwendungsfälle zu
vereinfachen.\fR
.IP \f[R]\[bu]\fR 2
\f[B]mkosi\-chroot\f[R]: Dieses Skript wird ein \f[B]chroot\f[R](8) in das
Abbild durchführen und den angegebenen Befehl ausführen. Zusätzlich zum
\f[B]chroot\f[R](8) in das Abbild wird es auch verschiedene Dateien und
Verzeichnisse in das Abbild einhängen (\f[CR]$SRCDIR\f[R],
\f[CR]$DESTDIR\f[R], \f[CR]$BUILDDIR\f[R], \f[CR]$OUTPUTDIR\f[R],
\f[CR]$CHROOT_SCRIPT\f[R]) und die entsprechenden Umgebungsvariablen ändern,
um auf die Orte innerhalb des Abbilds zu zeigen. Es wird auch
APIVFS\-Dateisysteme einhängen (\f[CR]/proc\f[R], \f[CR]/dev\f[R], …), um
sicherzustellen, dass in der Chroot ausgeführte Skripte und Werkzeuge
korrekt funktionieren. Falls erbeten leitet es auch
\f[CR]/etc/resolv.conf\f[R] vom Wirt in die Chroot weiter, so dass
DNS\-Auflösung innerhalb der Chroot funktioniert. Nachdem sich der Befehl
\f[B]mkosi\-chroot\f[R] beendet, werden verschiedene Einhängepunkte
bereinigt.\fR
.RS 2
.PP
Verwenden Sie beispielsweise folgendes, um \f[B]ls\f[R](1) innerhalb des
Abbilds aufzurufen:\fR
.IP
.EX
mkosi\-chroot ls …
.EE
.PP
Um das gesamte Skript innerhalb des Abbildes auszuführen, fügen Sie die
Endung \f[CR].chroot\f[R] zu dem Namen hinzu (\f[CR]mkosi.build.chroot\f[R]
anstatt \f[CR]mkosi.build\f[R], usw.).\fR
.RE
.IP \f[R]\[bu]\fR 2
Für alle unterstützten Paketverwalter (\f[B]dnf\f[R], \f[B]rpm\f[R](8),
\f[B]apt\f[R](8), \f[B]dpkg\f[R](1), \f[B]pacman\f[R](8),
\f[B]zypper\f[R](8)) werden Skripte mit dem gleichen Namen in
\f[CR]$PATH\f[R] 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. \f[CR]dnf install vim\f[R] durchführen können, um Vim
in das Abbild zu installieren.\fR
.RS 2
.PP
Zusätzlich werden \f[CR]mkosi\-install\f[R], \f[CR]mkosi\-reinstall\f[R],
\f[CR]mkosi\-upgrade\f[R] und \f[CR]mkosi\-remove\f[R] die entsprechende
Aktion des Paketverwalters, der zum Baus des Abbilds verwandt wird,
aufrufen.\fR
.RE
.IP \f[R]\[bu]\fR 2
\f[B]git\f[R](1) wird automatisch mit \f[CR]safe.directory=*\f[R]
aufgerufen, um Berechtigungsfehler bei der Ausführung als Benutzer root in
einem Benutzernamensraum zu vermeiden.\fR
.IP \f[R]\[bu]\fR 2
Beim Aufruf außerhalb des Abbildes werden \f[B]useradd\f[R](8) und
\f[B]groupadd\f[R](8) automatisch mit \f[CR]\-\-root=$BUILDROOT\f[R]
aufgerufen.\fR
.PP
Wenn Skripte ausgeführt werden, werden alle noch schreibbaren Verzeichnisse
schreibgeschützt gemacht (\f[CR]/home\f[R], \f[CR]/var\f[R],
\f[CR]/root\f[R], …) 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 \f[B]mkosi\f[R] als Root ausgeführt wird.\fR
.PP
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.
.SH Dateien
Um den Bau von Abbildern für Entwicklungsversionen Ihrer Projekte zu
erleichtern, kann \f[B]mkosi\f[R] Konfigurationsdaten aus dem lokalen
Verzeichnis unter der Annahme, dass es im einen \f[I]Quell\f[R]\-Baum
aufgerufen wurde, lesen. Insbesondere werden die folgenden Dateien verwandt,
falls sie im lokalen Verzeichnis existieren:\fR
.IP \f[R]\[bu]\fR 2
Das Verzeichnis \f[CB]mkosi.skeleton/\f[R] oder das Archiv
\f[CB]mkosi.skeleton.tar\f[R] können zum Einfügen von Dateien in das Abbild
verwandt werden. Die Dateien werden \f[I]vor\f[R] 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.\fR
.RS 2
.PP
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.
.RE
.IP \[bu] 2
Das Verzeichnis \f[CB]mkosi.extra/\f[R] oder das Archiv
\f[CB]mkosi.extra.tar\f[R] können zum Einfügen zusätzlicher Dateien in das
Abbild verwandt werden, ergänzend zu den Inhalten der Distributionen. Sie
sind ähnlich zu \f[CR]mkosi.skeleton/\f[R] und
\f[CR]mkosi.skeleton.tar\f[R], aber die Dateien werden in den
Verzeichnisbaum des Abbildes kopiert, \f[I]nachdem\f[R] das Betriebssystem
installiert wurde.\fR
.RS 2
.PP
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.
.RE
.IP \[bu] 2
Das Verzeichnis \f[CB]mkosi.sandbox/\f[R] oder das Archiv
\f[CB]mkosi.sandbox.tar\f[R] 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 \f[CR]mkosi.skeleton/\f[R] und \f[CR]mkosi.skeleton.tar\f[R]
verwandt werden.\fR
.RS 2
.PP
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.
.RE
.IP \[bu] 2
Die Nspawn\-Einstellungsdatei \f[CB]mkosi.nspawn\f[R] 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.\fR
.IP \f[R]\[bu]\fR 2
Das Verzeichnis \f[CB]mkosi.cache/\f[R] wird automatisch als
Paket\-Herunterlade\-Zwischenspeicher verwandt, falls es existiert, um
wiederholte Läufe des Werkzeugs zu beschleunigen.\fR
.IP \f[R]\[bu]\fR 2
Das Verzeichnis \f[CB]mkosi.builddir/\f[R] wird automatisch als
Bauverzeichnis außerhalb des Quellbaums verwandt, falls es existiert und
falls die Baubefehle in den Skripten \f[CR]mkosi.build\f[R] dies
unterstützen. Insbesondere wird dieses Verzeichnis in den Bau\-Container
eingehängt und die Umgebungsvariable \f[CR]$BUILDDIR\f[R] darauf gesetzt,
wenn die Bauskripte aufgerufen werden. Ein Bauskript kann dann dieses
Verzeichnis als Bauverzeichnis verwenden, für \f[B]automake\f[R](1)\- oder
\f[B]ninja\f[R](1)\-artige Bauten außerhalb des Quellbaums. Dies beschleunigt
den Bau deutlich, insbesondere wenn \f[B]mkosi\f[R] im inkrementellen Modus
(\f[CR]\-i\f[R]) verwandt wird; nicht nur das Abbild und die
Bau\-Überlagerung, sondern auch der Baubaum wird zwischen nachfolgenden
Aufrufen wiederverwandt. Beachten Sie, dass die Umgebungsvariable
\f[CR]$BUILDDIR\f[R] 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.\fR
.IP \f[R]\[bu]\fR 2
Die Datei \f[CB]mkosi.rootpw\f[R] kann zur Bereitstellung des Passworts für
den Benutzer root des Abbildes verwandt werden. Falls dem Passwort
\f[CR]hashed:\f[R] 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).\fR
.IP \f[R]\[bu]\fR 2
Die Datei \f[CB]mkosi.passphrase\f[R] 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 \f[B]cryptsetup\f[R](8) und
\f[CR]/etc/crypttab\f[R] die Passphrasendatei erwarten). Die Datei muss den
Zugriffsmodus 0600 oder geringer haben.\fR
.IP \f[R]\[bu]\fR 2
Die Dateien \f[CB]mkosi.crt\f[R] und \f[CB]mkosi.key\f[R] enthalten ein
X.509\-Zertifikat und den privaten PEM\-Schlüssel, die verwandt werden, wenn
Signaturen benötigt werden (UEFI SecureBoot, Verity, …).\fR
.IP \f[R]\[bu]\fR 2
Das Verzeichnis \f[CB]mkosi.output/\f[R] wird zum Speichern aller
Bauartefakte verwandt.\fR
.IP \f[R]\[bu]\fR 2
Das Verzeichnis \f[CB]mkosi.credentials/\f[R] wird als Quelle zusätzlicher
Zugangsberechtigungen ähnlich zu der Option \f[CR]Credentials=\f[R]
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
\f[B]mkosi\f[R] die Datei ausführen und die Ausgabe auf der Standardausgabe
wird als Zugangsberechtigungswert verwandt. Die Ausgabe auf der
Standardfehlerausgabe wird ignoriert. Mit \f[CR]Credentials=\f[R]
konfigurierte Zugangsberechtigungen haben Vorrang vor Dateien in
\f[CR]mkosi.credentials\f[R].\fR
.IP \f[R]\[bu]\fR 2
Das Verzeichnis \f[CB]mkosi.repart/\f[R] wird als Quelle für
\f[B]systemd\-repart\f[R](8)\-Partitionsdefinitionsdateien verwandt, die an
\f[B]systemd\-repart\f[R](8) beim Bau eines Abbilds übergeben werden. Falls
es nicht existiert und die Einstellung \f[CR]RepartDirectories=\f[R] nicht
konfiguriert ist, wird \f[B]mkosi\f[R] folgende Partitionsdefinitionsdateien
als Voreinstellung verwenden:\fR
.RS 2
.PP
\f[CR]00\-esp.conf\f[R] (falls ein startfähiges Abbild erstellt wird):\fR
.IP
.EX
\f[B][Partition]\f[R]
Type=esp
Format=vfat
CopyFiles=/boot:/
CopyFiles=/efi:/
SizeMinBytes=512M
SizeMaxBytes=512M\fR
.EE
.PP
\f[CR]05\-bios.conf\f[R] (falls ein BIOS\-startfähiges Abbild erstellt
wird):\fR
.IP
.EX
\f[B][Partition]\f[R]
\f[I]# UUID der Grub\-BIOS\-Systemstartpartition, die Grub bei GPTs benötigt,\f[R]
\f[I]# um sich selbst dort einzubetten.\f[R]
Type=21686148\-6449\-6e6f\-744e\-656564454649
SizeMinBytes=1M
SizeMaxBytes=1M\fR
.EE
.PP
\f[CR]10\-root.conf\fR
.IP
.EX
\f[B][Partition]\f[R]
Type=root
Format=<Standarddateisystem\-der\-Distribution>
CopyFiles=/
Minimize=guess\fR
.EE
.PP
Beachten Sie, dass keine der Vorgabe\-Partitionsdefinitionen verwandt wird,
falls entweder \f[CR]mkosi.repart/\f[R] gefunden oder
\f[CR]RepartDirectories=\f[R] verwandt wird.\fR
.RE
.PP
Alle diese Dateien sind optional.
.PP
Beachten Sie, dass der Ort aller dieser Dateien auch mittels Aufruf von
Befehlszeilenschaltern und als Einstellungen in \f[CR]mkosi.conf\f[R]
konfiguriert werden kann, falls für ein Projekt die Vorgabeeinstellungen
nicht akzeptabel sind.\fR
.SH ZWISCHENSPEICHERUNG
\f[B]mkosi\f[R] unterstützt drei verschiedene Zwischenspeicher zur
Beschleunigung von wiederholenden Neubauten von Abbildern. Konkret:\fR
.IP \f[R]1.\fR 3
Der Paketzwischenspeicher des Paketverwalters der Distribution kann zwischen
Bauten zwischengespeichert werden. Dies wird mit der Option
\f[CR]\-\-cache\-directory=\f[R] oder dem Verzeichnis \f[CR]mkosi.cache/\f[R]
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.\fR
.IP \f[R]2.\fR 3
Falls mittels \f[CR]\-\-incremental\f[R] 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
\f[CR]mkosi.build\f[R] 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[CR]\-f\f[R] entfernt werden.\fR
.IP \f[R]3.\fR 3
Schließlich können zwischen mehreren Bauten das Verzeichnis der Bauartefakte
mittels des Verzeichnisses \f[CR]mkosi.builddir/\f[R] 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 \f[CR]mkosi.build\f[R] zu beschleunigen.\fR
.PP
Der Paketzwischenspeicher und der inkrementelle Modus sind in jedem Fall
nützlich. Der abschließende Zwischenspeicher ist nur anwendbar, wenn
\f[B]mkosi\f[R] 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.\fR
.SH "Bau mehrerer Abbilder"
Falls das Verzeichnis \f[CR]mkosi.images/\f[R] existiert, wird
\f[B]mkosi\f[R] einzelne Unterabbild\-Konfigurationen daraus laden und jede
davon bauen. Abbildkonfigurationen können entweder Verzeichnisse sein, die
\f[B]mkosi\f[R]\-Konfigurationsdateien enthalten, oder reguläre Dateien mit
der Erweiterung \f[CR].conf\f[R].\fR
.PP
Wenn Abbildkonfigurationen in \f[CR]mkosi.images/\f[R] gefunden werden, wird
\f[B]mkosi\f[R] die in den Einstellungen \f[CR]Dependencies=\f[R] des
Hauptabbilds festgelegten Abbilder und alle ihre Abhängigkeiten (oder alle
davon, falls keine Abbilder explizit mit \f[CR]Dependencies=\f[R] in der
Hauptabbildkonfiguration konfiguriert wurden) bauen. Um Abhängigkeiten
zwischen Unterabbildern hinzuzufügen, kann auch die Einstellung
\f[CR]Dependencies=\f[R] verwandt werden. Unterabbilder werden immer vor dem
Hauptabbild gebaut.\fR
.PP
Wenn Abbilder definiert sind, wird \f[B]mkosi\f[R] zuerst die
Hauptabbildkonfiguration (Konfiguration außerhalb des Verzeichnisses
\f[CR]mkosi.images/\f[R]) 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:\fR
.IP \f[R]\[bu]\fR 2
\f[CR]Architecture=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]BuildDirectory=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]BuildSources=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]BuildSourcesEphemeral=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]CacheDirectory=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]CacheOnly=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]Distribution=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ExtraSearchPaths=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]Incremental=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]LocalMirror=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]Mirror=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]OutputDirectory=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]OutputMode=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]PackageCacheDirectory=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]PackageDirectories=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]Profiles=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ProxyClientCertificate=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ProxyClientKey=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ProxyExclude=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ProxyPeerCertificate=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ProxyUrl=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]Release=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]RepartOffline=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]Repositories=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]RepositoryKeyCheck=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SandboxTrees=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SourceDateEpoch=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ToolsTree=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ToolsTreeCertificates=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]UseSubvolumes=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SecureBootCertificate=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SecureBootCertificateSource=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SecureBootKey=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SecureBootKeySource=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]VerityCertificate=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]VerityCertificateSource=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]VerityKey=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]VerityKeySource=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SignExpectedPcrCertificate=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SignExpectedPcrCertificateSource=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SignExpectedPcrKey=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SignExpectedPcrKeySource=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]VolatilePackageDirectories=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]WithNetwork=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]WithTests\fR
.IP \f[R]\[bu]\fR 2
\f[CR]WorkspaceDirectory=\fR
.PP
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:
.IP \[bu] 2
\f[CR]ImageId=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ImageVersion=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SectorSize=\fR
.PP
Abbilder können sich auf Ausgaben von Abbildern beziehen, von denen sie
abhängen. Insbesondere wird \f[B]mkosi\f[R] für die folgenden Optionen nur
prüfen, ob die Eingabe genau vor dem Bau des Abbildes existiert:\fR
.IP \f[R]\[bu]\fR 2
\f[CR]BaseTrees=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ExtraTrees=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]Initrds=\fR
.PP
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 \f[CR]%O\f[R], um sich auf das
Ausgabeverzeichnis zu beziehen.\fR
.PP
Ein gutes Beispiel, wie mehrere Abbilder gebaut werden können, kann in dem
Depot von
.UR https://github.com/systemd/systemd/tree/main/mkosi.images
Systemd
.UE
gefunden werden.
.SH UMGEBUNGSVARIABLEN
.IP \[bu] 2
\f[CR]$MKOSI_LESS\f[R] setzt Optionen für \f[B]less\f[R](1) außer Kraft,
wenn es durch \f[B]mkosi\f[R] zur seitenweisen Darstellung der Ausgabe
verwandt wird.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$MKOSI_DNF\f[R] kann dazu verwandt werden, das als \f[B]dnf\f[R]
verwandte Programm außer Kraft zu setzen. Diese ist besonders für die
Auswahl zwischen \f[B]dnf\f[R] und \f[B]dnf5\f[R] nützlich.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$EPEL_MIRROR\f[R] kann zum Außerkraftsetzen des Ortes des
Standard\-Spiegels für das Epel\-Depot verwandt werden, wenn
\f[CR]Mirror=\f[R] eingesetzt wird. Standardmäßig schaut \f[B]mkosi\f[R]
nach dem Epel\-Depot im Unterverzeichnis \f[CR]fedora\f[R] des
Elternverzeichnisses des in \f[CR]Mirror=\f[R] festgelegten Spiegels. Falls
der Spiegel beispielsweise auf \f[CR]https://mirror.net/centos\-stream\f[R]
gesetzt ist, wird \f[B]mkosi\f[R] nach dem Epel\-Depot in
\f[CR]https://mirror.net/fedora/epel\f[R] suchen.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SYSEXT_SCOPE\f[R] und \f[CR]CONFEXT_SCOPE\f[R] können zum
Außerkraftsetzen des Vorgabewertes der entsprechenden Datei
\f[CR]extension\-release\f[R] beim Bau einer Systemerweiterung oder
Konfigurationserweiterung verwandt werden. Standardmäßig wird der Wert auf
\f[CR]initrd system portable\f[R] gesetzt.\fR
.SH BEISPIELE
Ein rohes \f[I]GPT\f[R]\-Abbild mit \f[B]ext4\f[R](5) als
\f[CR]image.raw\f[R] erstellen und ausführen:\fR
.IP
.EX
# mkosi \-p systemd \-\-incremental boot
.EE
.PP
Ein startfähiges \f[I]GPT\f[R]\-Abbild als \f[CR]foobar.raw\f[R] erstellen
und ausführen:\fR
.IP
.EX
$ 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
.EE
.PP
Ein »\f[I]Fedora Linux\f[R]«\-Abbild in einem einfachen Verzeichnis erstellen
und ausführen:\fR
.IP
.EX
# mkosi \-\-distribution fedora \-\-format directory boot
.EE
.PP
Ein komprimiertes Abbild \f[CR]image.raw.xz\f[R] mit installiertem SSH
erstellen und eine Prüfsummendatei hinzufügen:\fR
.IP
.EX
$ mkosi \-\-distribution fedora \-\-format disk \-\-checksum \-\-compress\-output \-\-package=openssh\-clients
.EE
.PP
Innerhalb eines Quellverzeichnis eines \f[B]automake\f[R](1)\-basierenden
Projekts \f[B]mkosi\f[R] so konfigurieren, dass der einfache Aufruf von
\f[B]mkosi\f[R] ohne Parameter ein Betriebssystemabbild erstellt, das eine
gebaute Version des Projekts in seinem aktuellen Zustand enthält:\fR
.IP
.EX
$ 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 [ \[dq]$container\[dq] != \[dq]mkosi\[dq] ]; then
    exec mkosi\-chroot \[dq]$CHROOT_SCRIPT\[dq] \[dq]$\[at]\[dq]
fi

cd $SRCDIR
\&./autogen.sh
\&./configure \-\-prefix=/usr
make \-j \[ga]nproc\[ga]
make install
EOF
$ chmod +x mkosi.build
# mkosi \-\-incremental boot
# systemd\-nspawn \-bi image.raw
.EE
.SS "Verschiedene Arten, mit \f[CR]vm\fB zu starten"
Die leichteste Art, eine virtuelle Maschine zu starten, ist ein Abbild mit
den benötigten Komponenten zu bauen und \f[B]mkosi\f[R] \f[B]qemu\f[R] mit
allen korrekten Optionen aufzurufen:\fR
.IP
.EX
$ mkosi \-d fedora \[rs]
    \-\-autologin \[rs]
    \-p systemd\-udev,systemd\-boot,kernel\-core \[rs]
    build
$ mkosi \-d fedora vm
…
fedora login: root (automatic login)
[root\[at]fedora \[ti]]#
.EE
.PP
Standardmäßig wird nur mit einer Textkonsole gestartet. In diesem Modus
verwenden Meldungen vom Systemstartprogramm, dem Kernel und
\f[B]systemd\f[R](1) und später die \f[B]getty\f[R](8)\-Anmeldeaufforderung
und die Shell das gleiche Terminal. Ein Umschalten zwischen der
\f[B]qemu\f[R]\-Konsole und dem Überwachungsprogramm ist durch Eingabe von
\f[CR]Strg\-a c\f[R] möglich. Das \f[B]qemu\f[R]\-Überwachungsprogramm kann
beispielsweise zum Einschleusen bestimmter Tastendrücke oder zum schnellen
Herunterfahren der Maschine verwandt werden. Alternativ kann die Maschine
mittels \f[CR]Strg\-a x\f[R] heruntergefahren werden.\fR
.PP
Um mit einem graphischen Fenster zu starten, fügen Sie
\f[CR]\-\-console=gui\f[R] hinzu:\fR
.IP
.EX
$ mkosi \-d fedora \-\-console=gui qemu
.EE
.PP
Ein Kernel kann direkt durch \f[CR]mkosi vm \-kernel … \-initrd … \-append
\[aq]…\[aq]\f[R] 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 \f[CR]\-append\f[R] von
\f[B]qemu\f[R] die im Kernel eingebettete Standardbefehlszeile und sämtliche
vorherige Angaben von \f[CR]\-append\f[R] ersetzt.\fR
.PP
Das UKI wird auch in das Ausgabeverzeichnis kopiert und kann direkt
gestartet werden:
.IP
.EX
$ mkosi vm \-kernel mkosi.output/fedora\[ti]38/image.efi
.EE
.PP
Beim Systemstart unter Verwendung eines externen Kernels wird der Kernel
nicht \f[I]in\f[R] dem Abbild benötigt, aber die Kernelmodule sollten
installiert sein.\fR
.PP
Es ist auch möglich, einen \f[I]direkten Kernelsystemstart\f[R] in ein
Systemstartprogramm durchzuführen. Dabei wird ausgenutzt, dass
\f[B]systemd\-boot\f[R](7) ein gültiges UEFI\-Programm ist:\fR
.IP
.EX
$ mkosi vm \-kernel /usr/lib/systemd/boot/efi/systemd\-bootx64.efi
.EE
.PP
In diesem Szenario wird der Kernel aus dem ESP mittels
\f[B]systemd\-boot\f[R](7) geladen.\fR
.SH ANFORDERUNGEN
\f[B]mkosi\f[R] 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, \f[B]mkosi\f[R] aus Git heraus auszuführen, bis eine neue
Veröffentlichung stattfand.
.PP
\f[B]mkosi\f[R] benötigt einen Kernel, der \f[CR]mount_setattr()\f[R]
bereitstellt, was in 5.12. eingeführt wurde.\fR
.PP
\f[B]mkosi\f[R] benötigt derzeit Systemd 254, um startfähige Plattenabbilder
zu bauen.
.PP
Werden keine Distributionspakete verwandt, müssen Sie sicherstellen, dass
die notwendigen Abhängigkeiten installiert sind. Unter \f[I]Fedora
Linux\f[R] benötigen Sie beispielsweise:\fR
.IP
.EX
\f[I]# dnf install btrfs\-progs apt dosfstools mtools edk2\-ovmf e2fsprogs squashfs\-tools gnupg python3 tar xfsprogs xz zypper sbsigntools\fR
.EE
.PP
Unter Debian/Kali/Ubuntu könnte es notwendig sein, die Pakete
\f[CR]ubuntu\-keyring\f[R], \f[CR]ubuntu\-archive\-keyring\f[R],
\f[CR]kali\-archive\-keyring\f[R] und/oder \f[CR]debian\-archive\-keyring\f[R]
explizit zu installieren, zusätzlich zu \f[B]apt\f[R](8), abhängig davon,
was für eine Art von Distributionsabbildern Sie bauen möchten.\fR
.PP
Beachten Sie, dass die minimal notwendige Python\-Version 3.9 ist.
.PP
\f[B]mkosi\f[R] 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
\f[B]mkosi\f[R] nicht richtig funktioniert.
.PP
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
\f[CR]kernel.unprivileged_userns_clone\f[R] oder
\f[CR]user.max.user_namespace\f[R].\fR
.PP
Für Ubuntu können Sie die Beschränkung für \f[B]mkosi\f[R] aufheben, indem
Sie den nachfolgendne Schnippsel anpassen, dass er auf Ihr Programm
\f[B]mkosi\f[R] zeigt, ihn nach \f[CR]/etc/apparmor.d/pfad.zu.mkosi\f[R]
kopieren und dann \f[CR]systemctl reload apparmor\f[R] ausführen:\fR
.IP
.EX
abi <abi/4.0>,

include <tunables/global>

/pfad/zu/mkosi flags=(default_allow) {
  userns,
}
.EE
.SH "Häufig gestellte Fragen (FAQ)"
.IP \[bu] 2
Warum funktioniert auf Debian/Kali/Ubuntu KVM mit \f[CR]mkosi vm\f[R]
nicht?\fR
.RS 2
.PP
Während es bei anderen Distributionen kein Problem gibt, auf
\f[CR]/dev/kvm\f[R] zuzugreifen, ist es unter Debian/Kali/Ubuntu nur für
Benutzer in der Gruppe \f[CR]kvm\f[R] erlaubt. Da \f[B]mkosi\f[R] einen
Benutzernamensraum beim Betrieb ohne Privilegien abtrennt, verliert es den
Zugriff auf die Gruppe \f[CR]kvm\f[R], selbst wenn der aufrufende Benutzer
in der Gruppe kvm war, denn zum Zeitpunkt, zu dem \f[B]qemu\f[R] gestartet
wird, gibt es auf \f[CR]/dev/kvm\f[R] keinen Zugriff mehr. Um das zu
umgehen, können Sie die Berechtigungen auf den Geräteknoten auf
\f[CR]0666\f[R] ändern, was ausreicht, damit KVM ohne Privilegien
funktioniert. Damit diese Änderungen über Neustarts hinweg erhalten bleibt,
kopieren Sie \f[CR]/usr/lib/tmpfiles.d/static\-nodes\-permissions.conf\f[R]
nach \f[CR]/etc/tmpfiles.d/static\-nodes\-permissions.conf\f[R] und ändern Sie
den Modus von \f[CR]/dev/kvm\f[R] von \f[CR]0660\f[R] auf
\f[CR]0666\f[R].\fR
.RE
.IP \f[R]\[bu]\fR 2
Wie füge ich zu einem Abbild einen normalen Benutzer hinzu?
.RS 2
.PP
Sie können den nachfolgenden Schnipsel in ein post\-installation\-Skript
hinzufügen:
.IP
.EX
useradd \-\-create\-home \-\-user\-group $USER \-\-password \[dq]$(openssl passwd \-stdin \-6 <$USER_PASSWORD_FILE)\[dq]
.EE
.PP
Beachten Sie, dass seit Systemd v256
\f[B]systemd\-homed\-firstboot.service\f[R](1) die Erstellung eines normalen
Benutzers beim ersten Systemstart anfragt, falls es aktiviert ist und keine
normalen Benutzer existieren.\fR
.RE
.IP \f[R]\[bu]\fR 2
Warum sehe ich beim Bau von Abbildern Fehler beim \f[B]chown\f[R](1) von
Dateien?
.RS 2
.PP
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
\f[B]mkosi\f[R] 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.
.PP
Beachten Sie, dass die Aufrufe von \f[B]chown\f[R](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 \f[CR]MKOSI_CHROOT_SUPPRESS_CHOWN\f[R] auf den Wert true
(\f[CR]1\f[R], \f[CR]yes\f[R], \f[CR]true\f[R]) setzen, um die Aufrufe von
\f[B]chown\f[R](1) in den Skripten \f[B]mkosi\-chroot\f[R] und
\&\f[CR].chroot\f[R] zu unterdrücken.\fR
.PP
Falls dieses Verhalten dazu führt, dass sich in Ihrem Abbild betriebene
Anwendungen nicht korrekt verhalten, könnten Sie \f[B]mkosi\f[R] als Root
ausführen, wodurch dieses Problem vermieden wird. Falls der Betrieb von
\f[B]mkosi\f[R] als Root nicht gewünscht ist, können Sie alternativ
\f[CR]unshare \-\-map\-auto \-\-map\-current\-user \-\-setuid 0 \-\-setgid 0\f[R]
verwenden, um Root in einem Benutzernamensraum mit mehr als einem Benutzer
zu werden, unter der Annahme, dass die UID/GID\-Abbildungen in
\f[CR]/etc/subuid\f[R] und \f[CR]/etc/subgid\f[R] korrekt konfiguriert
sind. Beachten Sie, dass der Betrieb von \f[B]mkosi\f[R] als Root oder mit
\f[CR]unshare\f[R] bedeutet, dass alle von \f[B]mkosi\f[R] erzeugten
Ausgabedateien nicht mehr ihrem aktuellen Benutzer gehören.\fR
.PP
Für \f[B]systemd\f[R](1)\-Dienste, die Verzeichnisse in \f[CR]/var\f[R]
benötigen, die dem Benutzer und der Gruppe des Dienstes gehören können diese
Verzeichnisse in Paketen ausgeliefert oder mittels
\f[B]systemd\-tmpfiles\f[R](8) erstellt werden. Beachten Sie, das die
Verwendung von \f[CR]StateDirectory=\f[R], \f[CR]CacheDirectory=\f[R] oder
\f[CR]LogsDirectory=\f[R] in der Dienstedatei eine Alternative dazu
darstellt. Dies weist \f[B]systemd\f[R](1) an, die Verzeichnisse zu
erstellen, wenn es erstmalig den Dienst startet.\fR
.PP
Alternativ können die Direktiven \f[CR]z\f[R] oder \f[CR]Z\f[R] für
\f[B]systemd\-tmpfiles\f[R](8) verwandt werden, um verschiedene Verzeichnisse
und Dateien mittels \f[B]chown\fR(1) auf den Eigentümer umzuschreiben, wenn
das System erstmalig startet.\fR
.RE
.IP \f[R]\[bu]\fR 2
Warum sagt \f[CR]portablectl inspect
<Abbild>\f[R]/\f[CR]systemd\-dissect <Abbild>\f[R] das mein
portierbarer Dienst gar keiner sei?\fR
.RS 2
.PP
\f[B]systemd\-dissect\f[R](1) und \f[CR]portablectl inspect\f[R] prüfen auf
\f[CR]PORTABLE_PREFIXES=\f[R] in \f[B]os\-release\f[R](5) und erkennen den
portierbaren Dienst nicht als solchen, wenn der Schlüssel fehlt. Es wird
dann ein x unter \f[I]Use as\f[R] im Falle von \f[B]systemd\-dissect\f[R](1)
oder \f[CR]n/a\f[R] unter \f[I]Portable Service\f[R] für
\f[B]portablectl\f[R](1) angezeigt.\fR
.PP
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 \f[B]mkosi\f[R] keinen setzen.\fR
.PP
Sie können in der Datei \f[B]os\-release\f[R](5) selbst in einem
Postinst\-Skript \f[CR]PORTABLE_PREFIXES=\f[R] setzen.\fR
.RE
.SH REFERENZEN
.IP \[bu] 2

.UR https://github.com/systemd/mkosi/
Primäres Mkosi\-Git\-Depot auf GitHub
.UE
.IP \[bu] 2

.UR https://0pointer.net/blog/mkosi\-a\-tool\-for\-generating\-os\-images.html
mkosi \[em] A Tool for Generating OS Images
.UE
\ Einleitende
Blog\-Veröffentlichung von Lennart Poettering
.IP \[bu] 2

.UR https://lwn.net/Articles/726655/
The mkosi OS generation tool
.UE
\ LWN\-Artikel
.SH "SIEHE AUCH"
\f[B]systemd\-nspawn\f[R](1), \f[B]systemd\-repart\f[R](8),
\f[B]dnf\f[R](8)\fR
.PP
.SH ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von
Helge Kreutzmann <debian@helgefjell.de>
erstellt.
.PP
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License Version 3
.UE
oder neuer bezüglich der
Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
.PP
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden,
schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer:
.MT debian-l10n-german@lists.debian.org
.ME .