mkosi(1)                    General Commands Manual                   mkosi(1)

BEZEICHNUNG
       mkosi - Massgeschneiderte Betriebssystemabbilder bauen

UBERSICHT
       mkosi [Optionen<?>] init

       mkosi [Optionen<?>] summary

       mkosi [Optionen<?>] cat-config

       mkosi [Optionen <?>] build [-- Befehlszeile<?>]

       mkosi [Optionen <?>] shell [-- Befehlszeile<?>]

       mkosi [Optionen <?>] boot [-- Nspawn-Einstellungen<?>]

       mkosi [Optionen<?>] vm  [-- Vmm-Parameter<?>]

       mkosi [Optionen<?>] ssh [-- Befehlszeile<?>]

       mkosi [Optionen<?>] journalctl [-- Befehlszeile<?>]

       mkosi [Optionen<?>] coredumpctl [-- Befehlszeile<?>]

       mkosi [Optionen<?>] sysupdate [-- Sysupdate-Einstellungen<?>]

       mkosi [Optionen<?>] box [-- Befehlszeile<?>]

       mkosi [Optionen<?>] dependencies [-- Optionen<?>]

       mkosi [Optionen<?>] clean

       mkosi [Optionen<?>] serve

       mkosi [Optionen<?>] burn <Gerat>

       mkosi [Optionen<?>] bump

       mkosi [Optionen<?>] genkey

       mkosi [Optionen<?>] documentation [Handbuch]

       mkosi [Optionen<?>] completion [Shell]

       mkosi [Optionen<?>] latest-snapshot

       mkosi [Optionen<?>] help

BESCHREIBUNG
       mkosi ist ein Werkzeug zum leichten Bau angepasster
       Betriebssystemabbilder. Es ist eine kunstvolle Hulle fur dnf, apt(8),
       pacman(8) und zypper(8), die Plattenabbilder mit einer Reihe von
       Schnickschnack erstellen konnen.

   Unterbefehle
       Die folgenden Unterbefehle werden erkannt:

       init   Initialisiert mkosi. Dies ist eine einmalige Aktion, die
              verschiedene Konfigurationsdateien fur einen optimalen Betrieb
              einrichtet. Derzeit initialisiert dies nur eine Erganzung
              tmpfiles.d fur das Paketzwischenspeicherverzeichnis von mkosi,
              um sicherzustellen, dass alte und nicht mehr verwandte Dateien
              automatisch bereinigt werden.

       summary
              Zeigt eine menschenlesbare Zusammenfassung aller fur den Bau des
              Abbilds verwandten Optionen an. Dies wird die Befehlszeile und
              die Konfigurationsdateien auswerten, aber nur ausgeben, wofur es
              konfiguriert ist und nicht wirklich etwas bauen oder ausfuhren.

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

       build  Baut das Abbild basierend auf den auf der Befehlszeile und in
              den Konfigurationsdateien ubergebenen Einstellungen. Dieser
              Befehl ist die Vorgabe, falls kein Unterbefehl explizit
              angegeben ist. An die Bauskripte konnen Argumente ubergeben
              werden, falls welche definiert sind. Um Optionen an die
              Bauskripte zu ubegeben, trennen Sie diese von den normalen
              Optionen von mkosi durch --.

       shell  Dies baut das Abbild, falls es noch nicht gebaut ist, und ruft
              dann systemd-nspawn(1) auf, um eine interaktive Shell im Abbild
              auszufuhren. Dafur muss das System nicht gestartet werden, es
              ist eher wie eine bessere chroot(8). Nach dem Unterbefehl shell
              kann eine optionale Befehlszeile angegeben werden, die anstelle
              der Shell in dem Container aufgerufen werden soll. Um
              zusatzliche Optionen an Nspawn zu ubergeben, trennen Sie diese
              mittels -- von den normalen Optionen ab.

       boot   Ahnlich wie shell, startet systemd(1) im Abbild mittels
              systemd-nspawn(1) anstatt eine Shell zu offnen. Nach dem
              Unterbefehl boot konnen zusatzliche Argumente an das Init-System
              in dem Abbild angegeben werden. Um zusatzliche Optionen an
              Nspawn zu ubergeben, trennen Sie diese mittels -- von den
              normalen Optionen ab.

       vm     Ahnlich wie boot, verwendet aber den konfigurierten Monitor fur
              virtuelle Maschinen (standardmassig qemu), um das Abbild zu
              starten, d.h. anstelle einer Container-Virtualisierung wird eine
              Virtualisierung einer virtuellen Maschine verwandt. Wie
              zusatzliche Befehlszeilenargumente interpretiert werden hangt
              von dem konfigurierten Monitor fur virtuelle Maschinen ab.
              Weitere Informationen finden Sie in VirtualMachineMonitor=. Um
              zusatzliche Optionen an den konfigurierten Monitor fur virtuelle
              Maschinen zu ubergeben, trennen Sie diese von den normalen
              Optionen mittels -- ab.

       ssh    Wenn das Abbild mit der Option Ssh=yes gebaut wird oder der
              Dienst sshd-vsock von Systemd innerhalb der VM lauft (Systemd
              v256+), verbindet dieser Befehl die gestartete virtuelle
              Maschine mittels SSH. Stellen Sie sicher, dass mkosi ssh mit der
              gleichen Konfiguration wie mkosi build ausgefuhrt wird, so dass
              es die notwendigen Informationen hat, um sich mit der laufenden
              virtuellen Maschine mittels SSH zu verbinden. Insbesondere wird
              der private SSH-Schlussel aus der Einstellung SshKey= verwandt,
              um sich mit der virtuellen Maschine zu verbinden. Verwenden Sie
              mkosi genkey, um automatisch einen Schlussel und ein Zertifikat
              zu erstellen, das von mkosi aufgenommen wird. Alle nach dem
              Unterbefehl ssh ubergebene Argumente werden als Argumente an den
              Aufruf von ssh(1) ubergeben. Um zusatzliche Optionen zu
              ubergeben, trennen Sie diese von den normalen Optionen mittels
              -- ab. Um sich mit einem Container zu verbinden, verwenden Sie
              machinectl login oder machinectl shell.

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

       journalctl
              Verwendet journalctl(1), um das Journal innerhalb des Abbildes
              zu untersuchen. Alle nach dem Unterbefehl journalctl angegebenen
              und durch -- von den regularen Optionen getrennten Argumente
              werden an den Aufruf von journalctl(1) angehangt.

       coredumpctl
              Verwendet coredumpctl(1), um nach Speicherabbilder innerhalb des
              Abbilds zu suchen. Alle nach dem Unterbefehl coredumpctl
              angegebenen und durch -- von den regularen Optionen getrennten
              Argumente werden an den Aufruf von coredumpctl(1) angehangt.

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

       boot   Ruft beliebige Befehle innerhalb der gleichen Umgebung auf, die
              zur Ausfuhrung anderer Unterbefehle wie boot, shell, vm und
              weiteren verwandt wird. Dies bedeutet, dass /usr durch /usr vom
              Werkzeugbaum ersetzt wird, falls einer verwandt wird, wahrend
              ansonsten alles andere am Ort verbleibt. Falls kein Befehl
              bereitgestellt wird, wird $SHELL oder bash(1), falls $SHELL
              nicht gesetzt ist, ausgefuhrt. Um zusatzliche Optionen an den
              angegebenen Befehl zu ubergeben, trennen Sie diese durch -- von
              den regularen Optionen.

       clean  Entfernt aus vorherigen Baulaufen erstellte Bauartefakte. Falls
              mit -f kombiniert, werden auch inkrementelle
              Bauzwischenspeicher-Abbilder und der Werkzeugbaum entfernt.
              Falls -f zweimal angegeben ist, werden samtliche
              Paketzwischenspeicher entfernt.

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

       burn <Gerat>
              Dies baut das Abbild, falls es noch nicht gebaut wurde und
              schreibt es dann auf das angegebene Blockgerat. Die
              Partitionsinhalte werden unverandert geschrieben, aber die
              GPT-Partitionstabelle wird korrigiert, so dass sie auf die
              Sektor- und Blockgrossen des angegebenen Mediums passt.

       bump   Erhoht die Version des Abbildes aus mkosi.version und schreibt
              die resultierende Versionszeichenkette nach mkosi.version. Dies
              ist zur Implementierung eines einfachen Versionierungsschematas
              nutzlich: jedes Mal, wenn dieser Unterbefehl aufgerufen wird,
              wird die Version als Vorbereitung fur den nachsten Bau erhoht.
              Beachten Sie, dass --auto-bump/-B zum automatischen Erhohen der
              Version bei jedem Bau verwandt werden konnen. Die neue Version
              wird in diesem Fall nur nach mkosi.version geschrieben, falls
              der Bau erfolgreich ist.

              Falls mkosi.bump existiert, wird sie aufgerufen, um eine neu
              Version zu erstellen, die anstelle von eigener Logik von mkosi
              verwandt wird.

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

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

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

       completion
              Erstellt Shell-Vervollstandigungen fur die als Argument
              ubergebene Shell und gibt diese auf der Standardausgabe aus. Es
              werden die Argumente bash, fish und zsh verstanden.

       dependencies
              Gibt die Liste der von mkosi zum Bauen und Starten von Abbildern
              benotigten Pakete aus.

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

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

              Standardmassig werden nur die Abhangigkeiten angezeigt, die zum
              Bau von Abbildern mit mkosi benotigt werden. Es konnen
              zusatzliche Werkzeugbaumprofile aktiviert werden, um auch die
              Pakete auszugeben, die zu solchen Profilen gehoren.
              Beispielsweise wird die Ausfuhrung von mkosi dependencies --
              --profile runtime auch zusatzlich zu den regularen Paketen die
              Pakete in dem Profil >>runtime<< ausgeben. Lesen Sie die
              Dokumentation von ToolsTreeProfiles= fur eine Liste der
              verfugbaren Profile.

       latest-snapshot
              Gibt den neuesten verfugbaren Schnappschuss in dem
              konfigurierten Spiegel aus.

              Dieser Unterbefehl ist nutzlich, um Schnappschusse gelegentlich
              zu aktualisieren. Beachten Sie, dass dieser Unterbefehl nur den
              neusten Schnappschuss ausgibt. Es obliegt dem Aufrufenden
              sicherzustellen, dass der Schnappschuss in die geplante
              Konfigurationsdatei geschrieben wird.

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

   Reine Befehlszeilenoptionen
       Diese Einstellungen konnen nicht mittels der Konfigurationsdateien
       konfiguriert werden.

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

       --directory=, -C
              Akzeptiert einen Pfad zu einem Verzeichnis. Vor allen anderen
              Aktivitaten wechselt mkosi in dieses Verzeichnis. Beachten Sie,
              dass in diesem Verzeichnis nach den verschiedenen
              Konfigurationsdateien gesucht wird, daher ist die Verwendung
              dieser Option ein wirksammes Mittel, ein Projekt zu bauen, das
              sich in einem bestimmten Verzeichnis befindet. Dies ist
              standardmassig das aktuelle Verzeichnis. Falls die leere
              Zeichenketten angegeben ist, werden alle Konfigurationen in dem
              aktuellen Arbeitsverzeichnis ignoriert.

       --debug
              Aktiviert zusatzliche Fehlersuchausgaben.

       --debug-shell
              Falls die Ausfuhrung eines Befehls in dem Abbild fehlschlagt,
              wird mkosi eine interaktive Shell in dem Abbild starten, um ein
              weitere Fehlersuche zu ermoglichen.

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

       --debug-sandbox
              Fuhrt mkosi-sandbox(1) mit strace(1) aus.

       --version
              Zeigt die Paketversion.

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

       --genkey-common-name=
              Allgemeiner Name, der bei der Erzeugung von Schlusseln mittels
              des Befehls genkey von mkosi verwandt wird. Standardmassig mkosi
              of %u, wobei %u auf den Benutzernamen des Benutzer, der mkosi
              aufruft, erweitert wird.

       --genkey-valid-days=
              Anzahl an Tagen, die Schlussel gultig bleiben sollen, wenn
              Schlussel mit dem Befehl genkey von mkosi erstellt werden.
              Standardmassig zwei Jahre (730 Tage).

       --auto-bump=, -B
              Falls angegeben wird die Version erhoht und falls der Bau
              erfolgreich ist, wird die Version nach mkosi.version auf eine
              Art ahnlich zum Unterbefehl bump geschrieben. Dies ist fur
              einfaches, lineares Versionsmanagement nutzlich: jeder Bau in
              einer Reihe wird eine um eins gegenuber dem vorherigen Bau
              erhohte Versionsnummer haben.

              Falls mkosi.bump existiert, wird sie aufgerufen, um eine neu
              Version zu erstellen, die anstelle von eigener Logik von mkosi
              verwandt wird.

       --doc-format
              Das Format, in dem die Dokumentation angezeigt werden soll.
              Unterstutzt die Werte markdown, man, pandoc, system und auto. Im
              Falle von markdown wird die Dokumentation im usrpunglichen
              Markdown-Format angezeigt. man zeigt die Dokumentation im
              Handbuchseitenformat, falls dies verfugbar ist. pandoc erstellt
              das Handbuchseitenformat dynamisch, falls pandoc(1) verfugbar
              ist. system zeigt die systemweite Handbuchseite fur mkosi, die
              nicht zwingend der Version entspricht, die Sie verwenden,
              abhangig davon, wie mkosi installiert wurde. auto (die Vorgabe)
              wird alle Methoden in der Reihenfolge man, pandoc, markdown,
              system ausprobieren.

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

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

       --rerun-build-scripts, -R
              Fuhrt die Bauskripte erneut aus. Benotigt die aktivierte Option
              Incremental= und das Abbild muss bereits einmal gebaut worden
              sein. Falls History= aktiviert ist, wird der Verlauf von dem
              vorherigen Bau erneut verwandt und kein neuer Verlauf
              geschrieben.

   Unterstutzte Ausgabeformate
       Die folgenden Ausgabeformate werden unterstutzt:

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

       o Einfaches Verzeichnis, enthalt den Betriebssystembaum (Verzeichnis)

       o TAR-Archiv (tar)

       o CPIO-Archiv (cpio)

       o Vereinigtes Kernelabbild (UKI)

       o <?> und viele weitere. Informationen hierzu in der nachfolgenden
         Beschreibung fur Format=.

       Das Ausgabeformat kann auch auf none gesetzt werden, wenn Sie mochten,
       dass mkosi uberhaupt kein Abbild erstellt. Dies kann nutzlich sein,
       falls Sie das Abbild nur dazu verwenden mochten, eine andere Ausgabe in
       den Bauskripten zu erstellen (z.B. ein RPM zu bauen).

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

       Es wird nachdrucklich empfohlen, mkosi auf einem Dateisystem
       auszufuhren, das Reflinks unterstutzt, wie xfs(5) und btrfs(5) und alle
       zusammengehorigen Verzeichnisse auf dem gleichen Dateisystem zu
       behalten. Dies ermoglicht es mkosi, Abbilder sehr schnell durch
       Verwendung von Reflinks zur Durchfuhrung von
       Kopieren-Beim-Schreiben-Aktionen zu erstellen.

   Konfigurationseinstellungen
       Die folgenden Einstellungen konnen uber Konfigurationsdateien (der
       Syntax mit EineEinstellung=Wert) und auf der Befehlszeile (der Syntax
       mit --Eine-Einstellung=Wert) gesetzt werden. Fur einige
       Befehlszeilenparameter ist auch eine Abkurzung mit einem Buchstaben
       erlaubt. In den Konfigurationsdateien muss die Einstellung in dem
       korrekten Abschnitt erfolgen, daher sind die Einstellungen nachfolgend
       gemass des Abschnittes gruppiert.

       Die Konfiguration wird in der folgenden Reihenfolge ausgewertet:

       o Die Befehlszeilenargumente werden ausgewertet.

       o mkosi.local.conf und mkosi.local werden ausgewertet, falls sie
         existieren. Diese Datei und das Verzeichnis sollte in .gitignore
         (oder aquivalent) sein und sind fur lokale Konfiguration gedacht.

       o Falls eine Option einen entsprechenden Standardpfad hat, wird dieser
         ausgewertet, falls der Standardpfad existiert.

       o mkosi.conf wird ausgewertet, falls es in dem mit --directory=
         konfigurierten oder im aktuellen Arbeitsverzeichnis, falls
         --directory= nicht verwandt wird, existiert. Falls das angegebene
         Verzeichnis kein mkosi.conf oder mkosi.tools.conf enthalt und ein
         mkosi/mkosi.conf oder mkosi/mkosi.tools.conf existiert, wird die
         Konfiguration stattdessen aus dem Unterverzeichnis mkosi/ des
         angegebenen Verzeichnis ausgewertet.

       o mkosi.conf.d/ wird im gleichen Verzeichnis wie mkosi.conf
         ausgewertet, falls sie existiert. Jedes Verzeichnis und jede Datei
         mit der Endung .conf in mkosi.conf.d/ wird ausgewertet. Jedes
         Verzeichnis in mkosi.conf.d wird ausgewertet, als ob es ein normales
         Verzeichnis auf der obersten Ebene ware. Die Ausnahmen sind
         mkosi.images/ und mkosi.tools.conf, die nur im Verzeichnis auf der
         obersten Ebene aufgenommen werden.

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

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

       Beachten Sie, dass die uber die Befehlszeile konfigurierten
       Einstellungen immer die uber Konfigurationsdateien konfigurierte
       Einstellungen ausser Kraft setzen. Falls die gleiche Einstellung mehr
       als einmal mittels Konfigurationsdateien konfiguriert ist, setzen
       spatere Zuweisungen fruhere ausser Kraft, sofern die Einstellungen
       nicht eine Sammlung an Werten akzeptierten. Auch werden Einstellungen,
       die aus mkosi.local.conf oder mkosi.local/ gelesen werden Einstellungen
       von anderen Konfigurationsdateien, die spater ausgewertet werden,
       ausser Kraft setzen, allerdings nicht solche, die auf der Befehlszeile
       angegeben werden.

       Fur Einstellungen, die einen einzelnen Wert akzeptieren, kann die leere
       Zuweisung (EineEinstellung= oder --eine-einstellung=) zum
       Ausserkraftsetzen einer vorherigen Einstellung und zum Zurucksetzen auf
       die Vorgabewerte verwandt werden.

       Einstellungen, die eine Sammlung von Werten akzeptieren, werden
       zusammengefuhrt, indem neue Werte an die bereits konfigurierten Werte
       angehangt werden. Durch Zuweisung einer leeren Zeichenkette zu einer
       solchen Einstellung werden alle vorher zugewiesenen Werte entfernt und
       auch alle konfigurierten Standardwerte ausser Kraft gesetzt. Die auf
       der Befehlszeile angegebenen Werte werden nach allen Werten aus den
       Konfigurationsdateien angehangt.

       Um Konfigurationsdateien bedingt einzubinden, kann der Abschnitt
       [Match] verwandt werden. Ein Abschnitt [Match] besteht aus einzelnen
       Bedingungen. Bedingungen konnen ein Weiterleitungssymbol (|) nach dem
       Gleichheitszeichen verwenden (<?>=|<?>). Dadurch wird die Bedingung
       eine auslosende Bedingung. Die Konfigurationsdatei wird eingebunden,
       falls das logische UND aller nicht auslosenden Bedingungen und das
       logische ODER aller auslosenden Bedingungen erfullt 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 anschliessend das Ausrufezeichen.

       Beachten Sie, dass die Bedingungen in [Match] mit den aktuellen Werten
       einer bestimmten Einstellung verglichen werden und keine Anderungen an
       Einstellungen berucksichtigen, die in Konfigurationsdateien bereits
       erfolgten, aber noch nicht ausgewertet wurden (auf der Befehlszeile
       angegebene Einstellungen werden berucksichtigt). Beachten Sie auch,
       dass das Prufen der Ubereinstimmung mit einer Einstellung und das
       anschliessende Andern in einer anderen Konfigurationsdatei zu
       unerwarteten Ergebnissen fuhren kann.

       Der Abschnitt [Match] in einer Datei mkosi.conf in einem Verzeichnis
       gilt fur das gesamte Verzeichnis. Falls die Bedingungen nicht erfullt
       sind, wird das gesamte Verzeichnis ubersprungen. Die Abschnitte [Match]
       von Dateien in mkosi.conf.d/ und mkosi.local.conf gelten nur fur die
       Datei selbst.

       Falls es mehrere Abschnitte [Match] in der gleichen Konfigurationsdatei
       gibt, muss jede erfullt werden, damit die Konfigurationsdatei
       eingebunden wird. Insbesondere gelten auslosende Bedingungen nur fur
       den aktuellen Abschnitt [Match] und werden zwischen mehreren
       Abschnitten [Match] zuruckgesetzt. In dem folgenden Beispiel erfolgt
       nur eine Ubereinstimmung, falls das Ausgabeformat entweder disk oder
       directory ist und die Architektur entweder x86-64 oder arm64 ist:

              [Match]
              Format=|disk
              Format=|directory

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

       Der Abschnitt [TriggerMatch] kann zur Anzeige von auslosenden
       Ubereinstimmungen verwandt werden. Diese sind zu auslosenden
       Bedingungen in Systemd-Units identisch, ausser dass sie fur den
       gesamten Ubereinstimmungsabschnitt statt nur einer einzelnen Bedingung
       gelten. Beispielsweise stimmt folgendes uberein, falls die Distribution
       debian und die Veroffentlichung bookworm ist oder falls die
       Distribution ubuntu und die Veroffentlichung noble ist.

              [TriggerMatch]
              Distribution=debian
              Release=bookworm

              [TriggerMatch]
              Distribution=ubuntu
              Release=noble

       Die Semantik von Bedingungen in [TriggerMatch]-Abschnitten ist
       identisch zu [Match], d.h. alle normalen Bedingungen werden durch ein
       logisches UND und alle auslosenden Bedingungen werden durch ein
       logisches ODER zusammengefasst. Beim Mischen von [Match]- und
       [TriggerMatch]-Abschnitten wird eine Ubereinstimmung erreicht, wenn
       alle [Match]-Abschnitte ubereinstimmen und mindestens ein
       [TriggerMatch]-Abschnitt ubereinstimmt. Die Abwesenheit eines
       Ubereinstimmungsabschnittes wird als true ausgewertet. Logisch bedeutet
       dies:

              (<?><?> Match<?>) ^ (<?><?> TriggerMatch<?>)

       Es gibt auch Unterstutzung fur die Abschnitte [Assert] und
       [TriggerAssert], die sich identisch verhalten, um auf Abschnitte zu
       passen, ausser dass die Auswertung der Konfiguration fehlschlagen wird,
       falls die Assert-Abschnitte nicht erfullt sind, d.h. alle Abschnitte
       [Assert] in einer Datei sowie mindestens ein Abschnitt [TriggertAssert]
       mussen erfullt sein oder das Auswerten der Konfiguration wird
       fehlschlagen.

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

   Abschnitt [Distribution]
       Distribution=, --distribution=, -d
              Die im Abbild zu installierende Distribution. Akzeptiert eines
              der folgenden Argumente: fedora, debian, kali, ubuntu, arch,
              opensuse, mageia, centos, rhel, rhel-ubi, openmandriva, rocky,
              alma, azure oder custom. Falls nicht angegeben ist die Vorgabe
              die Distribution des Wirtsystems oder custom, falls die
              Distribution des Wirtsystems keine unterstutzte Distribution
              ist.

       Release=, --release=, -r
              Die Veroffentlichung der im Abbild zu installierenden
              Distribution. Die genaue Syntax des akzeptierten Arguments hangt
              von der verwandten Distribution ab und ist entweder eine
              numerische Zeichenkette (im Falle von Fedora Linux, CentOS, <?>,
              z.B. 29) oder ein Versionsname der Distribution (im Falle von
              Debian, Kali, Ubuntu, <?>, z.B. artful). Standardmassig die
              neuste Version der ausgewahlten Distribution oder die Version,
              die auf der Wirtmaschine lauft, falls sie mit einer
              konfigurierten Distribution ubereinstimmt.

       Architecture=, --architecture=
              Die Architektur fur die das Abbild gebaut wird. Die tatsachlich
              unterstutzten Architekturen hangen von der verwandten
              Distribution ab und ob ein startfahiges Abbild erbeten wird.
              Beim Bau fur eine fremde Architektur mussen Sie auch den
              Benutzermodus-Emulator fur diese Architektur installieren und
              registrieren.

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

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

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

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

       Snapshot=
              Ladt Pakete von dem angegebenen Schnappschuss herunter, anstatt
              die neusten Distributionspakete von dem angegebenen Spiegel
              herunterzuladen. Akzeptiert eine Schnappschusskennung (das
              Format der Schnappschusskennung ist distributionsabhangig).
              Verwenden Sie den Unterbefehl latest-snapshot, um den neusten
              verfugbaren Schnappschuss zu ermitteln.

              Falls diese Einstellung konfiguriert ist und Mirror= nicht
              explizit konfiguriert ist, werden verschiedene Vorgabe-Spiegel
              verwandt:

                              X86-64                               Aarch64
              ------------------------------------------------------------------------------------
              Debian          https://snapshot.debian.org
              Arch            https://archive.archlinux.org        http://mirror.archlinuxarm.org
              OpenSUSE        http://download.opensuse.org
              Ubuntu          http://archive.ubuntu.com            http://ports.ubuntu.com
              Centos          https://composes.stream.centos.org
              Fedora          https://kojipkgs.fedoraproject.org

              Nur fur die oben aufgefuhrten Distributionen werden
              Schnappschusse unterstutzt.

       LocalMirror=, --local-mirror=
              Der Spiegel wird als ein lokaler, einfacher und direkter Spiegel
              anstelle der Verwendung als Prafix fur die volle Reihe von
              Depots, die normalerweise von Distributionen angeboten werden,
              verwandt. Nutzlich beim Bau vollstandig ohne Netzanbindung mit
              einem einzelnen Depot. Wird fur deb-, rpm- und pacman-basierte
              Distributionen unterstutzt. Setzt --mirror= ausser Kraft, aber
              nur fur lokale mkosi-Bauten, es wird nicht im letztendlichen
              Abbild konfiguriert, stattdessen wird --mirror= (oder das
              Standard-Depot) innerhalb des letztendlichen Abbilds
              konfiguriert.

       RepositoryKeyCheck=, --repository-key-check=
              Steuert die Signatur-/Schlusseluberprufung bei der Verwendung
              von Depots, standardmassig aktiviert. Die Deaktivierung ist bei
              der Kombination mit --local-mirror= und der ausschliesslichen
              Verwendung eines lokalen Depots aus einem lokalen Dateisystem
              nutzlich.

       RepositoryKeyFetch=, --repository-key-fetch=
              Steuert, ob mkosi die Distributions-GPG-Schlussel aus der Ferne
              abholt. Auf Ubuntu standardmassig 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 standardmassig
              deaktiviert. Wenn deaktiviert, mussen die
              Distributions-GPG-Schlussel fur die Zieldistribution lokal auf
              dem Rechner zusammen mit dem Paketverwalter fur diese
              Distribution installiert sein.

              Diese Einstellung ist nur fur Distributionen implementiert, die
              dnf, pacman(8) oder zypper(8) als ihren Paketverwalter
              verwenden. Fur andere Distributionen wird der
              Distributions-GPG-Schlussel immer lokal nachgeschlagen,
              unabhangig vom Wert dieser Einstellung. Um die
              Distributions-GPG-Schlussel fur Distributionen zur Verfugung zu
              stellen, ohne diese Einstellung zu aktivieren, muss das
              entsprechende Paket auf dem Wirt installiert sein. Dabei handelt
              es sich typischerweise um entweder archlinux-keyring,
              debian-keyring, kali-archive-keyring, ubuntu-keyring oder
              distribution-gpg-keys (fur RPM-basierte Distributionen).

       Repositories=, --repositories=
              Aktiviert standardmassig deaktivierte Paket-Depots. Dies kann
              zur Aktivierung der EPEL-Depots fur CentOS oder anderer
              Komponenten der Debian/Kali/Ubuntu-Depots verwandt werden.

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

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

              Falls das Format none verwandt wird, werden die Ausgaben von
              vorherigen Bauten nicht entfernt, aber Bereinigungsskripte
              (siehe CleanScripts=) werden weiterhin ausgefuhrt. Dies
              ermoglicht das erneute Ausfuhren von Bauskripten (siehe
              BuildScripts=), ohne die Ergebnisse eines vorherigen Baus zu
              entfernen.

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

       Output=, --output=, -o
              Fur die erstellte Ausgabedatei oder das Ausgabeverzeichnis zu
              verwendender Name. Standardmassig image oder, falls ImageId=
              verwandt wird, wird dieser als standardmassiger Ausgabename
              verwandt, optional wird die mit ImageVersion= angegebene Version
              angehangt oder der Name des Abbildes wird gegenuber ImageId
              bevorzugt, falls ein bestimmtes Abbild aus mkosi.images gebaut
              wird. Beachten Sie, dass diese Option nicht die Konfiguration
              des Ausgabeverzeichnisses ermoglicht, verwenden Sie dafur
              OutputDirectory=.

              Beachten Sie, dass dies nur den Ausgabeprafix festlegt, der
              vollstandige Ausgabename kann abhangig von dem festgelegten
              Ausgabeformat, der verwandten Komprimierung und Abbildversion
              image_7.8.raw.xz sein.

       OutputExtension=, --output-extension=
              Verwenden die angegebene Erweiterung fur die Augabedatei.
              Standardmassig die angemessene Erweiterung, basierend auf dem
              Ausgabeformt. Enthalt nur die Dateierweiterung, nicht die
              Komprimierungserweiterung, die an diese Erweiterung angehangt
              wird, falls Komprimierung aktiviert ist.

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

       CompressLevel=, --compress-level=
              Konfiguriert die zu verwendende Komprimierungsstufe. Akzeptiert
              eine Ganzzahl. Die moglichen Werte hangen von der verwandten
              Komprimierung ab.

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

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

       ImageVersion=, --image-version=
              Konfiguriert die Abbild-Version. Dies akzeptiert jede
              Zeichenkette, es wird aber empfohlen, eine Reihe von durch
              Punkten getrennte Komponenten festzulegen. Die Version kann auch
              durch Lesen einer Datei mkosi.version (in diesem Fall kann sie
              bequem mit dem Unterbefehl bump oder der Option --auto-bump
              verwaltet werden) oder durch Lesen der Standardausgabe, falls
              diese ausfuhrbar ist (siehe den nachfolgenden Abschnitt
              Skripte), konfiguriert werden. Wenn dies angegeben ist, wird die
              festgelegte Abbildversion in den standardmassigen
              Ausgabedateinamen aufgenommen, d.h. anstelle von image.raw wird
              die Vorgabe image_0.1.raw fur Version 0.1 des Abbildes oder
              ahnlich lauten. Die Version wird auch mittels $IMAGE_VERSION an
              alle aufgerufenen Bauskripte ubergeben (das konnte nutzlich
              sein, um es in /usr/lib/os-release oder ahnliche einzubauen,
              insbesondere in das darin befindliche Feld IMAGE_VERSION=).

       ImageId=, --image-id=
              Konfiguriert den Abbildkennzeichner. Dies akzeptiert eine
              formlose Zeichenkette, die zur Kennzeichnung des Abbilds
              verwandt werden soll. Falls gesetzt, wird danach die
              Standard-Ausgabedatei benannt (moglicherweise mit angehangter
              Version). Der Kennzeichner wird auch mittels $IMAGE_ID an alle
              aufgerufenen Bauskripte ubergeben. Die Abbildkennzeichnung wird
              automatisch zu /usr/lib/os-release hinzugefugt.

       SplitArtifacts=, --split-artifacts=
              Die Artekfaktypen, die aus dem endgultigen Abbild herausgenommen
              werden sollen. Eine Kommata-getrennte Liste, die aus uki,
              kernel, initrd, os-release, prcs, partitions, roothash,
              kernel-modules-initrd, repart-definitions und tar besteht. Beim
              Bauen eines selbststartenden Abbildes entsprechen kernel und
              initrd ihren im Abbild (oder dem UKI) gefundenen Artefakten,
              wahrend uki das gesamte UKI herauskopiert. Wird pcrs angegeben,
              wird eine JSON-Datei, die den vorberechneten TPM2-Hash enthalt,
              rausgeschrieben, entsprechend der UKI-Spezifikation
              <https://uapi-group.org/specifications/specs/unified_kernel_image/#json-format-for-pcrsig>

              Beim Bau eines Plattenabbildes und wenn partitions angegeben
              ist, wird --split=yes an systemd-repart(8) ubergeben, damit dies
              getrennte Partitionsdateien fur jede konfigurierte Partition
              schreibt. Lesen Sie die Handbuchseite
              <https://www.freedesktop.org/software/systemd/man/systemd-repart.html#--split=BOOL>
              fur weitere Informationen. Dies ist fur
              A/B-Aktualisierungsszenarien nutzlich, bei denen ein bestehendes
              Plattenabbild mit einer neuen Version einer Wurzel- oder
              /usr-Partition zusammen mit der zugehorigen Verity-Partition und
              einem vereinigten Kernel erweitert werden soll.

              Wenn tar angegeben ist, wird das Rootfs zusatzlich als
              Tar-Archiv archiviert (entsprechend CompressOutput=
              komprimiert).

              Wenn roothash angegeben ist und ein dm-verity-Plattenabbild
              gebaut wird, wird der dm-verity-Wurzelhash als separate Datei
              rausgeschrieben, was fur Offline-Signaturen praktisch ist.

              kernel-modules-initrd entspricht den getrennten
              Kernelmodul-Initrds, die mkosi an die Haupt-Initird anhangt.
              Dies ist hauptsachlich fur die Fehlersuche gedacht, da viele
              Initrd-Untersuchungswerkzeuge nicht mit mehreren,
              aneinandergehangten Initrds umgehen konnen.

              Wenn repart-definitions angegeben ist, wird ein Verzeichnis, das
              die verwandten Repart-Definitionslisten enthalt, in die
              Standardausgabe geschrieben. Falls mittels RepartDirectories=
              mehrere Verzeichnisse konfiguriert sind, werden sie
              zusammengefuhrt, wobei spatere Verzeichnisse gegenuber fruheren
              Prioritat haben, wenn Dateien mit identischem Namen existieren.

              Standardmassig werden uki, kernel und initrd herausgetrennt.

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

       SectorSize=, --sector-size=
              Setzt die Standardsektorgrosse, die systemd-repart(8) zum Bau
              eines Plattenabilds benutzt, ausser Kraft.

       Overlay=, --overlay=
              Bei der Verwendung zusammen mit BaseTrees= wird die Ausgabe nur
              aus Anderungen an den angegebenen Basisbaumen bestehen. Jeder
              Basisbaum wird als untere Lage in einer Overlayfs-Struktur
              angehangt und die Ausgabe wird die obere Lage, die am Anfang
              leer ist. Daher werden Dateien, die sich gegenuber dem Basisbaum
              nicht andern, nicht in der abschliessenden Ausgabe enthalten
              sein.

              Diese Option kann dazu verwandt werden, Systemd
              Systemerweiterungen
              <https://uapi-group.org/specifications/specs/extension_image> zu
              erstellen.

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

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

   Abschnitt [Content]
       Packages=, --package=, -p
              Installiert die angegebenen Distributionspakete (z.B.  RPM, deb,
              <?>) in dem Abbild. Akzeptiert eine Kommata-getrennte Liste von
              Paketangaben. Diese Option kann mehrfach verwandt werden; dann
              werden die angegebenen Paketlisten kombiniert. Verwenden Sie
              BuildPackages=, um Pakete anzugeben, die nur in einer
              Uberlagerung installiert werden, die eingehangt wird, wenn die
              Vorbereitungsskripte mit dem Argument build ausgefuhrt werden
              und wenn die Bauskripte ausgefuhrt werden.

              Die Arten und Syntax der erlaubten Paketangaben hangen von dem
              Paketinstallationsprogramm ab (z.B. dnf fur rpm(8)-basierte
              Distributionen oder apt(8) fur deb(5)-basierte Distributionen),
              kann aber Paketnamen, Paketnamen mit Versionen und/oder
              Architektur, Paketnamen-Globs, Paketgruppen und virtuelle
              Bereitstellungen (>>provides<<), einschliesslich Dateipfaden,
              enthalten.

              Siehe PackageDirectories= zu Informationen daruber, wie lokale
              Pakete zur Installation mit Packages= verfugbar gemacht werden
              konnen.

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

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

       BuildPackages=, --build-package=
              Ahnlich wie Packages=, konfiguriert aber Pakete, die nur in eine
              Uberlagerung installiert werden, die oberhalb des Abbildes
              verfugbar gemacht wird, um Skripte vorzubereiten, die mit dem
              Argument build ausgefuhrt werden, sowie den Bauskripten. Diese
              Option sollte zum Auffuhren von Paketen verwandt werden, die
              Header-Dateien, Compiler, Bausysteme, Linker und andere
              Bauwerkzeuge enthalten, die die Skripte mkosi.build zur
              Ausfuhrung benotigen. Beachten Sie, dass die hier aufgefuhrten
              Pakete im endgultigen Abbild nicht enthalten sein werden.

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

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

       PackageDirectories=, --package-directory=
              Legt Verzeichnisse fest, die zusatzliche Pakete enthalten, die
              wahrend des Baus verfugbar gemacht werden sollen. mkosi wird ein
              lokales Depot mit allen Paketen aus diesen Verzeichnissen
              erstellen und es beim Installieren von Paketen oder Ausfuhren
              von Skripten verfugbar machen. Falls das Verzeichnis
              mkosi.packages/ im lokalen Verzeichnis gefunden wird, wird es
              auch fur diesen Zweck verwandt.

       VolatilePackageDirectories=, --volatile-package-directory=
              Ahnlich zu PackageDirectories=, aber samtliche Anderungen an den
              Paketen in diesen Verzeichnissen werden die
              zwischengespeicherten Abbilder nicht fur ungultig erklaren,
              falls Incremental= aktiviert ist.

              Zusatzlich konnen Bauskripte weitere Pakete zu den lokalen
              Depots hinzufugen, indem sie gebaute Pakete in $PACKAGEDIR
              ablegen. Die in $PACKAGEDIR abgelegten Pakete werden von allen
              gebauten Abbildern gemeinsam benutzt und sind daher zur
              Installation in allen Abbildern mittels VolatilePackages=
              verfugbar.

       WithRecommends=, --with-recommends=
              Konfiguriert, ob empfohlene Pakete oder schwache Abhangigkeiten
              installiert werden, abhangig davon, wie sie vom verwandten
              Paketverwalter benannt werden. Standardmassig werden empfohlene
              Pakete nicht installiert. Dies wird nur von Paketverwaltern
              unterstutzt, die dieses Konzept unterstutzen. Derzeit sind dies
              apt(8), dnf(8) und zypper(8).

       WithDocs=, --with-docs=
              Bindet Dokumentation in das Abbild ein. Standardmassig
              aktiviert. Wenn deaktiviert, wird die Dokumentation in das
              Abbild nicht aufgenommen, falls der zugrundeliegende
              Paketverwalter das unterstutzt. Die Umgebungsvariable $WITH_DOCS
              wird an die Skripte mkosi.build mit 0 oder 1 weitergegeben,
              abhangig davon, ob diese Option aktiviert oder deaktiviert ist.

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

              Anstelle eines Verzeichnisses kann eine Tar-Datei oder ein
              Plattenabbild bereitgestellt werden. In diesem Fall wird es in
              den Betriebssystembaum entpackt. Dieser Betriebsmodus erlaubt
              das explizite Setzen von Berechtigungen und
              Dateieigentumerschaften, insbesondere fur Projekte, die in einem
              Versionsverwaltungssystem wie git(1) gespeichert sind, das die
              Metadaten fur die Dateieigentumerschaft und den Zugriffsmodus
              fur ubergebene Dateien vollstandig beibehalt.

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

              Beachten Sie, dass die Gerustbaume zwischengespeichert werden
              und alle Anderungen an den Gerustbaumen, nachdem ein
              zwischengespeichertes Abbild gebaut wurde (bei der Verwendung
              von Incremental=), nur angewandt werden, wenn das
              zwischengespeicherte Abbild neu gebaut wird (durch Verwendung
              von -ff oder der Ausfuhrung von mkosi -f clean).

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

              Um zusatzliche Paketverwalter-Konfigurationsdateien wie
              zusatzliche Depots hinzuzufugen, verwenden Sie SandboxTrees=, da
              mkosi die Paketverwalter von ausserhalb (und nicht innerhalb)
              des Abbildes aufruft und daher samtliche mittels SkeletonTrees=
              bereitgestellte Konfigurationsdateien nicht wirksam werden, wenn
              mkosi den Paketverwalter zur Installation von Paketen aufruft.

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

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

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

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

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

       SourceDateEpoch=, --source-date-epoch=
              Akzeptiert einen Zeitstempel in Sekunden seit dem UNIX-Epcoh als
              Argument. Dateiveranderungszeiten aller Dateien werden auf
              diesen Wert befestigt. Die Variable wird auch an
              systemd-repart(8) und alle von mkosi ausgefuhrten Skripte
              weitergegeben. Falls nicht explizit gesetzt, wird
              SOURCE_DATE_EPOCH aus --environment= und aus der Umgebung des
              Wirtsystems in dieser Reihenfolge ausprobiert. Siehe
              SOURCE_DATE_EPOCH
              <https://reproducible-builds.org/specs/source-date-epoch/> fur
              weitere Informationen.

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

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

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

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

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

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

       Bootable=, --bootable=
              Akzeptiert einen logischen Wert oder auto. Aktiviert oder
              deaktiviert die Erstellung eines startfahigen Abbildes. Falls
              aktiviert, wird mkosi ein EFI-Systemstartprogramm installieren
              und eine ESP-Partition hinzufugen, wenn die Plattenabbildausgabe
              verwandt wird. Falls das ausgewahlte EFI-Systemstartprogramm
              (siehe Bootloader=) nicht installiert ist oder keine
              Kernelabbilder gefunden werden konnen, wird der Bau
              fehlschlagen. auto verhalt sich so, als ob die Option aktiviert
              ware, aber der Bau schlagt nicht fehl, falls entweder kein
              Kernelabbild oder das ausgewahlte 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 hinzugefugt,
              falls das Plattenausgabeformat verwandt wird.

              Falls das Ausgabeformat esp verwandt wird, werden immer eine
              ESP-Partition und ein Systemstartprogramm hinzugefugt und die
              Option Bootable= steuert nur, ob ein UKI in der ESP-Partition
              hinzgefugt wird.

       Bootloader=, --bootloader=
              Akzeptiert entweder none, systemd-boot, uki, grub,
              systemd-boot-signed, uki-signed oder grub-signed. Standardmassig
              systemd-boot. Falls auf none gesetzt, wird kein
              EFI-Systemstartprogramm in das Abbild installiert. Falls auf
              systemd-boot gesetzt, wird systemd-boot(7) installiert und fur
              jeden installierten Kernel ein UKI erstellt und in EFI/Linux im
              ESP gespeichert. Falls auf uki gesetzt, wird ein einzelnes UKI
              fur den neuesten installierten Kernel (demjenigen mit der
              hochsten Version), der in EFI/BOOT/BOOTX64.EFI im ESP
              installiert ist, generiert. Falls auf grub gesetzt, wird fur
              jeden installierten Kernel ein UKI erstellt und in EFI/Linux im
              ESP gespeichert. Fur jeden erstellten UKI wird ein Menueintrag
              zu der Grub-Konfiguration in grub/grub.cfg im ESP hinzugefugt,
              der in den UKI weiterladt. Zur Anpassung wird ein grub.cfg auch
              nach EFI/<Distribution>/grub.cfg aus Kompatibilitatsgrunden mit
              signierten Versionen von Grub grub/grub.cfg im ESP geschrieben,
              da diese die Konfiguration von diesem Ort laden.

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

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

              Hinweis: Bei der Verwendung von systemd-boot oder
              systemd-boot-signed erwartet mkosi, dass die
              systemd-boot-EFI-Programme im Abbild vorhanden sind. Abhangig
              von Ihrer Distribution, konnten diese separat paketiert sein.
              Beispielsweise benotigen Debian-basierter Abbilder
              systemd-boot-efi.

       BiosBootloader=, --bios-bootloader=
              Akzeptiert entweder none oder grub. Standardmassig none. Falls
              auf none gesetzt, wird kein BIOS-Systemstartprogramm
              installiert. Falls auf grub gesetzt, wird Grub als
              BIOS-Systemstartprogramm installiert, falls ein startfahiges
              Abbild mit der Option Bootable= erbeten wird. Falls keine
              Repart-Partitionsdefinitionsdateien konfiguriert sind, wird
              mkosi eine Grub-BIOS-Systemstartpartition und eine
              EFI-Systempartition zu den Standard-Partitionsdefinitionsdateien
              hinzufugen.

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

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

              Selbst wenn kein EFI-Systemstartladeprogramm installiert ist,
              wird dennoch ein ESP fur BIOS-Systemstarts benotigt, da dort der
              Kernel, die Initrd und Grub-Module gespeichert werden.

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

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

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

       UnifiedKernelImages=, --unified-kernel-images=
              Gibt an, ob vereinigte Kernelabbilder verwandt werden sollen,
              wenn Bootloader= auf systemd-boot oder grub gesetzt ist.
              Akzeptiert none, unsigned, signed oder auto. Standardmassig
              auto. Falls unsigned oder signed, werden vereinigte
              Kernelabbilder immer verwandt und der Bau wird fehlschlagen,
              falls eine der fur den Bau von vereinigten Kernelabbildern
              benotigten Komponenten fehlt. Falls auf auto gesetzt, werden
              vereinigte Kernelabbilder verwandt, falls alle benotigten
              Komponenten verfugbar sind. Andernfalls werden stattdessen
              Typ-1-Eintrage, wie in der Systemstartladerspezifikation
              definiert, verwandt. Falls deaktiviert, werden Typ-1-Eintrage
              immer verwandt. Bootloader= wird auf eine der signierten
              Varianten gesetzt, ein vorab gebautes UKI wird durchsucht und
              der Bau wird fehlschlagen, falls es nicht gefunden werden kann,
              ausser wenn UnifiedKernelImages= auf unsigned gesetzt ist. In
              diesem Fall wird das UKI lokal gebaut. Dies ist nutzlich, wenn
              dies mit der auf custom gesetzten Laufzeitoption Firmware=
              kombiniert wird, so dass der lokal signierte Schlussel in der
              UEFI-Datenbank registriert wird.

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

              Die folgenden Kennzeichner konnen ausserdem verwendet werden:

              Kennzeichner   Wert
              ----------------------------------------
              &&             &-Zeichen
              &e             Zugangsmerkmal
              &k             Kernelversion
              &h             Wert des Kernelarguments
                             roothash= oder usrhash=

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

              Siehe die Dokumentation fur den Abschnitt UKIProfile zu
              Informationen, welche Einstellungen in
              UKI-Profil-Konfigurationsdateien vorgenommen werden konnen.

       Initrds=, --initrd=
              Verwendet vom Benutzer bereitgestellte Initrd(s). Akzeptiert
              eine Kommata-getrennte Liste von Pfaden zu Initrd-Dateien. Diese
              Option kann mehrfach angewendet werden. Dann werden die
              aufgefuhrten Initrd-Listen kombiniert. Falls keine Initrds
              angegeben sind und ein startfahiges Medium erbeten wurde, wird
              mkosi automatisch eine Standard-Initrd bauen.

              mkosi wird auch nach Initrds in einem Unterverzeichnis
              io.mkosi.initrd des Artefakt-Verzeichnisses suchen (siehe
              $ARTIFACTDIR in dem Abschnitt UMGEBUNGSVARIABLEN). Alle dort
              gefundenen Initrds werden an das oder die vom Benutzer
              bereitgestellt(en) und alle von [B]mkosi gebauten
              Vorgabe-Initrds angehangt

       InitrdProfiles=, --initrd-profile=
              Setzt das Profil, das fur die Standard-Initrd aktiviert werden
              soll. Akzeptiert eine Kommata-getrennte Liste von Profilen.
              Standardmassig sind alle Profile deaktiviert.

              Das Profil lvm aktiviert Unterstutzung fur LVM. Das Profil
              network aktiviert Unterstutzung fur Netzwerk mittels
              systemd-networkd(8). Das Profil nfs aktiviert Unterstutzung fur
              NFS. Es benotigt Netzwerkunterstutzung in der Initrd, mittels
              des Profils network oder einer anderen, angepassten Methode. Das
              Profil pkcs11 aktiviert Unterstutzung fur PKCS#11. Das Profil
              plymouth stellt eine graphische Schnittstelle fur den
              Systemstart bereit (Animation und Passworteingabe). Das Profil
              raid aktiviert Unterstutzung fur RAID-Systeme.

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

       InitrdVolatilePackages=, --initrd-volatile-package=
              Ahnlich zu VolatilePackages=, ausser das es auf die
              Standard-Initrd angewandt wird.

       Devicetrees=, --devicetrees=
              Kommata-getrennte Liste von Devicetree-Mustern fur die
              automatische, Hardware-basierte Auswahl. Muster sind
              Glob-Ausdrucke. mkosi sucht an den Standardorten relativ zu
              /usr/lib/modules/<kver>/dtb/,
              /usr/lib/firmware/<kver>/device-tree/ und
              /usr/lib/linux-image-<kver>/ nach Devictree-Dateien.

              Fur UKI-Bauten aktivieren mehrere Treffer die automatische,
              Hardware-basierte Auswahl mittels der Abschnitte .dtbauto. Fur
              Typ-1-Systemstarteintrage wird genau ein Treffer benotigt.

              Beispiel: Devicetrees=rockchip/*,imx.* wurde alle
              Rockchip-Devicetrees und alle IMX-Devicetrees aufnehmen.

       Splash=, --splash=
              Wenn gesetzt, wird der Systemstart-Startbildschirm fur alle
              durch mkosi gebauten vereinigten Kernelabbilder aus dem
              angegebenen Pfad innerhalb des Abbilds aufgenommen.

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

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

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

       KernelModules=, --kernel-modules=
              Akzeptiert eine Liste von Glob-Muster, die festlegen, welche
              Kernel-Module im Abbild aufgenommen werden sollen. Jedem
              Argument kann ein Gedankenstrich (-) zum Ausschluss passender
              Module vorangestellt werden. Die Argumente werden der
              Reihenfolge nach ausgewertet, das letzte positive oder negative
              passende Muster bestimmt das Ergebnis. Die Module, die zum
              Schluss auf ein positives Muster passen, werden im Abbild
              aufgenommen, sowie deren Modul- und Firmware-Abhangigkeiten.

              Die Endung .ko und Kompressionsendungen werden beim Vergleich
              ignoriert.

              Globs werden mit Modulpfaden relativ zu /usr/lib/module/<kver>
              verglichen, z.B. wird das Modul zum Zweck des Vergleichs unter
              /usr/lib/module/<kver>/kernel/foo/bar.ko.xz zu kernel/foo/bar.

              Mit >>/<< beginnende Globs werden besonders behandelt. Der Glob
              wird zuerst mit einem Pfad relativ zu
              /usr/lib/module/<kver>/kernel verglichen und nur dann mit
              /usr/lib/module/<kver>/. Dies dient der Bequemlichkeit, da
              normalerweise nur die Baum-internen Module unter kernel/ von
              Interesse sind.

              Beispielsweise kann das Modul unter
              /usr/lib/module/<kver>/kernel/foo/bar.ko.xz entweder mit
              /foo/bar oder /kernel/foo/bar verglichen werden.

              Das Glob-Muster kann einfach nur den Basisnamen enthalten (z.B.
              loop), der auf den Basisnamen des Moduls passen muss, den
              relativen Pfad (z.B. block/loop), das auf die abschliessenden
              Komponenten des Modulpfades bis zum Basisnamen passen muss oder
              ein absoluter Pfad (z.B. /drivers/block/loop), der auf den
              vollstandigen Pfad zum Modul passen muss.

              Wird / angehangt, dann passt das Muster auf alle Module
              unterhalb dieses Verzeichnisses.

              Die Muster konnen Shell-artige Globs (*, ?, [<?>-<?>])
              enthalten.

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

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

       KernelModulesInitrd=, --kernel-modules-initrd=
              Logischer Wert, standardmassig aktiviert (true). Falls beim Bau
              eines Abbildes aktiviert, wird mkosi eine zusatzliche Initrd fur
              jedes von ihm zusammengebaute vereinigte Kernelabbild erstellen.
              Diese Initrd enthalt nur Module und moglicherweise Firmware. Sie
              wird dann an die Basis-Initrd angehangt, um die abschliessende
              Initrd zu bilden. Dadurch bleibt die Basis-Initrd
              Kernel-unabhangig und erganzt nur die Argumente mit ihren
              notwendigerweise kernelversions-abhangigen Modulen, wenn das UKI
              zusammengebaut wird.

              Falls deaktiviert, wird kein zusatzliches Initrd erstellt.
              Beachten Sie, dass die Kernelmodule weiterhin nicht in die
              Basis-Initrd aufgenommen werden, die Kernel-unabhangig
              verbleibt. Stattdessen wird angenommen, dass der Benutzer die
              notwendigen Kernelmodule (falls sie existieren) in einer
              zusatzlichen, angepassten Initrd bereitstellt.

       KernelInitrdModules=, --kernel-modules-initrd-include=
              Wie KernelModules=, legt aber die in der Initrd einzubindenden
              Kernelmodule fest.

       FirmwareFiles=, --firmware-files=
              Akzeptiert eine Liste von Glob-Muster, die die im Abbild
              einzubindende Firmware festlegt. Die Muster werden genau wie bei
              der Einstellung KernelModules= interpretiert, ausser dass die
              Pfade relativ zum Unterverzeichnis /usr/lib/firmware/<Unterverz>
              sind. Die Komprimierungserweiterung wird ignoriert und darf in
              dem Muster nicht enthalten sein.

              Firmware-Abhangigkeiten von im Abbild installierten
              Kernel-Modulen werden automatisch aufgenommen.

              Beispiel: FirmwareFiles=cxgb4/bcm8483.bin oder
              FirmwareFiles=bcm8483.* wurden beide dazu fuhren, dass
              /usr/lib/firmware/cxgb4/bcm8483.bin.xz aufgenommen wurde, selbst
              wenn es nicht als Modul aufgefuhrt ist.

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

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

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

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

       Ssh=, --ssh=
              Gibt an, ob eine Socket-Unit fur sshd(8) und passende Dienste in
              dem endgultigen Abbild installiert werden sollen. Akzeptiert
              entweder always, never, auto oder runtime. Standardmassig auto.

              Falls auf auto gesetzt und sshd(8) im Abbild vorhanden ist und
              das Generator-Programm systemd-ssh-generator nicht vorhanden ist
              oder falls sie auf always gesetzt ist, wird mkosi sshd-Units im
              endgultigen Abbild installieren, die SSH uber VSock offenlegen.
              Falls auf never gesetzt, wird mkosi diese Units nicht
              installieren. Falls der Wert runtime verwandt wird, wird mkosi
              auch keine Units installieren, aber den Start von mkosi vm
              abbrechen, falls keine SSH-Zugangsberechtigungen konfiguriert
              sind. Beim Bau mit dieser Option und dem Betrieb des Abbilds
              mittels mkosi vm kann der Befehl mkosi ssh zum Verbinden mit dem
              Container/der VM mittels SSH verwandt werden. Beachten Sie, dass
              Sie weiterhin sicherstellen mussen, dass Openssh im Abbild
              installiert ist, damit sich mkosi ssh korrekt verhalt. Fuhren
              Sie mkosi genkey aus, um automatisch ein X.509-Zertifikat und
              private Schlussel zu erzeugen, die von mkosi zur Aktivierung vom
              SSH-Zugriff zu jeder virtuellen Maschine mittels mkosi ssh
              verwandt werden. Um auf mittels mkosi boot gestartete Abbilder
              zuzugreifen, verwenden Sie machinectl(1).

              Beginnend mit Systemd v256 wird systemd-ssh-generator(8)
              automatisch sshd(8) uber VSock bereitstellen, wenn er innerhalb
              einer VM ausgefuhrt wird. Falls Sie daher eine neuere Version
              von Systemd innerhalb einer VM verwenden, kann diese Option im
              Allgemeinen nicht verwandt werden. OpenSSH muss weiterhin in dem
              Abbild installiert sein und die Standardeinstellung von
              --vsock=auto ist ausreichend um sicherzustellen, dass ein VSock
              innerhalb der VM verfugbar ist.

              Hinweis: Falls die Distribution des Abbildes SELinux verwendet,
              wird der Dienst sshd(8) von mkosi den Zugriff auf den VSock
              verweigern. Dies fuhrt zu einem Verbindungsfehlschag vom
              Wirtsystem darauf. Sie mussen entweder die Durchsetzung von
              SELinux deaktivieren oder ein angepasstes Richtlinienmodul
              erstellen (z.B. mit audit2allow(1)).

       SELinuxRelabel=, --selinux-relabel=
              Legt fest, ob Dateien neu markiert werden sollen, um auf die
              SELinux-Richtlinie des Abbilds zu passen. Akzeptiert einen
              logischen Wert oder auto. Standardmassig auto. Falls
              deaktiviert, werden Dateien nicht neu markiert. Falls aktiviert,
              muss eine SELinux-Richtlinie im Abbild installiert werden und
              setfiles(8) verfugbar sein, um Dateien zu markieren. Falls
              wahrend setfiles(8) irgendein Fehler auftritt, wird der Bau
              fehlschlagen. Falls auf auto gesetzt, werden Dateien neu
              markiert, falls mkosi kein Verzeichnisabbild baut, eine
              SELinux-Richtlinie im Abbild installiert und setfiles(8)
              verfugbar ist. Alle wahrend setfiles(8) aufgetretenen Fehler
              werden ignoriert.

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

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

   Abschnitt [Validation]
       SecureBoot=, --secure-boot=
              Signiert systemd-boot(7) (falls es noch nicht signiert ist) und
              samtliche vereinigten Kernelabbilder fur UEFI SecureBoot.

       SecureBootAutoEnroll=, --secure-boot-auto-enroll=
              Einrichtung der automatischen Registrierung der Schlussel fur
              sicheren Systemstart in virtuellen Maschinen falls SecureBoot=
              verwandt wird, wie das in systemd-boot(7) beschrieben wird.
              Beachten Sie, dass systemd-boot(7) nur ab Systemd v253 die
              automatische Registrierung von Schlusseln fur sicheren
              Systemstart in virtuellen Maschinen durchfuhren wird. Um die
              automatische Registrierung unter Systemd v252 auf Maschinen ohne
              Virtualisierung durchzufuhren, mussen Sie eine
              systemd-boot(7)-Konfigurationsdatei nach /efi/loader/loader.conf
              mittels eines zusatzlichen Baumes mit secure-boot-enroll force
              oder secure-boot-enroll manual darin schreiben. Unter
              Systemd-Versionen alter als v252 wird keine automatische
              Registrierung unterstutzt. Standardmassig yes.

       SecureBootKey=, --secure-boot-key=
              Pfad zu der PEM-Datei, die den geheimen Schlussel zum Signieren
              des UEFI-Kernelabbilds, falls SecureBoot= verwandt wird und der
              PCR-Signaturen, falls SignExpectedPcr= auch verwandt wird,
              enthalt. Wenn SecureBootKeySource= angegeben ist, hangt der
              Eingabetyp von der Quelle ab.

       SecureBootCertificate=, --secure-boot-certificate=
              Pfad zu der X.509-Datei, die das Zertifikat fur das signierte
              UEFI-Kernelabbild enthalt, falls SecureBoot= verwandt wird.

       SecureBootSignTool=, --secure-boot-sign-tool=
              Werkzeug zum Signieren von PE-Programmen fur den sicheren
              Systemstart. Akzeptiert entweder systemd-sbsign, sbsign oder
              auto. Standardmassig auto. Falls auf auto gesetzt, wird (wenn
              verfugbar) entweder systemd-sbsign(1) oder sbsign(1) verwandt,
              wobei systemd-sbsign(1) bevorzugt wird.

       Verity=, --verity=
              Ob Verity fur Erweiterungsabbilder erzwungen oder deaktiviert
              wird. Akzeptiert entwedersigned, hash, defer, auto oder einen
              logischen Wert. Falls auf signed gesetzt, muss ein
              Verity-Schlussel und -Zertifikat vorhanden sein und der Bau wird
              fehlschlagen, falls keine Verity-Partitionen in dem durch
              systemd-repart(8) erstellten Plattenabbild erkannt werden. Falls
              deaktiviert, werden Verity-Partitionen von durch systemd-repart
              erstellten Erweiterungsabbildern ausgeschlossen. Falls auf hash
              gesetzt, konfiguriert mkosi systemd-repart(8) so, dass eine
              Verity-Hash-Partition erstellt wird, aber keine
              Signatur-Partition. Falls auf defer gesetzt, wird Platz fur die
              Verity-Signaturpartition reserviert, allerdings noch nicht
              befullt. Falls auf auto gesetzt und ein Verity-Schlussel und
              -Zertifikat vorhanden sind, wird mkosi sie an systemd-repart(8)
              weitergeben und erwartet, dass das erstellte Plattenabbild
              Verity-Partitionen enthalten wird, aber der Bau wird nicht
              fehlschlagen, falls keine Verity-Partitionen in dem durch
              systemd-repart(8) erstellten Plattenabbild gefunden werden.

              Beachten Sie, dass das explizite Deaktivieren der
              Verity-Signatur und/oder des Hashes fur die Ausgabe disk noch
              nicht implementiert ist und derzeit nur fur Erweiterungsabbilder
              funktioniert.

       VerityKey=, --verity-key=
              Pfad zu der PEM-Datei, die den geheimen Schlussel zum Signieren
              der Verity-Signatur enthalt, falls eine Verity-Signaturpartition
              mit systemd-repart(8) hinzugefugt wird. Wenn VerityKeySource=
              festgelegt wird, hangt der Eingabetyp von der Quelle ab.

       VerityCertificate=, --verity-certificate=
              Pfad zu einer X.509-Datei, die das Zertifikat zum Signieren der
              Verity-Signatur enthalt, falls eine Verity-Signaturpartition
              mittels systemd-repart(8) hinzugefugt wird.

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

       SignExpectedPcrKey=, --sign-expected-pcr-key=
              Pfad zu der PEM-Datei, die den geheimen Schlussel zum Signieren
              der erwarteten PCR-Signatur enthalt. Wenn VerityKeySource=
              festgelegt wird, hangt der Eingabetyp von der Quelle ab.

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

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

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

       Passphrase=, --passphrase=
              Gibt den Pfad zu einer Datei an, die die fur die
              LUKS-Verschlusselung zu verwendende Passphrase enthalt. Sie
              sollte die Passphrase wortwortlich enthalten und nicht mit einem
              Zeilenumbruch enden (d.h. in dem gleichen Format sein, wie
              cryptsetup(8) und /etc/crypttab die Passphrasendatei erwarten).
              Die Datei muss den Zugriffsmodus 0600 oder kleiner haben.

              Beachten Sie, dass diese Einstellung alleine keine
              Verschlusselung aktiviert. Sie mussen auch eine oder mehrere
              Partitionsdefinitionen zu mkosi.repart/ mit Encrypt=key-file
              hinzufugen, um verschlusselte Partitionen zum Abbild
              hinzuzufugen.

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

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

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

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

       Key=, --key=
              Wahlt den fur das Signieren der SHA256SUMS zu verwendenden
              gpg(1)-Schlussel aus. Dieser Schlussel muss bereits im
              gpg(1)-Schlusselbund vorhanden sein.

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

              Das Werkzeugbaumverzeichnis wird zwischen wiederholten
              Abbildbauten beibehalten, ausser es wird durch Aufruf von mkosi
              clean -f bereinigt.

              Beachten Sie, dass Programme, die in einem der mit
              ExtraSearchPaths= konfigurierten Pfade gefunden werden, mit
              /usr/ vom Werkzeugbaum anstatt vom Wirt ausgefuhrt werden. Falls
              die Distribution des Hauptsystems oder die Veroffentlichung
              nicht auf die Werkzeugbaum-Distribution bzw. -Veroffentlichung
              passt, konnte dies zu Fehlern fuhren, wenn Programme aus einem
              der zusatzlichen Suchpfad ausgefuhrt werden.

              Falls auf yes gesetzt wird mkosi automatisch ein zusatzliches
              Werkzeugbaumabbild hinzufugen und es als Werkzeugbaum verwenden.
              Dieses Abbild kann weiter mit den nachfolgend beschriebenen
              Einstellungen konfiguriert werden oder mit mkosi.tools.conf, das
              entweder eine Datei oder ein Verzeichnis sein kann, welche(s)
              zusatzliche Konfiguration fur den Standard-Werkzeugbaum enthalt.

              Weitere Details finden Sie im Abschnitt WERKZEUGBAUM.

       ToolsTreeDistribution=, --tools-tree-distribution=
              Setzt die fur den Standard-Befehlsbaum zu verwendende
              Distribution. Standardmassig die Distribution des Hauptsystems,
              ausser fur Ubuntu, wo die Vorgabe Debian und RHEL, CentOS, Alma
              und Rocky, wo die Vorgabe Fedora ist, oder custom, falls die
              Distribution des Hauptsystems keine unterstutzte Distribution
              ist.

       ToolsTreeRelease=, --tools-tree-release=
              Setzt die fur den Standard-Werkzeugbaum zu verwendende
              Distributionsveroffentlichung. Standardmassig wird die in mkosi
              fest eingebaute Standard-Veroffentlichung fur die Distribution
              verwandt.

       ToolsTreeProfiles=, --tools-tree-profile=
              Setzt die fur den Standard-Werkzeugbaum zu aktivierende Profile.
              Akzeptiert eine Kommate-getrennte Liste, die aus devel, misc,
              package-manager und runtime besteht. Standardmassig sind alle
              Profile ausser devel aktiviert.

              Das Profil devel enthalt Werkzeuge, um C/C++-Projekte zu bauen.
              Das Profil misc enthalt verschiedene Werkzeuge, die fur den
              Einsatz in Skripten praktisch sind. Das Paketverwalterprofil
              enthalt Paketverwalter und zugehorige Werkzeuge, die uber die
              der nativen Werkzeuge der Werkzeugbaumdistribution hinausgehen.
              Das Profil runtime enthalt die Werkzeuge, die zum Starten von
              Abbildern in einem systemd-nspawn(1)-Container oder in einer
              virtuellen Maschine benotigt werden.

       ToolsTreeMirror=, --tools-tree-mirror=
              Setzt den fur den Standardwerkzeugbaum zu verwendenden Spiegel.
              Standardmassig wird der Standardspiegel fur die
              Werkzeugbaumdistribution verwandt.

       ToolsTreeRepositories=, --tools-tree-repository=
              Identisch zu Repositories=, aber fur den Standardwerkzeugbaum.

       ToolsTreeSandboxTrees=, --tools-tree-sandbox-tree=
              Identisch zu SandboxTrees=, aber fur den Standardwerkzeugbaum.

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

       ToolsTreePackageDirectories=, --tools-tree-package-directory=
              Identisch zu PackageDirectories=, aber fur den
              Standardwerkzeugbaum.

       ToolsTreeCertificates=, --tools-tree-certificates=
              Legt fest, ob Zertifikate und Schlussel aus dem Werkzeugbaum
              verwandt werden sollen. Standardmassig aktiviert. Falls
              aktiviert, werden /etc/pki/ca-trust, /etc/pki/tls, /etc/ssl,
              /etc/ca-certificates und /var/lib/ca-certificates von dem
              Werkzeugbaum verwandt. Andernfalls werden diese Verzeichnisse
              aus dem Wirtsystem aufgenommen.

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

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

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

       CacheOnly=, --cache-only=
              Akzeptiert entweder auto, metadata, always oder never.
              Standardmassig auto. Falls always, wird der Paketverwalter
              angewiesen, das Netzwerk nicht zu kontaktieren. Dies stellt eine
              minimale Reproduzierbarkeitsstufe bereit, solang der
              Paketzwischenspeicher bereits vollstandig gefullt ist. Falls auf
              metadata gesetzt kann der Paketverwalter weiterhin Pakete
              herunterladen, aber nicht die Metadaten des Depots
              synchronisieren. Falls auf auto gesetzt werden wahrend des Baus
              die Paketmetadaten synchronisiert (ausser es liegt ein
              zwischengespeichertes Abbild vor - siehe Incremental=) und die
              Pakete heruntergeladen. Falls never, werden die Depot-Metadaten
              immer synchronisiert und Pakete konnen wahrend des Baus
              heruntergeladen werden.

       SandboxTrees=, --sandbox-tree=
              Akzeptiert eine Kommata-getrennte Liste von
              Doppelpunkt-getrennten Pfadpaaren. Der erste Pfad jedes Paares
              bezieht sich auf ein Verzeichnis, das in die Sandbox von mkosi
              vor der Ausfuhrung eines Werkzeugs kopiert werden soll. Der
              zweite Pfad in jedem Paar bezieht sich auf das Zielverzeichnis
              innerhalb der Sandbox. Falls der zweite Pfad nicht bereit
              gestellt wird, wird das Verzeichnis auf das Wurzelverzeichnis
              der Sandbox kopiert. Der zweite Pfad wird immer als ein
              absoluter Pfad interpretiert. Falls das Verzeichnis
              mkosi.sandbox/ in dem lokalen Verzeichnis gefunden wird, wird es
              fur diesen Zweck mit dem Wurzelverzeichnis als Ziel verwandt
              (siehe auch den nachfolgenden Abschnitt DATEIEN).

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

       WorkspaceDirectory=, --workspace-directory=
              Pfad zu einem Verzeichnis, in dem temporar wahrend eines
              Abbild-Baus benotigte Daten gespeichert werden. Dieses
              Verzeichnis sollte uber genug Platz verfugen, das vollstandige
              Betriebssystemabbild zu speichern, obwohl in den meisten Modi
              der tatsachlich verwandte Plattenplatz kleiner ist. Falls nicht
              angegeben, wird ein Unterverzeichnis von $XDG_CACHE_HOME (falls
              gesetzt), $CACHE_DIRECTORY (falls gesetzt), $HOME/.cache (falls
              gesetzt) oder /var/tmp verwandt.

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

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

       CacheKey=, --cache-key=
              Legt das Unterverzeichnis innerhalb des
              Zwischenspeicherverzeichnisses fest, in dem das
              zwischengespeicherte Abbild gespeichert werden soll. Dies kann
              sowohl die normalen Kennzeichner (siehe Kennzeichner) als auch
              besondere verzogerte Kennzeichner festlegen, die nach Abschluss
              der Auswertung der Konfiguration anstatt wahrend der Auswertung
              der Konfiguration expandiert werden und die nachfolgend
              beschrieben werden. Das Standardformat fur diesen Parameter
              lautet &d~&r~&a~&I.

              Die folgenden Kennzeichner konnen ausserdem verwendet werden:

              Kennzeichner   Wert
              ------------------------------------------
              &&             &-Zeichen
              &d             Distribution=
              &r             Release=
              &a             Architecture=
              &i             ImageId=
              &v             ImageVersion=
              &I             Unterabbild-Name innerhalb
                             von mkosi.images/ oder
                             main

              Beachten Sie, dass alle Abbilder innerhalb eines Baus einen
              eindeutigen Zwischenspeicherschlussel haben mussen.

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

       BuildDirectory=, --build-directory=
              Akzeptiert einen Pfad zu einem Verzeichnis, das als
              Bauverzeichnis fur Bausysteme verwandt werden soll, die Bauen in
              separaten Verzeichnissen unterstutzen (wie Meson). Das auf diese
              Art verwandte Verzeichnis wird zwischen mehreren Bauten
              gemeinsam benutzt und ermoglicht es dem Bausystem, Artefakte
              (wie Objektdateien, Programmen, <?>), die bei vorherigen
              Aufrufen erzeugt wurden, wiederzuverwenden. Die Bauskripte
              konnen den Pfad zu diesem Verzeichnis in der Umgebungsvariable
              $BUILDDIR finden. Dieses Verzeichnis wird in das
              Wurzelverzeichnis des Abbildes eingehangt, wenn mkosi-chroot
              wahrend der Ausfuhrung der Bauskripte aufgerufen wird. Falls
              diese Option nicht verwandt wird, aber das Verzeichnis
              mkosi.builddir/ im lokalen Verzeichnis gefunden wird, wird es
              automatisch fur diesen Zweck verwandt (siehe auch den
              nachfolgenden Abschnitt DATEIEN).

       BuildKey=, --build-key=
              Legt das Unterverzeichnis innerhalb des Bauverzeichnisses fest,
              in dem die inkrementellen Bauten gespeichert werden sollen. Dies
              kann sowohl die normalen Kennzeichner (siehe Kennzeichner) als
              auch besondere verzogerte Kennzeichner festlegen, die nach
              Abschluss der Auswertung der Konfiguration anstatt wahrend der
              Auswertung der Konfiguration expandiert werden und die die
              gleichen verzogerten Kennzeichner sind, die von CacheKey=
              unterstutzt werden. Das Standardformat fur diesen Parameter
              lautet &d~&r~&a.

              Um die Verwendung eines Bauunterverzeichnisses vollstandig zu
              deaktivieren, weisen Sie dieser Einstellung ein wortliches - zu.

       UseSubvolumes=, --use-subvolumes=
              Akzeptiert einen logischen Wert oder auto. Aktiviert oder
              deaktiviert die Verwendung von btrfs(5)-Teildatentragern fur
              Verzeichnisbaumausgaben. Falls aktiviert wird mkosi das
              Wurzelverzeichnis als btrfs(5)-Teildatentrager erstellen und wo
              moglich btrfs(5)-Teildatentragerschnappschusse verwenden, um
              grundlegende oder zwischengespeicherte Baume zu kopieren, was
              viel schneller als rekursive Kopieren ist. Falls explizit
              aktiviert und btrfs(8) nicht installiert ist oder
              Teildatentrager nicht erstellt werden konnen, wird ein Fehler
              ausgelost. Falls auto, werden ein fehlendes btrfs(8) oder
              Fehlschlage beim Erstellen von Teildatentragern ignoriert.

       RepartOffline=, --repart-offline=
              Legt fest, ob Plattenabbilder mittels Loopback-Geraten gebaut
              werden. Standardmassig aktiviert. Wenn aktiviert, wird
              systemd-repart(8) keine Loopback-Gerate zum Bau von
              Plattenabbildern verwenden. Wenn deaktiviert, wird
              systemd-repart(8) immer Loopback-Gerate zum Bau von
              Plattenabbildern verwenden.

              Beachten Sie, dass mkosi nicht unprivilegiert ausgefuhrt werden
              kann, wenn RepartOffline=no verwandt wird und der Abbild-Bau als
              Benutzer root ausserhalb von Containern und mit auf dem
              Wirtsystem verfugbaren Loopback-Geraten erfolgt.

              Es gibt derzeit zwei bekannte Szenarien, bei denen
              RepartOffline=no verwandt werden muss. Das erste ist der Einsatz
              von Subvolumes= in einer Repart-Partitionsdefinitionsdatei, da
              Teildatentrager nicht ohne Loopback-Gerate erstellt werden
              konnen. Das zweite ist bei der Erstellung eines Systems mit
              SELinux und einer XFS-Wurzelpartition. Da mkfs.xfs(8) die
              Befullung eines XFS-Dateisystems mit erweiterten Attributen
              nicht erlaubt, mussen Loopback-Gerate verwandt werden um
              sicherzustellen, dass erweiterte SELinux-Attribute im erstellten
              XFS-Dateisystem landen.

       History=, --history=
              Akzeptiert einen logischen Wert. Falls aktiviert, wird mkosi die
              uber die CLI fur den neusten Bau bereitgestellte Konfiguration
              in das Unterverzeichnis .mkosi-private (unter dem Verzeichnis,
              in dem es aufgerufen wurde) schreiben.  Diese Argumente werden
              dann so lange wiederverwertet, wie das Abbild nicht neu gebaut
              wird, um deren immer wiederkehrende Angabe zu vermeiden.

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

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

       BuildSourcesEphemeral=, --build-sources-ephemeral=
              Akzeptiert einen logischen oder den besonderen Wert buildcache.
              Standardmassig deaktiviert. Konfiguriert, ob Anderungen an
              Quellverzeichnissen, dem Arbeitsverzeichnis und dem mit
              BuildSources= konfigurierten Verzeichnis dauerhaft sind. Falls
              aktiviert, werden nach der Ausfuhrung aller Skripte eines
              bestimmten Typs (ausser Synchronisationsskripte) alle
              Quellverzeichnisse auf ihren Originalzustand zuruckgesetzt.

              <?><?><?> Falls auf buildcache gesetzt wird die Uberlagerung
              nicht bei der Ausfuhrung von Bauskripten verworfen, sondern im
              Bauverzeichnis, konfiguriert mittels BuildDirectory=,
              gespeichert und bei nachfolgenden Laufen wiederverwandt. Die
              Uberlagerung wird weiterhin fur alle anderen Skripte verworfen.
              Diese Option kann fur ein fortgeschritteneres Zwischenspeichern
              bei Bauten verwandt werden, kann aber zu unerwarteten Zustanden
              des Bauverzeichnisses fuhren. Bei der Verwendung dieser Option
              muss ein Bauverzeichnis konfiguriert sein.  <?><?><?>

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

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

       WithTests=, --with-tests=, -T
              Falls auf >>false<< gesetzt (oder wenn die Befehlszeilenoption
              verwandt wird), wird die Umgebungsvariable $WITH_TESTS auf 0
              gesetzt, wenn die Skripte mkosi.build aufgerufen werden. Dies
              ist dafur gedacht, von Bauskripten zur Umgehung von Unit- oder
              Integrationstest, die normalerweise wahrend des
              Quellbauprozesses aufgerufen werden, verwandt zu werden.
              Beachten Sie, dass diese Option nur wirksam wird, wenn die
              mkosi.build-Bauskripte sie respektieren.

       WithNetwork=, --with-network=
              Wenn >>true<<, aktiviert Netzwerkverbindungen wahrend der von
              mkosi.build aufgerufenen Bauskripte. Standardmassig werden die
              Bauskripte mit abgeschaltetem Netzwerk ausgefuhrt. Die
              Umgebungsvariable $WITH_NETWORK wird an die
              mkosi.build-Bauskripte ubergeben um anzuzeigen, ob der Bau mit
              Netzwerk erfolgt.

       ProxyUrl=, --proxy-url=
              Konfiguriert einen Proxy, der fur alle ausgehenden
              Netzwerkverbindungen verwandt werden soll. Verschiedene
              Werkzeuge, die mkosi aufruft und fur die der Proxy konfiguriert
              werden kann, sind fur diesen Proxy konfiguriert. mkosi setzt
              auch verschiedene gut bekannte Umgebungsvariablen, um den Proxy
              zur Verwendung mit allen Programmen festzulegen, die es aufruft
              und die Internetzugriff benotigen konnten.

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

       ProxyPeerCertificate=, --proxy-peer-certificate=
              Konfiguriert eine Datei, die Zertifikate zur Uberprufung des
              Proxys enthalt. Standardmassig ist das der systemweite
              Zertifikaktspeicher.

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

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

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

       ProxyClientKey=, --proxy-client-key=
              Konfiguriert eine Datei, die den privaten Schlussel fur die
              Authentifizierung des Clients mit dem Proxy enthalt. Die Vorgabe
              ist das Proxy-Client-Zertifikat, falls eines bereitgestellt
              wurde.

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

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

       VirtualMachineMonitor=, --vmm=
              Konfiguriert den zu verwendenden Monitor fur virtuelle
              Maschinen. Akzeptiert entweder qemu oder vmspawn. Standardmassig
              qemu.

              Falls auf qemu gesetzt, wird das Abbild mit qemu gestartet. Die
              meisten Ausgabeformate konnen mit qemu gestartet werden. Alle
              nach dem Unterbefehl angegebenen Argumente werden an den Aufruf
              von qemu angehangt und als zusatzliche
              qemu-Befehlszeilenargumente interpretiert.

              Falls auf vmspawn gesetzt, wird systemd-vmspawn(1) zum
              Hochfahren des Abbildes benutzt. vmspawn unterstutzt nur
              platten- und verzeichnisartige Abbilder. Alle nach dem
              Unterbefehl angegebenen Argumente werden an den Aufruf von
              systemd-vmspawn(1) angehangt und als zusatzliche
              Vmspawn-Optionen und Kernelbefehlszeilenargumente interpretiert.

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

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

              Wird dies auf 0 gesetzt, wird die Anzahl der fur den
              mkosi-Prozess verfugbaren CPUs verwandt.

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

       MaxMem=, --maxmem=
              Konfiguriert die maximale Speichermenge, die der Gast insgesamt
              einsetzen darf (RAM + Hotplug-Speichergerate). Standardmassig
              die konfigurierte RAM-Grosse.

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

       CXL=, --cxl=
              Konfiguriert, ob fur eine angegebene Maschine CXL-Gerate
              aktiviert werden. Nur gultig, falls die Architektur CXL
              unterstutzt. Akzeptiert einen logischen Wert. Standardmassig
              false.

       VSock=, --vsock=
              Konfiguriert, ob ein Vsock beim Starten einer virtuellen
              Maschine vorgehalten werden soll. Akzeptiert einen logischen
              Wert oder auto. Standardmassig auto.

       VSockCID=, --vsock-cid=
              Konfiguriert die beim Starten einer virtuellen Maschine zu
              verwendende Verbindungskennung. Akzeptiert eine Zahl im
              Intervall [3, 0xFFFFFFFF) oder hash oder auto. Standardmassig
              auto. Wenn auf hash gesetzt wird die Verbindungskennung von dem
              vollstandigen Pfad zum Abbild abgeleitet. Wenn auf auto gesetzt,
              wird mkosi versuchen, automatisch eine freie Verbindungskennung
              zu finden. Andernfalls wird die bereitgestellte Nummer
              unverandert verwandt.

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

       Removable=, --removable=
              Konfiguriert, ob das Abbild als entfernbares Gerat beim Start
              einer virtuellen Maschine angehangt werden soll. Akzeptiert
              einen logischen Wert. Standardmassig no.

       Firmware=, --firmware=
              Konfiguriert die zu verwendende Firmware. Akzeptiert entweder
              uefi, uefi-secure-boot, bios, linux, linux-noinitrd oder auto.
              Standardmassig auto. Falls auf uefi gesetzt, wird die
              OVMF-Firmware ohne Unterstutzung fur sicheren Systemstart
              verwandt. Falls auf uefi-secure-boot gesetzt, wird die
              OVMF-Firmware mit Unterstutzung fur sicheren Systemstart
              verwandt. Falls auf bios gesetzt, wird die
              Standard-SeaBIOS-Firmware verwandt. Falls auf linux gesetzt,
              wird der direkte Kernelstart verwandt. Siehe die Option Linux=
              fur weitere Details daruber, welches Kernelabbild mit direktem
              Kernelsystemstart verwandt wird. linux-noinitrd ist mit linux
              identisch, ausser dass keine Initrd verwandt wird. Falls auf
              auto gesetzt wird falls moglich uefi-secure-boot und ansonsten
              linux verwandt.

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

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

              Falls auf microsoft-mok gesetzt wird eine bereits registrierte
              Firmware-Variablen-Datei mit dem >>Microsoft secure
              boot<<-Zertifikaten durch eine MokList-Variable erweitert, die
              das Zertifikat fur den sicheren Systemstart aus
              SecureBootCertificate= enthalt. Dies ist fur die gemeinsame
              Verwendung von durch die Distribution signierten Shim-Programmen
              und lokal signierten EFI-Programmen gedacht.

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

              virt-fw-vars aus dem Projekt virt-firmware
              <https://gitlab.com/kraxel/virt-firmware> kann zum Anpassen der
              OVMF-Variablendateien verwandt werden.

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

              Beachten Sie, dass bei der Verwendung des Ausgabeformats cpio
              der direkte Kernelsystemstart unabhangig von der konfigurierten
              Firmware verwandt wird. Abhangig von der konfigurierten Firmware
              konnte qemu den Kernel selbst starten oder die konfigurierte
              Firmware verwenden.

              Diese Einstellung darf sowohl die regularen Kennzeichner (siehe
              Kennzeichner) als auch die nachfolgend beschriebenen besonderen
              verzogerten Kennzeichner einbinden, die nach Abschluss der
              Auswertung der Konfiguration erweitert werden, statt wahrend der
              Auswertung der Konfiguration.

              Die folgenden Kennzeichner konnen ausserdem verwendet werden:

              Kennzeichner   Wert
              ---------------------------------
              &&             &-Zeichen
              &b             Das letztendliche
                             Bauverzeichnis
                             (einschliesslich
                             Unterverzeichnis)

       Drives=, --drive=
              Fugt ein Laufwerk hinzu. Akzeptiert eine Doppelpunkt-getrennte
              Zeichenkette im Format
              <Kennung>:<Grosse>[:<Verzeichnis>[:<Optionen>[:<Dateikennung>[:<Schalter>]]]].
              Kennung legt die dem Laufwerk zugeordnete Kennung fest. Diese
              kann als die Eigenschaft drive= in verschiedenen qemu-Geraten
              verwandt werden. Grosse legt die Grosse des Laufwerks fest. Dies
              akzeptiert eine Grosse in Byte. Zusatzliche konnen die Endungen
              K, M und G zur Festlegung einer Grosse in Kilobyte, Megabyte
              bzw. Gigabyte verwandt werden. Verzeichnis legt optional das
              Verzeichnis fest, in dem das dem Laufwerk zugrunde liegende
              Verzeichnis erstellt werden soll. Falls nicht gesetzt, wird die
              Datei unter /var/tmp erstellt. Optionen legen optional
              zusatzliche, durch Kommata getrennte Eigenschaften fest, die
              unverandert an die Option -blockdev von qemu ubergeben werden.
              Dateikennung legt die Kennung der Datei fest, die dem Laufwerk
              zugrunde liegt. Falls nicht gesetzt, ist die Laufwerkskennung
              die Vorgabe. Laufwerke mit der gleichen Dateikennung haben eine
              gemeinsame zugrundeliegende Datei. Das Verzeichnis und die
              Grosse der Datei wird aus dem ersten Laufwerk mit der
              angegebenen Dateikennung bestimmt. flags akzeptiert eine
              Kommata-getrennte Liste von Laufwerksschaltern, die derzeit nur
              persist unterstutzen. persist bestimmt, ob das Laufwerk uber
              Aufrufe von qemu hinweg dauerhaft besteht. Das den Dateien
              zugrundeliegende Laufwerk wird innerhalb des Schematas
              /<Verzeichnis>/mkosi-Laufwerk-<Maschinen-oder-Abbildname>-<Dateikennung>
              erstellt. Sie konnen Werte uberspringen, indem Sie sie auf die
              leere Zeichenkette setzen. Die Angabe von beispielsweise
              myfs:1G::::persist wird ein dauerhaftes Laufwerk unter
              /var/tmp/mkosi-drive-main-myfs erstellen.

              Beispielhafte Verwendung:

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

       QemuArgs=
              Leerzeichen-begrenzte Liste von zusatzlich beim Aufruf von qemu
              zu ubergebenen Argumenten.

       Ephemeral=, --ephemeral=
              Bei der Verwendung mit den Unterbefehlen shell, boot oder vm
              fuhrt diese Option den angegebenen Unterbefehl auf einem
              temporaren Schnappschuss des Ausgabeabbilds aus, das sofort
              entfernt wird, wenn der Container sich beendet. Die Vornahme
              temporarer Schnappschusse ist auf Dateisystemen effizienter, die
              Reflinks nativ unterstutzen (btrfs(5) oder xfs(5)), als auf
              traditionellen, bei denen das nicht der Fall ist (ext4(5)).

       Credentials=, --credential=
              Setzt die an systemd-nspawn(1) bzw. der virtuellen Maschine zu
              ubergebenen Zugangsberechtigungen, wenn mkosi shell/boot oder
              mkosi vm verwandt wird. Diese Option akzeptiert eine Leerzeichen
              getrennte Liste von Werten, die entweder Schlussel=Wert-Paare
              oder Pfade sein konnen. Falls ein Pfad bereitgestellt wird, wird
              der Zugangsberechtigungsname der Name der Datei sein, wenn der
              Pfad eine Datei ist. Falls die Datei ausfuhrbar ist, wird die
              Zugangsberechtigung die Ausgabe nach Ausfuhren der Datei sein.
              Andernfalls wird der Wert der Zugangsberechtigung der Inhalt der
              Datei sein. Falls der Pfad ein Verzeichnis ist, gilt die gleiche
              Logik fur jede Datei in dem Verzeichnis.

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

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

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

              Fur jedes eingehangte Verzeichnis wird die UID und GID des
              Benutzers, der Mkosi ausfuhrt, auf den Benutzer root in der
              Maschine abgebildet. Dies bedeutet, dass alle Dateien und
              Verzeichnisse so erscheinen, als ob sie root in der Maschine
              gehoren wurden und alle neuen Dateien und Verzeichnisse, die von
              root in der Maschine in diesen Verzeichnissen erstellt werden,
              gehoren auf der Wirtmaschine dem Benutzer, der Mkosi ausfuhrt.

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

       RuntimeSize=, --runtime-size=
              Falls angegeben werden Plattenabbilder bis zu der angegebenen
              Grosse vergrossert, wenn sie mit mkosi boot oder mkosi vm
              gestartet werden. Akzeptiert eine Grosse in Byte. Zusatzlich
              konnen die Endungen K, M und G verwandt werden, um eine Grosse
              in Kilobyte, Megabyte bzw. Gigabyte festzulegen.

       RuntimeNetwork=, --runtime-network=
              Akzeptiert entweder user, interface oder none. Standardmassig
              user. Legt das beim Systemstart einzurichtende Netzwerk fest.
              user richtet Benutzermodus-Vernetzung ein. interface richtet
              eine virtuelle Netzwerkverbindung zwischen dem Wirtrechner und
              dem Abbild ein. Dies ubersetzt sich in eine Veth-Schnittstelle
              fur mkosi shell und mkosi boot und eine Tap-Schnittstelle fur
              mkosi vm und mkosi vmspawn.

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

       RuntimeBuildSources=, --runtime-build-sources=
              Hangt die mit BuildSources= konfigurierten Bauquellen und das
              Bauverzeichnis (falls eines konfiguriert wurde) an die gleichen
              Orte in /work ein, an der sie eingehangt wurden, wenn das
              Bauskript ausgefuhrt wurde, wenn mkosi boot oder mkosi vm
              verwandt wurde.

       BindUser=, --bind-user=
              Bindet das Home-Verzeichnis des aktuellen Benutzers in den
              Container/die VM. Akzeptiert einen logischen Wert.
              Standardmassig deaktiviert.

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

       SshKey=, --ssh-key=
              Pfad zu dem privaten X.509-Schlussel im PEM-Format, der fur die
              Verbindung zu einer mit mkosi vm gestarteten virtuellen Maschine
              verwandt werden soll und die mittels des Befehls mkosi ssh
              aktivierten (oder mittels systemd-ssh-generator(8)
              installierten)Option Ssh= gebaut wurde. Falls nicht konfiguriert
              und mkosi.key im aktuellen Arbeitsverzeichnis existiert, wird
              dies automatisch fur diesen Zweck verwandt. Fuhren Sie mkosi
              genkey aus, um automatisch einen Schlussel in mkosi.key zu
              erstellen.

       SshCertificate=, --ssh-certificate=
              Pfad zu dem X.509-Zertifikat im PEM-Format zur Beistellung als
              offentlicher SSH-Schlussel in durch mkosi vm gestarteten
              virtuellen Maschinen. Falls nicht konfiguriert und mkosi.crt im
              aktuellen Arbeitsverzeichnis existiert, wird dies automatisch
              fur diesen Zweck verwandt. Fuhren Sie mkosi genkey aus, um
              automatisch ein Zertifikat in mkosi.crt zu erstellen.

       Machine=, --machine=
              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. mkosi --image=meinAbbild ssh).

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

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

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

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

              Beachten Sie, dass die Journal-Grosse auf 4G beschrankt ist,
              falls ein Pfad mit der Erweiterung .journal angegeben wird.
              Konfigurieren Sie ein Ausgabeverzeichnis anstelle einer Datei,
              falls ihre Auslastung mehr als 4G an Journal-Daten erzeugt.

       StorageTargetMode=, --storage-target-mode=
              Legt fest, ob der Unterbefehl serve systemd-storagetm zum
              Ausliefern von Plattenabbildern uber NVME-TCP starten soll.
              Akzeptiert einen logischen Wert oder auto. Falls aktiviert, wird
              systemd-storagetm immer gestartet und mkosi wird fehlschlagen,
              falls es systemd-storagetm nicht starten kann. Falls
              deaktiviert, wird systemd-storagetm niemals gestartet. Falls
              auto, wird systemd-storagetm gestartet, wenn ein Plattenabbild
              gebaut wird, das Programm systemd-storagetm gefunden wird und
              mkosi serve unter der Benutzerkennung root aufgerufen wird.

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

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

   Abschnitt [Match]
       Profiles=
              Ubereinstimmung mit den konfigurierten Profilen.

       Distribution=
              Ubereinstimmung mit der konfigurierten Distribution.

       Release=
              Ubereinstimmung mit der konfigurierten
              Distributionsveroffentlichung. Falls diese Bedingung verwandt
              wird und noch keine Distribution explizit konfiguriert wurde,
              wird die Distribution und Veroffentlichung der Wirtmaschine
              verwandt.

       Architecture=
              Ubereinstimmung mit der konfigurierten Architektur. Falls diese
              Bedingung verwandt wird und noch keine Architektur explizit
              konfiguriert wurde, wird die Architektur des Wirtsystems
              verwandt. Architecture=uefi kann fur Ubereinstimmungen mit allen
              Architekturen, die UEFI unterstutzen, verwandt werden.

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

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

       ImageId=
              Ubereinstimmung mit der konfigurierten Abbildkennung, Globs
              werden unterstutzt. Falls diese Bedingung verwandt wird und noch
              keine Abbildkennung explizit konfiguriert wurde, schlagt diese
              Bedingung fehl.

       ImageVersion=
              Ubereinstimmung mit der konfigurierten Abbildversion. Den
              Abbildversionen konnen die Operatoren ==, !=, >=, <=, <, > fur
              umfangreiche Versionsvergleiche entsprechend der
              UAPI-Gruppenversionsformatspezifikation vorangestellt werden.
              Falls kein Operator vorangestellt wird, wird standardmassig der
              Gleichheits-Operator angenommen. Falls diese Bedingung verwandt
              wird und noch keine Abbildversion explizit konfiguriert wurde,
              schlagt diese Bedingung fehl.

       Bootable=
              Ubereinstimmung mit dem konfigurierten Wert fur die
              Funktionalitat Bootable=. Akzeptiert einen logischen Wert oder
              auto.

       Format=
              Ubereinstimmung mit dem konfigurierten Wert fur die Option
              Format=. Akzeptiert ein Ausgabeformat (siehe die Option
              Format=).

       SystemdVersion=
              Ubereinstimmung mit der Systemd-Version des Wirtsystems (wie von
              systemctl --version berichtet). Den Werten konnen die Operatoren
              ==, !=, >=, <=, <, > fur umfangreiche Versionsvergleiche
              entsprechend der UAPI-Gruppenversionsformatspezifikation
              vorangestellt werden. Falls kein Operator vorangestellt wird,
              wird standardmassig der Gleichheits-Operator angenommen.

       BuildSources=
              Akzeptiert einen Bauquellen-Zielpfad (siehe BuildSources=).
              Diese Ubereinstimmung ist erfullt, falls eine der konfigurierten
              Bauquellen diesen Zielpfad verwendet. Enthalt beispielsweise
              eine Datei mkosi.conf Folgendes:

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

              Und eine Erganzung, die folgendes enthalt:

                     [Match]
                     BuildSources=kernel

              Die Erganzung wird aufgenommen.

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

       HostArchitecture=
              Ubereinstimmung mit der grundstandigen Architektur des
              Wirtrechners. Siehe die Einstellung Architecture= fur eine Liste
              moglicher Werte.

       ToolsTreeDistribution=
              Ubereinstimmung mit der konfigurierten
              Werkzeugbaum-Distribution.

       ToolsTreeRelease=
              Ubereinstimmung mit der konfigurierten
              Werkzeugbaum-Veroffentlichung.

       Environment=
              Ubereinstimmung mit einem bestimmten, mit Environment=
              konfigurierten Schlussel/Wert-Paar. Falls kein Wert
              bereitgestellt wird, wird uberpruft, ob ein angegebener
              Schlussel sich in der Umgebung befindet, unabhangig von seinem
              Wert.

       Image= Vergleicht mit dem aktuellen (Unter-)Abbild. Der Name des
              Unterabbilds ist sein Name in mkosi.images/ (ohne die Endung
              .conf). Der Name des Abbilds auf oberster Ebene lautet main. Der
              Haupteinsatzfall ist die Moglichkeit, eine gemeinsame
              Konfiguration zu verwenden, die sowohl vom Abbild auf der
              obersten Ebene als auch allen Unterabbildern eingebunden werden
              kann, indem die allgemeingultigen Einstellungen durch einen
              Treffer Image=main gesteuert werden.

       Diese Tabelle zeigt, welche Ubereinstimmer Globs und machtige
       Vergleiche unterstutzen sowie den Vorgabewert, gegen den uberpruft
       wird, falls zum Zeitpunkt des Einlesens der Konfigurationsdatei kein
       Wert bereitgestellt wurde:

       Ubereinstimmer           Globs   Umfangreiche   Vorgabe
                                        Vergleiche
       ---------------------------------------------------------------------------------------------
       Profiles=                no      no             Ubereinstimmung schlagt fehl
       Distribution=            no      no             Ubereinstimmung mit Distribution des
                                                       Wirtsystems
       Release=                 no      no             Ubereinstimmung mit Veroffentlichung des
                                                       Wirtsystems
       Architecture=            no      no             Ubereinstimmung mit Architektur des
                                                       Wirtsystems
       PathExists=              no      no             n.Z.
       ImageId=                 yes     no             Ubereinstimmung schlagt fehl
       ImageVersion=            no      yes            Ubereinstimmung schlagt fehl
       Bootable=                no      no             Ubereinstimmung mit automatischer
                                                       Funktionalitat
       Format=                  no      no             Ubereinstimmung mit Standardformat
       SystemdVersion=          no      yes            n.Z.
       BuildSources=            no      no             Ubereinstimmung schlagt fehl
       HostArchitecture=        no      no             n.Z.
       ToolsTreeDistribution=   no      no             Ubereinstimmung mit dem
                                                       Ruckfall-Werkzeugbaum der Distribution
                                                       (siehe ToolsTreeDistribution= in [Build])
       ToolsTreeRelease=        no      no             Ubereinstimmung mit
                                                       Standard-Werkzeugbaum-Veroffentlichung
       Environment=             no      no             n.Z.
       Image=                   no      no             n.Z.

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

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

              Die eingebauten Konfigurationen fur die Vorgabe-Initrd, den
              Vorgabe-Werkzeugbaum, das standardmassige
              Virtuelle-Maschinenabbild und die standardmassige UKI-Erganzung
              von mkosi konnen eingebunden werden, indem der wortliche Wert
              mkosi-initrd, mkosi-tools, mkosi-vm bzw. mkosi-addon eingebunden
              wird.

              Beachten Sie: Einbindenamen, die mit entweder dem wortlichen
              mkosi- oder contrib- beginnen, sind fur die Verwendung durch
              mkosi selbst reserviert.

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

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

              Wird diese Einstellung fur das >>Hauptabbild<< angegeben, legt
              sie fest, welche Unterabbilder gebaut werden sollen. Siehe den
              Abschnitt BAU MEHRERER ABBILDER fur weitere Informationen.

       MinimumVersion=, --minimum-version=
              Die minimale Version von mkosi, die zum Bau dieser Konfiguration
              benotigt wird. Falls mehrfach angegeben, wird die hochste
              festgelegte Version verwandt.

              Die minimale Version kann auch als ein Git-Commit-Hash
              festgelegt werden, wenn ihr commit: vorangestellt wird. In
              diesem Fall muss mkosi aus einem git(1)-Depot heraus aufgerufen
              werden und der angegeben Git-Commit-Hash muss ein Vorfahre des
              aktuell abgerufenen Git-Commits in dem Depot sein, aus dem mkosi
              heraus aufgerufen wird.

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

       PassEnvironment=, --pass-environment=
              Akzeptiert eine Liste von durch Leerzeichen getrennten
              Umgebungsvariablennamen. Beim Bau mehrerer Abbilder werden die
              aufgefuhrten Umgebungsvariablen an jedes einzelne Unterabbild
              ubergeben, als ob sie >>universelle<< Einstellungen waren. Siehe
              den Abschnitt BAU MEHRERER ABBILDER fur weitere Informationen.

   Abschnitt [UKIProfile]
       Der Abschnitt UKIProfile kann in UKI-Profil-Konfigurationsdateien
       verwandt werden, die an die Einstellung UnifiedKernelImageProfiles=
       ubergeben werden. Die folgenden Einstellungen konnen im Abschnitt
       UKIProfile festgelegt werden:

       Profile=
              Der Inhalt des Abschnitts .profile des UKI-Profils. Akzeptiert
              eine Liste von Schlussel/Wert-Paaren, getrennt durch =. Der
              Schlussel ID= muss angegeben werden. Siehe die Spezifikation
              <https://uapi-group.org/specifications/specs/unified_kernel_image/#multi-profile-ukis>
              fur eine vollstandige Liste aller moglichen Schlussel.

       Cmdline=
              Zusatzliche Kernelbefehlszeilenoptionen fur das UKI-Profil.
              Akzeptiert eine durch Leerzeichen begrenzte Liste von
              zusatzlichen Kernelbefehlszeilenargumenten. Beachten Sie, dass
              der letztendliche Abschnitt .cmdline eine Kombination des
              grundlegenden Abschnitts .cmdline und der mit dieser Option
              festgelegten zusatzlichen Kernelbefehlszeilenargumente ist.

       SignExpectedPcr=
              Signiert erwartete PCR-Messungen fur dieses UKI-Profil.
              Akzeptiert einen logischen Wert. Standardmassig aktiviert.

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

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

       Es gibt auch von Einstellungen unabhangige Kennzeichner:

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

       Schliesslich gibt es Kennzeichner, die von einer Einstellung abgeleitet
       werden:

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

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

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

       Die folgende Tabelle zeigt Beispielwerte fur die oben aufgefuhrten
       Verzeichniskennzeichner:

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

   Unterstutzte Distributionen
       Fur die folgenden Distributionen konnen Abbilder zur Installation
       erstellt werden:

       o Fedora Linux

       o Debian

       o Kali Linux

       o Ubuntu

       o Arch Linux

       o openSUSE

       o Mageia

       o CentOS

       o RHEL

       o RHEL UBI

       o OpenMandriva

       o Rocky Linux

       o Alma Linux

       o Azure Linux

       o postmarketOS

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

       Theoretisch kann jede Distribution auf dem Wirtrechner zum Bau der
       Abbilder, die jede andere Distribution enthalten konnen, verwandt
       werden, solange die notwendigen Werkzeuge verfugbar sind. Insbesondere
       jede Distribution, die apt(8) paketiert, kann zum Bau von Abbildern von
       Debian, Kali oder Ubuntu verwandt werden. Jede Distribution, die dnf(8)
       paketiert, kann zum Bau von Abbildern von jeder rpm(8)-basierten
       Distribution verwandt werden. Jede Distribution, die pacman(8)
       paketiert, kann zum Bau von Abbildern von Arch Linux verwandt werden.
       Jede Distribution, die zypper(8) paketiert, kann zum Bau von Abbildern
       von openSUSE verwandt werden. Andere Distributionen und
       Bauautomatisierungswerkzeuge fur eingebettete Linux-Systeme wie
       Buildroot, OpenEmbedded und Yocto Project konnen durch Auswahl der
       Distribution custom und der Befullung des Rootfs mit einer Kombination
       von Basisbaumen, Gerustbaumen und Vorbereitungsskripten verwandt
       werden.

       Derzeit paketiert Fedora Linux alle relevanten Werkzeuge seit Fedora
       28.

       Beachten Sie, dass Sie Abbilder fur RHEL nur auf einem Wirtsystem bauen
       konnen, das uber ein RHEL-Abonnement verfugt (das beispielsweise mit
       dem subscription-manager eingerichtet wurde), wenn Sie keinen
       angepassten Spiegel verwenden.

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

       1. Wertet Befehlszeilen-Optionen aus

       2. Wertet Konfigurationsdateien aus

       3. Fuhrt Konfigurationsskripte aus (mkosi.configure)

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

       5. Trennt den Einhangenamensraum ab

       6. Hangt die folgenden Verzeichnisse schreibgechutzt neu ein, falls sie
          existieren:

           o /usr

           o /etc

           o /opt

           o /srv

           o /boot

           o /efi

           o /media

           o /mnt

       Fuhren Sie dann fur jedes Abbild die folgenden Schritte aus:

        1. Kopieren von Sandbox-Baumen in den Arbeitsbereich

        2. Synchronisieren der Depot-Metadaten des Paketverwalters

        3. Ausfuhren der Synchronisierungsskripte (mkosi.sync)

        4. Kopieren der Basisbaume (--base-tree=) in das Abbild

        5. Wiederverwenden eines zwischengespeicherten Abbilds, falls
           verfugbar

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

        7. Kopieren von Gerustbaumen (mkosi.skeleton) in das Abbild

        8. Installieren der Distribution und Pakete in das Abbild

        9. Ausfuhren der Vorbereitungsskripte auf dem Abbild mit dem Argument
           final (mkosi.prepare)

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

       11. Ausfuhren der Vorbereitungsskripte auf der Uberlagerung mit dem
           Argument build, falls irgendwelche Bauskripte konfiguriert sind
           (mkosi.prepare)

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

       13. Ausfuhren der Bauskripte auf dem Abbild & der Uberlagerung, falls
           irgendwelche Bauskripte konfiguriert sind (mkosi.build)

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

       15. Kopieren der Bauskripteausgaben in das Abbild

       16. Kopieren der zusatzlichen Baume in das Abbild (mkosi.extra)

       17. Ausfuhren der Post-Install-Skripte (mkosi.postinst)

       18. Schreiben der fur Ssh=, Autologin= und MakeInitrd= benotigten
           Konfigurationsdateien

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

       20. Ausfuhren von systemd-sysusers(8)

       21. Ausfuhren von systemd-tmpfiles(8)

       22. Ausfuhren von systemctl preset-all

       23. Ausfuhren von depmod(8)

       24. Ausfuhren von systemd-firstboot(1)

       25. Ausfuhren vom systemd-hwdb(8)

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

       27. Ausfuhren von SELinux-Neumarkierung, falls eine SELinux-Richtlinie
           installiert ist

       28. Ausfuhren von Finalisierungskripten (mkosi.finalize)

       29. Erstellen des Vereinigten Kernelabbildes, falls so konfiguriert

       30. Erstellen des finalen Ausgabeformats

       31. Ausfuhren der Post-Ausgabe-Skripte (mkosi.postoutput)

SKRIPTE
       Um die Anpassung von Abbildern zu erlauben, die nicht mittels der in
       mkosi eingebauten Funktionalitaten implementiert werden konnen,
       unterstutzt mkosi die Ausfuhrung von Skripten zu verschiedenen
       Zeitpunkten wahrend des Abbildbauprozesses, die das Abbild nach Bedarf
       anpassen konnen. Skripte werden auf dem Wirtsystem als Root (entweder
       als echtem Root oder Root innerhalb des Benutzernamensraums, den mkosi
       bei dem unprivilegierten Aufruf erstellte) mit einer angepassten
       Umgebung ausgefuhrt, um die Veranderung des Abbildes zu erleichtern.
       Fur jedes Skript werden die konfigurierten Bauquellen (BuildSources=)
       in das aktuelle Arbeitsverzeichnis eingehangt, bevor das Skript im
       aktuellen Arbeitsverzeichnis ausgefuhrt wird. $SRCDIR wird so gesetzt,
       dass es auf das aktuelle Arbeitsverzeichnis zeigt. Die folgenden
       Skripte werden unterstutzt:

       o Falls mkosi.configure (ConfigureScripts=) existiert, wird es vor dem
         Bau des Abbilds ausgefuhrt. Dieses Skript kann zur dynamischen
         Veranderung der Konfiguration verwandt werden. Es empfangt die
         Konfiguration serialisiert als JSON auf der Standardeingabe und
         sollte die veranderte Konfiguration serialisiert auf der
         Standardausgabe ausgeben. Beachten Sie, dass dieses Skript nur
         ausgefuhrt wird, wenn das Abbild gebaut oder gestartet wird
         (Unterbefehle build, vm, boot und shell). Falls ein
         Vorgabe-Werkzeugbaum konfiguriert ist, wird er vor der Ausfuhrung des
         Konfigurationsskriptes gebaut und das Konfigurationsskript wird mit
         vorhandenen Werkzeugen ausgefuhrt. Das bedeutet auch, dass die durch
         das Konfigurationsskript vorgenommenen Anderungen nicht in der
         Ausgabe von summary sichtbar sein werden.

       o Falls mkosi.sync (SyncScripts=) existiert, wird es vor dem Bau des
         Abbildes ausgefuhrt. Dieses Skript kann zur Aktualisierung
         verschiedener, wahrend des Baus verwandter Quellen eingesetzt werden.
         Ein Anwendungsszenario ist die Ausfuhrung von git pull in
         verschiedenen Quelldepots vor dem Bau des Abbildes. Insbesondere gilt
         die Einstellung BuildSourcesEphemeral= nicht fur
         Synchronisationsskripte, was bedeutet, dass Synchronisationsskripte
         zur Aktualisierung von Bauquellen verwandt werden konnen, selbst wenn
         BuildSourcesEphemeral= aktiviert ist.

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

       o Falls mkosi.build (BuildScripts=) existiert, wird es ausgefuhrt, wenn
         die Bauuberlagerung oberhalb des Wurzelverzeichnisses des Abbildes
         eingehangt wurde. Bei der Ausfuhrung der Bauskripte zeigt $DESTDIR
         auf ein Verzeichnis, in dem die Skripte alle erstellten Dateien
         ablegen sollen, die dann im Abbild landen sollen. Beachten Sie, dass
         die Bausysteme, die auf make(1),automake(1) und meson(1) basieren, im
         Allgemeinen $DESTDIR berucksichtigen und damit der Bau von
         source-Baumen sehr naturlich vonstatten geht. Nach der Ausfuhrung des
         Bauskripts wird der Inhalt von $DESTDIR in das Abbild kopiert.

       o Falls mkosi.postinst (PostInstallationScripts=) existiert, wird es
         nach der Installation der (optionalen) Bau- und Zusatzbaume
         ausgefuhrt. Dieses Skript kann zur Veranderung des Abbilds ohne jede
         Beschrankung verwandt werden, nachdem alle Softwarepakete und
         Bauquellen installiert wurden.

       o Falls mkosi.finalize (FinalizeScripts=) existiert, wird es als
         letzter Schritt der Vorbereitung des Abbildes ausgefuhrt.

       o Falls mkosi.postoutput (PostOutputScripts=) existiert, wird es direkt
         nach der Erstellung aller Ausgabedateien ausgefuhrt, bevor sie
         abschliessend in das Ausgabeverzeichnis geschoben werden. Dies kann
         zur Erstellung zusatzlicher oder alternativer Ausgaben verwandt
         werden, z.B. SHA256FILES oder SBOM-Listen.

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

       o Falls mkosi.version existiert und ausfuhrbar ist, wird sie wahrend
         der Auswertung der Konfiguration ausgefuhrt und fullt ImageVersion=
         mit der Ausgabe auf der Standardausgabe. Dies kann fur externe
         Versionverfolgung verwandt werden, z.B. mit git describe oder date
         '+%Y-%m-%d'. Beachten Sie, dass dieses Skript auf dem Hauptsystem
         ohne irgendeine Sandbox ausgefuhrt wird.

       o Falls mkosi.version existiert und ausfuhrbar ist, wird sie wahrend
         der Auswertung der Konfiguration ausgefuhrt und fullt RootPassword=
         mit der Ausgabe auf der Standardausgabe. Dies kann zur Erstellung
         eines zufalligen Passworts verwandt werden. Um sich daran zu
         erinnern, kann es auf der Standardfehlerausgabe ausgegeben werden
         oder durch Lesen von $MKOSI_CONFIG in einem anderen Skript
         (z.B. mkosi.postoutput) ermittelt werden. Beachten Sie, dass dieses
         Skript auf dem Hauptsystem ohne irgendeine Sandbox ausgefuhrt wird.

       Falls ein Skript die Erweiterung .chroot verwendet, wird mkosi ein
       chroot(8) mittels mkosi-chroot (siehe unten) durchfuhren, bevor das
       Skript ausgefuhrt wird. Falls beispielsweise mkosi.postinst.chroot
       existiert, wird mkosi ein chroot(8) in das Abbild durchfuhren und das
       Skript als Postinstallationsskript ausfuhren.

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

       o mkosi.sync.d,

       o mkosi.prepare.d,

       o mkosi.build.d,

       o mkosi.postinst.d,

       o mkosi.finalize.d,

       o mkosi.postoutput.d und

       o mkosi.clean.d.

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

       Von mkosi ausgefuhrte Skripte erhalten die folgenden
       Umgebungsvariablen:

       o $ARCHITECTURE enthalt die Architektur aus der Einstellung
         Architecture=. Falls Architecture= nicht gesetzt ist, wird es die
         native Architektur der Wirtmaschine erhalten. Siehe die Dokumentation
         von Architecture= fur mogliche Werte dieser Variablen.

       o $QEMU_ARCHITECTURE enthalt die Architektur aus $ARCHITECTURE in dem
         von qemu verwandten Format. Nutzlich, um das Programm von Qemu zu
         finden (qemu-system-$QEMU_ARCHITECTURE).

       o $EFI_ARCHITECTURE enthalt die Architektur aus $ARCHITECTURE in dem
         von UEFI verwandten Format. Auf Architekturen, die UEFI nicht
         unterstutzen, ist sie nicht gesetzt.

       o $DISTRIBUTION enthalt die Distribution aus der Einstellung
         Distribution=.

       o $RELEASE enthalt die Veroffentlichung aus der Einstellung Release=.

       o $DISTRIBUTION_ARCHITECTURE enthalt die Architektur aus $ARCHITECTURE
         in dem von der konfigurierten Distribution verwandten Format.

       o $PROFILES enthalt die Profile aus der Einstellung Profiles= als eine
         Kommata-getrennte Zeichenkette.

       o $CACHED wird auf 1 gesetzt, falls ein zwischengespeichertes Abbild
         verfugbar ist, ansonsten auf 0.

       o $CHROOT_SCRIPT enthalt den Pfad zu dem laufenden Skript, relativ zum
         Wurzelverzeichnis des Abbildes. Der primare Anwendungsfall fur diese
         Variable ist in der Kombination mit dem Skript mkosi-chroot. Siehe
         die nachfolgende Beschreibung von mkosi-chroot fur weitere
         Informationen.

       o $SRCDIR enthalt den Pfad zu dem Verzeichnis, aus dem mkosi heraus
         aufgerufen wurde, wobei alle konfigurierten Bauquellen oben auf
         eingehangt sind. $CHROOT_SRCDIR enthalt den Wert, den $SRCDIR nach
         Aufruf von mkosi-chroot haben wird.

       o $BUILDDIR ist nur definiert, falls mkosi.builddir existiert und auf
         das zu verwendende Bauverzeichnis zeigt. Dies ist fur alle
         Bausysteme, die Bauen ausserhalb des Bau-Baums unterstutzen,
         nutzlich, um bereits gebaute Artefakte von einem vorherigen Durchlauf
         wiederzuverwenden. $CHROOT_BUILDDIR enthalt den Wert, den $BUILDDIR
         nach Aufruf von mkosi-chroot haben wird.

       o $DESTDIR ist ein Verzeichnis, in das samtliche installierte und durch
         ein Bauskript erstellte Software abgelegt werden kann. Diese Variable
         wird nur gesetzt, wenn ein Bauskript ausgefuhrt wird. $CHROOT_DESTDIR
         enthalt den Wert, den $DESTDIR nach Aufruf von mkosi-chroot haben
         wird.

       o $OUTPUTDIR zeigt auf das Vorbereitungsverzeichnis, das zum Speichern
         der wahrend des Baus erstellten Bauartefakte verwandt wird.
         $CHROOT_OUTPUTDIR enthalt den Wert, den $OUTPUTDIR nach Aufruf von
         mkosi-chroot haben wird.

       o $PACKAGEDIR zeigt auf das Verzeichnis, das das lokale Paketdepot
         enthalt. Bauskripte konnen weitere Pakete zum lokalen Depot
         hinzufugen, indem sie Pakete nach $PACKAGEDIR schreiben.

       o $ARTIFACTDIR zeigt auf das Verzeichnis, das zur Weitergabe von
         Bauartefakten verwandt wird, die wahrend des Baus erstellt wurden und
         die fur die Verwendung durch Mkosi bereitgestellt werden. Dies ist
         ahnlich zu PACKAGEDIR, ist aber fur Artefakte gedacht, die keine vom
         Paketverwalter verstandenen Pakete sein konnen, z.B. Initrds, die
         durch andere Initrd-Generatoren neben Mkosi erstellt wurden.
         Bauskripte konnen weitere Artekfakte zu dem Verzeichnis hinzufugen,
         indem sie sie in $ARTIFACTDIR ablegen. Dateien in diesem Verzeichnis
         sind fur den aktuellen Bau verfugbar und werden nicht wie die Inhalte
         von $OUTPUTDIR herauskopiert.

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

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

         o io.mkosi.initrd: Alle Dateien in diesem Verzeichnis werden als
           Initrds verwandt und in lexikographischer Reihenfolge
           aneinandergehangt.

         Es wird empfohlen, dass Benutzer von $ARTIFACTDIR Dinge fur ihre
         eigene Verwendung in ahnlichen Verzeichnissen mit eigenem Namensraum
         ablegen, z.B. lokal.mein.Namensraum.

       o $BUILDROOT ist das Wurzelverzeichnis des gebauten Abbilds, optional
         mit der Bauuberlagerung oben auf eingehangt, abhangig vom Skript, das
         ausgefuhrt wird.

       o $WITH_DOCS ist entweder 0 oder 1, abhangig davon, ob der Bau eines
         Abbildes mit oder ohne Dokumentation angefordert wurde
         (WithDocs=yes). Ein Bauskript sollte die Installation samtlicher
         Paketdokumentationen nach $DESTDIR unterdrucken, falls $WITH_DOCS auf
         0 gesetzt ist.

       o $WITH_TESTS ist entweder 0 oder 1, abhangig davon, ob ein Bau mit
         oder ohne laufende Test-Suite angefordert wurde (WithTests=no). Ein
         Bauskript sollte die Ausfuhrung jeder Einheiten- oder
         Integrationstests unterlassen, falls $WITH_TESTS auf 0 gesetzt ist.

       o $WITH_NETWORK ist entweder 0 oder 1, abhangig davon, ob ein Bau mit
         oder ohne Netzwerkanbindung ausgefuhrt wird (WithNetwork=no). Ein
         Bauskript sollte samtliche Netzwerkkommunikation unterlassen, falls
         $WITH_NETWORK auf 0 gesetzt ist.

       o $SOURCE_DATE_EPOCH wird definiert falls erbeten
         (SourceDateEpoch=TIMESTAMP, Environment=SOURCE_DATE_EPOCH=TIMESTAMP
         oder die Umgebungsvariable auf dem Wirtsystem $SOURCE_DATE_EPOCH).
         Dies ist nutzlich, um Bauten wiederholbar zu machen. Siehe
         SOURCE_DATE_EPOCH
         <https://reproducible-builds.org/specs/source-date-epoch/>  zu
         weiteren Informationen.

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

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

       o $IMAGE_ID enthalt den Kennzeichner aus der Einstellung ImageId= oder
         --image-id=.

       o $IMAGE_VERSION enthalt die Version aus der Einstellung ImageVersion=
         oder --image-version=.

       o $MKOSI_DEBUG ist entweder 0 oder 1, abhangig davon, ob
         Fehlersuchausgabe aktiviert ist.

       In dieser Tabelle konnen Sie ersehen, welches Skript welche
       Umgebungsvariable erhalt:

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

       Zusatzlich werden bei der Skript-Ausfuhrung einige Skripte uber den
       $PATH verfugbar gemacht, um haufige Anwendungsfalle zu vereinfachen.

       o mkosi-chroot: Dieses Skript wird ein chroot(8) in das Abbild
         durchfuhren und den angegebenen Befehl ausfuhren. Zusatzlich zum
         chroot(8) in das Abbild wird es auch verschiedene Dateien und
         Verzeichnisse in das Abbild einhangen ($SRCDIR, $DESTDIR, $BUILDDIR,
         $OUTPUTDIR, $CHROOT_SCRIPT) und die entsprechenden Umgebungsvariablen
         andern, um auf die Orte innerhalb des Abbilds zu zeigen. Es wird auch
         APIVFS-Dateisysteme einhangen (/proc, /dev, <?>), um sicherzustellen,
         dass in der Chroot ausgefuhrte Skripte und Werkzeuge korrekt
         funktionieren. Falls erbeten leitet es auch /etc/resolv.conf vom Wirt
         in die Chroot weiter, so dass DNS-Auflosung innerhalb der Chroot
         funktioniert. Nachdem sich der Befehl mkosi-chroot beendet, werden
         verschiedene Einhangepunkte bereinigt.

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

                mkosi-chroot ls <?>

         Um das gesamte Skript innerhalb des Abbildes auszufuhren, fugen Sie
         die Endung .chroot zu dem Namen hinzu (mkosi.build.chroot anstatt
         mkosi.build, usw.).

       o Fur alle unterstutzten Paketverwalter (dnf, rpm(8), apt(8), dpkg(1),
         pacman(8), zypper(8)) werden Skripte mit dem gleichen Namen in $PATH
         abgelegt, um sicherzustellen, dass diese Befehle auf dem
         Wurzelverzeichnis des Abbildes mit der vom Benutzer bereitgestellten
         Konfiguration anstelle auf dem Wirtsystem agieren. Dies bedeutet,
         dass Sie aus einem Skript z.B. dnf install vim durchfuhren konnen, um
         Vim in das Abbild zu installieren.

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

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

       o Beim Aufruf ausserhalb des Abbildes werden useradd(8) und groupadd(8)
         automatisch mit --root=$BUILDROOT aufgerufen.

       Wenn Skripte ausgefuhrt werden, werden alle noch schreibbaren
       Verzeichnisse schreibgeschutzt gemacht (/home, /var, /root, <?>) und
       nur die minimale Menge an Verzeichnissen, die schreibbar bleiben
       mussen, bleiben schreibbar. Dies dient dazu sicherzustellen, dass die
       Skripte nicht das Wirtsystem durcheinander bringen konnen, wenn mkosi
       als Root ausgefuhrt wird.

       Beachten Sie, dass alle Quellverzeichnisse bei der Ausfuhrung der
       Skripte fluchtig werden, was bedeutet, das alle Anderungen an den
       Quellverzeichnissen wahrend der Ausfuhrung der Skripte verworfen
       werden, wenn die Skripte mit der Ausfuhrung fertig sind. Verwenden Sie
       die Ausgabe-, Bau- oder Zwischenspeicherverzeichnisse, falls Sie Daten
       zwischen Bauten weiternutzen wollen.

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

       o Das Verzeichnis mkosi.skeleton/ oder das Archiv mkosi.skeleton.tar
         konnen zum Einfugen von Dateien in das Abbild verwandt werden. Die
         Dateien werden vor der Installation der Distributionspakete in das
         Abbild kopiert. Dies ermoglicht die fruhe Bereitstellung von Dateien,
         beispielsweise zur Konfiguration des Paketverwalters oder um
         Systemd-Voreinstellungen zu setzen.

         Bei der Verwendung des Verzeichnisses werden Dateieigentumerschaften
         nicht erhalten: alle kopierten Dateien werden root gehoren. Um
         Eigentumerschaften beizubehalten, verwenden Sie ein Tar-Archiv.

       o Das Verzeichnis mkosi.extra/ oder das Archiv mkosi.extra.tar konnen
         zum Einfugen zusatzlicher Dateien in das Abbild verwandt werden,
         erganzend zu den Inhalten der Distributionen. Sie sind ahnlich zu
         mkosi.skeleton/ und mkosi.skeleton.tar, aber die Dateien werden in
         den Verzeichnisbaum des Abbildes kopiert, nachdem das Betriebssystem
         installiert wurde.

         Bei der Verwendung des Verzeichnisses werden Dateieigentumerschaften
         nicht erhalten: alle kopierten Dateien werden root gehoren. Um
         Eigentumerschaften beizubehalten, verwenden Sie ein Tar-Archiv.

       o Das Verzeichnis mkosi.sandbox/ oder das Archiv mkosi.sandbox.tar
         konnen zur Konfiguration des Paketverwalters verwandt werden, ohne
         dass diese Dateien in das Abbild eingefugt werden. Falls die Dateien
         in das Abbild eingefugt werden sollten, sollte stattdessen
         mkosi.skeleton/ und mkosi.skeleton.tar verwandt werden.

         Bei der Verwendung des Verzeichnisses werden Dateieigentumerschaften
         nicht erhalten: alle kopierten Dateien werden root gehoren. Um
         Eigentumerschaften beizubehalten, verwenden Sie ein Tar-Archiv.

       o Die Nspawn-Einstellungsdatei mkosi.nspawn wird an den gleichen Ort
         wie die Ausgabeabbilddatei kopiert, falls sie existiert. Dies ist
         nutzlich, da Nspawn nach Einstellungsdateien neben den von ihm
         gestarteten Abbildern nach zusatzlichen
         Container-Laufzeiteinstellungen sucht.

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

       o Das Verzeichnis mkosi.builddir/ wird automatisch als Bauverzeichnis
         ausserhalb des Quellbaums verwandt, falls es existiert und falls die
         Baubefehle in den Skripten mkosi.build dies unterstutzen.
         Insbesondere wird dieses Verzeichnis in den Bau-Container eingehangt
         und die Umgebungsvariable $BUILDDIR darauf gesetzt, wenn die
         Bauskripte aufgerufen werden. Ein Bauskript kann dann dieses
         Verzeichnis als Bauverzeichnis verwenden, fur automake(1)- oder
         ninja(1)-artige Bauten ausserhalb des Quellbaums. Dies beschleunigt
         den Bau deutlich, insbesondere wenn mkosi im inkrementellen Modus
         (-i) verwandt wird; nicht nur das Abbild und die Bau-Uberlagerung,
         sondern auch der Baubaum wird zwischen nachfolgenden Aufrufen
         wiederverwandt. Beachten Sie, dass die Umgebungsvariable $BUILDDIR
         nicht gesetzt wird, falls dieses Verzeichnis nicht existiert und es
         den Bauskripten uberlassen bleibt zu entscheiden, ob im Quellbaum
         oder ausserhalb des Quellbaums gebaut und welches Verzeichnis
         verwandt wird.

       o Die Datei mkosi.rootpw kann zur Bereitstellung des Passworts fur den
         Benutzer root des Abbildes verwandt werden. Falls dem Passwort
         hashed: vorangestellt ist, wird es als bereits gehashtes Passwort
         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).

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

       o Die Dateien mkosi.crt und mkosi.key enthalten ein X.509-Zertifikat
         und den privaten PEM-Schlussel, die verwandt werden, wenn Signaturen
         benotigt werden (UEFI SecureBoot, Verity, <?>).

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

       o Das Verzeichnis mkosi.credentials/ wird als Quelle zusatzlicher
         Zugangsberechtigungen ahnlich zu der Option Credentials= verwandt.
         Fur jede Datei in dem Verzeichnis wird der Dateiname als
         Zugangsberechtigungsname verwandt und die Dateiinhalte werden der
         Zugangsberechtigungswert oder, falls die Datei ausfuhrbar ist, wird
         mkosi die Datei ausfuhren und die Ausgabe auf der Standardausgabe
         wird als Zugangsberechtigungswert verwandt. Die Ausgabe auf der
         Standardfehlerausgabe wird ignoriert. Mit Credentials= konfigurierte
         Zugangsberechtigungen haben Vorrang vor Dateien in mkosi.credentials.

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

         00-esp.conf (falls ein startfahiges Abbild erstellt wird):

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

         05-bios.conf (falls ein BIOS-startfahiges Abbild erstellt wird):

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

         10-root.conf

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

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

       Alle diese Dateien sind optional.

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

ZWISCHENSPEICHERUNG
       mkosi unterstutzt drei verschiedene Zwischenspeicher zur Beschleunigung
       von wiederholenden Neubauten von Abbildern. Konkret:

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

       2. Falls mittels --incremental= der inkrementelle Modus aktiviert ist,
          werden zwischengespeicherte Kopien des abschliessenden Abbildes und
          Bauuberlagerungen erstellt, direkt vor dem Hereinkopieren der
          Bauquellen (fur Bau-Uberlagerungen) oder vor dem Hereinkopieren von
          durch mkosi.build erstellten Artefakten (fur das abschliessende
          Abbild). Diese Art der Zwischenspeicherung erlaubt das Umgehen des
          zeitaufwandigen 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 regelmassig andern. Beachten Sie, dass dieser
          Zwischenspeicher manuell geleert werden muss: immer, wenn die
          Paketliste geandert wird, mussen die zwischengespeicherten Abbilder
          manuell vor dem nachsten Neubau mittels des Schalters -f entfernt
          werden.

       3. Schliesslich konnen zwischen mehreren Bauten das Verzeichnis der
          Bauartefakte mittels des Verzeichnisses mkosi.builddir/ gemeinsam
          verwandt werden. Dieses Verzeichnis ermoglicht es Systemen wie
          Meson, bereits kompilierte Quellen aus einem vorherigen Bau zu
          verwenden und damit den Bauprozess eines Bauskriptes mkosi.build zu
          beschleunigen.

       Der Paketzwischenspeicher und der inkrementelle Modus sind in jedem
       Fall nutzlich. Der abschliessende Zwischenspeicher ist nur anwendbar,
       wenn mkosi mit einem Quellbaum und Bauskript verwandt wird. Sind alle
       drei zusammen aktiviert, dann ist die Durchlaufzeit fur Abbildbauten
       minimal, da nur die Quelldateien neu kompiliert werden mussen.

WERKZEUGBAUME
       Werkzeugbaume sind sekundare Abbilder, die mkosi zum Bau der
       tatsachlichen Abbilder verwenden kann. Dies ist nutzlich, damit Bauten
       von Abbildern reproduzierbarer werden, aber erlaubt auch den Einsatz
       neuerer Werkzeuge, die in der Distribution des Hauptsystems, auf dem
       mkosi lauft, noch nicht verfugbar sind.

       Werkzeugbaume konnen mittels der Option ToolsTree= oder dem Verzeichnis
       mkosi.tools bereitgestellt oder automatisch durch mkosi gebaut werden,
       falls auf ToolsTree=yes gesetzt. In den meisten Anwendungsfallen reicht
       das Setzen hiervon aus, um die Vorgabewerkzeugbaume zu verwenden und
       der Einsatz eines Werkzeugbaums wird empfohlen.

       Vollstandig angepasste Werkzeugbaume konne wie jedes andere
       mkosi-Abbild gebaut werden, aber mkosi stellt ein eingebauten
       Einbindung bereit, die die Vorgabe-Werkzeugbaumpakete bereitstellt:

              mkosi --include=mkosi-tools --format=directory

       Werkzeugbaume, einschliesslich von Vorgabewerkzeugbaumen, konnen
       mittels der verschiedenen Variablen ToolsTree*= sowie der
       Konfigurationsdatei oder dem Konfigurationsverzeichnis mkosi.tools.conf
       weiter angepasst werden. Das Ausgabeformat fur Werkzeugbaume kann
       derzeit uber die Konfigurationsdateien nicht geandert werden.

       Die nachfolgende Tabelle zeigt, fur welche Distributionen
       Standard-Werkzeugbaumpakete definiert sind und welche Pakete in diese
       Standardwerkzeugbaume aufgenommen werden:

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

BAUEN MEHRERER ABBILDER
       Falls das Verzeichnis mkosi.images/ existiert, wird mkosi einzelne
       Unterabbild-Konfigurationen daraus laden und jede davon bauen.
       Abbildkonfigurationen konnen entweder Verzeichnisse sein, die
       mkosi-Konfigurationsdateien enthalten, oder regulare Dateien mit der
       Erweiterung .conf.

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

       Wenn Abbilder definiert sind, wird mkosi zuerst die
       Hauptabbildkonfiguration (Konfiguration ausserhalb des Verzeichnisses
       mkosi.images/) einlesen, gefolgt von der Abbild-spezifischen
       Konfiguration.

       Fur den Standard-Werkzeugbaum und das Hauptabbild gelten mehrere
       >>multiverselle<< Einstellungen, die nicht getrennt vom Hauptabbild
       konfiguriert werden konnen:

       o RepositoryKeyCheck=

       o RepositoryKeyFetch=

       o SourceDateEpoch=

       o CacheOnly=

       o WorkspaceDirectory=

       o PackageCacheDirectory=

       o BuildSources=

       o BuildSourcesEphemeral=

       o ProxyClientCertificate=

       o ProxyClientKey=

       o ProxyExclude=

       o ProxyPeerCertificate=

       o ProxyUrl=

       Mehrere >>allgemeine<< Einstellungen gelten fur das Hauptabbild und
       seine Unterabbilder und konnen fur Unterabbilder nicht separat
       konfiguriert werden. Die folgenden Einstellungen sind allgemein und
       konnen in Unterabbildern nicht konfiguriert werden:

       o Architecture=

       o BuildDirectory=

       o CacheDirectory=

       o Distribution=

       o ExtraSearchPaths=

       o Incremental=

       o LocalMirror=

       o Mirror=

       o OutputDirectory=

       o OutputMode=

       o PackageDirectories=

       o Release=

       o RepartOffline=

       o Repositories=

       o SandboxTrees=

       o ToolsTree=

       o ToolsTreeCertificates=

       o UseSubvolumes=

       o SecureBootCertificate=

       o SecureBootCertificateSource=

       o SecureBootKey=

       o SecureBootKeySource=

       o VerityCertificate=

       o VerityCertificateSource=

       o VerityKey=

       o VerityKeySource=

       o VolatilePackageDirectories=

       o WithNetwork=

       o WithTests

       Es gibt auch Einstellungen, die an Unterabbilder weitergegeben werden,
       aber ausser Kraft gesetzt werden konnen. Fur 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, konnen dort aber ausser
       Kraft gesetzt werden:

       o Profiles=

       o ImageId=

       o ImageVersion=

       o SectorSize=

       o CacheKey=

       o BuildKey=

       o CompressLevel=

       o SignExpectedPcrKey=

       o SignExpectedPcrKeySource=

       o SignExpectedPcrCertificate=

       o SignExpectedPcrCertificateSource=

       Zusatzlich gibt es verschiedene Einstellungen, die nur in dem
       Hauptabbild konfiguriert werden konnen, aber nicht an Unterabbilder
       weitergegeben werden:

       o MinimumVersion=

       o PassEnvironment=

       o ToolsTreeDistribution=

       o ToolsTreeRelease=

       o ToolsTreeProfiles=

       o ToolsTreeMirror=

       o ToolsTreeRepositories=

       o ToolsTreeSandboxTrees=

       o ToolsTreePackages=

       o ToolsTreePackageDirectories=

       o History=

       o Jede Einstellung in dem Abschnitt [Runtime]

       Abbilder konnen sich auf Ausgaben von Abbildern beziehen, von denen sie
       abhangen. Insbesondere wird mkosi fur die folgenden Optionen nur
       prufen, ob die Eingabe genau vor dem Bau des Abbildes existiert:

       o BaseTrees=

       o ExtraTrees=

       o Initrds=

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

       Ein gutes Beispiel, wie mehrere Abbilder gebaut werden konnen, kann in
       dem Depot von Systemd
       <https://github.com/systemd/systemd/tree/main/mkosi/mkosi.images>
       gefunden werden.

UMGEBUNGSVARIABLEN
       o $MKOSI_LESS setzt Optionen fur less(1) ausser Kraft, wenn es durch
         mkosi zur seitenweisen Darstellung der Ausgabe verwandt wird.

       o $MKOSI_DNF kann dazu verwandt werden, das als dnf verwandte Programm
         ausser Kraft zu setzen. Diese ist besonders fur die Auswahl zwischen
         dnf und dnf5 nutzlich.

       o $EPEL_MIRROR kann zum Ausserkraftsetzen des Ortes des
         Standard-Spiegels fur das Epel-Depot verwandt werden, wenn Mirror=
         eingesetzt wird. Standardmassig schaut mkosi nach dem Epel-Depot im
         Unterverzeichnis fedora des Elternverzeichnisses des in Mirror=
         festgelegten Spiegels. Falls der Spiegel beispielsweise auf
         https://mirror.net/centos-stream gesetzt ist, wird mkosi nach dem
         Epel-Depot in https://mirror.net/fedora/epel suchen.

       o SYSEXT_SCOPE und CONFEXT_SCOPE konnen zum Ausserkraftsetzen des
         Vorgabewertes der entsprechenden Datei extension-release beim Bau
         einer Systemerweiterung oder Konfigurationserweiterung verwandt
         werden. Standardmassig wird der Wert auf initrd system portable
         gesetzt.

BEISPIELE
       Ein rohes GPT-Abbild mit ext4(5) als image.raw erstellen und ausfuhren:

              # mkosi -p systemd -i boot

       Ein startfahiges GPT-Abbild als foobar.raw erstellen und ausfuhren:

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

       Ein >>Fedora Linux<<-Abbild in einem einfachen Verzeichnis erstellen
       und ausfuhren:

              # mkosi --distribution fedora --format directory boot

       Ein komprimiertes Abbild image.raw.xz mit installiertem SSH erstellen
       und eine Prufsummendatei hinzufugen:

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

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

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

              [Output]
              Format=disk

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

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

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

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

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

       Standardmassig wird nur mit einer Textkonsole gestartet. In diesem
       Modus verwenden Meldungen vom Systemstartprogramm, dem Kernel und
       systemd(1) und spater die getty(8)-Anmeldeaufforderung und die Shell
       das gleiche Terminal. Ein Umschalten zwischen der qemu-Konsole und dem
       Uberwachungsprogramm ist durch Eingabe von Strg-a c moglich. Das
       qemu-Uberwachungsprogramm kann beispielsweise zum Einschleusen
       bestimmter Tastendrucke oder zum schnellen Herunterfahren der Maschine
       verwandt werden. Alternativ kann die Maschine mittels Strg-a x
       heruntergefahren werden.

       Um mit einem graphischen Fenster zu starten, fugen Sie --console=gui
       hinzu:

              $ mkosi -d fedora --console=gui qemu

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

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

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

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

       Es ist auch moglich, einen direkten Kernelsystemstart in ein
       Systemstartprogramm durchzufuhren. Dabei wird ausgenutzt, dass
       systemd-boot(7) ein gultiges UEFI-Programm ist:

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

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

ANFORDERUNGEN
       mkosi wird fur verschiedene Distributionen paketiert: Debian, Kali,
       Ubuntu, Arch Linux, Fedora Linux, OpenMandriva, Gentoo, postmarketOS.
       Beachten Sie, dass seit der letzten Veroffentlichung einige Zeit
       vergangen ist und die von den Distributionen ausgelieferten Pakete
       stark veraltet sind. Daher wird derzeit empfohlen, mkosi aus Git heraus
       auszufuhren, bis eine neue Veroffentlichung stattfand.

       mkosi benotigt einen Kernel, der mount_setattr() bereitstellt, was in
       5.12. eingefuhrt wurde.

       mkosi benotigt derzeit Systemd 254, um startfahige Plattenabbilder zu
       bauen.

       Werden keine Distributionspakete verwandt, mussen Sie sicherstellen,
       dass die notwendigen Abhangigkeiten installiert sind. Unter Fedora
       Linux benotigen Sie beispielsweise:

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

       Unter Debian/Kali/Ubuntu konnte es notwendig sein, die Pakete
       ubuntu-keyring, ubuntu-archive-keyring, kali-archive-keyring und/oder
       debian-archive-keyring explizit zu installieren, zusatzlich zu apt(8),
       abhangig davon, was fur eine Art von Distributionsabbildern Sie bauen
       mochten.

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

       mkosi benotigt unbeschrankte Moglichkeiten, Namensraume zu erstellen
       und darin zu agieren. Einige Distributionen beschranken die Erstellung
       von oder Capabilities in Benutzernamensraumen, wodurch mkosi nicht
       richtig funktioniert.

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

       Fur Ubuntu konnen Sie die Beschrankung fur mkosi aufheben, indem Sie
       den nachfolgenden Schnippsel anpassen, dass er auf Ihr Programm mkosi
       zeigt, ihn nach /etc/apparmor.d/aufgeloster.pfad.zu.mkosi kopieren und
       dann systemctl reload apparmor ausfuhren:

              abi <abi/4.0>,

              include <tunables/global>

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

HAUFIG GESTELLTE FRAGEN (FAQ)
       o Warum funktioniert auf Debian/Kali/Ubuntu KVM mit mkosi vm nicht?

         Wahrend es bei anderen Distributionen kein Problem gibt, auf /dev/kvm
         zuzugreifen, ist es unter Debian/Kali/Ubuntu nur fur Benutzer in der
         Gruppe kvm erlaubt. Da mkosi einen Benutzernamensraum beim Betrieb
         ohne Privilegien abtrennt, verliert es den Zugriff auf die Gruppe
         kvm, selbst wenn der aufrufende Benutzer in der Gruppe kvm war, denn
         zum Zeitpunkt, zu dem qemu gestartet wird, gibt es auf /dev/kvm
         keinen Zugriff mehr. Um das zu umgehen, konnen Sie die Berechtigungen
         auf den Gerateknoten auf 0666 andern, was ausreicht, damit KVM ohne
         Privilegien funktioniert. Damit diese Anderungen uber Neustarts
         hinweg erhalten bleibt, kopieren Sie
         /usr/lib/tmpfiles.d/static-nodes-permissions.conf nach
         /etc/tmpfiles.d/static-nodes-permissions.conf und andern Sie den
         Modus von /dev/kvm von 0660 auf 0666.

       o Wie fuge ich zu einem Abbild einen normalen Benutzer hinzu?

         Sie konnen den nachfolgenden Schnipsel in ein
         post-installation-Skript hinzufugen:

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

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

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

         Erfolgt die Ausfuhrung nicht als Root, kann Ihr Benutzer keine
         Eigentumerschaft von Dateien fur beliebige Eigentumer andern.
         Verschiedene Distributionen liefern immer noch Dateien in ihren
         Paketen aus, die nicht dem Benutzer root gehoren. Erfolgt die
         Ausfuhrung nicht als Root, bildet mkosi den aktuellen Benutzer beim
         Aufruf des Paketverwalters auf root ab, was bedeutet, dass die
         Anderung der Eigentumerschaft auf root funktionieren wird, aber die
         Anderung der Eigentumerschaft auf jeden anderen Benutzer oder jede
         andere Gruppe fehlschlagen wird.

         Beachten Sie, dass die Aufrufe von chown(1) nur bei der Ausfuhrung
         von Paketverwaltern unterdruckt werden, aber nicht bei der Ausfuhrung
         von Skripten. Falls dies z.B. fur ein Bauskript benotigt wird, konnen
         Sie die Variable MKOSI_CHROOT_SUPPRESS_CHOWN auf den Wert true (1,
         yes, true) setzen, um die Aufrufe von chown(1) in den Skripten
         mkosi-chroot und .chroot zu unterdrucken.

         Falls dieses Verhalten dazu fuhrt, dass sich in Ihrem Abbild
         betriebene Anwendungen nicht korrekt verhalten, konnten Sie mkosi als
         Root ausfuhren, wodurch dieses Problem vermieden wird. Falls der
         Betrieb von mkosi als Root nicht gewunscht ist, konnen Sie alternativ
         unshare --map-auto --map-current-user --setuid 0 --setgid 0
         verwenden, um Root in einem Benutzernamensraum mit mehr als einem
         Benutzer zu werden, unter der Annahme, dass die UID/GID-Abbildungen
         in /etc/subuid und /etc/subgid korrekt konfiguriert sind. Beachten
         Sie, dass der Betrieb von mkosi als Root oder mit unshare bedeutet,
         dass alle von mkosi erzeugten Ausgabedateien nicht mehr ihrem
         aktuellen Benutzer gehoren.

         Fur systemd(1)-Dienste, die Verzeichnisse in /var benotigen, die dem
         Benutzer und der Gruppe des Dienstes gehoren konnen diese
         Verzeichnisse in Paketen ausgeliefert oder mittels
         systemd-tmpfiles(8) erstellt werden. Beachten Sie, das die Verwendung
         von StateDirectory=, CacheDirectory= oder LogsDirectory= in der
         Dienstedatei eine Alternative dazu darstellt. Dies weist systemd(1)
         an, die Verzeichnisse zu erstellen, wenn es erstmalig den Dienst
         startet.

         Alternativ konnen die Direktiven z oder Z fur systemd-tmpfiles(8)
         verwandt werden, um verschiedene Verzeichnisse und Dateien mittels
         chown(1) auf den Eigentumer umzuschreiben, wenn das System erstmalig
         startet.

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

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

         Da es keine gute Voreinstellung fur diesen Schlussel gibt und das
         erstellte portierbare Diensteabbild sich weiterhin korrekt anhangt,
         selbst wenn der Schlussel nicht gesetzt ist, wird mkosi keinen
         setzen.

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

REFERENZEN
       o

         Primares Mkosi-Git-Depot auf GitHub
         <https://github.com/systemd/mkosi/>

       o

         mkosi -- A Tool for Generating OS Images
         <https://0pointer.net/blog/mkosi-a-tool-for-generating-os-images.html>
          Einleitende Blog-Veroffentlichung von Lennart Poettering

       o

         The mkosi OS generation tool <https://lwn.net/Articles/726655/>
         LWN-Artikel

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

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

       Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General
       Public License Version 3 <https://www.gnu.org/licenses/gpl-3.0.html>
       oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG
       ubernommen.

       Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden,
       schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer
       <debian-l10n-german@lists.debian.org>.

                                                                      mkosi(1)