.\" -*- coding: UTF-8 -*- '\" t .\" Automatically generated by Pandoc 3.6 .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH mkosi 1 "" "" .SH BEZEICHNUNG mkosi \[en] Maßgeschneiderte Betriebssystemabbilder bauen .SH ÜBERSICHT \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]init\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]summary\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]cat\-config\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR …] \f[B]build\fR [\-\- \f[I]Befehlszeile\fR…]\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR …] \f[B]shell\fR [\-\- \f[I]Befehlszeile\fR…]\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR …] \f[B]boot\fR [\-\- \f[I]Nspawn\-Einstellungen\fR…]\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]vm\fR [\-\- \f[I]Vmm\-Parameter\fR…]\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]ssh\fR [\-\- \f[I]Befehlszeile\fR…]\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]journalctl\fR [\-\- \f[I]Befehlszeile\fR…]\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]coredumpctl\fR [\-\- \f[I]Befehlszeile\fR…]\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]sysupdate\fR [\-\- \f[I]Sysupdate\-Einstellungen\fR…]\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]box\fR [\-\- \f[I]Befehlszeile\fR…]\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]dependencies\fR [\-\- \f[I]Optionen\fR…]\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]clean\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]serve\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]burn\fR <\f[I]Gerät\fR>\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]bump\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]genkey\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]documentation\fR [\f[I]Handbuch\fR]\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]completion\fR [\f[I]Shell\fR]\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]latest\-snapshot\fR .PP \f[B]mkosi\fR [\f[I]Optionen\fR…] \f[B]help\fR .SH BESCHREIBUNG \f[B]mkosi\f[R] ist ein Werkzeug zum leichten Bau angepasster Betriebssystemabbilder. Es ist eine kunstvolle Hülle für \f[B]dnf\f[R], \f[B]apt\f[R](8), \f[B]pacman\f[R](8) und \f[B]zypper\f[R](8), die Plattenabbilder mit einer Reihe von Schnickschnack erstellen können. .SS Unterbefehle Die folgenden Unterbefehle werden erkannt: .TP \f[B]init\fR Initialisiert \f[B]mkosi\f[R]. Dies ist eine einmalige Aktion, die verschiedene Konfigurationsdateien für einen optimalen Betrieb einrichtet. Derzeit initialisiert dies nur eine Ergänzung \f[I]tmpfiles.d\f[R] für das Paketzwischenspeicherverzeichnis von \f[B]mkosi\f[R], um sicherzustellen, dass alte und nicht mehr verwandte Dateien automatisch bereinigt werden.\fR .TP \f[CR]summary\fR Zeigt eine menschenlesbare Zusammenfassung aller für den Bau des Abbilds verwandten Optionen an. Dies wird die Befehlszeile und die Konfigurationsdateien auswerten, aber nur ausgeben, wofür es konfiguriert ist und nicht wirklich etwas bauen oder ausführen.\fR .TP \f[CR]cat\-config\fR Gibt die Namen und Inhalte aller geladenen Konfigurationsdateien aus. \f[B]mkosi\f[R] lädt einen Schwung Dateien aus verschiedenen Orten und dieser Befehl erleichtert es herauszufinden, was wo konfiguriert ist.\fR .TP \f[CR]build\fR Baut das Abbild basierend auf den auf der Befehlszeile und in den Konfigurationsdateien übergebenen Einstellungen. Dieser Befehl ist die Vorgabe, falls kein Unterbefehl explizit angegeben ist. An die Bauskripte können Argumente übergeben werden, falls welche definiert sind. Um Optionen an die Bauskripte zu übegeben, trennen Sie diese von den normalen Optionen von \f[B]mkosi\fR durch \f[B]\-\-\f[R].\fR .TP \f[CR]shell\fR Dies baut das Abbild, falls es noch nicht gebaut ist, und ruft dann \f[B]systemd\-nspawn\f[R](1) auf, um eine interaktive Shell im Abbild auszuführen. Dafür muss das System nicht gestartet werden, es ist eher wie eine bessere \f[B]chroot\f[R](8). Nach dem Unterbefehl \f[B]shell\f[R] kann eine optionale Befehlszeile angegeben werden, die anstelle der Shell in dem Container aufgerufen werden soll. Um zusätzliche Optionen an Nspawn zu übergeben, trennen Sie diese mittels \f[B]\-\-\f[R] von den normalen Optionen ab.\fR .TP \f[B]boot\fR Ähnlich wie \f[B]shell\f[R], startet \f[B]systemd\f[R](1) im Abbild mittels \f[B]systemd\-nspawn\f[R](1) anstatt eine Shell zu öffnen. Nach dem Unterbefehl \f[B]boot\f[R] können zusätzliche Argumente an das Init\-System in dem Abbild angegeben werden. Um zusätzliche Optionen an Nspawn zu übergeben, trennen Sie diese mittels \f[B]\-\-\f[R] von den normalen Optionen ab.\fR .TP \f[B]vm\fR Ähnlich wie \f[B]boot\f[R], verwendet aber den konfigurierten Monitor für virtuelle Maschinen (standardmäßig \f[B]qemu\f[R]), um das Abbild zu starten, d.h. anstelle einer Container\-Virtualisierung wird eine Virtualisierung einer virtuellen Maschine verwandt. Wie zusätzliche Befehlszeilenargumente interpretiert werden hängt von dem konfigurierten Monitor für virtuelle Maschinen ab. Weitere Informationen finden Sie in \f[B]VirtualMachineMonitor=\f[R]. Um zusätzliche Optionen an den konfigurierten Monitor für virtuelle Maschinen zu übergeben, trennen Sie diese von den normalen Optionen mittels \f[B]\-\-\f[R] ab.\fR .TP \f[B]ssh\fR Wenn das Abbild mit der Option \f[B]Ssh=yes\f[R] gebaut wird oder der Dienst \f[B]sshd\-vsock\f[R] von Systemd innerhalb der VM läuft (Systemd v256+), verbindet dieser Befehl die gestartete virtuelle Maschine mittels SSH. Stellen Sie sicher, dass \f[B]mkosi ssh\f[R] mit der gleichen Konfiguration wie \f[B]mkosi build\f[R] ausgeführt wird, so dass es die notwendigen Informationen hat, um sich mit der laufenden virtuellen Maschine mittels SSH zu verbinden. Insbesondere wird der private SSH\-Schlüssel aus der Einstellung \f[B]SshKey=\f[R] verwandt, um sich mit der virtuellen Maschine zu verbinden. Verwenden Sie \f[B]mkosi genkey\f[R], um automatisch einen Schlüssel und ein Zertifikat zu erstellen, das von \f[B]mkosi\f[R] aufgenommen wird. Alle nach dem Unterbefehl \f[B]ssh\f[R] übergebene Argumente werden als Argumente an den Aufruf von \f[B]ssh\f[R](1) übergeben. Um zusätzliche Optionen zu übergeben, trennen Sie diese von den normalen Optionen mittels \f[B]\-\-\f[R] ab. Um sich mit einem Container zu verbinden, verwenden Sie \f[B]machinectl login\f[R] oder \f[B]machinectl shell\f[R].\fR .RS .PP Die Option \f[CR]Machine=\f[R] kann dazu verwandt werden, der Maschine beim Systemstart einen angepassten Rechnernamen zu geben, der später für einen \f[B]ssh\f[R](1)\-Zugang verwandt werden kann (z.B.\ \f[CR]mkosi \-\-machine=meinemaschine vm\f[R] gefolgt von \f[CR]mkosi \-\-machine=meinemaschine ssh\f[R]).\fR .RE .TP \f[B]journalctl\fR Verwendet \f[B]journalctl\f[R](1), um das Journal innerhalb des Abbildes zu untersuchen. Alle nach dem Unterbefehl \f[B]journalctl\f[R] angegebenen und durch \f[B]\-\-\f[R] von den regulären Optionen getrennten Argumente werden an den Aufruf von \f[B]journalctl\f[R](1) angehängt.\fR .TP \f[B]coredumpctl\fR Verwendet \f[B]coredumpctl\f[R](1), um nach Speicherabbilder innerhalb des Abbilds zu suchen. Alle nach dem Unterbefehl \f[B]coredumpctl\f[R] angegebenen und durch \f[B]\-\-\f[R] von den regulären Optionen getrennten Argumente werden an den Aufruf von \f[B]coredumpctl\f[R](1) angehängt.\fR .TP \f[B]sysupdate\fR Ruft \f[B]systemd\-sysupdate\f[R](8) auf, wobei die Option \f[B]\-\-transfer\-source=\f[R] auf das Ausgabeverzeichnis und die Option \f[B]\-\-definitions=\f[R] auf das mit \f[B]SysupdateDirectory=\f[R] konfigurierte Verzeichnis gesetzt ist. Alle nach dem Unterbefehl \f[B]sysupdate\f[R] festgelegten und durch \f[B]\-\-\f[R] von den regulären Optionen getrennten Argumente werden direkt an \f[B]systemd\-sysupdate\f[R](8) weitergegeben.\fR .TP \f[B]boot\fR Ruft beliebige Befehle innerhalb der gleichen Umgebung auf, die zur Ausführung anderer Unterbefehle wie \f[B]boot\f[R], \f[B]shell\f[R], \f[B]vm\f[R] und weiteren verwandt wird. Dies bedeutet, dass \f[I]/usr\f[R] durch \f[I]/usr\f[R] vom Werkzeugbaum ersetzt wird, falls einer verwandt wird, während ansonsten alles andere am Ort verbleibt. Falls kein Befehl bereitgestellt wird, wird \f[B]$SHELL\f[R] oder \f[B]bash\f[R](1), falls \f[B]$SHELL\f[R] nicht gesetzt ist, ausgeführt. Um zusätzliche Optionen an den angegebenen Befehl zu übergeben, trennen Sie diese durch \f[B]\-\-\f[R] von den regulären Optionen.\fR .TP \f[B]clean\fR Entfernt aus vorherigen Bauläufen erstellte Bauartefakte. Falls mit \f[B]\-f\f[R] kombiniert, werden auch inkrementelle Bauzwischenspeicher\-Abbilder und der Werkzeugbaum entfernt. Falls \f[B]\-f\f[R] zweimal angegeben ist, werden sämtliche Paketzwischenspeicher entfernt.\fR .TP \f[B]serve\fR Dies baut das Abbild, falls es noch nicht gebaut wurde und liefert dann das Ausgabeverzeichnis (d.h. normalerweise \f[CR]mkosi.output/\f[R], s.u.) über einen kleinen eingebauten HTTP\-Server, der auf Port 8081 auf Anfragen wartet, aus. Kombinieren Sie dies mit \f[CR]\-f\f[R], um das Abbild bedingungslos neuzubauen, bevor es ausgeliefert wird. Dieser Befehl ist für das Testen netzwerkbasierten Erwerbens von Betriebssystemabbildern nützlich, beispielsweise mittels \f[CR]machinectl pull\-raw …\f[R] und \f[CR]machinectl pull\-tar …\f[R].\fR .TP \f[CR]burn \fR Dies baut das Abbild, falls es noch nicht gebaut wurde und schreibt es dann auf das angegebene Blockgerät. Die Partitionsinhalte werden unverändert geschrieben, aber die GPT\-Partitionstabelle wird korrigiert, so dass sie auf die Sektor\- und Blockgrößen des angegebenen Mediums passt. .TP \f[B]bump\fR Erhöht die Version des Abbildes aus \f[I]mkosi.version\f[R] und schreibt die resultierende Versionszeichenkette nach \f[I]mkosi.version\f[R]. Dies ist zur Implementierung eines einfachen Versionierungsschematas nützlich: jedes Mal, wenn dieser Unterbefehl aufgerufen wird, wird die Version als Vorbereitung für den nächsten Bau erhöht. Beachten Sie, dass \f[B]\-\-auto\-bump\f[R]/\f[B]\-B\f[R] zum automatischen Erhöhen der Version bei jedem Bau verwandt werden können. Die neue Version wird in diesem Fall nur nach \f[I]mkosi.version\f[R] geschrieben, falls der Bau erfolgreich ist.\fR .RS .PP Falls \f[I]mkosi.bump\f[R] existiert, wird sie aufgerufen, um eine neu Version zu erstellen, die anstelle von eigener Logik von \f[B]mkosi\fR verwandt wird.\fR .RE .TP \f[B]genkey\fR Erstellt ein Paar von SecureBoot\-Schlüsseln zur Verwendung mit den Optionen \f[CR]SecureBootKey=\f[R]/\f[CR]\-\-secure\-boot\-key=\f[R] und \f[CR]SecureBootCertificate=\f[R]/\f[CR]\-\-secure\-boot\-certificate=\f[R].\fR .TP \f[CR]documentation\fR Zeigt die Dokumentation von \f[B]mkosi\f[R]. Falls kein Argument angegeben ist, wird die Handbuchseite \f[B]mkosi\f[R](1) angezeigt, aber die Argumente \f[CR]mkosi\f[R], \f[CR]mkosi\-initrd\f[R], \f[CR]initrd\f[R], \f[CR]mkosi\-sandbox\f[R], \f[CR]sandbox\f[R], \f[CR]mkosi.news\f[R] und \f[CR]news\f[R] werden unterstützt und zeigen die Handbuchseiten für \f[B]mkosi\f[R](1), \f[B]mkosi\-initrd\f[R](1), \f[B]mkosi\-sandbox\f[R](1) bzw. die NEWS\-Datei von \f[B]mkosi\f[R] an.\fR .RS .PP Standardmäßig wird dieser Unterbefehl verschiedene Arten zur Ausgabe der Dokumentation ausprobieren, eine bestimmte Option kann mit der Option \f[CR]\-\-doc\-format\f[R] ausgewählt werden. Paketierer von Distributionen wird empfohlen, eine Datei \f[CR]mkosi.1\f[R] in das Verzeichnis \f[CR]mkosi/resources\f[R] des Python\-Pakets abzulegen, falls sie dort fehlt, sowie sie im geeigneten Suchpfad für Handbuchseiten zu installieren. Die Handbuchseite kann aus der Markdown\-Datei \f[CR]mkosi/resources/man/mkosi.1.md\f[R] zum Beispiel mittels \f[CR]pandoc \-t man \-s \-o mkosi.1 mkosi.1.md\f[R] erstellt werden.\fR .RE .TP \f[CR]completion\fR Erstellt Shell\-Vervollständigungen für die als Argument übergebene Shell und gibt diese auf der Standardausgabe aus. Es werden die Argumente \f[CR]bash\f[R], \f[CR]fish\f[R] und \f[CR]zsh\f[R] verstanden.\fR .TP \f[CR]dependencies\fR Gibt die Liste der von \f[B]mkosi\f[R] zum Bauen und Starten von Abbildern benötigten Pakete aus.\fR .RS .PP Diese Liste kann direkt an einen Paketverwalter weitergeleitet werden, um die Pakete zu installieren. Falls beispielsweise das Wirtsystem den \f[B]dnf\f[R]\-Paketverwalter verwendet, könnten die Pakete wie folgt installiert werden: .IP .EX mkosi dependencies \f[B]|\f[R] xargs \-d \[aq]\[rs]n\[aq] dnf install\fR .EE .PP Standardmäßig werden nur die Abhängigkeiten angezeigt, die zum Bau von Abbildern mit \f[B]mkosi\f[R] benötigt werden. Es können zusätzliche Werkzeugbaumprofile aktiviert werden, um auch die Pakete auszugeben, die zu solchen Profilen gehören. Beispielsweise wird die Ausführung von \f[B]mkosi dependencies \-\- \-\-profile runtime\f[R] auch zusätzlich zu den regulären Paketen die Pakete in dem Profil »runtime« ausgeben. Lesen Sie die Dokumentation von \f[B]ToolsTreeProfiles=\f[R] für eine Liste der verfügbaren Profile.\fR .RE .TP \f[B]latest\-snapshot\fR Gibt den neuesten verfügbaren Schnappschuss in dem konfigurierten Spiegel aus. .RS .PP Dieser Unterbefehl ist nützlich, um Schnappschüsse 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. .RE .TP \f[CR]help\fR Dieser Unterbefehl ist identisch zum nachfolgend dokumentierten Schalter \f[CR]\-\-help\f[R]: Er zeigt eine kurze Erklärung zur Verwendung.\fR .SS "Reine Befehlszeilenoptionen" Diese Einstellungen können nicht mittels der Konfigurationsdateien konfiguriert werden. .TP \f[B]\-\-force\f[R], \f[B]\-f\fR Ersetzt beim Bau eines Abbildes die Ausgabedatei, falls sie bereits existiert. Standardmäßig verweigert \f[B]mkosi\f[R] eine Aktion, wenn ein Abbild gebaut wird und ein Ausgabeartefakt bereits existiert. Geben Sie diese Option einmal an, um alle Bauartefakte aus einem vorherigen Lauf vor dem Neubau des Abbildes zu entfernen. Falls inkrementelle Bauten aktiviert sind, wird zweimalige Angabe sicherstellen, dass inkrementelle Zwischenspeicherdateien auch entfernt werden, bevor der Neubau eingeleitet wird. Falls ein Paketzwischenspeicher verwandt wird (siehe auch den nachfolgenden Abschnitt \f[B]DATEIEN\f[R]) wird die dreimalige Angabe sicherstellen, dass auch der Paketzwischenspeicher entfernt wird, bevor der Neubau eingeleitet wird. Für die Aktion \f[B]clean\f[R] hat diese Option eine leicht andere Auswirkung: Standardmäßig wird der Unterbefehl nur Bauartefakte aus dem vorherigen Lauf entfernen, durch einmalige Angabe werden auch die inkrementellen Zwischenspeicherdateien und der Werkzeugbaum gelöscht, bei doppelter Angabe wird auch der Paketzwischenspeicher entfernt.\fR .TP \f[B]\-\-directory=\f[R], \f[B]\-C\fR Akzeptiert einen Pfad zu einem Verzeichnis. Vor allen anderen Aktivitäten wechselt \f[B]mkosi\f[R] in dieses Verzeichnis. Beachten Sie, dass in diesem Verzeichnis nach den verschiedenen Konfigurationsdateien gesucht wird, daher ist die Verwendung dieser Option ein wirksammes Mittel, ein Projekt zu bauen, das sich in einem bestimmten Verzeichnis befindet. Dies ist standardmäßig das aktuelle Verzeichnis. Falls die leere Zeichenketten angegeben ist, werden alle Konfigurationen in dem aktuellen Arbeitsverzeichnis ignoriert.\fR .TP \f[B]\-\-debug\fR Aktiviert zusätzliche Fehlersuchausgaben. .TP \f[B]\-\-debug\-shell\fR Falls die Ausführung eines Befehls in dem Abbild fehlschlägt, wird \f[B]mkosi\f[R] eine interaktive Shell in dem Abbild starten, um ein weitere Fehlersuche zu ermöglichen. .TP \f[CR]\-\-debug\-workspace\fR Löscht, wenn angegeben, das Arbeitsbereichsverzeichnis nicht und seine Lage wird protokolliert, wenn sich \f[B]mkosi\f[R] beendet.\fR .TP \f[B]\-\-debug\-sandbox\fR Führt \f[B]mkosi\-sandbox\f[R](1) mit \f[B]strace\f[R](1) aus.\fR .TP \f[B]\-\-version\fR Zeigt die Paketversion. .TP \f[CR]\-\-help\f[R], \f[CR]\-h\fR Zeigt einen kurzen Hinweis zum Aufruf. .TP \f[CR]\-\-genkey\-common\-name=\fR Allgemeiner Name, der bei der Erzeugung von Schlüsseln mittels des Befehls \f[CR]genkey\f[R] von \f[B]mkosi\f[R] verwandt wird. Standardmäßig \f[CR]mkosi of %u\f[R], wobei \f[CR]%u\f[R] auf den Benutzernamen des Benutzer, der \f[B]mkosi\f[R] aufruft, erweitert wird.\fR .TP \f[CR]\-\-genkey\-valid\-days=\fR Anzahl an Tagen, die Schlüssel gültig bleiben sollen, wenn Schlüssel mit dem Befehl \f[CR]genkey\f[R] von \f[B]mkosi\f[R] erstellt werden. Standardmäßig zwei Jahre (730 Tage).\fR .TP \f[B]\-\-auto\-bump=\f[R], \f[B]\-B\fR Falls angegeben wird die Version erhöht und falls der Bau erfolgreich ist, wird die Version nach \f[I]mkosi.version\f[R] auf eine Art ähnlich zum Unterbefehl \f[B]bump\f[R] geschrieben. Dies ist für einfaches, lineares Versionsmanagement nützlich: jeder Bau in einer Reihe wird eine um eins gegenüber dem vorherigen Bau erhöhte Versionsnummer haben.\fR .RS .PP Falls \f[I]mkosi.bump\f[R] existiert, wird sie aufgerufen, um eine neu Version zu erstellen, die anstelle von eigener Logik von \f[B]mkosi\fR verwandt wird.\fR .RE .TP \f[B]\-\-doc\-format\fR Das Format, in dem die Dokumentation angezeigt werden soll. Unterstützt die Werte \f[CR]markdown\f[R], \f[CR]man\f[R], \f[CR]pandoc\f[R], \f[CR]system\f[R] und \f[CR]auto\f[R]. Im Falle von \f[CR]markdown\f[R] wird die Dokumentation im usrpünglichen Markdown\-Format angezeigt. \f[CR]man\f[R] zeigt die Dokumentation im Handbuchseitenformat, falls dies verfügbar ist. \f[CR]pandoc\f[R] erstellt das Handbuchseitenformat dynamisch, falls \f[B]pandoc\f[R](1) verfügbar ist. \f[CR]system\f[R] zeigt die systemweite Handbuchseite für \f[B]mkosi\f[R], die nicht zwingend der Version entspricht, die Sie verwenden, abhängig davon, wie \f[B]mkosi\f[R] installiert wurde. \f[CR]auto\f[R] (die Vorgabe) wird alle Methoden in der Reihenfolge \f[CR]man\f[R], \f[CR]pandoc\f[R], \f[CR]markdown\f[R], \f[CR]system\f[R] ausprobieren.\fR .TP \f[B]\-\-json\fR Zeigt die zusammenfassende Ausgabe als JSON\-SEQ. .TP \f[B]\-\-wipe\-build\-dir\f[R], \f[B]\-w\fR Vernichtet vor dem Bau des Abbildes das Bauverzeichnis, falls eines konfiguriert ist. .TP \f[B]\-\-rerun\-build\-scripts\f[R], \f[B]\-R\fR Führt die Bauskripte erneut aus. Benötigt die aktivierte Option \f[B]Incremental=\f[R] und das Abbild muss bereits einmal gebaut worden sein. Falls \f[B]History=\f[R] aktiviert ist, wird der Verlauf von dem vorherigen Bau erneut verwandt und kein neuer Verlauf geschrieben.\fR .SS "Unterstützte Ausgabeformate" Die folgenden Ausgabeformate werden unterstützt: .IP \[bu] 2 Rohes \f[I]GPT\f[R]\-Plattenabbild, mittels \f[B]systemd\-repart\f[R](8) erstellt (\f[I]Platte\f[R])\fR .IP \f[R]\[bu]\fR 2 Einfaches Verzeichnis, enthält den Betriebssystembaum (\f[I]Verzeichnis\f[R])\fR .IP \f[R]\[bu]\fR 2 TAR\-Archiv (\f[I]tar\f[R])\fR .IP \f[R]\[bu]\fR 2 CPIO\-Archiv (\f[I]cpio\f[R])\fR .IP \f[R]\[bu]\fR 2 Vereinigtes Kernelabbild (\f[I]UKI\f[R])\fR .IP \f[R]\[bu]\fR 2 … und viele weitere. Informationen hierzu in der nachfolgenden Beschreibung für \f[B]Format=\f[R].\fR .PP Das Ausgabeformat kann auch auf \f[I]none\f[R] gesetzt werden, wenn Sie möchten, dass \f[B]mkosi\f[R] überhaupt kein Abbild erstellt. Dies kann nützlich sein, falls Sie das Abbild nur dazu verwenden möchten, eine andere Ausgabe in den Bauskripten zu erstellen (z.B. ein RPM zu bauen).\fR .PP Wenn ein \f[I]GPT\f[R]\-Plattenabbild erstellt wird, können Repart\-Partitionsdefinitionsdateien in \f[CR]mkosi.repart/\f[R] abgelegt werden, um das erstellte Plattenabbild zu konfigurieren.\fR .PP Es wird nachdrücklich empfohlen, \f[B]mkosi\f[R] auf einem Dateisystem auszuführen, das Reflinks unterstützt, wie \f[V]xfs\f[R](5) und \f[V]btrfs\f[R](5) und alle zusammengehörigen Verzeichnisse auf dem gleichen Dateisystem zu behalten. Dies ermöglicht es \f[B]mkosi\f[R], Abbilder sehr schnell durch Verwendung von Reflinks zur Durchführung von Kopieren\-Beim\-Schreiben\-Aktionen zu erstellen.\fR .SS Konfigurationseinstellungen Die folgenden Einstellungen können über Konfigurationsdateien (der Syntax mit \f[CR]EineEinstellung=Wert\f[R]) und auf der Befehlszeile (der Syntax mit \f[CR]\-\-Eine\-Einstellung=Wert\f[R]) gesetzt werden. Für einige Befehlszeilenparameter ist auch eine Abkürzung mit einem Buchstaben erlaubt. In den Konfigurationsdateien muss die Einstellung in dem korrekten Abschnitt erfolgen, daher sind die Einstellungen nachfolgend gemäß des Abschnittes gruppiert.\fR .PP Die Konfiguration wird in der folgenden Reihenfolge ausgewertet: .IP \[bu] 2 Die Befehlszeilenargumente werden ausgewertet. .IP \[bu] 2 \f[I]mkosi.local.conf\f[R] und \f[I]mkosi.local\f[R] werden ausgewertet, falls sie existieren. Diese Datei und das Verzeichnis sollte in \&\f[I].gitignore\f[R] (oder äquivalent) sein und sind für lokale Konfiguration gedacht.\fR .IP \f[R]\[bu]\fR 2 Falls eine Option einen entsprechenden Standardpfad hat, wird dieser ausgewertet, falls der Standardpfad existiert. .IP \[bu] 2 \f[I]mkosi.conf\f[R] wird ausgewertet, falls es in dem mit \f[B]\-\-directory=\f[R] konfigurierten oder im aktuellen Arbeitsverzeichnis, falls \f[B]\-\-directory=\f[R] nicht verwandt wird, existiert. Falls das angegebene Verzeichnis kein \f[I]mkosi.conf\f[R] oder \f[I]mkosi.tools.conf\f[R] enthält und ein \f[I]mkosi/mkosi.conf\f[R] oder \f[I]mkosi/mkosi.tools.conf\f[R] existiert, wird die Konfiguration stattdessen aus dem Unterverzeichnis \f[B]mkosi/\f[R] des angegebenen Verzeichnis ausgewertet.\fR .IP \f[R]\[bu]\fR 2 \f[I]mkosi.conf.d/\f[R] wird im gleichen Verzeichnis wie \f[I]mkosi.conf\f[R] ausgewertet, falls sie existiert. Jedes Verzeichnis und jede Datei mit der Endung \f[I].conf\f[R] in \f[I]mkosi.conf.d/\f[R] wird ausgewertet. Jedes Verzeichnis in \f[I]mkosi.conf.d\f[R] wird ausgewertet, als ob es ein normales Verzeichnis auf der obersten Ebene wäre. Die Ausnahmen sind \f[I]mkosi.images/\f[R] und \f[I]mkosi.tools.conf\f[R], die nur im Verzeichnis auf der obersten Ebene aufgenommen werden.\fR .IP \f[R]\[bu]\fR 2 Falls irgendwelche Profile definiert sind, werden deren Konfiguration aus dem Verzeichnis \f[CR]mkosi.profiles/\f[R] ausgewertet.\fR .IP \f[R]\[bu]\fR 2 Unterabbilder werden aus dem Verzeichnis \f[I]mkosi.images/\f[R] ausgewertet, falls es existiert.\fR .PP Beachten Sie, dass die über die Befehlszeile konfigurierten Einstellungen immer die über Konfigurationsdateien konfigurierte Einstellungen außer Kraft setzen. Falls die gleiche Einstellung mehr als einmal mittels Konfigurationsdateien konfiguriert ist, setzen spätere Zuweisungen frühere außer Kraft, sofern die Einstellungen nicht eine Sammlung an Werten akzeptierten. Auch werden Einstellungen, die aus \f[I]mkosi.local.conf\f[R] oder \f[I]mkosi.local/\f[R] gelesen werden Einstellungen von anderen Konfigurationsdateien, die später ausgewertet werden, außer Kraft setzen, allerdings nicht solche, die auf der Befehlszeile angegeben werden.\fR .PP Für Einstellungen, die einen einzelnen Wert akzeptieren, kann die leere Zuweisung (\f[CR]EineEinstellung=\f[R] oder \f[CR]\-\-eine\-einstellung=\f[R]) zum Außerkraftsetzen einer vorherigen Einstellung und zum Zurücksetzen auf die Vorgabewerte verwandt werden.\fR .PP Einstellungen, die eine Sammlung von Werten akzeptieren, werden zusammengeführt, indem neue Werte an die bereits konfigurierten Werte angehängt werden. Durch Zuweisung einer leeren Zeichenkette zu einer solchen Einstellung werden alle vorher zugewiesenen Werte entfernt und auch alle konfigurierten Standardwerte außer Kraft gesetzt. Die auf der Befehlszeile angegebenen Werte werden nach allen Werten aus den Konfigurationsdateien angehängt. .PP Um Konfigurationsdateien bedingt einzubinden, kann der Abschnitt \f[CR][Match]\f[R] verwandt werden. Ein Abschnitt \f[CR][Match]\f[R] besteht aus einzelnen Bedingungen. Bedingungen können ein Weiterleitungssymbol (\f[CR]|\f[R]) nach dem Gleichheitszeichen verwenden (\f[CR]…=|…\f[R]). Dadurch wird die Bedingung eine auslösende Bedingung. Die Konfigurationsdatei wird eingebunden, falls das logische UND aller nicht auslösenden Bedingungen und das logische ODER aller auslösenden Bedingungen erfüllt wird. Um das Ergebnis einer Bedingung zu negieren, stellen Sie dem Argument ein Ausrufezeichen voran. Falls einem Argument ein Weiterleitungssymbol und ein Ausrufezeichen vorangestellt wird, muss das Weiterleitungssymbol zuerst angegeben werden und anschließend das Ausrufezeichen.\fR .PP Beachten Sie, dass die Bedingungen in \f[CR][Match]\f[R] mit den aktuellen Werten einer bestimmten Einstellung verglichen werden und keine Änderungen an Einstellungen berücksichtigen, die in Konfigurationsdateien bereits erfolgten, aber noch nicht ausgewertet wurden (auf der Befehlszeile angegebene Einstellungen werden berücksichtigt). Beachten Sie auch, dass das Prüfen der Übereinstimmung mit einer Einstellung und das anschließende Ändern in einer anderen Konfigurationsdatei zu unerwarteten Ergebnissen führen kann.\fR .PP Der Abschnitt \f[CR][Match]\f[R] in einer Datei \f[CR]mkosi.conf\f[R] in einem Verzeichnis gilt für das gesamte Verzeichnis. Falls die Bedingungen nicht erfüllt sind, wird das gesamte Verzeichnis übersprungen. Die Abschnitte \f[CR][Match]\f[R] von Dateien in \f[CR]mkosi.conf.d/\f[R] und \f[CR]mkosi.local.conf\f[R] gelten nur für die Datei selbst.\fR .PP Falls es mehrere Abschnitte \f[CR][Match]\f[R] in der gleichen Konfigurationsdatei gibt, muss jede erfüllt werden, damit die Konfigurationsdatei eingebunden wird. Insbesondere gelten auslösende Bedingungen nur für den aktuellen Abschnitt \f[CR][Match]\f[R] und werden zwischen mehreren Abschnitten \f[CR][Match]\f[R] zurückgesetzt. In dem folgenden Beispiel erfolgt nur eine Übereinstimmung, falls das Ausgabeformat entweder \f[CR]disk\f[R] oder \f[CR]directory\f[R] ist und die Architektur entweder \f[CR]x86\-64\f[R] oder \f[CR]arm64\f[R] ist:\fR .IP .EX \f[B][Match]\f[R] Format=|disk Format=|directory\fR \f[B][Match]\f[R] Architecture=|x86\-64 Architecture=|arm64\fR .EE .PP Der Abschnitt \f[B][TriggerMatch]\f[R] kann zur Anzeige von auslösenden Übereinstimmungen verwandt werden. Diese sind zu auslösenden Bedingungen in Systemd\-Units identisch, außer dass sie für den gesamten Übereinstimmungsabschnitt statt nur einer einzelnen Bedingung gelten. Beispielsweise stimmt folgendes überein, falls die Distribution \f[B]debian\f[R] und die Veröffentlichung \f[B]bookworm\f[R] ist oder falls die Distribution \f[B]ubuntu\f[R] und die Veröffentlichung \f[B]noble\f[R] ist.\fR .IP .EX \f[B][TriggerMatch]\f[R] Distribution=debian Release=bookworm\fR \f[B][TriggerMatch]\f[R] Distribution=ubuntu Release=noble\fR .EE .PP Die Semantik von Bedingungen in \f[CR][TriggerMatch]\f[R]\-Abschnitten ist identisch zu \f[CR][Match]\f[R], d.h. alle normalen Bedingungen werden durch ein logisches UND und alle auslösenden Bedingungen werden durch ein logisches ODER zusammengefasst. Beim Mischen von \f[CR][Match]\f[R]\- und \f[CR][TriggerMatch]\f[R]\-Abschnitten wird eine Übereinstimmung erreicht, wenn alle \f[CR][Match]\f[R]\-Abschnitte übereinstimmen und mindestens ein \f[CR][TriggerMatch]\f[R]\-Abschnitt übereinstimmt. Die Abwesenheit eines Übereinstimmungsabschnittes wird als true ausgewertet. Logisch bedeutet dies:\fR .IP .EX (⋀ᵢ Matchᵢ) ∧ (⋁ᵢ TriggerMatchᵢ) .EE .PP Es gibt auch Unterstützung für die Abschnitte \f[B][Assert]\f[R] und \f[B][TriggerAssert], die sich identisch verhalten, um auf Abschnitte zu passen, außer dass die Auswertung der Konfiguration fehlschlagen wird, falls die Assert\-Abschnitte nicht erfüllt sind, d.h. alle Abschnitte \f[B][Assert]\f[R] in einer Datei sowie mindestens ein Abschnitt \f[B][TriggertAssert]\f[R] müssen erfüllt sein oder das Auswerten der Konfiguration wird fehlschlagen.\fR .PP Befehlszeilenoptionen, die kein Argument akzeptieren, werden ohne \f[CR]=\f[R] in ihrer langen Version angezeigt. In der Konfigurationsdatei sollten sie mit einem logischen Argument angegeben werden: entweder \f[CR]1\f[R], \f[CR]yes\f[R] oder \f[CR]true\f[R] zum aktivieren oder \f[CR]0\f[R], \f[CR]no\f[R], \f[CR]false\f[R] zum deaktivieren.\fR .SS "Abschnitt [Distribution]" .TP \f[CR]Distribution=\f[R], \f[CR]\-\-distribution=\f[R], \f[CR]\-d\fR Die im Abbild zu installierende Distribution. Akzeptiert eines der folgenden Argumente: \f[CR]fedora\f[R], \f[CR]debian\f[R], \f[CR]kali\f[R], \f[CR]ubuntu\f[R], \f[CR]arch\f[R], \f[CR]opensuse\f[R], \f[CR]mageia\f[R], \f[CR]centos\f[R], \f[CR]rhel\f[R], \f[CR]rhel\-ubi\f[R], \f[CR]openmandriva\f[R], \f[CR]rocky\f[R], \f[CR]alma\f[R], \f[CR]azure\f[R] oder \f[CR]custom\f[R]. Falls nicht angegeben ist die Vorgabe die Distribution des Wirtsystems oder \f[CR]custom\f[R], falls die Distribution des Wirtsystems keine unterstützte Distribution ist.\R .TP \f[CR]Release=\f[R], \f[CR]\-\-release=\f[R], \f[CR]\-r\fR Die Veröffentlichung der im Abbild zu installierenden Distribution. Die genaue Syntax des akzeptierten Arguments hängt von der verwandten Distribution ab und ist entweder eine numerische Zeichenkette (im Falle von Fedora Linux, CentOS, …, z.B. \f[CR]29\f[R]) oder ein Versionsname der Distribution (im Falle von Debian, Kali, Ubuntu, …, z.B. \f[CR]artful\f[R]). Standardmäßig die neuste Version der ausgewählten Distribution oder die Version, die auf der Wirtmaschine läuft, falls sie mit einer konfigurierten Distribution übereinstimmt.\fR .TP \f[CR]Architecture=\f[R], \f[CR]\-\-architecture=\fR Die Architektur für die das Abbild gebaut wird. Die tatsächlich unterstützten Architekturen hängen von der verwandten Distribution ab und ob ein startfähiges Abbild erbeten wird. Beim Bau für eine fremde Architektur müssen Sie auch den Benutzermodus\-Emulator für diese Architektur installieren und registrieren. .RS .PP Pro gebautem Abbild kann eine der folgenden Architekturen festgelegt werden: \f[CR]alpha\f[R], \f[CR]arc\f[R], \f[CR]arm\f[R], \f[CR]arm64\f[R], \f[CR]ia64\f[R], \f[CR]loongarch64\f[R], \f[CR]mips64\-le\f[R], \f[CR]mips\-le\f[R], \f[CR]parisc\f[R], \f[CR]ppc\f[R], \f[CR]ppc64\f[R], \f[CR]ppc64\-le\f[R], \f[CR]riscv32\f[R], \f[CR]riscv64\f[R], \f[CR]s390\f[R], \f[CR]s390x\f[R], \f[CR]tilegx\f[R], \f[CR]x86\f[R], \f[CR]x86\-64\f[R].\fR .RE .TP \f[CR]Mirror=\f[R], \f[CR]\-\-mirror=\f[R], \f[CR]\-m\fR Der Spiegel für das Herunterladen der Distributionspakete. Erwartet eine Spiegel\-URL als Argument. Falls nicht angegeben wird der Standard\-Spiegel für die Distribution verwandt. .RS .PP Die Standard\-Spiegel für jede Distribution sind wie folgt (sofern nicht angegeben, wird der gleiche Spiegel für alle Architekturen verwandt): .PP .TS tab(@); lw(13.3n) lw(30.0n) lw(26.7n). T{ T}@T{ X86\-64 T}@T{ Aarch64 T} _ T{ \f[CR]Debian\fR T}@T{ \f[R]http://deb.debian.org\fR T}@T{ T} T{ \f[CR]Arch\fR T}@T{ \f[R]https://fastly.mirror.pkgbuild.com\fR T}@T{ \f[R]http://mirror.archlinuxarm.org\fR T} T{ \f[CR]OpenSUSE\fR T}@T{ \f[R]http://download.opensuse.org\fR T}@T{ T} T{ \f[CR]kali\fR T}@T{ \f[R]http://http.kali.org/kali\fR T}@T{ T} T{ \f[CR]Ubuntu\fR T}@T{ \f[R]http://archive.ubuntu.com\fR T}@T{ \f[R]http://ports.ubuntu.com\fR T} T{ \f[CR]Centos\fR T}@T{ \f[R]https://mirrors.centos.org\fR T}@T{ T} T{ \f[CR]Rocky\fR T}@T{ \f[R]https://mirrors.rockylinux.org\fR T}@T{ T} T{ \f[CR]Alma\fR T}@T{ \f[R]https://mirrors.almalinux.org\fR T}@T{ T} T{ \f[CR]Fedora\fR T}@T{ \f[R]https://mirrors.fedoraproject.org\fR T}@T{ T} T{ \f[CR]RHEL\-ubi\fR T}@T{ \f[R]https://cdn\-ubi.redhat.com\fR T}@T{ T} T{ \f[CR]Mageia\fR T}@T{ \f[R]https://www.mageia.org\fR T}@T{ T} T{ \f[CR]Openmandriva\fR T}@T{ \f[R]http://mirrors.openmandriva.org\fR T}@T{ T} T{ \f[CR]azure\fR T}@T{ \f[R]https://packages.microsoft.com/\fR T}@T{ T} .TE .RE .TP \f[B]Snapshot=\fR Lädt Pakete von dem angegebenen Schnappschuss herunter, anstatt die neusten Distributionspakete von dem angegebenen Spiegel herunterzuladen. Akzeptiert eine Schnappschusskennung (das Format der Schnappschusskennung ist distributionsabhängig). Verwenden Sie den Unterbefehl \f[B]latest\-snapshot\f[R], um den neusten verfügbaren Schnappschuss zu ermitteln.\fR .RS .PP Falls diese Einstellung konfiguriert ist und \f[B]Mirror=\f[R] nicht explizit konfiguriert ist, werden verschiedene Vorgabe\-Spiegel verwandt:\fR .PP .TS tab(@); lw(13.3n) lw(30.0n) lw(26.7n). T{ T}@T{ X86\-64 T}@T{ Aarch64 T} _ T{ \f[CR]Debian\fR T}@T{ \f[R]https://snapshot.debian.org\fR T}@T{ T} T{ \f[CR]Arch\fR T}@T{ \f[R]https://archive.archlinux.org\fR T}@T{ \f[R]http://mirror.archlinuxarm.org\fR T} T{ \f[CR]OpenSUSE\fR T}@T{ \f[R]http://download.opensuse.org\fR T}@T{ T} T{ \f[CR]Ubuntu\fR T}@T{ \f[R]http://archive.ubuntu.com\fR T}@T{ \f[R]http://ports.ubuntu.com\fR T} T{ \f[CR]Centos\fR T}@T{ \f[R]https://composes.stream.centos.org\fR T}@T{ T} T{ \f[CR]Fedora\fR T}@T{ \f[R]https://kojipkgs.fedoraproject.org\fR T}@T{ T} .TE .PP Nur für die oben aufgeführten Distributionen werden Schnappschüsse unterstützt. .RE .TP \f[CR]LocalMirror=\f[R], \f[CR]\-\-local\-mirror=\fR Der Spiegel wird als ein lokaler, einfacher und direkter Spiegel anstelle der Verwendung als Präfix für die volle Reihe von Depots, die normalerweise von Distributionen angeboten werden, verwandt. Nützlich beim Bau vollständig ohne Netzanbindung mit einem einzelnen Depot. Wird für \f[B]deb\f[R]\-, \f[B]rpm\f[R]\- und \f[B]pacman\f[R]\-basierte Distributionen unterstützt. Setzt \f[CR]\-\-mirror=\f[R] außer Kraft, aber nur für lokale \f[B]mkosi\f[R]\-Bauten, es wird nicht im letztendlichen Abbild konfiguriert, stattdessen wird \f[CR]\-\-mirror=\f[R] (oder das Standard\-Depot) innerhalb des letztendlichen Abbilds konfiguriert.\fR .TP \f[CR]RepositoryKeyCheck=\f[R], \f[CR]\-\-repository\-key\-check=\fR Steuert die Signatur\-/Schlüsselüberprüfung bei der Verwendung von Depots, standardmäßig aktiviert. Die Deaktivierung ist bei der Kombination mit \f[CR]\-\-local\-mirror=\f[R] und der ausschließlichen Verwendung eines lokalen Depots aus einem lokalen Dateisystem nützlich.\fR .TP \f[CR]RepositoryKeyFetch=\f[R], \f[CR]\-\-repository\-key\-fetch=\fR Steuert, ob \f[B]mkosi\f[R] die Distributions\-GPG\-Schlüssel aus der Ferne abholt. Auf Ubuntu standardmäßig aktiviert, wenn kein Werkzeugbaum verwandt wird oder wenn der Ubuntu\-Werkzeugbaum zum Bau von Arch\-Linux\- oder RPM\-basierte\-Distributionen verwandt wird. Auf allen anderen Distributionen standardmäßig deaktiviert. Wenn deaktiviert, müssen die Distributions\-GPG\-Schlüssel für die Zieldistribution lokal auf dem Rechner zusammen mit dem Paketverwalter für diese Distribution installiert sein.\fR .RS .PP Diese Einstellung ist nur für Distributionen implementiert, die \f[B]dnf\f[R], \f[B]pacman\f[R](8) oder \f[B]zypper\f[R](8) als ihren Paketverwalter verwenden. Für andere Distributionen wird der Distributions\-GPG\-Schlüssel immer lokal nachgeschlagen, unabhängig vom Wert dieser Einstellung. Um die Distributions\-GPG\-Schlüssel für Distributionen zur Verfügung zu stellen, ohne diese Einstellung zu aktivieren, muss das entsprechende Paket auf dem Wirt installiert sein. Dabei handelt es sich typischerweise um entweder \f[CR]archlinux\-keyring\f[R], \f[CR]debian\-keyring\f[R], \f[CR]kali\-archive\-keyring\f[R], \f[CR]ubuntu\-keyring\f[R] oder \f[CR]distribution\-gpg\-keys\f[R] (für RPM\-basierte Distributionen).\fR .RE .TP \f[CR]Repositories=\f[R], \f[CR]\-\-repositories=\fR Aktiviert standardmäßig deaktivierte Paket\-Depots. Dies kann zur Aktivierung der EPEL\-Depots für CentOS oder anderer Komponenten der Debian/Kali/Ubuntu\-Depots verwandt werden. .SS "Abschnitt [Output]" .TP \f[B]Format=\f[R], \f[B]\-\-format=\f[R], \f[B]\-t\fR Das zu erstellende Abbild\-Format. Entweder \f[B]directory\f[R] (zur direkten Erstellung eines Betriebssystemabbildes im lokalen Verzeichnis), \f[B]tar\f[R] (ähnlich, es wird aber ein Tarball des Betriebssystemabbildes erstellt), \f[B]cpio\f[R] (ähnlich, es wird aber ein Cpio\-Archiv erstellt), \f[B]disk\f[R] (ein Blockgerät\-Betriebssystemabbild mit einer GPT\-Partitionstabelle), \f[B]uki\f[R] (ein vereinigtes Kernel\-Abbild mit einem Betriebssystemabbild im PE\-Abschnitt \f[B].initrd\f[R]), \f[B]esp\f[R] (ein Plattenabbild mit nur einer ESP\-Partition, Systemstartprogramm und optional einer UKI), \f[B]oci\f[R] (ein mit der OCI\-Abbildspezifikation kompatibles Verzeichnis),\f[B]sysext\f[R], \f[B]confext\f[R], \f[B]portable\f[R], \f[B]addon\f[R] oder \f[B]none\f[R] (das Betriebssystem\-Abbild ist nur als Bau\-Artefakt zur Erstellung eines weiteren Artefaktes gedacht).\fR .RS .PP Falls das Ausgabeformat \f[CR]disk\f[R] verwandt wird, wird das Plattenabbild mittels \f[B]systemd\-repart\f[R](8) erstellt. Die zu verwendenden Repart\-Partitions\-Definitionsdateien können mittels der Einstellung \f[CR]RepartDirectories=\f[R] oder mittels \f[CR]mkosi.repart/\f[R] konfiguriert werden. Wenn Verity\-Partitionen mittels der Einstellung \f[CR]Verity=\f[R] von \f[B]systemd\-repart\f[R](8) konfiguriert werden, wird \f[B]mkosi\f[R] automatisch den Root\-Hash der Verity\-Hash\-Partition aus der JSON\-Ausgabe von \f[B]systemd\-repart\f[R](8) auswerten und ihn in die Kernel\-Befehlszeile jedes durch \f[B]mkosi\f[R] gebauten vereinigten Kernel\-Abbildes aufnehmen.\fR .PP Falls das Format \f[CR]none\f[R] verwandt wird, werden die Ausgaben von vorherigen Bauten nicht entfernt, aber Bereinigungsskripte (siehe \f[CR]CleanScripts=\f[R]) werden weiterhin ausgeführt. Dies ermöglicht das erneute Ausführen von Bauskripten (siehe \f[CR]BuildScripts=\f[R]), ohne die Ergebnisse eines vorherigen Baus zu entfernen.\fR .RE .TP \f[CR]ManifestFormat=\f[R], \f[CR]\-\-manifest\-format=\fR Den oder die zu erstellende Manifestformattyp oder \-typen. Eine Kommata\-getrennte Liste, die aus \f[CR]json\f[R] (das Standard\-JSON\-Ausgabeformat, das die zu installierenden Pakete beschreibt), \f[CR]changelog\f[R] (ein menschenlesbares Textformat, das zum Ermitteln von Unterschieden entwickelt wurde) besteht. Standardmäßig wird kein Manifest erstellt.\fR .TP \f[CR]Output=\f[R], \f[CR]\-\-output=\f[R], \f[CR]\-o\fR Für die erstellte Ausgabedatei oder das Ausgabeverzeichnis zu verwendender Name. Standardmäßig \f[CR]image\f[R] oder, falls \f[CR]ImageId=\f[R] verwandt wird, wird dieser als standardmäßiger Ausgabename verwandt, optional wird die mit \f[CR]ImageVersion=\f[R] angegebene Version angehängt oder der Name des Abbildes wird gegenüber \f[CR]ImageId\f[R] bevorzugt, falls ein bestimmtes Abbild aus \f[CR]mkosi.images\f[R] gebaut wird. Beachten Sie, dass diese Option nicht die Konfiguration des Ausgabeverzeichnisses ermöglicht, verwenden Sie dafür \f[CR]OutputDirectory=\f[R]. .RS .PP Beachten Sie, dass dies nur den Ausgabepräfix festlegt, der vollständige Ausgabename kann abhängig von dem festgelegten Ausgabeformat, der verwandten Komprimierung und Abbildversion \f[CR]image_7.8.raw.xz\f[R] sein.\fR .RE .TP \f[B]OutputExtension=\f[R], \f[B]\-\-output\-extension=\fR Verwenden die angegebene Erweiterung für die Augabedatei. Standardmäßig die angemessene Erweiterung, basierend auf dem Ausgabeformt. Enthält nur die Dateierweiterung, nicht die Komprimierungserweiterung, die an diese Erweiterung angehängt wird, falls Komprimierung aktiviert ist. .TP \f[B]CompressOutput=\f[R], \f[B]\-\-compress\-output=\fR Konfiguriert die Komprimierung für das resultierende Abbild oder Archiv. Das Argument kann entweder ein logischer Wert oder ein Komprimierungsalgorithmus (\f[B]xz\f[R](1), \f[B]zstd\f[R](1)) sein. Standardmäßig wird die Komprimierung \f[B]zstd\f[R](1) sein, außer bei CentOS und abgeleiteten Distributionen bis Version 8, wo die Vorgabe \f[B]xz\f[R](1) ist und bei OCI\-Abbildern, wo die Vorgabe \f[B]gzip\f[R](1) ist. Beachten Sie, dass das Abbild nicht direkt gestartet werden kann, wenn Komprimierung auf Plattenabbildtypen angewendet wird, sondern erst eine Dekomprimierung erfolgen muss. Das bedeutet auch, dass die Unterbefehle \f[CR]shell\f[R], \f[CR]boot\f[R], \f[CR]vm\f[R] bei der Verwendung dieser Option nicht verfügbar sind. Impliziert für \f[CR]tar\f[R], \f[CR]cpio\f[R], \f[CR]uki\f[R], \f[CR]esp\f[R], \f[CR]oci\f[R] und \f[CR]addon\f[R].\fR .TP \f[CR]CompressLevel=\f[R], \f[CR]\-\-compress\-level=\fR Konfiguriert die zu verwendende Komprimierungsstufe. Akzeptiert eine Ganzzahl. Die möglichen Werte hängen von der verwandten Komprimierung ab. .TP \f[CR]OutputDirectory=\f[R], \f[CR]\-\-output\-directory=\f[R], \f[CR]\-O\fR Pfad zu einem Verzeichnis, in dem alle erstellten Artefakte abgelegt werden sollen. Falls dies nicht angegeben ist und das Verzeichnis \f[CR]mkosi.output/\f[R] im lokalen Verzeichnis existiert, dann wird dies automatisch für diesen Zweck verwandt.\fR .TP \f[CR]OutputMode=\f[R], \f[CR]\-\-output\-mode=\fR Dateizugriffsmodus, der bei der Erstellung der Ausgabe\-Abbild\-Datei verwandt wird. Akzeptiert einen Zugriffsmodus in oktaler Notation. Falls nicht gesetzt, wird die aktuelle Systemvorgabe verwandt. .TP \f[CR]ImageVersion=\f[R], \f[CR]\-\-image\-version=\fR Konfiguriert die Abbild\-Version. Dies akzeptiert jede Zeichenkette, es wird aber empfohlen, eine Reihe von durch Punkten getrennte Komponenten festzulegen. Die Version kann auch durch Lesen einer Datei \f[CR]mkosi.version\f[R] (in diesem Fall kann sie bequem mit dem Unterbefehl \f[CR]bump\f[R] oder der Option \f[CR]\-\-auto\-bump\f[R] verwaltet werden) oder durch Lesen der Standardausgabe, falls diese ausführbar ist (siehe den nachfolgenden Abschnitt \f[B]Skripte\f[R]), konfiguriert werden. Wenn dies angegeben ist, wird die festgelegte Abbildversion in den standardmäßigen Ausgabedateinamen aufgenommen, d.h. anstelle von \f[CR]image.raw\f[R] wird die Vorgabe \f[CR]image_0.1.raw\f[R] für Version \f[CR]0.1\f[R] des Abbildes oder ähnlich lauten. Die Version wird auch mittels \f[CR]$IMAGE_VERSION\f[R] an alle aufgerufenen Bauskripte übergeben (das könnte nützlich sein, um es in \f[CR]/usr/lib/os\-release\f[R] oder ähnliche einzubauen, insbesondere in das darin befindliche Feld \f[CR]IMAGE_VERSION=\f[R]).\fR .TP \f[B]ImageId=\f[R], \f[B]\-\-image\-id=\fR Konfiguriert den Abbildkennzeichner. Dies akzeptiert eine formlose Zeichenkette, die zur Kennzeichnung des Abbilds verwandt werden soll. Falls gesetzt, wird danach die Standard\-Ausgabedatei benannt (möglicherweise mit angehängter Version). Der Kennzeichner wird auch mittels \f[CR]$IMAGE_ID\f[R] an alle aufgerufenen Bauskripte übergeben. Die Abbildkennzeichnung wird automatisch zu \f[CR]/usr/lib/os\-release\f[R] hinzugefügt.\fR .TP \f[B]SplitArtifacts=\f[R], \f[B]\-\-split\-artifacts=\fR Die Artekfaktypen, die aus dem endgültigen Abbild herausgenommen werden sollen. Eine Kommata\-getrennte Liste, die aus \f[B]uki\f[R], \f[B]kernel\f[R], \f[B]initrd\f[R], \f[B]os\-release\f[R], \f[B]prcs\f[R], \f[B]partitions\f[R], \f[B]roothash\f[R], \f[B]kernel\-modules\-initrd\f[R], \f[B]repart\-definitions\f[R] und \f[B]tar\f[R] besteht. Beim Bauen eines selbststartenden Abbildes entsprechen \f[B]kernel\f[R] und \f[B]initrd\f[R] ihren im Abbild (oder dem UKI) gefundenen Artefakten, während \f[B]uki\f[R] das gesamte UKI herauskopiert.\fR Wird \f[CR]pcrs\f[R] angegeben, wird eine JSON\-Datei, die den vorberechneten TPM2\-Hash enthält, rausgeschrieben, entsprechend der .UR https://uapi\-group.org/specifications/specs/unified_kernel_image/#json\-format\-for\-pcrsig UKI\-Spezifikation .UE . Dies ist für die Offline\-Signierung nützlich.\fR .RS .PP Beim Bau eines Plattenabbildes und wenn \f[B]partitions\f[R] angegeben ist, wird \f[B]\-\-split=yes\f[R] an \f[B]systemd\-repart\f[R](8) übergeben, damit dies getrennte Partitionsdateien für jede konfigurierte Partition schreibt. Lesen Sie die .UR https://www.freedesktop.org/software/systemd/man/systemd\-repart.html#\-\-split=BOOL Handbuchseite .UE für weitere Informationen. Dies ist für A/B\-Aktualisierungsszenarien nützlich, bei denen ein bestehendes Plattenabbild mit einer neuen Version einer Wurzel\- oder \f[I]/usr\f[R]\-Partition zusammen mit der zugehörigen Verity\-Partition und einem vereinigten Kernel erweitert werden soll.\fR .PP Wenn \f[B]tar\f[R] angegeben ist, wird das Rootfs zusätzlich als Tar\-Archiv archiviert (entsprechend \f[B]CompressOutput=\f[R] komprimiert).\fR .PP Wenn \f[B]roothash\f[R] angegeben ist und ein dm\-verity\-Plattenabbild gebaut wird, wird der dm\-verity\-Wurzelhash als separate Datei rausgeschrieben, was für Offline\-Signaturen praktisch ist.\fR .PP \f[B]kernel\-modules\-initrd\f[R] entspricht den getrennten Kernelmodul\-Initrds, die \f[B]mkosi\fR an die Haupt\-Initird anhängt. Dies ist hauptsächlich für die Fehlersuche gedacht, da viele Initrd\-Untersuchungswerkzeuge nicht mit mehreren, aneinandergehängten Initrds umgehen können.\fR .PP Wenn \f[B]repart\-definitions\f[R] angegeben ist, wird ein Verzeichnis, das die verwandten Repart\-Definitionslisten enthält, in die Standardausgabe geschrieben. Falls mittels \f[B]RepartDirectories=\f[R] mehrere Verzeichnisse konfiguriert sind, werden sie zusammengeführt, wobei spätere Verzeichnisse gegenüber früheren Priorität haben, wenn Dateien mit identischem Namen existieren.\fR .PP Standardmäßig werden \f[B]uki\f[R], \f[B]kernel\f[R] und \f[B]initrd\f[R] herausgetrennt.\fR .RE .TP \f[B]RepartDirectories=\f[R], \f[B]\-\-repart\-directory=\fR Pfade zu Verzeichnissen, die Partitionsdefinitionsdateien von \f[B]systemd\-repart\f[R](8) enthalten, die verwandt werden, wenn \f[B]mkosi\f[R] \f[B]systemd\-repart\f[R](8) beim Bau eines Plattenabbildes aufruft. Falls \f[CR]mkosi.repart/\f[R] im lokalen Verzeichnis existiert, wird es für diesen Zweck auch verwandt. Beachten Sie, dass \f[B]mkosi\f[R] Repart mit \f[CR]\-\-root=\f[R] aufruft, um die Wurzel auf die Wurzel des Abbildes zu setzen, daher werden alle Quellpfade \f[CR]CopyFiles=\f[R] in Partitionsdefinitionsdateien relativ zum Wurzelverzeichnis des Abbildes sein.\fR .TP \f[B]SectorSize=\f[R], \f[B]\-\-sector\-size=\fR Setzt die Standardsektorgröße, die \f[B]systemd\-repart\f[R](8) zum Bau eines Plattenabilds benutzt, außer Kraft. .TP \f[B]Overlay=\f[R], \f[B]\-\-overlay=\fR Bei der Verwendung zusammen mit \f[CR]BaseTrees=\f[R] wird die Ausgabe nur aus Änderungen an den angegebenen Basisbäumen bestehen. Jeder Basisbaum wird als untere Lage in einer Overlayfs\-Struktur angehängt und die Ausgabe wird die obere Lage, die am Anfang leer ist. Daher werden Dateien, die sich gegenüber dem Basisbaum nicht ändern, nicht in der abschließenden Ausgabe enthalten sein. .RS .PP Diese Option kann dazu verwandt werden, .UR https://uapi\-group.org/specifications/specs/extension_image Systemd \f[I]Systemerweiterungen\f[R] .UE zu erstellen\&.\fR .RE .TP \f[B]Seed=\f[R], \f[B]\-\-seed=\fR Akzeptiert eine UUID oder den besonderen Wert \f[CR]random\f[R] als Argument. Setzt den von \f[B]systemd\-repart\f[R](8) beim Bau des Plattenabbildes verwandten Zufallsstartwert außer Kraft. Dies ist zur Erstellung wiederholbarer Bauten nützlich, bei denen vorhersehbare UUIDs und andere Partitionsmetadaten bei jedem Bau abgeleitet werden können sollen. Falls nicht explizit angegeben und die Datei \f[CR]mkosi.seed\f[R] im lokalen Verzeichnis existiert, wird daraus die zu verwendende UUID gelesen. Andernfalls wird eine zufällige UUID verwandt.\fR .TP \f[CR]CleanScripts=\f[R], \f[CR]\-\-clean\-script=\fR Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als Bereinigungsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt \f[B]SKRIPTE\f[R] für weitere Informationen.\fR .SS "Abschnitt [Content]" .TP \f[CR]Packages=\f[R], \f[CR]\-\-package=\f[R], \f[CR]\-p\fR Installiert die angegebenen Distributionspakete (z.B. \ RPM, deb, …) in dem Abbild. Akzeptiert eine Kommata\-getrennte Liste von Paketangaben. Diese Option kann mehrfach verwandt werden; dann werden die angegebenen Paketlisten kombiniert. Verwenden Sie \f[CR]BuildPackages=\f[R], um Pakete anzugeben, die nur in einer Überlagerung installiert werden, die eingehängt wird, wenn die Vorbereitungsskripte mit dem Argument \f[CR]build\f[R] ausgeführt werden und wenn die Bauskripte ausgeführt werden.\fR .RS .PP Die Arten und Syntax der erlaubten \f[I]Paketangaben\f[R] hängen von dem Paketinstallationsprogramm ab (z.B.\ \f[B]dnf\f[R] für \f[B]rpm\f[R](8)\-basierte Distributionen oder \f[B]apt\f[R](8) für \f[B]deb\f[R](5)\-basierte Distributionen), kann aber Paketnamen, Paketnamen mit Versionen und/oder Architektur, Paketnamen\-Globs, Paketgruppen und virtuelle Bereitstellungen (»provides«), einschließlich Dateipfaden, enthalten.\fR .PP Siehe \f[B]PackageDirectories=\f[R] zu Informationen darüber, wie lokale Pakete zur Installation mit \f[B]Packages=\f[R] verfügbar gemacht werden können.\fR .PP \f[B]Beispiel\f[R]: Bei der Verwendung einer Distribution, die \f[B]dnf\f[R] verwendet, würde die nachfolgende Konfiguration das Paket \f[B]meson\f[R](1) (in der neusten Version), die 32\-bit\-Version des Pakets \f[CR]libfdisk\-devel\f[R], alle verfügbaren Pakete, deren Namen mit \f[CR]git\-\f[R] beginnt, ein \f[B]systemd\f[R]\-RPM aus dem lokalen Dateisystem, eines der Pakete, das \f[CR]/usr/bin/ld\f[R] bereitstellt, die Pakete in der Gruppe \f[I]Development Tools\f[R] und das Paket, das das Python\-Modul \f[B]mypy\f[R](1) enthält, installieren.\fR .IP .EX Packages=meson libfdisk\-devel.i686 git\-* /usr/bin/ld \[at]development\-tools python3dist(mypy) .EE .RE .TP \f[CR]BuildPackages=\f[R], \f[CR]\-\-build\-package=\fR Ähnlich wie \f[CR]Packages=\f[R], konfiguriert aber Pakete, die nur in eine Überlagerung installiert werden, die oberhalb des Abbildes verfügbar gemacht wird, um Skripte vorzubereiten, die mit dem Argument \f[CR]build\f[R] ausgeführt werden, sowie den Bauskripten. Diese Option sollte zum Aufführen von Paketen verwandt werden, die Header\-Dateien, Compiler, Bausysteme, Linker und andere Bauwerkzeuge enthalten, die die Skripte \f[CR]mkosi.build\f[R] zur Ausführung benötigen. Beachten Sie, dass die hier aufgeführten Pakete im endgültigen Abbild nicht enthalten sein werden.\fR .TP \f[CR]VolatilePackages=\f[R], \f[CR]\-\-volatile\-package=\fR Ähnlich zu \f[CR]Packages=\f[R], aber Pakete, die mit dieser Einstellung konfiguriert sind, werden nicht zwischengespeichert, wenn \f[CR]Incremental=\f[R] aktiviert ist und werden nach der Ausführung aller Bauskripte installiert.\fR .RS .PP Insbesondere kann diese Einstellung zur Installation von Paketen verwandt werden, die sich oft ändern oder die durch ein Bauskript gebaut werden. .RE .TP \f[CR]PackageDirectories=\f[R], \f[CR]\-\-package\-directory=\fR Legt Verzeichnisse fest, die zusätzliche Pakete enthalten, die während des Baus verfügbar gemacht werden sollen. \f[B]mkosi\f[R] wird ein lokales Depot mit allen Paketen aus diesen Verzeichnissen erstellen und es beim Installieren von Paketen oder Ausführen von Skripten verfügbar machen. Falls das Verzeichnis \f[CR]mkosi.packages/\f[R] im lokalen Verzeichnis gefunden wird, wird es auch für diesen Zweck verwandt.\fR .TP \f[CR]VolatilePackageDirectories=\f[R], \f[CR]\-\-volatile\-package\-directory=\fR Ähnlich zu \f[CR]PackageDirectories=\f[R], aber sämtliche Änderungen an den Paketen in diesen Verzeichnissen werden die zwischengespeicherten Abbilder nicht für ungültig erklären, falls \f[CR]Incremental=\f[R] aktiviert ist.\fR .RS .PP Zusätzlich können Bauskripte weitere Pakete zu den lokalen Depots hinzufügen, indem sie gebaute Pakete in \f[CR]$PACKAGEDIR\f[R] ablegen. Die in \f[CR]$PACKAGEDIR\f[R] abgelegten Pakete werden von allen gebauten Abbildern gemeinsam benutzt und sind daher zur Installation in allen Abbildern mittels \f[CR]VolatilePackages=\f[R] verfügbar.\fR .RE .TP \f[B]WithRecommends=\f[R], \f[B]\-\-with\-recommends=\fR Konfiguriert, ob empfohlene Pakete oder schwache Abhängigkeiten installiert werden, abhängig davon, wie sie vom verwandten Paketverwalter benannt werden. Standardmäßig werden empfohlene Pakete nicht installiert. Dies wird nur von Paketverwaltern unterstützt, die dieses Konzept unterstützen. Derzeit sind dies \f[B]apt\f[R](8), \f[B]dnf\f[R](8) und \f[B]zypper\f[R](8). .TP \f[B]WithDocs=\f[R], \f[B]\-\-with\-docs=\fR Bindet Dokumentation in das Abbild ein. Standardmäßig aktiviert. Wenn deaktiviert, wird die Dokumentation in das Abbild nicht aufgenommen, falls der zugrundeliegende Paketverwalter das unterstützt. Die Umgebungsvariable \f[CR]$WITH_DOCS\f[R] wird an die Skripte \f[CR]mkosi.build\f[R] mit \f[CR]0\f[R] oder \f[CR]1\f[R] weitergegeben, abhängig davon, ob diese Option aktiviert oder deaktiviert ist.\fR .TP \f[B]BaseTrees=\f[R], \f[B]\-\-base\-tree=\fR Akzeptiert eine Komma\-getrennte Liste von Pfaden zu Verwendung als Basisbäume. Bei der Verwendung werden diese Basisbäume in die Betriebssystembäume kopiert und formen die Basisdistribution anstelle der normalen Installation. Es werden nur zusätzliche Pakete ergänzend zu den bereits in den Basisbäumen installierten Paketen installiert. Beachten Sie, dass das Basisabbild weiterhin die Paketverwaltermetadaten durch Setzen von \f[CR]CleanPackageMetadata=no\f[R] (siehe \f[CR]CleanPackageMetadata=\f[R]) enthalten muss, damit das korrekt funktioniert. .RS .PP Anstelle eines Verzeichnisses kann eine Tar\-Datei oder ein Plattenabbild bereitgestellt werden. In diesem Fall wird es in den Betriebssystembaum entpackt. Dieser Betriebsmodus erlaubt das explizite Setzen von Berechtigungen und Dateieigentümerschaften, insbesondere für Projekte, die in einem Versionsverwaltungssystem wie \f[B]git\f[R](1) gespeichert sind, das die Metadaten für die Dateieigentümerschaft und den Zugriffsmodus für übergebene Dateien vollständig beibehält.\fR .RE .TP \f[B]SkeletonTrees=\f[R], \f[B]\-\-skeleton\-tree=\fR Akzeptiert eine Kommata\-getrennte Liste von Doppelpunkt\-getrennten Pfadpaaren. Der erste Pfad jedes Paares bezieht sich auf ein Verzeichnis, das vor Aufruf des Paketverwalters in den Betriebssystembaum kopiert werden soll. Der zweite Pfad in jedem Paar bezieht sich auf das Zielverzeichnis innerhalb des Abbildes. Falls der zweite Pfad nicht bereit gestellt wird, wird das Verzeichnis auf das Wurzelverzeichnis des Abbildes kopiert. Der zweite Pfad wird immer als ein absoluter Pfad interpretiert. Verwenden Sie dies, um Dateien und Verzeichnisse in den Betriebssystembaum einzufügen, bevor der Paketverwalter irgendwelche Pakete installiert. Falls das Verzeichnis \f[I]mkosi.skeleton/\f[R] in dem lokalen Verzeichnis gefunden wird, wird es auch für diesen Zweck mit dem Wurzelverzeichnis als Ziel verwandt (siehe auch den nachfolgenden Abschnitt \f[B]DATEIEN\f[R]).\fR .RS .PP Beachten Sie, dass die Gerüstbäume zwischengespeichert werden und alle Änderungen an den Gerüstbäumen, nachdem ein zwischengespeichertes Abbild gebaut wurde (bei der Verwendung von \f[CR]Incremental=\f[R]), nur angewandt werden, wenn das zwischengespeicherte Abbild neu gebaut wird (durch Verwendung von \f[CR]\-ff\f[R] oder der Ausführung von \f[CR]mkosi \-f clean\f[R]).\fR .PP Gemäß der obigen Basisbaumlogik kann anstelle eines Verzeichnisses auch eine Tar\-Datei bereitgestellt werden. \f[CR]mkosi.skeleton.tar\f[R] wird automatisch verwandt, falls es im lokalen Verzeichnis gefunden wird.\fR .PP Um zusätzliche Paketverwalter\-Konfigurationsdateien wie zusätzliche Depots hinzuzufügen, verwenden Sie \f[CR]SandboxTrees=\f[R], da \f[B]mkosi\f[R] die Paketverwalter von außerhalb (und nicht innerhalb) des Abbildes aufruft und daher sämtliche mittels \f[CR]SkeletonTrees=\f[R] bereitgestellte Konfigurationsdateien nicht wirksam werden, wenn \f[B]mkosi\f[R] den Paketverwalter zur Installation von Paketen aufruft.\fR .RE .TP \f[B]ExtraTrees=\f[R], \f[B]\-\-extra\-tree=\fR Akzeptiert eine Kommata\-getrennte Liste von Doppelpunkt\-getrennten Pfadpaaren. Der erste Pfad jedes Paares bezieht sich auf ein Verzeichnis, das vom Wirtsystem in das Abbild kopiert werden soll. Der zweite Pfad in jedem Paar bezieht sich auf das Zielverzeichnis innerhalb des Abbildes. Falls der zweite Pfad nicht bereit gestellt wird, wird das Verzeichnis auf das Wurzelverzeichnis des Abbildes kopiert. Der zweite Pfad wird immer als ein absoluter Pfad interpretiert. Verwenden Sie dies, um beliebige, mit der Distribution ausgelieferte Standardkonfigurationsdateien außer Kraft zu setzen. Falls das Verzeichnis \f[I]mkosi.extra/\f[R] in dem lokalen Verzeichnis gefunden wird, wird es auch für diesen Zweck mit dem Wurzelverzeichnis als Ziel verwandt (siehe auch den nachfolgenden Abschnitt \f[B]DATEIEN\f[R]).\fR .RS .PP Gemäß der obigen Basisbaumlogik kann anstelle eines Verzeichnisses auch eine Tar\-Datei bereitgestellt werden. \f[CR]mkosi.extra.tar\f[R] wird automatisch verwandt, falls es im lokalen Verzeichnis gefunden wird.\fR .RE .TP \f[B]RemovePackages=\f[R], \f[B]\-\-remove\-package=\fR Akzeptiert eine Kommata\-getrennte Liste von Spezifikation von zu entfernenden Paketen, im gleichen Format wie \f[CR]Packages=\f[R]. Die Entfernung erfolgt als einer der letzten Schritte. Dieser Schritt wird übersprungen, falls \f[CR]CleanPackageMetadata=no\f[R] verwandt wird.\fR .TP \f[CR]RemoveFiles=\f[R], \f[CR]\-\-remove\-files=\fR Akzeptiert eine Kommata\-getrennte Liste von Globs. Dateien im Abbild, die auf die Globs passen, werden am Ende vollständig entfernt. .TP \f[CR]CleanPackageMetadata=\f[R], \f[CR]\-\-clean\-package\-metadata=\fR Aktiviert/Deaktiviert das Entfernen der Paketverwalter\-Datenbanken und Depot\-Metadaten am Ende der Installation. Kann als \f[CR]true\f[R], \f[CR]false\f[R] oder (die Vorgabe) \f[CR]auto\f[R] angegeben werden. Bei \f[CR]auto\f[R] werden die Paketverwalter\-Datenbanken und Depot\-Metadaten entfernt, falls das Programm des entsprechenden Paketverwalters am Ende der Installation \f[I]nicht\f[R] vorhanden ist.\fR .TP \f[B]SourceDateEpoch=\f[R], \f[B]\-\-source\-date\-epoch=\fR Akzeptiert einen Zeitstempel in Sekunden seit dem UNIX\-Epcoh als Argument. Dateiveränderungszeiten aller Dateien werden auf diesen Wert befestigt. Die Variable wird auch an \f[B]systemd\-repart\f[R](8) und alle von \f[B]mkosi\f[R] ausgeführten Skripte weitergegeben. Falls nicht explizit gesetzt, wird \f[B]SOURCE_DATE_EPOCH\f[R] aus \f[B]\-\-environment=\f[R] und aus der Umgebung des Wirtsystems in dieser Reihenfolge ausprobiert. Siehe .UR https://reproducible\-builds.org/specs/source\-date\-epoch/ SOURCE_DATE_EPOCH .UE für weitere Informationen.\fR .TP \f[B]SyncScripts=\f[R], \f[B]\-\-sync\-script=\fR Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als Synchronisationsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt \f[B]SKRIPTE\f[R] für weitere Informationen.\fR .TP \f[B]PrepareScripts=\f[R], \f[B]\-\-prepare\-script=\fR Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als Vorbereitungsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt \f[B]SKRIPTE\f[R] für weitere Informationen.\fR .TP \f[CR]BuildScripts=\f[R], \f[CR]\-\-build\-script=\fR Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als Bauskripte für dieses Abbild verwandt werden. Siehe den Abschnitt \f[B]SKRIPTE\f[R] für weitere Informationen.\fR .TP \f[CR]PostInstallationScripts=\f[R], \f[CR]\-\-postinst\-script=\fR Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als Post\-Installationsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt \f[B]SKRIPTE\f[R] für weitere Informationen.\fR .TP \f[B]FinalizeScripts=\f[R], \f[B]\-\-finalize\-script=\fR Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als Finalisierungsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt \f[B]SKRIPTE\f[R] für weitere Informationen.\fR .TP \f[B]PostOutputScripts=\f[R], \f[B]\-\-postoutput\-script=\fR Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als Post\-Ausgabeskripte für dieses Abbild verwandt werden. Siehe den Abschnitt \f[B]SKRIPTE\f[R] für weitere Informationen.\fR .TP \f[B]Bootable=\f[R], \f[B]\-\-bootable=\fR Akzeptiert einen logischen Wert oder \f[CR]auto\f[R]. Aktiviert oder deaktiviert die Erstellung eines startfähigen Abbildes. Falls aktiviert, wird \f[B]mkosi\f[R] ein EFI\-Systemstartprogramm installieren und eine ESP\-Partition hinzufügen, wenn die Plattenabbildausgabe verwandt wird. Falls das ausgewählte EFI\-Systemstartprogramm (siehe \f[CR]Bootloader=\f[R]) nicht installiert ist oder keine Kernelabbilder gefunden werden können, wird der Bau fehlschlagen. \f[CR]auto\f[R] verhält sich so, als ob die Option aktiviert wäre, aber der Bau schlägt nicht fehl, falls entweder kein Kernelabbild oder das ausgewählte EFI\-Systemstartprogramm nicht gefunden werden kann. Falls deaktiviert, wird kein Systemstartprogramm installiert, selbst falls es innerhalb des Abbildes gefunden wird, kein vereinigtes Kernelabbild wird erstellt und keine ESP\-Partition wird zu dem Abbild hinzugefügt, falls das Plattenausgabeformat verwandt wird.\fR .RS .PP Falls das Ausgabeformat \f[B]esp\f[R] verwandt wird, werden immer eine ESP\-Partition und ein Systemstartprogramm hinzugefügt und die Option \f[B]Bootable=\f[R] steuert nur, ob ein UKI in der ESP\-Partition hinzgefügt wird.\fR .RE .TP \f[CR]Bootloader=\f[R], \f[CR]\-\-bootloader=\fR Akzeptiert entweder \f[CR]none\f[R], \f[CR]systemd\-boot\f[R], \f[CR]uki\f[R], \f[CR]grub\f[R], \f[CR]systemd\-boot\-signed\f[R], \f[CR]uki\-signed\f[R] oder \f[CR]grub\-signed\f[R]. Standardmäßig \f[CR]systemd\-boot\f[R]. Falls auf \f[CR]none\f[R] gesetzt, wird kein EFI\-Systemstartprogramm in das Abbild installiert. Falls auf \f[CR]systemd\-boot\f[R] gesetzt, wird \f[B]systemd\-boot\f[R](7) installiert und für jeden installierten Kernel ein UKI erstellt und in \f[CR]EFI/Linux\f[R] im ESP gespeichert. Falls auf \f[CR]uki\f[R] gesetzt, wird ein einzelnes UKI für den neuesten installierten Kernel (demjenigen mit der höchsten Version), der in \f[CR]EFI/BOOT/BOOTX64.EFI\f[R] im ESP installiert ist, generiert. Falls auf \f[CR]grub\f[R] gesetzt, wird für jeden installierten Kernel ein UKI erstellt und in \f[CR]EFI/Linux\f[R] im ESP gespeichert. Für jeden erstellten UKI wird ein Menüeintrag zu der Grub\-Konfiguration in \f[CR]grub/grub.cfg\f[R] im ESP hinzugefügt, der in den UKI weiterlädt. Zur Anpassung wird ein grub.cfg auch nach \f[CR]EFI//grub.cfg\f[R] aus Kompatibilitätsgründen mit signierten Versionen von Grub \f[CR]grub/grub.cfg\f[R] im ESP geschrieben, da diese die Konfiguration von diesem Ort laden.\fR .RS .PP Die Varianten \f[CR]signed\f[R] werden nur von Distributionen ausgelieferte, vorab\-signierte EFI\-Programme installieren.\fR .PP Kernel müssen unter \f[CR]/usr/lib/modules/$version\f[R] mit Namen \f[CR]vmlinux\f[R] oder \f[CR]vmlinuz\f[R] im Wurzeldateisystem abgelegt werden (beispielsweise mittels \f[CR]ExtraTrees=\f[R]). Das \f[CR]$version\f[R] lautet genau so, wie das Make\-Ziel \f[CR]kernelversion\f[R] von Kbuild es erstellt. .PP Hinweis: Bei der Verwendung von \f[B]systemd\-boot\f[R] oder \f[B]systemd\-boot\-signed\f[R] erwartet \f[B]mkosi\f[R], dass die \f[B]systemd\-boot\f[R]\-EFI\-Programme im Abbild vorhanden sind. Abhängig von Ihrer Distribution, könnten diese separat paketiert sein. Beispielsweise benötigen Debian\-basierter Abbilder \f[B]systemd\-boot\-efi\f[R].\fR .RE .TP \f[B]BiosBootloader=\f[R], \f[B]\-\-bios\-bootloader=\fR Akzeptiert entweder \f[CR]none\f[R] oder \f[CR]grub\f[R]. Standardmäßig \f[CR]none\f[R]. Falls auf \f[CR]none\f[R] gesetzt, wird kein BIOS\-Systemstartprogramm installiert. Falls auf \f[CR]grub\f[R] gesetzt, wird Grub als BIOS\-Systemstartprogramm installiert, falls ein startfähiges Abbild mit der Option \f[CR]Bootable=\f[R] erbeten wird. Falls keine Repart\-Partitionsdefinitionsdateien konfiguriert sind, wird \f[B]mkosi\f[R] eine Grub\-BIOS\-Systemstartpartition und eine EFI\-Systempartition zu den Standard\-Partitionsdefinitionsdateien hinzufügen. .RS .PP Beachten Sie, dass diese Option sich nicht mit der Option \f[CR]Bootloader=\f[R] gegenseitig ausschließt. Es ist möglich, ein Abbild zu haben, das sowohl unter UEFI als auch BIOS startet, indem sowohl \f[CR]Bootloader=\f[R] als auch \f[CR]BiosBootloader=\f[R] konfiguriert wird.\fR .PP Die Grub\-BIOS\-Systemstartpartition sollte die UUID \f[CR]21686148\-6449\-6e6f\-744e\-656564454649\f[R] haben und mindestens 1 MB groß sein.\fR .PP Selbst wenn kein EFI\-Systemstartladeprogramm installiert ist, wird dennoch ein ESP für BIOS\-Systemstarts benötigt, da dort der Kernel, die Initrd und Grub\-Module gespeichert werden. .RE .TP \f[CR]ShimBootloader=\f[R], \f[CR]\-\-shim\-bootloader=\fR Akzeptiert entweder \f[CR]none\f[R], \f[CR]unsigned\f[R] oder \f[CR]signed\f[R]. Standardmäßig \f[CR]none\f[R]. Falls auf \f[CR]none\f[R] gesetzt, werden Shim und MokManager nicht in die ESP installiert. Falls auf \f[CR]unsigned\f[R] gesetzt, wird \f[B]mkosi\f[R] nach unsignierten Shim\- und MokManager\-EFI\-Programmen suchen und sie installieren. Falls \f[CR]SecureBoot=\f[R] aktiviert ist, wird \f[B]mkosi\f[R] vor der Installation die unsignierten EFI\-Programme signieren. Falls auf \f[CR]signed\f[R] gesetzt, wird \f[B]mkosi\f[R] nach signierten EFI\-Programmen suchen und sie installieren. Selbst wenn \f[CR]SecureBoot=\f[R] aktiviert ist, wird \f[B]mkosi\f[R] die Programme nicht erneut signieren.\fR .RS .PP Beachten Sie, dass diese Option nur wirksam wird, wenn ein auf UEFI\-Firmware startfähiges Abbild mittels anderer Optionen angefragt wird (\f[CR]Bootable=\f[R], \f[CR]Bootloader=\f[R]).\fR .PP Beachten Sie, dass \f[B]mkosi\f[R] nur bereits signierte Systemladeprogramme, Kernelabbilddateien und vereinigte Kernelabbilder installieren wird, wenn diese Option aktiviert ist, da selbstsignierte Programme von signierten Versionen von Shim nicht akzeptiert würden. .RE .TP \f[B]UnifiedKernelImages=\f[R], \f[B]\-\-unified\-kernel\-images=\fR Gibt an, ob vereinigte Kernelabbilder verwandt werden sollen, wenn \f[B]Bootloader=\f[R] auf \f[B]systemd\-boot\f[R] oder \f[B]grub\f[R] gesetzt ist. Akzeptiert \f[B]none\f[R], \f[B]unsigned\f[R], \f[B]signed\f[R] oder \f[B]auto\f[R]. Standardmäßig \f[B]auto\f[R]. Falls \f[B]unsigned\f[R] oder \f[B]signed\f[R], werden vereinigte Kernelabbilder immer verwandt und der Bau wird fehlschlagen, falls eine der für den Bau von vereinigten Kernelabbildern benötigten Komponenten fehlt. Falls auf \f[B]auto\f[R] gesetzt, werden vereinigte Kernelabbilder verwandt, falls alle benötigten Komponenten verfügbar sind. Andernfalls werden stattdessen Typ\-1\-Einträge, wie in der Systemstartladerspezifikation definiert, verwandt. Falls deaktiviert, werden Typ\-1\-Einträge immer verwandt. \f[B]Bootloader=\f[R] wird auf eine der signierten Varianten gesetzt, ein vorab gebautes UKI wird durchsucht und der Bau wird fehlschlagen, falls es nicht gefunden werden kann, außer wenn \f[B]UnifiedKernelImages=\f[R] auf \f[B]unsigned\f[R] gesetzt ist. In diesem Fall wird das UKI lokal gebaut. Dies ist nützlich, wenn dies mit der auf \f[B]custom\f[R] gesetzten Laufzeitoption \f[B]Firmware=\f[R] kombiniert wird, so dass der lokal signierte Schlüssel in der UEFI\-Datenbank registriert wird.\fR .TP \f[B]UnifiedKernelImageFormat=\f[R], \f[B]\-\-unified\-kernel\-image\-format=\fR Akzeptiert einen Dateinamen ohne irgendeine Pfadkomponente, um das Format festzulegen, in dem vereinigte Kernelabbilder installiert werden sollen. Dies kann sowohl die normalen Kennzeichner (siehe \f[B]Kennzeichner\f[R]) als auch besondere verzögerte Kennzeichner festlegen, die während der Installation von Dateien expandiert und die nachfolgend beschrieben werden. Das Standardformat für diesen Parameter lautet \f[CR]&e\-&k\f[R] wobei \f[CR]\-&h\f[R] angehängt wird, falls \f[CR]roothash=\f[R] oder \f[CR]usrhash=\f[R] auf der Kernelbefehlszeile gefunden wird und \f[CR]+&c\f[R] falls \f[CR]/etc/kernel/tries\f[R] im Abbild gefunden wird.\fR .RS .PP Die folgenden Kennzeichner können außerdem verwendet werden: .PP .TS tab(@); l l. T{ Kennzeichner T}@T{ Wert T} _ T{ \f[CR]&&\fR T}@T{ \f[CR]&\f[R]\-Zeichen\fR T} T{ \f[CR]&e\fR T}@T{ \f[R]Zugangsmerkmal\fR T} T{ \f[CR]&k\fR T}@T{ \f[R]Kernelversion\fR T} T{ \f[CR]&h\fR T}@T{ Wert des Kernelarguments \f[CR]roothash=\f[R] oder \f[CR]usrhash=\f[R]\fR T} .TE .RE .TP \f[CR]UnifiedKernelImageProfiles=\f[R], \f[CR]\-\-uki\-profile=\fR Baut zusätzliche UKI\-Profile. Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu UKI\-Profil\-Konfigurationsdateien. Diese Option kann mehrfach angegeben werden. Dann wird jede Konfiguration in das entsprechende UKI\-Profil gebaut. Konfigurationsdateien im Verzeichnis \f[CR]mkosi.uki\-profiles/\f[R] werden automatisch aufgenommen. Alle konfigurierten UKI\-Profile werden als zusätzliche UKI\-Profile für jedes von \f[B]mkosi\f[R] gebaute UKI hinzugefügt.\fR .RS .PP Siehe die Dokumentation für den Abschnitt \f[CR]UKIProfile\f[R] zu Informationen, welche Einstellungen in UKI\-Profil\-Konfigurationsdateien vorgenommen werden können. .RE .TP \f[B]Initrds=\f[R], \f[B]\-\-initrd=\fR Verwendet vom Benutzer bereitgestellte Initrd(s). Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Initrd\-Dateien. Diese Option kann mehrfach angewendet werden. Dann werden die aufgeführten Initrd\-Listen kombiniert. Falls keine Initrds angegeben sind und ein startfähiges Medium erbeten wurde, wird \f[B]mkosi\f[R] automatisch eine Standard\-Initrd bauen.\fR .RS .PP \f[B]mkosi\f[R] wird auch nach Initrds in einem Unterverzeichnis \f[I]io.mkosi.initrd\f[R] des Artefakt\-Verzeichnisses suchen (siehe \f[I]$ARTIFACTDIR\f[R] in dem Abschnitt \f[B]UMGEBUNGSVARIABLEN\f[R]). Alle dort gefundenen Initrds werden an das oder die vom Benutzer bereitgestellt(en) und alle von \fB[B]mkosi\fR gebauten Vorgabe\-Initrds angehängt\fR .RE .TP \f[B]InitrdProfiles=\f[R], \f[B]\-\-initrd\-profile=\fR Setzt das Profil, das für die Standard\-Initrd aktiviert werden soll. Akzeptiert eine Kommata\-getrennte Liste von Profilen. Standardmäßig sind alle Profile deaktiviert. .RS .PP Das Profil \f[B]lvm\f[R] aktiviert Unterstützung für LVM. Das Profil \f[B]network\f[R] aktiviert Unterstützung für Netzwerk mittels \f[B]systemd\-networkd\f[R](8). Das Profil \f[B]nfs\f[R] aktiviert Unterstützung für NFS. Es benötigt Netzwerkunterstützung in der Initrd, mittels des Profils \f[B]network\f[R] oder einer anderen, angepassten Methode. Das Profil \f[B]pkcs11\f[R] aktiviert Unterstützung für PKCS#11. Das Profil \f[B]plymouth\f[R] stellt eine graphische Schnittstelle für den Systemstart bereit (Animation und Passworteingabe). Das Profil \f[B]raid\f[R] aktiviert Unterstützung für RAID\-Systeme.\fR .RE .TP \f[CR]InitrdPackages=\f[R], \f[CR]\-\-initrd\-package=\fR Extra\-Pakete, die in die Standard\-Initrd installiert werden sollen. Akzeptiert eine Kommata\-getrennte Liste von Paketspezifikationen. Diese Option kann mehrfach angewendet werden. Dann werden die aufgeführten Paketlisten kombiniert. .TP \f[CR]InitrdVolatilePackages=\f[R], \f[CR]\-\-initrd\-volatile\-package=\fR Ähnlich zu \f[CR]VolatilePackages=\f[R], außer das es auf die Standard\-Initrd angewandt wird.\fR .TP \f[B]Devicetrees=\f[R], \f[B]\-\-devicetrees=\fR Kommata\-getrennte Liste von Devicetree\-Mustern für die automatische, Hardware\-basierte Auswahl. Muster sind Glob\-Ausdrücke. \f[B]mkosi\f[R] sucht an den Standardorten relativ zu \f[I]/usr/lib/modules//dtb/\f[R], \f[I]/usr/lib/firmware//device\-tree/\f[R] und \f[I]/usr/lib/linux\-image\-/\f[R] nach Devictree\-Dateien.\fR .RS .PP Für UKI\-Bauten aktivieren mehrere Treffer die automatische, Hardware\-basierte Auswahl mittels der Abschnitte \f[B].dtbauto\f[R]. Für Typ\-1\-Systemstarteinträge wird genau ein Treffer benötigt.\fR .PP Beispiel: \f[B]Devicetrees=rockchip/*,imx.*\f[R] würde alle Rockchip\-Devicetrees und alle IMX\-Devicetrees aufnehmen.\fR .RE .TP \f[B]Splash=\f[R], \f[B]\-\-splash=\fR Wenn gesetzt, wird der Systemstart\-Startbildschirm für alle durch \f[B]mkosi\f[R] gebauten vereinigten Kernelabbilder aus dem angegebenen Pfad innerhalb des Abbilds aufgenommen.\fR .TP \f[B]MicrocodeHost=\f[R], \f[B]\-\-microcode\-host=\fR Wenn auf true gesetzt, wird nur der Mikrocode für die CPU des Wirtsystems in das Abbild aufgenommen. .TP \f[B]KernelCommandLine=\f[R], \f[B]\-\-kernel\-command\-line=\fR Verwendet beim Bau von Abbildern die angegebene Kernelbefehlszeile. .RS .PP Falls die Wurzel\- oder Verity\-Partition mit aktiviertem Verity erstellt werden, werden \f[CR]roothash=\f[R] bzw. \f[CR]usrhash=\f[R] automatisch zu der Kernel\-Befehlszeile hinzugefügt und \f[CR]root=\f[R] oder \f[CR]mount.usr=\f[R] sollten nicht hinzugefügt werden. Andernfalls, falls der Wert dieser Einstellung die selbstdeutenden Symbole \f[CR]root=PARTUUID\f[R] oder \f[CR]mount.usr=PARTUUID\f[R] enthält, werden diese mit der Partitions\-UUID der Wurzel\- bzw. usr\-Partition ersetzt. Beispielsweise würde \f[CR]root=PARTUUID\f[R] durch \f[CR]root=PARTUUID=58c7d0b2\-d224\-4834\-a16f\-e036322e88f7\f[R] ersetzt, wobei \f[CR]58c7d0b2\-d224\-4834\-a16f\-e036322e88f7\f[R] die Partitions\-UUID der Wurzelpartition ist.\fR .RE .TP \f[B]KernelModules=\f[R], \f[B]\-\-kernel\-modules=\fR Akzeptiert eine Liste von Glob\-Muster, die festlegen, welche Kernel\-Module im Abbild aufgenommen werden sollen. Jedem Argument kann ein Gedankenstrich (\f[B]\-\f[R]) zum \f[I]Ausschluss\[R] 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\-Abhängigkeiten.\fR .RS .PP Die Endung \f[B].ko\f[R] und Kompressionsendungen werden beim Vergleich ignoriert.\fR .PP Globs werden mit Modulpfaden relativ zu \f[I]/usr/lib/module/\f[R] verglichen, z.B. wird das Modul zum Zweck des Vergleichs unter \f[I]/usr/lib/module//kernel/foo/bar.ko.xz\f[R] zu \f[I]kernel/foo/bar\f[R].\fR .PP Mit »/« beginnende Globs werden besonders behandelt. Der Glob wird \f[I]zuerst\f[R] mit einem Pfad relativ zu \f[I]/usr/lib/module//kernel\f[R] verglichen und nur dann mit \f[I]/usr/lib/module//\f[R]. Dies dient der Bequemlichkeit, da normalerweise nur die Baum\-internen Module unter \f[I]kernel/\f[R] von Interesse sind.\fR .PP Beispielsweise kann das Modul unter \f[I]/usr/lib/module//kernel/foo/bar.ko.xz\f[R] entweder mit \f[I]/foo/bar\f[R] oder \f[I]/kernel/foo/bar\f[R] verglichen werden.\fR .PP Das Glob\-Muster kann einfach nur den Basisnamen enthalten (z.B. \f[B]loop\f[R]), der auf den Basisnamen des Moduls passen muss, den relativen Pfad (z.B. \f[I]block/loop\f[R]), das auf die abschließenden Komponenten des Modulpfades bis zum Basisnamen passen muss oder ein absoluter Pfad (z.B. \f[I]/drivers/block/loop\f[R]), der auf den vollständigen Pfad zum Modul passen muss.\fR .PP Wird \f[B]/\f[R] angehängt, dann passt das Muster auf alle Module unterhalb dieses Verzeichnisses.\fR .PP Die Muster können Shell\-artige Globs (\f[B]*\f[R], \f[B]?\f[R], \f[B][…\-…]\f[R]) enthalten.\fR .PP Falls der besondere Wert \f[CR]default\f[R] verwandt wird, werden auch die in der Konfiguration \f[B]mkosi\-initrd\f[R] definierten Standard\-Kernelmodule aufgenommen.\fR .PP Falls der besondere Wert \f[CR]host\f[R] verwandt wird, werden auch die auf dem Wirtsystem aktuell geladenen Module aufgenommen.\fR .RE .TP \f[CR]KernelModulesInitrd=\f[R], \f[CR]\-\-kernel\-modules\-initrd=\fR Logischer Wert, standardmäßig aktiviert (true). Falls beim Bau eines Abbildes aktiviert, wird \f[B]mkosi\f[R] eine zusätzliche Initrd für jedes von ihm zusammengebaute vereinigte Kernelabbild erstellen. Diese Initrd enthält nur Module und möglicherweise Firmware. Sie wird dann an die Basis\-Initrd angehängt, um die abschließende Initrd zu bilden. Dadurch bleibt die Basis\-Initrd Kernel\-unabhängig und ergänzt nur die Argumente mit ihren notwendigerweise kernelversions\-abhängigen Modulen, wenn das UKI zusammengebaut wird.\fR .RS .PP Falls deaktiviert, wird kein zusätzliches Initrd erstellt. Beachten Sie, dass die Kernelmodule weiterhin \f[B]nicht\f[R] in die Basis\-Initrd aufgenommen werden, die Kernel\-unabhängig verbleibt. Stattdessen wird angenommen, dass der Benutzer die notwendigen Kernelmodule (falls sie existieren) in einer zusätzlichen, angepassten Initrd bereitstellt.\fR .RE .TP \f[B]KernelInitrdModules=\f[R], \f[B]\-\-kernel\-modules\-initrd\-include=\fR Wie \f[B]KernelModules=\f[R], legt aber die in der Initrd einzubindenden Kernelmodule fest.\fR .TP \f[B]FirmwareFiles=\f[R], \f[B]\-\-firmware\-files=\fR Akzeptiert eine Liste von Glob\-Muster, die die im Abbild einzubindende Firmware festlegt. Die Muster werden genau wie bei der Einstellung \f[B]KernelModules=\f[R] interpretiert, außer dass die Pfade relativ zum Unterverzeichnis \f[I]/usr/lib/firmware/ sind\f[R]. Die Komprimierungserweiterung wird ignoriert und darf in dem Muster nicht enthalten sein.\fR .RS .PP Firmware\-Abhängigkeiten von im Abbild installierten Kernel\-Modulen werden automatisch aufgenommen. .PP Beispiel: \f[B]FirmwareFiles=cxgb4/bcm8483.bin\f[R] oder \f[B]FirmwareFiles=bcm8483.*\f[R] würden beide dazu führen, dass \f[I]/usr/lib/firmware/cxgb4/bcm8483.bin.xz\f[R] aufgenommen würde, selbst wenn es nicht als Modul aufgeführt ist.\fR .RE .TP \f[CR]Locale=\f[R], \f[CR]\-\-locale=\f[R], \f[CR]LocaleMessages=\f[R], \f[CR]\-\-locale\-messages=\f[R], \f[CR]Keymap=\f[R], \f[CR]\-\-keymap=\f[R], \f[CR]Timezone=\f[R], \f[CR]\-\-timezone=\f[R], \f[CR]Hostname=\f[R], \f[CR]\-\-hostname=\f[R], \f[CR]RootShell=\f[R], \f[CR]\-\-root\-shell=\fR Die Einstellungen \f[CR]Locale=\f[R], \f[CR]\-\-locale=\f[R], \f[CR]LocaleMessages=\f[R], \f[CR]\-\-locale\-messages=\f[R], \f[CR]Keymap=\f[R], \f[CR]\-\-keymap=\f[R], \f[CR]Timezone=\f[R], \f[CR]\-\-timezone=\f[R], \f[CR]Hostname=\f[R], \f[CR]\-\-hostname=\f[R], \f[CR]RootShell=\f[R], \f[CR]\-\-root\-shell=\f[R] entsprechen den identisch benannten Systemd\-firstboot\-Optionen. Siehe \f[B]systemd\-firstboot\f[R](1) für weitere Informationen. Ergänzend werden, wo anwendbar, die entsprechenden Systemd\-Zugangsberechtigungen für diese Einstellungen nach \f[CR]/usr/lib/credstore\f[R] geschrieben, so dass sie selbst dann angewandt werden, wenn nur \f[CR]/usr\f[R] im Abbild ausgeliefert wird.\fR .TP \f[B]RootPassword=\f[R], \f[B]\-\-root\-password=\f[R],\fR Setzt das Root\-Passwort des Systems. Falls diese Option nicht verwandt wird, aber eine Datei \f[I]mkosi.rootpw\f[R] im lokalen Verzeichnis gefunden wird, wird das Passwort automatisch daraus gelesen oder falls die Datei ausführbar ist, wird sie als Skript ausgeführt und stattdessen wird die Standardausgabe gelesen (siehe den nachfolgenden Abschnitt \f[B]SKRIPTE\f[R]). Falls das Passwort mit \f[B]hashed:\f[R] beginnt, wird es als ein bereits gehashtes Passwort betrachtet. Das Root\-Passwort wird auch in \f[I]/usr/lib/credstore\f[R] unterhalb der entsprechenden Systemd\-Zugangsberechtigung gespeichert, so dass es selbst dann angewandt wird, wenn nur \f[I]/usr\f[R] im Abbild ausgeliefert wird. Um ein entsperrtes Konto ohne Passwort zu erstellen, verwenden Sie \f[B]hashed:\f[R] ohne einen Hash.\fR .TP \f[B]Autologin=\f[R], \f[B]\-\-autologin=\f[R], \f[B]\-a\fR Aktiviert die automatische Anmeldung für den Benutzer \f[CR]root\f[R] auf \f[CR]/dev/pts/0\f[R] (nspawn), \f[CR]/dev/tty1\f[R] und \f[CR]/dev/hvc0\f[R].\fR .TP \f[B]MakeInitrd=\f[R], \f[B]\-\-make\-initrd=\fR Fügt \f[CR]/etc/initrd\-release\f[R] und \f[CR]/init\f[R] zum Abbild hinzu, so dass es als ein Initramfs verwandt werden kann.\fR .TP \f[B]Ssh=\f[R], \f[B]\-\-ssh=\fR Gibt an, ob eine Socket\-Unit für \f[B]sshd\f[R](8) und passende Dienste in dem endgültigen Abbild installiert werden sollen. Akzeptiert entweder \f[B]always\f[R], \f[B]never\f[R], \f[B]auto\f[R] oder \f[B]runtime\f[R]. Standardmäßig \f[B]auto\f[R].\fR .RS .PP Falls auf \f[B]auto\f[R] gesetzt und \f[B]sshd\f[R](8) im Abbild vorhanden ist und das Generator\-Programm \f[B]systemd\-ssh\-generator\f[R] nicht vorhanden ist oder falls sie auf \f[B]always\f[R] gesetzt ist, wird \f[B]mkosi\f[R] \f[B]sshd\f[R]\-Units im endgültigen Abbild installieren, die SSH über VSock offenlegen. Falls auf \f[B]never\f[R] gesetzt, wird \f[B]mkosi\f[R] diese Units nicht installieren. Falls der Wert \f[B]runtime\f[R] verwandt wird, wird \f[B]mkosi\f[R] auch keine Units installieren, aber den Start von \f[B]mkosi vm\f[R] abbrechen, falls keine SSH\-Zugangsberechtigungen konfiguriert sind. Beim Bau mit dieser Option und dem Betrieb des Abbilds mittels \f[B]mkosi vm\f[R] kann der Befehl \f[B]mkosi ssh\f[R] zum Verbinden mit dem Container/der VM mittels SSH verwandt werden. Beachten Sie, dass Sie weiterhin sicherstellen müssen, dass Openssh im Abbild installiert ist, damit sich \f[B]mkosi ssh\f[R] korrekt verhält. Führen Sie \f[B]mkosi genkey\f[R] aus, um automatisch ein X.509\-Zertifikat und private Schlüssel zu erzeugen, die von \f[B]mkosi\f[R] zur Aktivierung vom SSH\-Zugriff zu jeder virtuellen Maschine mittels \f[B]mkosi ssh\f[R] verwandt werden. Um auf mittels \f[B]mkosi boot\f[R] gestartete Abbilder zuzugreifen, verwenden Sie \f[B]machinectl\f[R](1).\fR .PP Beginnend mit Systemd v256 wird \f[B]systemd\-ssh\-generator\fR(8) automatisch \f[B]sshd\f[R](8) über VSock bereitstellen, wenn er innerhalb einer VM ausgeführt 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 \f[B]\-\-vsock=auto\f[R] ist ausreichend um sicherzustellen, dass ein VSock innerhalb der VM verfügbar ist. .PP Hinweis: Falls die Distribution des Abbildes SELinux verwendet, wird der Dienst \f[B]sshd\f[R](8) von \f[B]mkosi\f[R] den Zugriff auf den VSock verweigern. Dies führt zu einem Verbindungsfehlschag vom Wirtsystem darauf. Sie müssen entweder die Durchsetzung von SELinux deaktivieren oder ein angepasstes Richtlinienmodul erstellen (z.B.\ mit \f[B]audit2allow\f[R](1)).\fR .RE .TP \f[B]SELinuxRelabel=\f[R], \f[B]\-\-selinux\-relabel=\fR Legt fest, ob Dateien neu markiert werden sollen, um auf die SELinux\-Richtlinie des Abbilds zu passen. Akzeptiert einen logischen Wert oder \f[B]auto\f[R]. Standardmäßig \f[B]auto\f[R]. Falls deaktiviert, werden Dateien nicht neu markiert. Falls aktiviert, muss eine SELinux\-Richtlinie im Abbild installiert werden und \f[B]setfiles\f[R](8) verfügbar sein, um Dateien zu markieren. Falls während \f[B]setfiles\f[R](8) irgendein Fehler auftritt, wird der Bau fehlschlagen. Falls auf \f[B]auto\f[R] gesetzt, werden Dateien neu markiert, falls \f[B]mkosi\f[R] kein Verzeichnisabbild baut, eine SELinux\-Richtlinie im Abbild installiert und \f[B]setfiles\f[R](8) verfügbar ist. Alle während \f[B]setfiles\f[R](8) aufgetretenen Fehler werden ignoriert.\fR .RS .PP Beachten Sie, dass bei der nicht privilegierten Ausführung \f[B]setfiles\f[R](8) beim Setzen von allen Markierungen fehlschlagen wird, die nicht in der SELinux\-Richtlinie des Wirtsystems sind. Um sicherzustellen, dass \f[B]setfiles\f[R](8) ohne Fehler erfolgreich ist, führen Sie \f[B]mkosi\f[R] als Root aus oder bauen Sie von einem Wirtsystem, das die gleichen SELinux\-Richtlinie wie im zu bauenden Abbild verwendet.\fR .RE .TP \f[B]MachineId=\f[R], \f[B]\-\-machine\-id=\fR Akzeptiert eine UUID oder den besonderen Wert \f[CR]random\f[R]. Setzt die Maschinenkennung des Abbildes auf die angegebene UUID. Falls auf \f[CR]random\f[R] gesetzt, wird eine zufällige UUID nach \f[CR]/etc/machine\-id\f[R] geschrieben. Falls nicht explizit angegeben und die Datei \f[CR]mkosi.machine\-id\f[R] im lokalen Verzeichnis existiert, wird die zu verwendende UUID daraus gelesen. Andernfalls wird \f[CR]uninitialized\f[R] nach \f[CR]/etc/machine\-id\f[R] geschrieben.\fR .SS "Abschnitt [Validation]" .TP \f[B]SecureBoot=\f[R], \f[B]\-\-secure\-boot=\fR Signiert \f[B]systemd\-boot\f[R](7) (falls es noch nicht signiert ist) und sämtliche vereinigten Kernelabbilder für UEFI SecureBoot.\fR .TP \f[B]SecureBootAutoEnroll=\f[R], \f[B]\-\-secure\-boot\-auto\-enroll=\fR Einrichtung der automatischen Registrierung der Schlüssel für sicheren Systemstart in virtuellen Maschinen falls \f[CR]SecureBoot=\f[R] verwandt wird, wie das in \f[B]systemd\-boot\f[R](7) beschrieben wird. Beachten Sie, dass \f[B]systemd\-boot\f[R](7) nur ab Systemd v253 die automatische Registrierung von Schlüsseln für sicheren Systemstart in virtuellen Maschinen durchführen wird. Um die automatische Registrierung unter Systemd v252 auf Maschinen ohne Virtualisierung durchzuführen, müssen Sie eine \f[B]systemd\-boot\f[R](7)\-Konfigurationsdatei nach \f[CR]/efi/loader/loader.conf\f[R] mittels eines zusätzlichen Baumes mit \f[CR]secure\-boot\-enroll force\f[R] oder \f[CR]secure\-boot\-enroll manual\f[R] darin schreiben. Unter Systemd\-Versionen älter als v252 wird keine automatische Registrierung unterstützt. Standardmäßig \f[CR]yes\f[R].\fR .TP \f[CR]SecureBootKey=\f[R], \f[CR]\-\-secure\-boot\-key=\fR Pfad zu der PEM\-Datei, die den geheimen Schlüssel zum Signieren des UEFI\-Kernelabbilds, falls \f[CR]SecureBoot=\f[R] verwandt wird und der PCR\-Signaturen, falls \f[CR]SignExpectedPcr=\f[R] auch verwandt wird, enthält. Wenn \f[CR]SecureBootKeySource=\f[R] angegeben ist, hängt der Eingabetyp von der Quelle ab.\fR .TP \f[B]SecureBootCertificate=\f[R], \f[B]\-\-secure\-boot\-certificate=\fR Pfad zu der X.509\-Datei, die das Zertifikat für das signierte UEFI\-Kernelabbild enthält, falls \f[CR]SecureBoot=\f[R] verwandt wird.\fR .TP \f[B]SecureBootSignTool=\f[R], \f[B]\-\-secure\-boot\-sign\-tool=\fR Werkzeug zum Signieren von PE\-Programmen für den sicheren Systemstart. Akzeptiert entweder \f[CR]systemd\-sbsign\f[R], \f[CR]sbsign\f[R] oder \f[CR]auto\f[R]. Standardmäßig \f[CR]auto\f[R]. Falls auf \f[CR]auto\f[R] gesetzt, wird (wenn verfügbar) entweder \f[B]systemd\-sbsign\fR(1) oder \f[B]sbsign\f[R](1) verwandt, wobei \f[B]systemd\-sbsign\f[R](1) bevorzugt wird.\fR .TP \f[B]Verity=\f[R], \f[B]\-\-verity=\fR Ob Verity für Erweiterungsabbilder erzwungen oder deaktiviert wird. Akzeptiert entweder\f[B]signed\f[R], \f[B]hash\f[R], \f[B]defer\f[R], \f[B]auto\f[R] oder einen logischen Wert. Falls auf \f[B]signed\f[R] gesetzt, muss ein Verity\-Schlüssel und \-Zertifikat vorhanden sein und der Bau wird fehlschlagen, falls keine Verity\-Partitionen in dem durch \f[B]systemd\-repart\f[R](8) erstellten Plattenabbild erkannt werden. Falls deaktiviert, werden Verity\-Partitionen von durch \f[B]systemd\-repart\f[R] erstellten Erweiterungsabbildern ausgeschlossen. Falls auf \f[B]hash\f[R] gesetzt, konfiguriert \f[B]mkosi\f[R] \f[B]systemd\-repart\f[R](8) so, dass eine Verity\-Hash\-Partition erstellt wird, aber keine Signatur\-Partition. Falls auf \f[B]defer\f[R] gesetzt, wird Platz für die Verity\-Signaturpartition reserviert, allerdings noch nicht befüllt. Falls auf \f[B]auto\f[R] gesetzt und ein Verity\-Schlüssel und \-Zertifikat vorhanden sind, wird \f[B]mkosi\f[R] sie an \f[B]systemd\-repart\f[R](8) weitergeben und erwartet, dass das erstellte Plattenabbild Verity\-Partitionen enthalten wird, aber der Bau wird nicht fehlschlagen, falls keine Verity\-Partitionen in dem durch \f[B]systemd\-repart\f[R](8) erstellten Plattenabbild gefunden werden.\fR .RS .PP Beachten Sie, dass das explizite Deaktivieren der Verity\-Signatur und/oder des Hashes für die Ausgabe \f[B]disk\f[R] noch nicht implementiert ist und derzeit nur für Erweiterungsabbilder funktioniert.\fR .RE .TP \f[B]VerityKey=\f[R], \f[B]\-\-verity\-key=\fR Pfad zu der PEM\-Datei, die den geheimen Schlüssel zum Signieren der Verity\-Signatur enthält, falls eine Verity\-Signaturpartition mit \f[B]systemd\-repart\f[R](8) hinzugefügt wird. Wenn \f[CR]VerityKeySource=\f[R] festgelegt wird, hängt der Eingabetyp von der Quelle ab.\fR .TP \f[B]VerityCertificate=\f[R], \f[B]\-\-verity\-certificate=\fR Pfad zu einer X.509\-Datei, die das Zertifikat zum Signieren der Verity\-Signatur enthält, falls eine Verity\-Signaturpartition mittels \f[B]systemd\-repart\f[R](8) hinzugefügt wird.\fR .TP \f[B]SignExpectedPcr=\f[R], \f[B]\-\-sign\-expected\-pcr=\fR Misst die Komponenten des vereinigten Kernelabbildes (UKI) mittels \f[B]systemd\-measure\f[R](1) und bettet die PCR\-Signatur in das vereinigte Kernelabbild ein. Diese Option akzeptiert einen logischen Wert oder den besonderen Wert \f[CR]auto\f[R], der die Vorgabe ist, der identisch zu einem wahren Wert ist, falls das Programm \f[B]systemd\-measure\f[R] im \f[CR]PATH\f[R] ist. Hängt vom aktivierten \f[CR]SecureBoot=\f[R] und Schlüssel aus \f[CR]SecureBootKey=\f[R] ab.\fR .TP \f[B]SignExpectedPcrKey=\f[R], \f[B]\-\-sign\-expected\-pcr\-key=\fR Pfad zu der PEM\-Datei, die den geheimen Schlüssel zum Signieren der erwarteten PCR\-Signatur enthält. Wenn \f[CR]VerityKeySource=\f[R] festgelegt wird, hängt der Eingabetyp von der Quelle ab.\fR .TP \f[CR]SignExpectedPcrCertificate=\f[R], \f[CR]\-\-sign\-expected\-pcr\-certificate=\fR Pfad zu einer X.509\-Datei, die das Zertifikat zum Signieren der erwarteten PCR\-Signatur enthält. .TP \f[CR]SecureBootKeySource=\f[R], \f[CR]\-\-secure\-boot\-key\-source=\f[R], \f[CR]VerityKeySource=\f[R], \f[CR]\-\-verity\-key\-source=\f[R], \f[CR]SignExpectedPcrKeySource=\f[R], \f[CR]\-\-sign\-expected\-key\-source=\fR Die Quelle des entsprechenden privaten Schlüssels, um OpenSSL\-Engines und \-Provider zu unterstützen, z.B.\ \f[CR]\-\-secure\-boot\-key\-source=engine:pkcs11\f[R] oder \f[CR]\-\-secure\-boot\-key\-source=provider:pkcs11\f[R].\fR .TP \f[CR]SecureBootCertificateSource=\f[R], \f[CR]\-\-secure\-boot\-certificate\-source=\f[R], \f[CR]VerityCertificateSource=\f[R], \f[CR]\-\-verity\-certificate\-source=\f[R], \f[CR]SignExpectedPcrCertificateSource=\f[R], \f[CR]\-\-sign\-expected\-certificate\-source=\fR Die Quelle der entsprechenden Zertifikate, um OpenSSL\-Provider zu unterstützen, z.B.\ \f[CR]\-\-secure\-boot\-certificate\-source=provider:pkcs11\f[R]. Beachten Sie, dass Engines nicht unterstützt werden. .TP \f[B]Passphrase=\f[R], \f[B]\-\-passphrase=\fR Gibt den Pfad zu einer Datei an, die die für die LUKS\-Verschlüsselung zu verwendende Passphrase enthält. Sie sollte die Passphrase wortwörtlich enthalten und nicht mit einem Zeilenumbruch enden (d.h.\ in dem gleichen Format sein, wie \f[B]cryptsetup\f[R](8) und \f[CR]/etc/crypttab\f[R] die Passphrasendatei erwarten). Die Datei muss den Zugriffsmodus 0600 oder kleiner haben.\fR .RS .PP Beachten Sie, dass diese Einstellung alleine keine Verschlüsselung aktiviert. Sie müssen auch eine oder mehrere Partitionsdefinitionen zu \f[I]mkosi.repart/\f[R] mit \f[B]Encrypt=key\-file\f[R] hinzufügen, um verschlüsselte Partitionen zum Abbild hinzuzufügen.\fR .RE .TP \f[B]Checksum=\f[R], \f[B]\-\-checksum=\fR Erstellt eine Datei \f[CR].SHA256SUMS\f[R] über alle erstellten Artefakte, nachdem der Bau abgeschlossen ist.\fR .TP \f[B]Sign=\f[R], \f[B]\-\-sign=\fR Signiert nach Fertigstellung die erstellte \f[CR]SHA256SUMS\f[R] mittels \f[B]gpg\f[R](1).\fR .TP \f[B]OpenPGPTool=\f[R], \f[B]\-\-openpgp\-tool=\fR Zum Signieren zu verwendende OpenPGP\-Implementierung. \f[CR]gpg\f[R] ist die Vorgabe. Durch Wahl einer anderen als die Vorgabe wird das Werkzeug für Zustandslose OpenPGP (SOP) zum Signieren der Datei \f[CR]SHA256SUMS\f[R] verwandt.\fR .RS .PP Beispielhaft seien \f[CR]sqop\f[R] und \f[CR]rsop\f[R] genannt, aber jede Implementierung von https://www.openpgp.org/about/sop/, die lokal installiert werden kann, funktioniert.\fR .RE .TP \f[B]Key=\f[R], \f[B]\-\-key=\fR Wählt den für das Signieren der \f[CR]SHA256SUMS\f[R] zu verwendenden \f[B]gpg\f[R](1)\-Schlüssel aus. Dieser Schlüssel muss bereits im \f[B]gpg\f[R](1)\-Schlüsselbund vorhanden sein.\fR .SS "Abschnitt [Build]" .TP \f[B]ToolsTree=\f[R], \f[B]\-\-tools\-tree=\fR Falls angegeben, werden von \f[B]mkosi\f[R] ausgeführte Programme zum Bau und Starten eines Abbilds innerhalb des angegeben Baums statt im Wirtsystem gesucht. Verwenden Sie diese Option, um den Abbildbau reproduzierbarer zu machen, indem Sie immer die gleiche Version von Programmen zum Bau des letztendlichen Abbildes verwenden, anstelle der gerade im Wirtsystem installierten Version. Falls diese Option nicht verwandt wird, aber das Verzeichnis \f[CR]mkosi.tools/\f[R] im lokalen Verzeichnis gefunden wird, wird es automatisch für diesen Zweck mit dem Wurzelverzeichnis als Ziel verwandt.\fR .RS .PP Das Werkzeugbaumverzeichnis wird zwischen wiederholten Abbildbauten beibehalten, außer es wird durch Aufruf von \f[B]mkosi clean \-f\f[R] bereinigt.\fR .PP Beachten Sie, dass Programme, die in einem der mit \f[CR]ExtraSearchPaths=\f[R] konfigurierten Pfade gefunden werden, mit \f[CR]/usr/\f[R] vom Werkzeugbaum anstatt vom Wirt ausgeführt werden. Falls die Distribution des Hauptsystems oder die Veröffentlichung nicht auf die Werkzeugbaum\-Distribution bzw. \-Veröffentlichung passt, könnte dies zu Fehlern führen, wenn Programme aus einem der zusätzlichen Suchpfad ausgeführt werden.\fR .PP Falls auf \f[B]yes\f[R] gesetzt wird \f[B]mkosi\f[R] automatisch ein zusätzliches Werkzeugbaumabbild hinzufügen und es als Werkzeugbaum verwenden. Dieses Abbild kann weiter mit den nachfolgend beschriebenen Einstellungen konfiguriert werden oder mit \f[I]mkosi.tools.conf\f[R], das entweder eine Datei oder ein Verzeichnis sein kann, welche(s) zusätzliche Konfiguration für den Standard\-Werkzeugbaum enthält.\fR .PP Weitere Details finden Sie im Abschnitt \f[B]WERKZEUGBAUM\f[R].\fR .RE .TP \f[B]ToolsTreeDistribution=\f[R], \f[B]\-\-tools\-tree\-distribution=\fR Setzt die für den Standard\-Befehlsbaum zu verwendende Distribution. Standardmäßig die Distribution des Hauptsystems, außer für Ubuntu, wo die Vorgabe Debian und RHEL, CentOS, Alma und Rocky, wo die Vorgabe Fedora ist, oder \f[CR]custom\f[R], falls die Distribution des Hauptsystems keine unterstützte Distribution ist.\fR .TP \f[B]ToolsTreeRelease=\f[R], \f[B]\-\-tools\-tree\-release=\fR Setzt die für den Standard\-Werkzeugbaum zu verwendende Distributionsveröffentlichung. Standardmäßig wird die in \f[B]mkosi\f[R] fest eingebaute Standard\-Veröffentlichung für die Distribution verwandt. .TP \f[B]ToolsTreeProfiles=\f[R], \f[B]\-\-tools\-tree\-profile=\fR Setzt die für den Standard\-Werkzeugbaum zu aktivierende Profile. Akzeptiert eine Kommate\-getrennte Liste, die aus \f[B]devel\f[R], \f[B]misc\f[R], \f[B]package\-manager\f[R] und \f[B]runtime\f[R] besteht. Standardmäßig sind alle Profile außer \f[B]devel\f[R] aktiviert.\fR .RS .PP Das Profil \f[B]devel\f[R] enthält Werkzeuge, um C/C++\-Projekte zu bauen. Das Profil \f[B]misc\f[R] enthält verschiedene Werkzeuge, die für den Einsatz in Skripten praktisch sind. Das Paketverwalterprofil enthält Paketverwalter und zugehörige Werkzeuge, die über die der nativen Werkzeuge der Werkzeugbaumdistribution hinausgehen. Das Profil \f[B]runtime\f[R] enthält die Werkzeuge, die zum Starten von Abbildern in einem \f[B]systemd\-nspawn\f[R](1)\-Container oder in einer virtuellen Maschine benötigt werden.\fR .RE .TP \f[B]ToolsTreeMirror=\f[R], \f[B]\-\-tools\-tree\-mirror=\fR Setzt den für den Standardwerkzeugbaum zu verwendenden Spiegel. Standardmäßig wird der Standardspiegel für die Werkzeugbaumdistribution verwandt. .TP \f[B]ToolsTreeRepositories=\f[R], \f[B]\-\-tools\-tree\-repository=\fR Identisch zu \f[CR]Repositories=\f[R], aber für den Standardwerkzeugbaum.\fR .TP \f[B]ToolsTreeSandboxTrees=\f[R], \f[B]\-\-tools\-tree\-sandbox\-tree=\fR Identisch zu \f[CR]SandboxTrees=\f[R], aber für den Standardwerkzeugbaum.\fR .TP \f[B]ToolsTreePackages=\f[R], \f[B]\-\-tools\-tree\-package=\fR Zusätzliche Pakete, die in den Standardwerkzeugbaum installiert werden sollen. Akzeptiert eine Kommata\-getrennte Liste von Paketspezifikationen. Diese Option kann mehrfach verwandt werden, dann werden die angegebenen Paketlisten kombiniert. .TP \f[B]ToolsTreePackageDirectories=\f[R], \f[B]\-\-tools\-tree\-package\-directory=\fR Identisch zu \f[CR]PackageDirectories=\f[R], aber für den Standardwerkzeugbaum.\fR .TP \f[B]ToolsTreeCertificates=\f[R], \f[B]\-\-tools\-tree\-certificates=\fR Legt fest, ob Zertifikate und Schlüssel aus dem Werkzeugbaum verwandt werden sollen. Standardmäßig aktiviert. Falls aktiviert, werden \f[I]/etc/pki/ca\-trust\f[R], \f[I]/etc/pki/tls\f[R], \f[I]/etc/ssl\f[R], \f[I]/etc/ca\-certificates\f[R] und \f[I]/var/lib/ca\-certificates\f[R] von dem Werkzeugbaum verwandt. Andernfalls werden diese Verzeichnisse aus dem Wirtsystem aufgenommen.\fR .TP \f[B]ExtraSearchPaths=\f[R], \f[B]\-\-extra\-search\-path=\fR Liste von durch Doppelpunkt getrennten Pfaden, in denen vor dem regulären Suchpfad \f[CR]$PATH\f[R] nach Werkzeugen gesucht wird.\fR .TP \f[B]Incremental=\f[R], \f[B]\-\-incremental=\f[R], \f[B]\-i\fR Akzeptiert entweder \f[CR]strict\f[R] oder einen logischen Wert als Argument. Aktiviert den inkrementellen Bau\-Modus. In diesem Modus wird direkt nach der Installation aller Betriebssystempakete und der Ausführung der Vorbereitungsskripte, aber bevor die Skripte \f[CR]mkosi.build\f[R] (und alles was danach passiert) aufgerufen werden, eine Kopie des Betriebssystemabbilds erstellt. Bei nachfolgenden Aufrufen von \f[B]mkosi\f[R] mit dem Schalter \f[CR]\-i\f[R] kann dieses zwischengespeicherte Abbild verwandt werden, um die Betriebssystempaketinstallation zu überspringen und daher dramatisch die Zeitdauer wiederholter Bauten reduzieren. Beachten Sie, dass es zwar eine rudimentäre Zwischenspeicher\-Entwertung gibt, diese aber weit von perfekt ist. Um einen Neubau eines zwischengespeicherten Abbilds zu erzwingen, kombinieren Sie \f[CR]\-i\f[R] mit \f[CR]\-ff\f[R] um sicherzustellen, dass das zwischengespeicherte Abbild zuerst entfernt und dann neu erstellt wird.\fR .RS .PP Falls auf \f[CR]strict\f[R] gesetzt, schlägt der Bau fehl, falls kein vorher gebautes und zwischengespeichertes Abbild existiert.\fR .RE .TP \f[CR]CacheOnly=\f[R], \f[CR]\-\-cache\-only=\fR Akzeptiert entweder \f[CR]auto\f[R], \f[CR]metadata\f[R], \f[CR]always\f[R] oder \f[CR]never\f[R]. Standardmäßig \f[CR]auto\f[R]. Falls \f[CR]always\f[R], wird der Paketverwalter angewiesen, das Netzwerk nicht zu kontaktieren. Dies stellt eine minimale Reproduzierbarkeitsstufe bereit, solang der Paketzwischenspeicher bereits vollständig gefüllt ist. Falls auf \f[CR]metadata\f[R] gesetzt kann der Paketverwalter weiterhin Pakete herunterladen, aber nicht die Metadaten des Depots synchronisieren. Falls auf \f[CR]auto\f[R] gesetzt werden während des Baus die Paketmetadaten synchronisiert (außer es liegt ein zwischengespeichertes Abbild vor \- siehe \f[CR]Incremental=\f[R]) und die Pakete heruntergeladen. Falls \f[CR]never\f[R], werden die Depot\-Metadaten immer synchronisiert und Pakete können während des Baus heruntergeladen werden.\fR .TP \f[B]SandboxTrees=\f[R], \f[B]\-\-sandbox\-tree=\fR Akzeptiert eine Kommata\-getrennte Liste von Doppelpunkt\-getrennten Pfadpaaren. Der erste Pfad jedes Paares bezieht sich auf ein Verzeichnis, das in die Sandbox von \f[B]mkosi\fR vor der Ausführung 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 \f[I]mkosi.sandbox/\f[R] in dem lokalen Verzeichnis gefunden wird, wird es für diesen Zweck mit dem Wurzelverzeichnis als Ziel verwandt (siehe auch den nachfolgenden Abschnitt \f[B]DATEIEN\f[R]).\fR .RS .PP \f[B]mkosi\f[R] wird nach der Paketverwalterkonfiguration und zugehörigen Dateien in den konfigurierten Sandbox\-Bäumen suchen. Falls nicht anders festgelegt, wird es die Konfigurationsdateien aus ihren kanonischen Orten in \f[CR]/usr\f[R] oder \f[CR]/etc\f[R] in den Sandbox\-Bäumen verwenden. Beispielsweise wird es nach \f[CR]/etc/dnf/dnf.conf\f[R] in Sandbox\-Bäumen suchen, falls \f[B]dnf\f[R] zur Installation von Paketen verwandt wird.\fR .RE .TP \f[B]WorkspaceDirectory=\f[R], \f[B]\-\-workspace\-directory=\fR Pfad zu einem Verzeichnis, in dem temporär während eines Abbild\-Baus benötigte Daten gespeichert werden. Dieses Verzeichnis sollte über genug Platz verfügen, das vollständige Betriebssystemabbild zu speichern, obwohl in den meisten Modi der tatsächlich verwandte Plattenplatz kleiner ist. Falls nicht angegeben, wird ein Unterverzeichnis von \f[I]$XDG_CACHE_HOME\f[R] (falls gesetzt), \f[I]$CACHE_DIRECTORY\f[R] (falls gesetzt), \f[I]$HOME/.cache\f[R] (falls gesetzt) oder \f[I]/var/tmp\f[R] verwandt.\fR .RS .PP Nach jedem Bau werden die Daten in diesem Verzeichnis automatisch entfernt. Es ist sicher, die Inhalte dieses Verzeichnisses manuell zu entfernen, falls der Aufruf von \f[B]mkosi\f[R] anormal abgebrochen wurde (beispielsweise aufgrund eines Neustarts oder Stromausfalls).\fR .RE .TP \f[B]CacheDirectory=\f[R], \f[B]\-\-cache\-directory=\fR Akzeptiert einen Pfad zu einem Verzeichnis, das als inkrementelles Zwischenspeicherverzeichnis für die erstellten inkrementellen Abbilder verwandt wird, wenn die Option \f[CR]Incremental=\f[R] aktiviert ist. Falls diese Option nicht verwandt wird, aber das Verzeichnis \f[CR]mkosi.cache/\f[R] im lokalen Verzeichnis gefunden wird, wird es automatisch für diesen Zweck verwandt.\fR .TP \f[B]CacheKey=\f[R], \f[B]\-\-cache\-key=\fR Legt das Unterverzeichnis innerhalb des Zwischenspeicherverzeichnisses fest, in dem das zwischengespeicherte Abbild gespeichert werden soll. Dies kann sowohl die normalen Kennzeichner (siehe \f[B]Kennzeichner\f[R]) als auch besondere verzögerte Kennzeichner festlegen, die nach Abschluss der Auswertung der Konfiguration anstatt während der Auswertung der Konfiguration expandiert werden und die nachfolgend beschrieben werden. Das Standardformat für diesen Parameter lautet \f[B]&d\[ti]&r\[ti]&a\[ti]&I\f[R].\fR .RS .PP Die folgenden Kennzeichner können außerdem verwendet werden: .PP .TS tab(@); l l. T{ Kennzeichner T}@T{ Wert T} _ T{ \f[CR]&&\fR T}@T{ \f[CR]&\f[R]\-Zeichen\fR T} T{ \f[I]&d\fR T}@T{ \f[B]Distribution=\fR T} T{ \f[I]&r\fR T}@T{ \f[B]Release=\fR T} T{ \f[I]&a\fR T}@T{ \f[CR]Architecture=\fR T} T{ \f[I]&i\fR T}@T{ \f[CR]ImageId=\fR T} T{ \f[I]&v\fR T}@T{ \f[CR]ImageVersion=\fR T} T{ \f[I]&I\fR T}@T{ \f[R]Unterabbild\-Name innerhalb von \f[I]mkosi.images/\fR oder \f[B]main\fR T} .TE .PP Beachten Sie, dass alle Abbilder innerhalb eines Baus einen eindeutigen Zwischenspeicherschlüssel haben müssen. .RE .TP \f[B]PackageCacheDirectory=\f[R], \f[B]\-\-package\-cache\-dir=\fR Akzeptiert einen Pfad zu einem Verzeichnis, das als Paketzwischenspeicherverzeichnis für den eingesetzten Distributionspaketverwalter verwandt wird. Falls nicht gesetzt, aber im lokalen Verzeichnis ein Verzeichnis \f[CR]mkosi.pkgcache/\f[R] gefunden wird, wird dies automatisch für diesen Zweck verwandt, andernfalls wird ein geeignetes Verzeichnis in dem Home\-Verzeichnis des Benutzers oder des Systems verwandt. .TP \f[B]BuildDirectory=\f[R], \f[B]\-\-build\-directory=\fR Akzeptiert einen Pfad zu einem Verzeichnis, das als Bauverzeichnis für Bausysteme verwandt werden soll, die Bauen in separaten Verzeichnissen unterstützen (wie Meson). Das auf diese Art verwandte Verzeichnis wird zwischen mehreren Bauten gemeinsam benutzt und ermöglicht es dem Bausystem, Artefakte (wie Objektdateien, Programmen, …), die bei vorherigen Aufrufen erzeugt wurden, wiederzuverwenden. Die Bauskripte können den Pfad zu diesem Verzeichnis in der Umgebungsvariable \f[I]$BUILDDIR\f[R] finden. Dieses Verzeichnis wird in das Wurzelverzeichnis des Abbildes eingehängt, wenn \f[B]mkosi\-chroot\f[R] während der Ausführung der Bauskripte aufgerufen wird. Falls diese Option nicht verwandt wird, aber das Verzeichnis \f[I]mkosi.builddir/\f[R] im lokalen Verzeichnis gefunden wird, wird es automatisch für diesen Zweck verwandt (siehe auch den nachfolgenden Abschnitt \f[B]DATEIEN\f[R]).\fR .TP \f[B]BuildKey=\f[R], \f[B]\-\-build\-key=\fR Legt das Unterverzeichnis innerhalb des Bauverzeichnisses fest, in dem die inkrementellen Bauten gespeichert werden sollen. Dies kann sowohl die normalen Kennzeichner (siehe \f[B]Kennzeichner\f[R]) als auch besondere verzögerte Kennzeichner festlegen, die nach Abschluss der Auswertung der Konfiguration anstatt während der Auswertung der Konfiguration expandiert werden und die die gleichen verzögerten Kennzeichner sind, die von \f[B]CacheKey=\f[R] unterstützt werden. Das Standardformat für diesen Parameter lautet \f[B]&d\[ti]&r\[ti]&a\f[R].\fR .RS .PP Um die Verwendung eines Bauunterverzeichnisses vollständig zu deaktivieren, weisen Sie dieser Einstellung ein wörtliches \f[B]\-\f[R] zu.\fR .RE .TP \f[B]UseSubvolumes=\f[R], \f[B]\-\-use\-subvolumes=\fR Akzeptiert einen logischen Wert oder \f[CR]auto\f[R]. Aktiviert oder deaktiviert die Verwendung von \f[B]btrfs\f[R](5)\-Teildatenträgern für Verzeichnisbaumausgaben. Falls aktiviert wird \f[B]mkosi\f[R] das Wurzelverzeichnis als \f[B]btrfs\f[R](5)\-Teildatenträger erstellen und wo möglich \f[B]btrfs\f[R](5)\-Teildatenträgerschnappschüsse verwenden, um grundlegende oder zwischengespeicherte Bäume zu kopieren, was viel schneller als rekursive Kopieren ist. Falls explizit aktiviert und \f[B]btrfs\f[R](8) nicht installiert ist oder Teildatenträger nicht erstellt werden können, wird ein Fehler ausgelöst. Falls \f[CR]auto\f[R], werden ein fehlendes \f[B]btrfs\f[R](8) oder Fehlschläge beim Erstellen von Teildatenträgern ignoriert.\fR .TP \f[CR]RepartOffline=\f[R], \f[CR]\-\-repart\-offline=\fR Legt fest, ob Plattenabbilder mittels Loopback\-Geräten gebaut werden. Standardmäßig aktiviert. Wenn aktiviert, wird \f[B]systemd\-repart\f[R](8) keine Loopback\-Geräte zum Bau von Plattenabbildern verwenden. Wenn deaktiviert, wird \f[B]systemd\-repart\f[R](8) immer Loopback\-Geräte zum Bau von Plattenabbildern verwenden.\fR .RS .PP Beachten Sie, dass \f[B]mkosi\f[R] nicht unprivilegiert ausgeführt werden kann, wenn \f[B]RepartOffline=no\f[R] verwandt wird und der Abbild\-Bau als Benutzer root außerhalb von Containern und mit auf dem Wirtsystem verfügbaren Loopback\-Geräten erfolgt.\fR .PP Es gibt derzeit zwei bekannte Szenarien, bei denen \f[CR]RepartOffline=no\f[R] verwandt werden muss. Das erste ist der Einsatz von \f[CR]Subvolumes=\f[R] in einer Repart\-Partitionsdefinitionsdatei, da Teildatenträger nicht ohne Loopback\-Geräte erstellt werden können. Das zweite ist bei der Erstellung eines Systems mit SELinux und einer XFS\-Wurzelpartition. Da \f[B]mkfs.xfs\f[R](8) die Befüllung eines XFS\-Dateisystems mit erweiterten Attributen nicht erlaubt, müssen Loopback\-Geräte verwandt werden um sicherzustellen, dass erweiterte SELinux\-Attribute im erstellten XFS\-Dateisystem landen.\fR .RE .TP \f[B]History=\f[R], \f[B]\-\-history=\fR Akzeptiert einen logischen Wert. Falls aktiviert, wird \f[B]mkosi\f[R] die über die CLI für den neusten Bau bereitgestellte Konfiguration in das Unterverzeichnis \f[I].mkosi\-private\f[R] (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.\fR .RS .PP Beispiel für den Nutzen dieses Vorgehens: Sie führen \f[CR]mkosi \-O mein\-angepasstes\-Ausgabeverzeichnis \-f\f[R] gefolgt von \f[CR]mkosi vm\f[R] aus. Dann wird \f[B]mkosi\f[R] mit der Information fehlschlagen, dass das Abbild noch nicht gebaut wurde. Falls Sie \f[CR]mkosi \-O mein\-angepasstes\-Ausgabeverzeichnis \-\-history=yes \-f\f[R] gefolgt von \f[CR]mkosi vm\f[R] ausführen, wird es das im vorhergehenden Schritt gebaute Abbild wie erwartet starten.\fR .RE .TP \f[B]BuildSources=\f[R], \f[B]\-\-build\-sources=\fR Akzeptiert eine Kommata\-getrennte Liste von Doppelpunkt\-getrennten Pfadpaaren. Der erste Pfad jedes Paars bezieht sich auf ein Verzeichnis, das vom Wirtsystem eingehängt werden soll. Der zweite Pfad jedes Paars bezieht sich auf das Verzeichnis, wohin das Quellverzeichnis beim Ausführen der Skripte eingehängt werden soll. Jedem Zielpfad wird \f[CR]/work/src\f[R] vorangestellt und alle Bauquellen werden vor dem Einhängen lexikographisch nach ihrem Ziel sortiert, so dass die Pfade auf der obersten Ebene zuerst eingehängt werden. Falls nicht explizit konfiguriert, wird das aktuelle Arbeitsverzeichnis nach \f[CR]/work/src\f[R] eingehängt.\fR .TP \f[CR]BuildSourcesEphemeral=\f[R], \f[CR]\-\-build\-sources\-ephemeral=\fR Akzeptiert einen logischen oder den besonderen Wert \f[CR]buildcache\f[R]. Standardmäßig deaktiviert. Konfiguriert, ob Änderungen an Quellverzeichnissen, dem Arbeitsverzeichnis und dem mit \f[CR]BuildSources=\f[R] konfigurierten Verzeichnis dauerhaft sind. Falls aktiviert, werden nach der Ausführung aller Skripte eines bestimmten Typs (außer Synchronisationsskripte) alle Quellverzeichnisse auf ihren Originalzustand zurückgesetzt.\fR .RS .PP 💥💣💥 Falls auf \f[CR]buildcache\f[R] gesetzt wird die Überlagerung nicht bei der Ausführung von Bauskripten verworfen, sondern im Bauverzeichnis, konfiguriert mittels \f[CR]BuildDirectory=\f[R], gespeichert und bei nachfolgenden Läufen wiederverwandt. Die Überlagerung wird weiterhin für alle anderen Skripte verworfen. Diese Option kann für ein fortgeschritteneres Zwischenspeichern bei Bauten verwandt werden, kann aber zu unerwarteten Zuständen des Bauverzeichnisses führen. Bei der Verwendung dieser Option muss ein Bauverzeichnis konfiguriert sein. 💥💣💥\fR .RE .TP \f[CR]Environment=\f[R], \f[CR]\-\-environment=\fR Fügt Variablen zu der Umgebung hinzu, mit der Paketverwalter und die Vorbereitungs\-/Bau\-/Postinstall\-/Finalisierungsskripte ausgeführt werden. Akzeptiert eine Leerzeichen\-getrennte Liste von Variablenzuweisungen oder nur Variablennamen. In letzterem Falle werden die Werte dieser Variablen von der Umgebung, aus der \f[B]mkosi\f[R] heraus aufgerufen wurde, durchgereicht. Diese Option kann mehr als einmal angegeben werden. Dann werden alle aufgeführten Variablen gesetzt. Falls die gleiche Variable zweimal gesetzt wird, setzt letztere Einstellung die vorhergehende außer Kraft.\fR .TP \f[CR]EnvironmentFiles=\f[R], \f[CR]\-\-env\-file=\fR Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Dateien, die Umgebungsvariablendefinitionen enthalten, die der Skript\-Umgebung hinzugefügt werden sollen. Verwendet \f[CR]mkosi.env\f[R], falls es im lokalen Verzeichnis gefunden wird. Diese Variablen werden zuerst aus \f[CR]mkosi.env\f[R], falls es existiert, dann aus den angegebenen Dateien und dann aus den Einstellungen \f[CR]Environment=\f[R] gelesen.\fR .TP \f[B]WithTests=\f[R], \f[B]\-\-with\-tests=\f[R], \f[B]\-T\fR Falls auf »false« gesetzt (oder wenn die Befehlszeilenoption verwandt wird), wird die Umgebungsvariable \f[CR]$WITH_TESTS\f[R] auf \f[CR]0\f[R] gesetzt, wenn die Skripte \f[CR]mkosi.build\f[R] aufgerufen werden. Dies ist dafür gedacht, von Bauskripten zur Umgehung von Unit\- oder Integrationstest, die normalerweise während des Quellbauprozesses aufgerufen werden, verwandt zu werden. Beachten Sie, dass diese Option nur wirksam wird, wenn die \f[CR]mkosi.build\f[R]\-Bauskripte sie respektieren.\fR .TP \f[CR]WithNetwork=\f[R], \f[CR]\-\-with\-network=\fR Wenn »true«, aktiviert Netzwerkverbindungen während der von \f[CR]mkosi.build\f[R] aufgerufenen Bauskripte. Standardmäßig werden die Bauskripte mit abgeschaltetem Netzwerk ausgeführt. Die Umgebungsvariable \f[CR]$WITH_NETWORK\f[R] wird an die \f[CR]mkosi.build\f[R]\-Bauskripte übergeben um anzuzeigen, ob der Bau mit Netzwerk erfolgt.\fR .TP \f[CR]ProxyUrl=\f[R], \f[CR]\-\-proxy\-url=\fR Konfiguriert einen Proxy, der für alle ausgehenden Netzwerkverbindungen verwandt werden soll. Verschiedene Werkzeuge, die \f[B]mkosi\f[R] aufruft und für die der Proxy konfiguriert werden kann, sind für diesen Proxy konfiguriert. \f[B]mkosi\f[R] setzt auch verschiedene gut bekannte Umgebungsvariablen, um den Proxy zur Verwendung mit allen Programmen festzulegen, die es aufruft und die Internetzugriff benötigen könnten. .TP \f[CR]ProxyExclude=\f[R], \f[CR]\-\-proxy\-exclude=\fR Konfiguriert Rechnernamen, für die Anfragen nicht durch den Proxy gehen sollen. Akzeptiert eine Kommata\-getrennte Liste von Rechnernamen. .TP \f[CR]ProxyPeerCertificate=\f[R], \f[CR]\-\-proxy\-peer\-certificate=\fR Konfiguriert eine Datei, die Zertifikate zur Überprüfung des Proxys enthält. Standardmäßig ist das der systemweite Zertifikaktspeicher. .RS .PP Derzeit wird das Setzen eines Proxy\-Gegenstellen\-Zertifikats nur unterstützt, wenn \f[B]dnf\f[R] oder \f[B]dnf5\f[R] zum Bau des Abbilds verwandt werden.\fR .RE .TP \f[CR]ProxyClientCertificate=\f[R], \f[CR]\-\-proxy\-client\-certificate=\fR Konfiguriert eine Datei, die das zur Authentifizierung des Clients mit dem Proxy verwandte Zertifikat enthält. .RS .PP Derzeit wird das Setzen eines Proxy\-Client\-Zertifikats nur unterstützt, wenn \f[B]dnf\f[R] oder \f[B]dnf5\f[R] zum Bau des Abbilds verwandt werden.\fR .RE .TP \f[CR]ProxyClientKey=\f[R], \f[CR]\-\-proxy\-client\-key=\fR Konfiguriert eine Datei, die den privaten Schlüssel für die Authentifizierung des Clients mit dem Proxy enthält. Die Vorgabe ist das Proxy\-Client\-Zertifikat, falls eines bereitgestellt wurde. .RS .PP Derzeit wird das Setzen eines Proxy\-Clients nur unterstützt, wenn \f[B]dnf\f[R] oder \f[B]dnf5\f[R] zum Bau des Abbildes verwandt wird.\fR .RE .SS "Abschnitt [Runtime] (früher als Abschnitt [Host] bekannt)" .TP \f[CR]NSpawnSettings=\f[R], \f[CR]\-\-settings=\fR Legt eine Einstellungsdatei \f[CR].nspawn\f[R] für \f[B]systemd\-nspawn\f[R](1) zur Verwendung in den Unterbefehlen \f[CR]boot\f[R] und \f[CR]shell\f[R] und zum Ablegen neben der erstellten Abbilddatei fest. Dies ist zur Konfiguration der Umgebung \f[B]systemd\-nspawn\f[R](1) bei der Ausführung nützlich. Falls diese Einstellung nicht verwandt wird, aber eine Datei \f[CR]mkosi.nspawn\f[R] im lokalen Verzeichnis gefunden wird, wird diese automatisch für diesen Zweck verwandt.\fR .TP \f[CR]VirtualMachineMonitor=\f[R], \f[CR]\-\-vmm=\fR Konfiguriert den zu verwendenden Monitor für virtuelle Maschinen. Akzeptiert entweder \f[CR]qemu\f[R] oder \f[CR]vmspawn\f[R]. Standardmäßig \f[CR]qemu\f[R].\fR .RS .PP Falls auf \f[CR]qemu\f[R] gesetzt, wird das Abbild mit \f[B]qemu\f[R] gestartet. Die meisten Ausgabeformate können mit \f[B]qemu\f[R] gestartet werden. Alle nach dem Unterbefehl angegebenen Argumente werden an den Aufruf von \f[B]qemu\f[R] angehängt und als zusätzliche \f[B]qemu\f[R]\-Befehlszeilenargumente interpretiert.\fR .PP Falls auf \f[CR]vmspawn\f[R] gesetzt, wird \f[B]systemd\-vmspawn\f[R](1) zum Hochfahren des Abbildes benutzt. \f[CR]vmspawn\f[R] unterstützt nur platten\- und verzeichnisartige Abbilder. Alle nach dem Unterbefehl angegebenen Argumente werden an den Aufruf von \f[B]systemd\-vmspawn\f[R](1) angehängt und als zusätzliche Vmspawn\-Optionen und Kernelbefehlszeilenargumente interpretiert.\fR .RE .TP \f[CR]Console=\f[R], \f[CR]\-\-console=\fR Konfiguriert, wie die Konsole der VM eingerichtet werden soll. Akzeptiert entweder \f[CR]interactive\f[R], \f[CR]read\-only\f[R], \f[CR]native\f[R] oder \f[CR]gui\f[R]. Standardmäßig \f[CR]interactive\f[R]. \f[CR]interactive\f[R] stellt eine interaktive Terminalschnittstelle zur VM bereit. \f[CR]read\-only\f[R] ist ähnlich, aber streng schreibgeschützt, d.h. sie akzeptiert keine Eingabe vom Benutzer. \f[CR]native\f[R] stellt auch eine TTY\-basierte Schnittstelle bereit, verwendet aber die in \f[B]qemu\f[R] eingebaute Implementierung (dadurch ist der Monitor von \f[B]qemu\f[R] verfügbar). \f[CR]gui\f[R] zeigt die graphische UI von \f[B]qemu\f[R] \f[B]qemu\f[R].\fR .TP \f[CR]CPUs=\f[R], \f[CR]\-\-cpus=\fR Konfiguriert die Anzahl der CPU\-Kerne, die dem Gast beim Starten einer virtuellen Maschine zugewiesen werden sollen. Standardmäßig \f[CR]2\f[R].\fR .RS .PP Wird dies auf \f[CR]0\f[R] gesetzt, wird die Anzahl der für den \f[B]mkosi\f[R]\-Prozess verfügbaren CPUs verwandt.\fR .RE .TP \f[CR]RAM=\f[R], \f[CR]\-\-ram=\fR Konfiguriert die Speichermenge, die einem Gast beim Starten einer virtuellen Maschine zugewiesen wird. Standardmäßig \f[CR]2G\f[R].\fR .TP \f[B]MaxMem=\f[R], \f[B]\-\-maxmem=\fR Konfiguriert die maximale Speichermenge, die der Gast insgesamt einsetzen darf (RAM + Hotplug\-Speichergeräte). Standardmäßig die konfigurierte RAM\-Größe. .TP \f[B]KVM=\f[R], \f[B]\-\-kvm=\fR Konfiguriert, ob KVM\-Beschleunigung beim Starten einer virtuellen Maschine verwandt werden soll. Akzeptiert einen logischen Wert oder \f[CR]auto\f[R]. Standardmäßig \f[CR]auto\f[R].\fR .TP \f[B]CXL=\f[R], \f[B]\-\-cxl=\fR Konfiguriert, ob für eine angegebene Maschine CXL\-Geräte aktiviert werden. Nur gültig, falls die Architektur CXL unterstützt. Akzeptiert einen logischen Wert. Standardmäßig \f[B]false\f[R].\fR .TP \f[B]VSock=\f[R], \f[B]\-\-vsock=\fR Konfiguriert, ob ein Vsock beim Starten einer virtuellen Maschine vorgehalten werden soll. Akzeptiert einen logischen Wert oder \f[CR]auto\f[R]. Standardmäßig \f[CR]auto\f[R].\fR .TP \f[B]VSockCID=\f[R], \f[B]\-\-vsock\-cid=\fR Konfiguriert die beim Starten einer virtuellen Maschine zu verwendende Verbindungskennung. Akzeptiert eine Zahl im Intervall \f[CR][3, 0xFFFFFFFF)\f[R] oder \f[CR]hash\f[R] oder \f[CR]auto\f[R]. Standardmäßig \f[CR]auto\f[R]. Wenn auf \f[CR]hash\f[R] gesetzt wird die Verbindungskennung von dem vollständigen Pfad zum Abbild abgeleitet. Wenn auf \f[CR]auto\f[R] gesetzt, wird \f[B]mkosi\f[R] versuchen, automatisch eine freie Verbindungskennung zu finden. Andernfalls wird die bereitgestellte Nummer unverändert verwandt.\fR .TP \f[CR]TPM=\f[R], \f[CR]\-\-tpm=\fR Konfiguriert, ob ein virtueller TPM beim Starten einer virtuellen Maschine verwandt werden soll. Akzeptiert einen logischen Wert oder \f[CR]auto\f[R]. Standardmäßig \f[CR]auto\f[R].\fR .TP \f[CR]Removable=\f[R], \f[CR]\-\-removable=\fR Konfiguriert, ob das Abbild als entfernbares Gerät beim Start einer virtuellen Maschine angehängt werden soll. Akzeptiert einen logischen Wert. Standardmäßig \f[B]no\f[R].\fR .TP \f[B]Firmware=\f[R], \f[B]\-\-firmware=\fR Konfiguriert die zu verwendende Firmware. Akzeptiert entweder \f[B]uefi\f[R], \f[B]uefi\-secure\-boot\f[R], \f[B]bios\f[R], \f[B]linux\f[R], \f[B]linux\-noinitrd\f[R] oder \f[B]auto\f[R]. Standardmäßig \f[B]auto\f[R]. Falls auf \f[B]uefi\f[R] gesetzt, wird die OVMF\-Firmware ohne Unterstützung für sicheren Systemstart verwandt. Falls auf \f[B]uefi\-secure\-boot\f[R] gesetzt, wird die OVMF\-Firmware mit Unterstützung für sicheren Systemstart verwandt. Falls auf \f[B]bios\f[R] gesetzt, wird die Standard\-SeaBIOS\-Firmware verwandt. Falls auf \f[B]linux\f[R] gesetzt, wird der direkte Kernelstart verwandt. Siehe die Option \f[B]Linux=\f[R] für weitere Details darüber, welches Kernelabbild mit direktem Kernelsystemstart verwandt wird. \f[B]linux\-noinitrd\f[R] ist mit \f[B]linux\f[R] identisch, außer dass keine Initrd verwandt wird. Falls auf \f[B]auto\f[R] gesetzt wird falls möglich \f[B]uefi\-secure\-boot\f[R] und ansonsten \f[B]linux\f[R] verwandt.\fR .TP \f[B]FirmwareVariables=\f[R], \f[B]\-\-firmware\-variables=\fR Konfiguriert den Pfad zu den zu verwendenden Firmwarevariablendateien der virtuellen Maschine. Derzeit wird diese Option nur berücksichtigt, wenn die Firmware \f[CR]uefi\f[R] oder \f[CR]uefi\-secure\-boot\f[R] verwandt wird. Falls nicht angegeben, wird \f[B]mkosi\f[R] nach der Standard\-Variablen\-Datei suchen und diese stattdessen verwenden.\fR .RS .PP Falls auf \f[CR]microsoft\f[R] gesetzt, wird eine Firmwarevariablendatei mit bereits registriertem sicheren Systemstartzertifikat von Microsoft verwandt.\fR .PP Falls auf \f[CR]microsoft\-mok\f[R] gesetzt wird eine bereits registrierte Firmware\-Variablen\-Datei mit dem »Microsoft secure boot«\-Zertifikaten durch eine \f[CR]MokList\f[R]\-Variable erweitert, die das Zertifikat für den sicheren Systemstart aus \f[CR]SecureBootCertificate=\f[R] enthält. Dies ist für die gemeinsame Verwendung von durch die Distribution signierten Shim\-Programmen und lokal signierten EFI\-Programmen gedacht.\fR .PP Falls auf \f[CR]custom\f[R] gesetzt, wird ein Zertifikat für sicheren Systemstart von \f[CR]SecureBootCertificate=\f[R] in die Standard\-Firmwarevariablendatei registriert.\fR .PP \f[CR]virt\-fw\-vars\f[R] aus dem Projekt .UR https://gitlab.com/kraxel/virt\-firmware virt\-firmware .UE kann zum Anpassen der OVMF\-Variablendateien verwandt werden.\fR .RE .TP \f[CR]Linux=\f[R], \f[CR]\-\-linux=\fR Setzt das für direkten Kernelsystemstart in \f[B]qemu\f[R] zu verwendende Kernelabbild. Falls nicht angegeben wird \f[B]mkosi\f[R] den über die Befehlszeile bereitgestellten Kernel (Option \f[B]\-kernel\f[R]) oder den neusten Kernel, der im Abbild installiert wurde, verwenden (oder fehlschlagen, falls kein Kernel im Abbild installiert wurde).\fR .RS .PP Beachten Sie, dass bei der Verwendung des Ausgabeformats \f[CR]cpio\f[R] der direkte Kernelsystemstart unabhängig von der konfigurierten Firmware verwandt wird. Abhängig von der konfigurierten Firmware könnte \f[B]qemu\f[R] den Kernel selbst starten oder die konfigurierte Firmware verwenden.\fR .PP Diese Einstellung darf sowohl die regulären Kennzeichner (siehe \f[B]Kennzeichner\f[R]) als auch die nachfolgend beschriebenen besonderen verzögerten Kennzeichner einbinden, die nach Abschluss der Auswertung der Konfiguration erweitert werden, statt während der Auswertung der Konfiguration.\fR .PP Die folgenden Kennzeichner können außerdem verwendet werden: .PP .TS tab(@); l l. T{ Kennzeichner T}@T{ Wert T} _ T{ \f[CR]&&\fR T}@T{ \f[CR]&\f[R]\-Zeichen\fR T} T{ \f[I]&b\fR T}@T{ \f[R]Das letztendliche Bauverzeichnis (einschließlich Unterverzeichnis)\fR T} .TE .RE .TP \f[B]Drives=\f[R], \f[B]\-\-drive=\fR Fügt ein Laufwerk hinzu. Akzeptiert eine Doppelpunkt\-getrennte Zeichenkette im Format \f[I]:[:[:[:[:]]]]\f[R]. \f[I]Kennung\f[R] legt die dem Laufwerk zugeordnete Kennung fest. Diese kann als die Eigenschaft \f[B]drive=\f[R] in verschiedenen \f[B]qemu\f[R]\-Geräten verwandt werden. \f[I]Größe\f[R] legt die Größe des Laufwerks fest. Dies akzeptiert eine Größe in Byte. Zusätzliche können die Endungen \f[B]K\f[R], \f[B]M\f[R] und \f[B]G\f[R] zur Festlegung einer Größe in Kilobyte, Megabyte bzw. Gigabyte verwandt werden. \f[I]Verzeichnis\f[R] legt optional das Verzeichnis fest, in dem das dem Laufwerk zugrunde liegende Verzeichnis erstellt werden soll. Falls nicht gesetzt, wird die Datei unter \f[I]/var/tmp\f[R] erstellt. \f[I]Optionen\f[R] legen optional zusätzliche, durch Kommata getrennte Eigenschaften fest, die unverändert an die Option \f[B]\-blockdev\f[R] von \f[B]qemu\f[R] übergeben werden. \f[I]Dateikennung\f[R] 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 Größe der Datei wird aus dem ersten Laufwerk mit der angegebenen Dateikennung bestimmt. \f[B]flags\f[R] akzeptiert eine Kommata\-getrennte Liste von Laufwerksschaltern, die derzeit nur \f[B]persist\f[R] unterstützen. \f[B]persist\f[R] bestimmt, ob das Laufwerk über Aufrufe von \f[B]qemu\f[R] hinweg dauerhaft besteht. Das den Dateien zugrundeliegende Laufwerk wird innerhalb des Schematas \f[I]//mkosi\-Laufwerk\-\- erstellt. Sie können Werte überspringen, indem Sie sie auf die leere Zeichenkette setzen. Die Angabe von beispielsweise \f[R]\f[B]myfs:1G::::persist\f[R] wird ein dauerhaftes Laufwerk unter \f[I]/var/tmp/mkosi\-drive\-main\-myfs\f[R] erstellen.\fR .RS .PP \f[B]Beispielhafte Verwendung:\fR .IP .EX \f[B][Runtime]\f[R] Drives=btrfs:10G ext4:20G QemuArgs=\-device nvme,serial=btrfs,drive=btrfs \-device nvme,serial=ext4,drive=ext4\fR .EE .RE .TP \f[CR]QemuArgs=\fR Leerzeichen\-begrenzte Liste von zusätzlich beim Aufruf von \f[B]qemu\f[R] zu übergebenen Argumenten. .TP \f[B]Ephemeral=\f[R], \f[B]\-\-ephemeral=\fR Bei der Verwendung mit den Unterbefehlen \f[CR]shell\f[R], \f[CR]boot\f[R] oder \f[CR]vm\f[R] führt diese Option den angegebenen Unterbefehl auf einem temporären Schnappschuss des Ausgabeabbilds aus, das sofort entfernt wird, wenn der Container sich beendet. Die Vornahme temporärer Schnappschüsse ist auf Dateisystemen effizienter, die Reflinks nativ unterstützen (\f[B]btrfs\f[R](5) oder \f[B]xfs\f[R](5)), als auf traditionellen, bei denen das nicht der Fall ist (\f[B]ext4\f[R](5)).\fR .TP \f[CR]Credentials=\f[R], \f[CR]\-\-credential=\fR Setzt die an \f[B]systemd\-nspawn\f[R](1) bzw. der virtuellen Maschine zu übergebenen Zugangsberechtigungen, wenn \f[CR]mkosi shell/boot\f[R] oder \f[CR]mkosi vm\f[R] verwandt wird. Diese Option akzeptiert eine Leerzeichen getrennte Liste von Werten, die entweder Schlüssel=Wert\-Paare oder Pfade sein können. Falls ein Pfad bereitgestellt wird, wird der Zugangsberechtigungsname der Name der Datei sein, wenn der Pfad eine Datei ist. Falls die Datei ausführbar ist, wird die Zugangsberechtigung die Ausgabe nach Ausführen der Datei sein. Andernfalls wird der Wert der Zugangsberechtigung der Inhalt der Datei sein. Falls der Pfad ein Verzeichnis ist, gilt die gleiche Logik für jede Datei in dem Verzeichnis.\fR .RS .PP Beachten Sie, dass die Werte nur als Pfade behandelt werden, falls sie den Begrenzer (\f[CR]=\f[R]) nicht enthalten.\fR .RE .TP \f[CR]KernelCommandLineExtra=\f[R], \f[CR]\-\-kernel\-command\-line\-extra=\fR Setzt zusätzliche Kernelbefehlszeilenargumente, die zur Laufzeit beim Starten des Abbilds an die Kernelbefehlszeile angehängt werden. Beim Systemstart in einen Container werden diese als zusätzliche Argumente an \f[B]systemd\f[R](1) übergeben. Beim Systemstart in eine VM werden diese mittels der SMBIOS\-OEM\-Zeichenkette io.systemd.stub.kernel\-cmdline\-extra an die Kernelbefehlszeile angehängt. Dies wird von \f[B]systemd\-boot\f[R](7)/\f[B]systemd\-stub\f[R](7) erst ab Version v254 aufgenommen.\fR .TP \f[CR]RuntimeTrees=\f[R], \f[CR]\-\-runtime\-tree=\fR Akzeptiert eine Doppelpunkt\-getrennte Liste von Pfaden. Der erste Pfad bezieht sich auf ein in jede von Mkosi zu startende Maschine (Container oder VM) einzuhängendes Verzeichnis. Der zweite Pfad bezieht sich auf das Zielverzeichnis innerhalb der Maschine. Falls der zweite Pfad nicht bereitgestellt wird, wird das Verzeichnis unter \f[CR]/root/src\f[R] in der Maschine eingehängt. Falls der zweite Pfad relativ ist, wird er relativ zu \f[CR]/root/src\f[R] in der Maschine interpretiert.\fR .RS .PP Für jedes eingehängte Verzeichnis wird die UID und GID des Benutzers, der Mkosi ausführt, auf den Benutzer root in der Maschine abgebildet. Dies bedeutet, dass alle Dateien und Verzeichnisse so erscheinen, als ob sie root in der Maschine gehören würden und alle neuen Dateien und Verzeichnisse, die von root in der Maschine in diesen Verzeichnissen erstellt werden, gehören auf der Wirtmaschine dem Benutzer, der Mkosi ausführt. .PP Beachten Sie, dass bei der Verwendung von \f[CR]mkosi vm\f[R] mit dieser Funktionalität Systemd v254 oder neuer im Abbild installiert sein muss.\fR .RE .TP \f[CR]RuntimeSize=\f[R], \f[CR]\-\-runtime\-size=\fR Falls angegeben werden Plattenabbilder bis zu der angegebenen Größe vergrößert, wenn sie mit \f[CR]mkosi boot\f[R] oder \f[CR]mkosi vm\f[R] gestartet werden. Akzeptiert eine Größe in Byte. Zusätzlich können die Endungen \f[CR]K\f[R], \f[CR]M\f[R] und \f[CR]G\f[R] verwandt werden, um eine Größe in Kilobyte, Megabyte bzw. Gigabyte festzulegen.\fR .TP \f[CR]RuntimeNetwork=\f[R], \f[CR]\-\-runtime\-network=\fR Akzeptiert entweder \f[CR]user\f[R], \f[CR]interface\f[R] oder \f[CR]none\f[R]. Standardmäßig \f[CR]user\f[R]. Legt das beim Systemstart einzurichtende Netzwerk fest. \f[CR]user\f[R] richtet Benutzermodus\-Vernetzung ein. \f[CR]interface\f[R] richtet eine virtuelle Netzwerkverbindung zwischen dem Wirtrechner und dem Abbild ein. Dies übersetzt sich in eine Veth\-Schnittstelle für \f[CR]mkosi shell\f[R] und \f[CR]mkosi boot\f[R] und eine Tap\-Schnittstelle für \f[CR]mkosi vm\f[R] und \f[CR]mkosi vmspawn\f[R].\fR .RS .PP Beachten Sie, dass bei der Verwendung von \f[CR]interface\f[R] \f[B]mkosi\f[R] nicht automatisch die Schnittstelle des Wirtsystems konfiguriert. Es wird erwartet, dass auf dem Wirtsystem eine hinreichend neue Version von \f[B]systemd\-networkd\f[R](8) läuft, die automatisch die Schnittstelle des Links auf dem Wirtsystem konfiguriert.\fR .RE .TP \f[CR]RuntimeBuildSources=\f[R], \f[CR]\-\-runtime\-build\-sources=\fR Hängt die mit \f[CR]BuildSources=\f[R] konfigurierten Bauquellen und das Bauverzeichnis (falls eines konfiguriert wurde) an die gleichen Orte in \f[CR]/work\f[R] ein, an der sie eingehängt würden, wenn das Bauskript ausgeführt würde, wenn \f[CR]mkosi boot\f[R] oder \f[CR]mkosi vm\f[R] verwandt würde.\fR .TP \f[B]BindUser=\f[R], \f[B]\-\-bind\-user=\fR Bindet das Home\-Verzeichnis des aktuellen Benutzers in den Container/die VM. Akzeptiert einen logischen Wert. Standardmäßig deaktiviert. .TP \f[B]UnitProperties=\f[R], \f[B]\-\-unit\-property=\fR Konfiguriert Systemd\-Unit\-Eigenschaften, die zu den zugewiesenen Systemd\-Geltungsbereichen hinzugewiesen werden sollen, wenn \f[B]mkosi boot\f[R] oder \f[B]mkosi vm\f[R] verwandt wird. Diese werden direkt an die Optionen \f[B]\-\-property=\f[R] von \f[B]systemd\-nspawn\f[R](1) bzw. \f[B]systemd\-run\f[R](1) übergeben.\fR .TP \f[B]SshKey=\f[R], \f[B]\-\-ssh\-key=\fR Pfad zu dem privaten X.509\-Schlüssel im PEM\-Format, der für die Verbindung zu einer mit \f[B]mkosi vm\f[R] gestarteten virtuellen Maschine verwandt werden soll und die mittels des Befehls \f[B]mkosi ssh\f[R] aktivierten (oder mittels \f[B]systemd\-ssh\-generator\f[R](8) installierten)Option \f[B]Ssh=\f[R] gebaut wurde. Falls nicht konfiguriert und \f[I]mkosi.key\f[R] im aktuellen Arbeitsverzeichnis existiert, wird dies automatisch für diesen Zweck verwandt. Führen Sie \f[B]mkosi genkey\f[R] aus, um automatisch einen Schlüssel in \f[I]mkosi.key\f[R] zu erstellen.\fR .TP \f[B]SshCertificate=\f[R], \f[B]\-\-ssh\-certificate=\fR Pfad zu dem X.509\-Zertifikat im PEM\-Format zur Beistellung als öffentlicher SSH\-Schlüssel in durch \f[CR]mkosi vm\f[R] gestarteten virtuellen Maschinen. Falls nicht konfiguriert und \f[CR]mkosi.crt\f[R] im aktuellen Arbeitsverzeichnis existiert, wird dies automatisch für diesen Zweck verwandt. Führen Sie \f[CR]mkosi genkey\f[R] aus, um automatisch ein Zertifikat in \f[CR]mkosi.crt\f[R] zu erstellen.\fR .TP \f[CR]Machine=\f[R], \f[CR]\-\-machine=\fR Gibt den beim Starten der Maschine zu verwendenden Maschinennamen an. Kann auch als Referenz auf ein bestimmtes Abbild beim Betreten mit SSH eines bestimmten Abbildes verwandt werden (z.B. \f[CR]mkosi \-\-image=meinAbbild ssh\f[R]).\fR .RS .PP Beachten Sie, dass \f[CR]Ephemeral=\f[R] aktiviert sein muss, um mehrere Instanzen des gleichen Abbildes zu starten.\fR .RE .TP \f[CR]Register=\f[R], \f[CR]\-\-register=\fR Akzeptiert einen logischen Wert oder \f[CR]auto\f[R]. Legt fest, ob die VM/der Container mit \f[B]systemd\-machined\f[R](8) registriert werden soll. Falls aktiviert, wird \f[B]mkosi\f[R] fehlschlagen, falls es keine VM/keinen Container mit \f[B]systemd\-machined\f[R](8) registrieren kann. Falls deaktiviert, wird \f[B]mkosi\f[R] die VM/den Container nicht mit \f[B]systemd\-machined\f[R](8) registrieren. Falls \f[CR]auto\f[R], wird \f[B]mkosi\f[R] die VM/den Container mit \f[B]systemd\-machined\f[R](8) registrieren, falls dies verfügbar ist. Standardmäßig \f[CR]auto\f[R].\fR .TP \f[CR]ForwardJournal=\f[R], \f[CR]\-\-forward\-journal=\fR Legt den Pfad fest, in dem Journalprotokolle aus Containern und virtuellen Maschinen weitergeleitet werden sollen. Falls der Pfad die Erweiterung \&\f[CR].journal\f[R] enthält, wird dieser als eine Datei interpretiert, in die das Journal geschrieben werden soll. Andernfalls wird der Pfad als ein Verzeichnis interpretiert, in das das Journal geschrieben werden soll.\fR .RS .PP Beachten Sie, dass Systemd v256 oder neuer in der virtuellen Maschine benötigt wird, damit Protokollweiterleitung funktioniert. .PP Beachten Sie, dass die Journal\-Größe auf \f[CR]4G\f[R] beschränkt ist, falls ein Pfad mit der Erweiterung \f[CR].journal\f[R] angegeben wird. Konfigurieren Sie ein Ausgabeverzeichnis anstelle einer Datei, falls ihre Auslastung mehr als \f[CR]4G\f[R] an Journal\-Daten erzeugt.\fR .RE .TP \f[B]StorageTargetMode=\f[R], \f[B]\-\-storage\-target\-mode=\fR Legt fest, ob der Unterbefehl \f[B]serve\f[R] \f[B]systemd\-storagetm\f[R] zum Ausliefern von Plattenabbildern über NVME\-TCP starten soll. Akzeptiert einen logischen Wert oder \f[B]auto\f[R]. Falls aktiviert, wird \f[B]systemd\-storagetm\f[R] immer gestartet und \f[B]mkosi\f[R] wird fehlschlagen, falls es \f[B]systemd\-storagetm\f[R] nicht starten kann. Falls deaktiviert, wird \f[B]systemd\-storagetm\f[R] niemals gestartet. Falls \f[B]auto\f[R], wird \f[B]systemd\-storagetm\f[R] gestartet, wenn ein Plattenabbild gebaut wird, das Programm \f[B]systemd\-storagetm\f[R] gefunden wird und \f[B]mkosi serve\f[R] unter der Benutzerkennung root aufgerufen wird.\fR .TP \f[CR]SysupdateDirectory=\f[R], \f[CR]\-\-sysupdate\-directory=\fR Pfad zu einem Verzeichnis, das Transferdefinitionsdateien von \f[B]systemd\-sysupdate\f[R](8) enthält, die von \f[CR]mkosi sysupdate\f[R] verwandt werden. Falls im lokalen Verzeichnis \f[CR]mkosi.sysupdate/\f[R] existiert, wird es automatisch für diesen Zweck verwandt.\fR .RS .PP Beachten Sie, dass \f[CR]mkosi sysupdate\f[R] \f[B]systemd\-sysupdate\f[R](8) mit \f[CR]\-\-transfer\-source=\f[R] auf das Ausgabeverzeichnis von \f[B]mkosi\f[R] gesetzt aufgerufen wird. Um dies in einer Transferdefinitionsdatei zu verwenden, setzen Sie \f[CR]PathRelativeTo=explicit\f[R], damit die Einstellung \f[CR]Path=\f[R] für die Transferquelle relativ zum Ausgabeverzeichnis von \f[B]mkosi\f[R] interpretiert wird. Im Allgemeinen reicht es aus, \f[CR]PathRelativeTo=explicit\f[R] und \f[CR]Path=/\f[R] relativ zu der Transferquelle zu konfigurieren, damit das Vergleichsmuster relativ zum Ausgabeverzeichnis von \f[B]mkosi\f[R] interpretiert wird.\fR .RE .SS "Abschnitt [Match]" .TP \f[CR]Profiles=\fR Übereinstimmung mit den konfigurierten Profilen. .TP \f[B]Distribution=\fR Übereinstimmung mit der konfigurierten Distribution. .TP \f[B]Release=\fR Übereinstimmung mit der konfigurierten Distributionsveröffentlichung. Falls diese Bedingung verwandt wird und noch keine Distribution explizit konfiguriert wurde, wird die Distribution und Veröffentlichung der Wirtmaschine verwandt. .TP \f[CR]Architecture=\fR Übereinstimmung mit der konfigurierten Architektur. Falls diese Bedingung verwandt wird und noch keine Architektur explizit konfiguriert wurde, wird die Architektur des Wirtsystems verwandt. \f[B]Architecture=uefi\f[R] kann für Übereinstimmungen mit allen Architekturen, die UEFI unterstützen, verwandt werden.\fR .TP \f[CR]Repositories=\fR Übereinstimmung mit Depots, die mit der Einstellung \f[CR]Repositories=\f[R] aktiviert wurden. Akzeptiert einen einzelnen Depotnamen.\fR .TP \f[B]PathExists=\fR Diese Bedingung ist erfüllt, wenn der angegebene Pfad existiert. Relative Pfade werden als relativ zum Elternverzeichnis der Konfigurationsdatei interpretiert, aus der diese Bedingung ausgelesen wurde. .TP \f[CR]ImageId=\fR Übereinstimmung mit der konfigurierten Abbildkennung, Globs werden unterstützt. Falls diese Bedingung verwandt wird und noch keine Abbildkennung explizit konfiguriert wurde, schlägt diese Bedingung fehl. .TP \f[CR]ImageVersion=\fR Übereinstimmung mit der konfigurierten Abbildversion. Den Abbildversionen können die Operatoren \f[CR]==\f[R], \f[CR]!=\f[R], \f[CR]>=\f[R], \f[CR]<=\f[R], \f[CR]<\f[R], \f[CR]>\f[R] für umfangreiche Versionsvergleiche entsprechend der UAPI\-Gruppenversionsformatspezifikation vorangestellt werden. Falls kein Operator vorangestellt wird, wird standardmäßig der Gleichheits\-Operator angenommen. Falls diese Bedingung verwandt wird und noch keine Abbildversion explizit konfiguriert wurde, schlägt diese Bedingung fehl.\fR .TP \f[CR]Bootable=\fR Übereinstimmung mit dem konfigurierten Wert für die Funktionalität \f[CR]Bootable=\f[R]. Akzeptiert einen logischen Wert oder \f[CR]auto\f[R].\fR .TP \f[CR]Format=\fR Übereinstimmung mit dem konfigurierten Wert für die Option \f[CR]Format=\f[R]. Akzeptiert ein Ausgabeformat (siehe die Option \f[CR]Format=\f[R]).\fR .TP \f[CR]SystemdVersion=\fR Übereinstimmung mit der Systemd\-Version des Wirtsystems (wie von \f[CR]systemctl \-\-version\f[R] berichtet). Den Werten können die Operatoren \f[CR]==\f[R], \f[CR]!=\f[R], \f[CR]>=\f[R], \f[CR]<=\f[R], \f[CR]<\f[R], \f[CR]>\f[R] für umfangreiche Versionsvergleiche entsprechend der UAPI\-Gruppenversionsformatspezifikation vorangestellt werden. Falls kein Operator vorangestellt wird, wird standardmäßig der Gleichheits\-Operator angenommen.\fR .TP \f[CR]BuildSources=\fR Akzeptiert einen Bauquellen\-Zielpfad (siehe \f[CR]BuildSources=\f[R]). Diese Übereinstimmung ist erfüllt, falls eine der konfigurierten Bauquellen diesen Zielpfad verwendet. Enthält beispielsweise eine Datei \f[CR]mkosi.conf\f[R] Folgendes:\fR .RS .IP .EX \f[B][Build]\f[R] BuildSources=../abc/qed:kernel\fR .EE .PP Und eine Ergänzung, die folgendes enthält: .IP .EX \f[B][Match]\f[R] BuildSources=kernel\fR .EE .PP Die Ergänzung wird aufgenommen. .PP Alle an diese Einstellung übergebenen absoluten Pfade werden relativ zum aktuellen Arbeitsverzeichnis interpretiert. .RE .TP \f[CR]HostArchitecture=\fR Übereinstimmung mit der grundständigen Architektur des Wirtrechners. Siehe die Einstellung \f[CR]Architecture=\f[R] für eine Liste möglicher Werte.\fR .TP \f[CR]ToolsTreeDistribution=\fR Übereinstimmung mit der konfigurierten Werkzeugbaum\-Distribution. .TP \f[CR]ToolsTreeRelease=\fR Übereinstimmung mit der konfigurierten Werkzeugbaum\-Veröffentlichung. .TP \f[CR]Environment=\fR Übereinstimmung mit einem bestimmten, mit \f[CR]Environment=\f[R] konfigurierten Schlüssel/Wert\-Paar. Falls kein Wert bereitgestellt wird, wird überprüft, ob ein angegebener Schlüssel sich in der Umgebung befindet, unabhängig von seinem Wert.\fR .TP \f[B]Image=\fR Vergleicht mit dem aktuellen (Unter\-)Abbild. Der Name des Unterabbilds ist sein Name in \f[I]mkosi.images/\f[R] (ohne die Endung \f[I].conf\f[R]). Der Name des Abbilds auf oberster Ebene lautet \f[I]main\f[R]. Der Haupteinsatzfall ist die Möglichkeit, eine gemeinsame Konfiguration zu verwenden, die sowohl vom Abbild auf der obersten Ebene als auch allen Unterabbildern eingebunden werden kann, indem die allgemeingültigen Einstellungen durch einen Treffer \f[CR]Image=main\f[R] gesteuert werden.\fR .PP Diese Tabelle zeigt, welche Übereinstimmer Globs und mächtige Vergleiche unterstützen sowie den Vorgabewert, gegen den überprüft wird, falls zum Zeitpunkt des Einlesens der Konfigurationsdatei kein Wert bereitgestellt wurde: .PP .TS tab(@); lw(13.1n) lw(3.5n) lw(9.1n) lw(44.3n). T{ Übereinstimmer T}@T{ Globs T}@T{ Umfangreiche Vergleiche T}@T{ Vorgabe T} _ T{ \f[CR]Profiles=\fR T}@T{ \f[R]no\fR T}@T{ \f[R]no\fR T}@T{ \f[R]Übereinstimmung schlägt fehl\fR T} T{ \f[B]Distribution=\fR T}@T{ \f[R]no\fR T}@T{ \f[R]no\fR T}@T{ \f[R]Übereinstimmung mit Distribution des Wirtsystems\fR T} T{ \f[B]Release=\fR T}@T{ \f[R]no\fR T}@T{ \f[R]no\fR T}@T{ \f[R]Übereinstimmung mit Veröffentlichung des Wirtsystems\fR T} T{ \f[CR]Architecture=\fR T}@T{ \f[R]no\fR T}@T{ \f[R]no\fR T}@T{ \f[R]Übereinstimmung mit Architektur des Wirtsystems\fR T} T{ \f[B]PathExists=\fR T}@T{ \f[R]no\fR T}@T{ \f[R]no\fR T}@T{ \f[R]n.Z.\fR T} T{ \f[CR]ImageId=\fR T}@T{ \f[R]yes\fR T}@T{ \f[R]no\fR T}@T{ \f[R]Übereinstimmung schlägt fehl\fR T} T{ \f[CR]ImageVersion=\fR T}@T{ \f[R]no\fR T}@T{ \f[R]yes\fR T}@T{ \f[R]Übereinstimmung schlägt fehl\fR T} T{ \f[CR]Bootable=\fR T}@T{ \f[R]no\fR T}@T{ \f[R]no\fR T}@T{ \f[R]Übereinstimmung mit automatischer Funktionalität\fR T} T{ \f[CR]Format=\fR T}@T{ \f[R]no\fR T}@T{ \f[R]no\fR T}@T{ \f[R]Übereinstimmung mit Standardformat\fR T} T{ \f[CR]SystemdVersion=\fR T}@T{ \f[R]no\fR T}@T{ \f[R]yes\fR T}@T{ \f[R]n.Z.\fR T} T{ \f[CR]BuildSources=\fR T}@T{ \f[R]no\fR T}@T{ \f[R]no\fR T}@T{ \f[R]Übereinstimmung schlägt fehl\fR T} T{ \f[CR]HostArchitecture=\fR T}@T{ \f[R]no\fR T}@T{ \f[R]no\fR T}@T{ \f[R]n.Z.\fR T} T{ \f[CR]ToolsTreeDistribution=\fR T}@T{ \f[R]no\fR T}@T{ \f[R]no\fR T}@T{ \f[R]Übereinstimmung mit dem Rückfall\-Werkzeugbaum der Distribution (siehe \f[CR]ToolsTreeDistribution=\f[R] in \f[CR][Build]\f[R])\fR T} T{ \f[CR]ToolsTreeRelease=\fR T}@T{ \f[R]no\fR T}@T{ \f[R]no\fR T}@T{ \f[R]Übereinstimmung mit Standard\-Werkzeugbaum\-Veröffentlichung\fR T} T{ \f[CR]Environment=\fR T}@T{ \f[R]no\fR T}@T{ \f[R]no\fR T}@T{ \f[R]n.Z.\fR T} T{ \f[B]Image=\fR T}@T{ \f[R]no\fR T}@T{ \f[R]no\fR T}@T{ \f[R]n.Z.\fR T} .TE .SS [Include] .TP \f[CR]Include=\f[R], \f[CR]\-\-include=\f[R], \f[CR]\-I\fR Bindet zusätzliche Konfiguration aus der angegebenen Datei oder dem angegebenen Verzeichnis ein. Die zusätzliche Konfiguration wird sofort nach Auswerten dieser Einstellung eingebunden, außer wenn dies auf der Befehlszeile passiert \- dann wird die zusätzliche Konfiguration nach Auswerten aller Befehlszeilenargumente eingebunden. .RS .PP Beachten Sie, dass jeder Pfad mit zusätzlicher Konfiguration nur einmal ausgewertet wird, selbst wenn er mit \f[CR]Include=\f[R] mehrfach eingebunden ist.\fR .PP Die eingebauten Konfigurationen für die Vorgabe\-Initrd, den Vorgabe\-Werkzeugbaum, das standardmäßige Virtuelle\-Maschinenabbild und die standardmäßige UKI\-Ergänzung von \f[B]mkosi\f[R] können eingebunden werden, indem der wörtliche Wert \f[B]mkosi\-initrd\f[R], \f[B]mkosi\-tools\f[R], \f[B]mkosi\-vm\f[R] bzw. \f[B]mkosi\-addon\f[R] eingebunden wird.\fR .PP Beachten Sie: Einbindenamen, die mit entweder dem wörtlichen \f[CR]mkosi\-\f[R] oder \f[CR]contrib\-\f[R] beginnen, sind für die Verwendung durch \f[B]mkosi\f[R] selbst reserviert.\fR .RE .SS "Abschnitt [Config]" .TP \f[B]Profiles=\f[R], \f[B]\-\-profile=\fR Wählt die angegebenen Profile aus. Ein Profil ist eine Konfigurationsdatei oder \-verzeichnis in dem Verzeichnis \f[CR]mkosi.profiles/\f[R]. Die Konfigurationsdateien und \-verzeichnisse werden nach der Auswertung der Datei \f[CR]mkosi.conf\f[R], aber vor allen Ergänzungskonfigurationen in \f[CR]mkosi.conf.d/*.conf\f[R] eingebunden.\fR .TP \f[CR]Dependencies=\f[R], \f[CR]\-\-dependency=\fR Die Abbilder, von denen dieses Abbild abhängt, festgelegt als Kommata\-getrennte Liste. Alle in dieser Option konfigurierten Abbilder werden vor diesem Abbild gebaut. .RS .PP Wird diese Einstellung für das »Hauptabbild« angegeben, legt sie fest, welche Unterabbilder gebaut werden sollen. Siehe den Abschnitt \f[B]BAU MEHRERER ABBILDER\f[R] für weitere Informationen.\fR .RE .TP \f[CR]MinimumVersion=\f[R], \f[CR]\-\-minimum\-version=\fR Die minimale Version von \f[B]mkosi\f[R], die zum Bau dieser Konfiguration benötigt wird. Falls mehrfach angegeben, wird die höchste festgelegte Version verwandt. .RS .PP Die minimale Version kann auch als ein Git\-Commit\-Hash festgelegt werden, wenn ihr \f[B]commit:\f[R] vorangestellt wird. In diesem Fall muss \f[B]mkosi\f[R] aus einem \f[B]git\[R](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 \f[B]mkosi\f[R] heraus aufgerufen wird.\fR .RE .TP \f[CR]ConfigureScripts=\f[R], \f[CR]\-\-configure\-script=\fR Akzeptiert eine Kommata\-getrennte Liste von Pfaden zu Programmen, die als Konfigurationsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt \f[B]SKRIPTE\f[R] für weitere Informationen.\fR .TP \f[CR]PassEnvironment=\f[R], \f[CR]\-\-pass\-environment=\fR Akzeptiert eine Liste von durch Leerzeichen getrennten Umgebungsvariablennamen. Beim Bau mehrerer Abbilder werden die aufgeführten Umgebungsvariablen an jedes einzelne Unterabbild übergeben, als ob sie »universelle« Einstellungen wären. Siehe den Abschnitt \f[B]BAU MEHRERER ABBILDER\f[R] für weitere Informationen.\fR .SS "Abschnitt [UKIProfile]" Der Abschnitt \f[CR]UKIProfile\f[R] kann in UKI\-Profil\-Konfigurationsdateien verwandt werden, die an die Einstellung \f[CR]UnifiedKernelImageProfiles=\f[R] übergeben werden. Die folgenden Einstellungen können im Abschnitt \f[CR]UKIProfile\f[R] festgelegt werden:\fR .TP \f[CR]Profile=\fR Der Inhalt des Abschnitts \f[CR].profile\f[R] des UKI\-Profils. Akzeptiert eine Liste von Schlüssel/Wert\-Paaren, getrennt durch \f[CR]=\f[R]. Der Schlüssel \f[CR]ID=\f[R] muss angegeben werden. Siehe die .UR https://uapi\-group.org/specifications/specs/unified_kernel_image/#multi\-profile\-ukis Spezifikation .UE für eine vollständige Liste aller möglichen Schlüssel.\fR .TP \f[CR]Cmdline=\fR Zusätzliche Kernelbefehlszeilenoptionen für das UKI\-Profil. Akzeptiert eine durch Leerzeichen begrenzte Liste von zusätzlichen Kernelbefehlszeilenargumenten. Beachten Sie, dass der letztendliche Abschnitt \f[CR].cmdline\f[R] eine Kombination des grundlegenden Abschnitts \&\f[CR].cmdline\f[R] und der mit dieser Option festgelegten zusätzlichen Kernelbefehlszeilenargumente ist.\fR .TP \f[B]SignExpectedPcr=\fR Signiert erwartete PCR\-Messungen für dieses UKI\-Profil. Akzeptiert einen logischen Wert. Standardmäßig aktiviert. .SS Kennzeichner Auf den aktuelle Wert verschiedener Einstellungen kann beim Auswerten mittels Kennzeichner zugegriffen werden. Um ein wörtliches Zeichen \f[CR]%\f[R] in einer Konfiguration zu schreiben, ohne es als Kennzeichner zu behandeln, verwenden Sie \f[CR]%%\f[R]. Es werden die folgenden Kennzeichner verstanden:\fR .PP .TS tab(@); l l. T{ Einstellung T}@T{ Kennzeichner T} _ T{ \f[B]Distribution=\fR T}@T{ \f[CR]%d\fR T} T{ \f[B]Release=\fR T}@T{ \f[CR]%r\fR T} T{ \f[CR]Architecture=\fR T}@T{ \f[CR]%a\fR T} T{ \f[CR]Format=\fR T}@T{ \f[CR]%t\fR T} T{ \f[CR]Output=\fR T}@T{ \f[CR]%o\fR T} T{ \f[CR]OutputDirectory=\fR T}@T{ \f[CR]%O\fR T} T{ \f[CR]ImageId=\fR T}@T{ \f[CR]%i\fR T} T{ \f[CR]ImageVersion=\fR T}@T{ \f[CR]%v\fR T} .TE .PP Es gibt auch von Einstellungen unabhängige Kennzeichner: .PP .TS tab(@); l l. T{ Kennzeichner T}@T{ Wert T} _ T{ \f[CR]%C\fR T}@T{ \f[R]Elternverzeichnis der aktuellen Konfigurationsdatei\fR T} T{ \f[CR]%P\fR T}@T{ \f[R]Aktuelles Arbeitsverzeichnis\fR T} T{ \f[CR]%D\fR T}@T{ \f[R]Verzeichnis, in dem \f[B]mkosi\f[R] aufgerufen wurde\fR T} T{ \f[CR]%I\fR T}@T{ \f[R]Name des aktuellen Unterabbildes in \f[CR]mkosi.images\fR T} .TE .PP Schließlich gibt es Kennzeichner, die von einer Einstellung abgeleitet werden: .PP .TS tab(@); l l. T{ Kennzeichner T}@T{ Wert T} _ T{ \f[CR]%F\fR T}@T{ \f[R]Das Standarddateisystem der konfigurierten Distribution\fR T} .TE .PP Beachten Sie, dass sich das aktuelle Arbeitsverzeichnis ändert, während \f[B]mkosi\f[R] seine Konfiguration auswertet. Insbesondere ändert \f[B]mkosi\f[R] sein Arbeitsverzeichnis jedes Mal, wenn es ein Verzeichnis mit einer Datei \f[CR]mkosi.conf\f[R] auswertet, auf dieses Verzeichnis.\fR .PP Beachten Sie, dass das Verzeichnis, aus dem \f[B]mkosi\f[R] heraus aufgerufen wurde, durch das Befehlszeilenargument \f[CR]\-\-directory=\f[R] beeinflusst wird.\fR .PP Die folgende Tabelle zeigt Beispielwerte für die oben aufgeführten Verzeichniskennzeichner: .PP .TS tab(@); lw(4.7n) lw(13.4n) lw(25.2n) lw(26.7n). T{ T}@T{ \f[CR]$D/mkosi.conf\fR T}@T{ \f[CR]$D/mkosi.conf.d/abc/abc.conf\fR T}@T{ \f[CR]$D/mkosi.conf.d/abc/mkosi.conf\fR T} \f[R]_\fR T{ \f[CR]%C\fR T}@T{ \f[CR]$D\fR T}@T{ \f[CR]$D/mkosi.conf.d\fR T}@T{ \f[CR]$D/mkosi.conf.d/abc\fR T} T{ \f[CR]%P\fR T}@T{ \f[CR]$D\fR T}@T{ \f[CR]$D\fR T}@T{ \f[CR]$D/mkosi.conf.d/abc\fR T} T{ \f[CR]%D\fR T}@T{ \f[CR]$D\fR T}@T{ \f[CR]$D\fR T}@T{ \f[CR]$D\fR T} .TE .SS "Unterstützte Distributionen" Für die folgenden Distributionen können Abbilder zur Installation erstellt werden: .IP \[bu] 2 \f[I]Fedora Linux\fR .IP \f[R]\[bu]\fR 2 \f[I]Debian\fR .IP \f[R]\[bu]\fR 2 \f[I]Kali Linux\fR .IP \f[R]\[bu]\fR 2 \f[I]Ubuntu\fR .IP \f[R]\[bu]\fR 2 \f[I]Arch Linux\fR .IP \f[R]\[bu]\fR 2 \f[I]openSUSE\fR .IP \f[R]\[bu]\fR 2 \f[I]Mageia\fR .IP \f[R]\[bu]\fR 2 \f[I]CentOS\fR .IP \f[R]\[bu]\fR 2 \f[I]RHEL\fR .IP \f[R]\[bu]\fR 2 \f[I]RHEL UBI\fR .IP \f[R]\[bu]\fR 2 \f[I]OpenMandriva\fR .IP \f[R]\[bu]\fR 2 \f[I]Rocky Linux\fR .IP \f[R]\[bu]\fR 2 \f[I]Alma Linux\fR .IP \f[R]\[bu]\fR 2 \f[I]Azure Linux\fR .IP \f[R]\[bu]\fR 2 \f[I]postmarketOS\fR .IP \f[R]\[bu]\fR 2 \f[I]None\f[R] (\f[B]Dazu muss der Benutzer ein bereits gebautes Rootfs bereitstellen\f[R])\fR .PP Theoretisch kann jede Distribution auf dem Wirtrechner zum Bau der Abbilder, die jede andere Distribution enthalten können, verwandt werden, solange die notwendigen Werkzeuge verfügbar sind. Insbesondere jede Distribution, die \f[B]apt\f[R](8) paketiert, kann zum Bau von Abbildern von \f[I]Debian\f[R], \f[I]Kali\f[R] oder \f[I]Ubuntu\f[R] verwandt werden. Jede Distribution, die \f[B]dnf\f[R](8) paketiert, kann zum Bau von Abbildern von jeder \f[V]rpm\f[R](8)\-basierten Distribution verwandt werden. Jede Distribution, die \f[B]pacman\f[R](8) paketiert, kann zum Bau von Abbildern von \f[I]Arch Linux\f[R] verwandt werden. Jede Distribution, die \f[B]zypper\f[R](8) paketiert, kann zum Bau von Abbildern von \f[I]openSUSE\f[R] verwandt werden. Andere Distributionen und Bauautomatisierungswerkzeuge für eingebettete Linux\-Systeme wie Buildroot, OpenEmbedded und Yocto Project können durch Auswahl der Distribution \f[CR]custom\f[R] und der Befüllung des Rootfs mit einer Kombination von Basisbäumen, Gerüstbäumen und Vorbereitungsskripten verwandt werden.\fR .PP Derzeit paketiert \f[I]Fedora Linux\f[R] alle relevanten Werkzeuge seit Fedora 28.\fR .PP Beachten Sie, dass Sie Abbilder für \f[CR]RHEL\f[R] nur auf einem Wirtsystem bauen können, das über ein \f[CR]RHEL\f[R]\-Abonnement verfügt (das beispielsweise mit dem \f[CR]subscription\-manager\f[R] eingerichtet wurde), wenn Sie keinen angepassten Spiegel verwenden.\fR .SH ARBEITSABLAUF Arbeitsablauf für \f[B]mkosi build\f[R]. Standardwerte bzw. \-aufrufe werden in Klammern dargestellt. Beim Bau mit \f[B]\-\-incremental=yes\f[R] erstellt \f[B]mkosi\f[R] einen Zwischenspeicher der Distributionsinstallation, falls er nicht bereits existiert und ersetzt die Distributionsinstallation in sukzessiven Aufrufen durch Daten aus dem Zwischenspeicher.\fR .IP \f[R]1.\fR 3 Wertet Befehlszeilen\-Optionen aus .IP 2. 3 Wertet Konfigurationsdateien aus .IP 3. 3 Führt Konfigurationsskripte aus (\f[CR]mkosi.configure\f[R])\fR .IP \f[R]4.\fR 3 Falls nicht als Root ausgeführt wird, trennt den Benutzernamensraum ab und der in \f[CR]/etc/subuid\f[R] und \f[CR]/etc/subgid\f[R] konfigurierte Subuid\-Bereich wird darin abgebildet.\fR .IP \f[R]5.\fR 3 Trennt den Einhängenamensraum ab .IP 6. 3 Hängt die folgenden Verzeichnisse schreibgechützt neu ein, falls sie existieren: .RS 4 .IP \[bu] 2 \f[CR]/usr\fR .IP \f[R]\[bu]\fR 2 \f[CR]/etc\fR .IP \f[R]\[bu]\fR 2 \f[CR]/opt\fR .IP \f[R]\[bu]\fR 2 \f[CR]/srv\fR .IP \f[R]\[bu]\fR 2 \f[CR]/boot\fR .IP \f[R]\[bu]\fR 2 \f[CR]/efi\fR .IP \f[R]\[bu]\fR 2 \f[CR]/media\fR .IP \f[R]\[bu]\fR 2 \f[CR]/mnt\fR .RE .PP Führen Sie dann für jedes Abbild die folgenden Schritte aus: .IP " 1." 4 Kopieren von Sandbox\-Bäumen in den Arbeitsbereich .IP " 2." 4 Synchronisieren der Depot\-Metadaten des Paketverwalters .IP " 3." 4 Ausführen der Synchronisierungsskripte (\f[CR]mkosi.sync\f[R])\fR .IP "\f[R] 4.\fR" 4 Kopieren der Basisbäume (\f[CR]\-\-base\-tree=\f[R]) in das Abbild\fR .IP "\f[R] 5.\fR" 4 Wiederverwenden eines zwischengespeicherten Abbilds, falls verfügbar .IP " 6." 4 Kopieren eines Schnappschusses der Depot\-Metadaten des Paketverwalters in das Abbild .IP " 7." 4 Kopieren von Gerüstbäumen (\f[CR]mkosi.skeleton\f[R]) in das Abbild\fR .IP "\f[R] 8.\fR" 4 Installieren der Distribution und Pakete in das Abbild .IP " 9." 4 Ausführen der Vorbereitungsskripte auf dem Abbild mit dem Argument \f[CR]final\f[R] (\f[CR]mkosi.prepare\f[R])\fR .IP \f[R]10.\fR 4 Installieren der Baupakete in der Überlagerung, falls irgendwelche Bauskripte konfiguriert sind .IP 11. 4 Ausführen der Vorbereitungsskripte auf der Überlagerung mit dem Argument \f[CR]build\f[R], falls irgendwelche Bauskripte konfiguriert sind (\f[CR]mkosi.prepare\f[R])\fR .IP \f[R]12.\fR 4 Zwischenspeichern des Abbilds, falls konfiguriert (\f[B]\-\-incremental=yes\f[R])\fR .IP \f[R]13.\fR 4 Ausführen der Bauskripte auf dem Abbild & der Überlagerung, falls irgendwelche Bauskripte konfiguriert sind (\f[CR]mkosi.build\f[R])\fR .IP \f[R]14.\fR 4 Finalisieren des Baus, falls das Ausgabeformat \f[CR]none\f[R] konfiguriert ist\fR .IP \f[R]15.\fR 4 Kopieren der Bauskripteausgaben in das Abbild .IP 16. 4 Kopieren der zusätzlichen Bäume in das Abbild (\f[CR]mkosi.extra\f[R])\fR .IP \f[R]17.\fR 4 Ausführen der Post\-Install\-Skripte (\f[CR]mkosi.postinst\f[R])\fR .IP \f[R]18.\fR 4 Schreiben der für \f[CR]Ssh=\f[R], \f[CR]Autologin=\f[R] und \f[CR]MakeInitrd=\f[R] benötigten Konfigurationsdateien\fR .IP \f[R]19.\fR 4 Installieren von \f[B]systemd\-boot\f[R](7) und konfigurieren des sicheren Systemstart, falls konfiguriert (\f[B]\-\-secure\-boot=yes\f[R])\fR .IP \f[R]20.\fR 4 Ausführen von \f[B]systemd\-sysusers\fR(8) .IP \f[R]21.\fR 4 Ausführen von \f[B]systemd\-tmpfiles\fR(8) .IP \f[R]22.\fR 4 Ausführen von \f[CR]systemctl preset\-all\fR .IP \f[R]23.\fR 4 Ausführen von \f[B]depmod\fR(8) .IP \f[R]24.\fR 4 Ausführen von \f[B]systemd\-firstboot\fR(1) .IP \f[R]25.\fR 4 Ausführen vom \f[B]systemd\-hwdb\fR(8) .IP \f[R]26.\fR 4 Entfernen von Pakete und Dateien (\f[CR]RemovePackages=\f[R], \f[CR]RemoveFiles=\f[R])\fR .IP \f[R]27.\fR 4 Ausführen von SELinux\-Neumarkierung, falls eine SELinux\-Richtlinie installiert ist .IP 28. 4 Ausführen von Finalisierungskripten (\f[CR]mkosi.finalize\f[R])\fR .IP \f[R]29.\fR 4 Erstellen des Vereinigten Kernelabbildes, falls so konfiguriert .IP 30. 4 Erstellen des finalen Ausgabeformats .IP 31. 4 Ausführen der Post\-Ausgabe\-Skripte (\f[CR]mkosi.postoutput\f[R])\fR .SH SKRIPTE Um die Anpassung von Abbildern zu erlauben, die nicht mittels der in \f[B]mkosi\f[R] eingebauten Funktionalitäten implementiert werden können, unterstützt \f[B]mkosi\f[R] die Ausführung von Skripten zu verschiedenen Zeitpunkten während des Abbildbauprozesses, die das Abbild nach Bedarf anpassen können. Skripte werden auf dem Wirtsystem als Root (entweder als echtem Root oder Root innerhalb des Benutzernamensraums, den \f[B]mkosi\f[R] bei dem unprivilegierten Aufruf erstellte) mit einer angepassten Umgebung ausgeführt, um die Veränderung des Abbildes zu erleichtern. Für jedes Skript werden die konfigurierten Bauquellen (\f[CR]BuildSources=\f[R]) in das aktuelle Arbeitsverzeichnis eingehängt, bevor das Skript im aktuellen Arbeitsverzeichnis ausgeführt wird. \f[CR]$SRCDIR\f[R] wird so gesetzt, dass es auf das aktuelle Arbeitsverzeichnis zeigt. Die folgenden Skripte werden unterstützt:\fR .IP \f[R]\[bu]\fR 2 Falls \f[I]mkosi.configure\f[R] (\f[CR]ConfigureScripts=\f[R]) existiert, wird es vor dem Bau des Abbilds ausgeführt. Dieses Skript kann zur dynamischen Veränderung der Konfiguration verwandt werden. Es empfängt die Konfiguration serialisiert als JSON auf der Standardeingabe und sollte die veränderte Konfiguration serialisiert auf der Standardausgabe ausgeben. Beachten Sie, dass dieses Skript nur ausgeführt wird, wenn das Abbild gebaut oder gestartet wird (Unterbefehle \f[CR]build\f[R], \f[CR]vm\f[R], \f[CR]boot\f[R] und \f[CR]shell\f[R]). Falls ein Vorgabe\-Werkzeugbaum konfiguriert ist, wird er vor der Ausführung des Konfigurationsskriptes gebaut und das Konfigurationsskript wird mit vorhandenen Werkzeugen ausgeführt. Das bedeutet auch, dass die durch das Konfigurationsskript vorgenommenen Änderungen nicht in der Ausgabe von \f[CR]summary\f[R] sichtbar sein werden.\fR .IP \f[R]\[bu]\fR 2 Falls \f[I]mkosi.sync\f[R] (\f[CR]SyncScripts=\f[R]) existiert, wird es vor dem Bau des Abbildes ausgeführt. Dieses Skript kann zur Aktualisierung verschiedener, während des Baus verwandter Quellen eingesetzt werden. Ein Anwendungsszenario ist die Ausführung von \f[CR]git pull\f[R] in verschiedenen Quelldepots vor dem Bau des Abbildes. Insbesondere gilt die Einstellung \f[CR]BuildSourcesEphemeral=\f[R] nicht für Synchronisationsskripte, was bedeutet, dass Synchronisationsskripte zur Aktualisierung von Bauquellen verwandt werden können, selbst wenn \f[CR]BuildSourcesEphemeral=\f[R] aktiviert ist.\fR .IP \f[R]\[bu]\fR 2 Falls \f[I]mkosi.prepare\f[R] (\f[CR]PrepareScripts=\f[R]) existiert, wird es zuerst mit dem Argument \f[CR]final\f[R] aufgerufen, direkt nachdem die Software\-Pakete installiert sind. Es wird ein zweites Mal mit dem Befehlszeilenparameter \f[CR]build\f[R] aufgerufen, direkt nachdem die Baupakete installiert sind und die Bauüberlagerung oberhalb des Wurzelverzeichnisses des Abbildes eingehängt ist. Dieses Skript hat Netzwerkzugang und kann zur Installation von Paketen aus weiteren Quellen neben dem Paketverwalter der Distribution verwandt werden (z.B. \ \f[B]pip\f[R](1), \f[B]npm\f[R](1), …), nachdem alle Software\-Pakete installiert wurden, aber bevor das Abbild zwischengespeichert wird (falls der inkrementelle Modus aktiviert wurde). Im Gegensatz zur einer Allzweckinstallation ist die Installtion von Paketen in das System (\f[CR]pip install\f[R], \f[CR]npm install \-g\f[R]) anstelle in \f[CR]$SRCDIR\f[R] sicher, da das Bauabbild nur für ein einzelnes Projekt verwandt wird und leicht entsorgt und neugebaut werden kann, und es daher kein Risiko von in Konflikt stehenden Abhängigkeiten und kein Risiko der Verunreinigung des Wirtsystems gibt.\fR .IP \f[R]\[bu]\fR 2 Falls \f[I]mkosi.build\f[R] (\f[CR]BuildScripts=\f[R]) existiert, wird es ausgeführt, wenn die Bauüberlagerung oberhalb des Wurzelverzeichnisses des Abbildes eingehängt wurde. Bei der Ausführung der Bauskripte zeigt \f[CR]$DESTDIR\f[R] auf ein Verzeichnis, in dem die Skripte alle erstellten Dateien ablegen sollen, die dann im Abbild landen sollen. Beachten Sie, dass die Bausysteme, die auf \f[B]make\f[R](1),\f[B]automake\f[R](1) und \f[B]meson\f[R](1) basieren, im Allgemeinen \f[CR]$DESTDIR\f[R] berücksichtigen und damit der Bau von \f[I]source\f[R]\-Bäumen sehr natürlich vonstatten geht. Nach der Ausführung des Bauskripts wird der Inhalt von \f[CR]$DESTDIR\f[R] in das Abbild kopiert.\fR .IP \f[R]\[bu]\fR 2 Falls \f[I]mkosi.postinst\f[R] (\f[CR]PostInstallationScripts=\f[R]) existiert, wird es nach der Installation der (optionalen) Bau\- und Zusatzbäume ausgeführt. Dieses Skript kann zur Veränderung des Abbilds ohne jede Beschränkung verwandt werden, nachdem alle Softwarepakete und Bauquellen installiert wurden.\fR .IP \f[R]\[bu]\fR 2 Falls \f[I]mkosi.finalize\f[R] (\f[CR]FinalizeScripts=\f[R]) existiert, wird es als letzter Schritt der Vorbereitung des Abbildes ausgeführt.\fR .IP \f[R]\[bu]\fR 2 Falls \f[I]mkosi.postoutput\f[R] (\f[CR]PostOutputScripts=\f[R]) existiert, wird es direkt nach der Erstellung aller Ausgabedateien ausgeführt, bevor sie abschließend in das Ausgabeverzeichnis geschoben werden. Dies kann zur Erstellung zusätzlicher oder alternativer Ausgaben verwandt werden, z.B.\ \f[CR]SHA256FILES\f[R] oder SBOM\-Listen.\fR .IP \f[R]\[bu]\fR 2 Falls \f[I]mkosi.clean\f[R] (\f[CR]CleanScripts=\f[R]) existiert, wird es direkt nach der Bereinigung eines vorherigen Baus ausgeführt. Ein Bereinigungsskript kann sämtliche Ausgaben bereinigen, die \f[B]mkosi\f[R] nicht kennt (z.B. Artefakte von \f[CR]SplitArtifacts=partitions\f[R] oder RPMs, die in einem Bauskript erstellt wurden). Beachten Sie, dass dieses Skript den Werkzeugbaum nicht verwendet, selbst wenn einer konfiguriert ist.\fR .IP \f[R]\[bu]\fR 2 Falls \f[I]mkosi.version\f[R] existiert und ausführbar ist, wird sie während der Auswertung der Konfiguration ausgeführt und füllt \f[CR]ImageVersion=\f[R] mit der Ausgabe auf der Standardausgabe. Dies kann für externe Versionverfolgung verwandt werden, z.B.\ mit \f[CR]git describe\f[R] oder \f[CR]date \[aq]+%Y\-%m\-%d\[aq]\f[R]. Beachten Sie, dass dieses Skript auf dem Hauptsystem ohne irgendeine Sandbox ausgeführt wird.\fR .IP \f[R]\[bu]\fR 2 Falls \f[I]mkosi.version\f[R] existiert und ausführbar ist, wird sie während der Auswertung der Konfiguration ausgeführt und füllt \f[CR]RootPassword=\f[R] mit der Ausgabe auf der Standardausgabe. Dies kann zur Erstellung eines zufälligen Passworts verwandt werden. Um sich daran zu erinnern, kann es auf der Standardfehlerausgabe ausgegeben werden oder durch Lesen von \f[CR]$MKOSI_CONFIG\f[R] in einem anderen Skript (z.B.\ \f[CR]mkosi.postoutput\f[R]) ermittelt werden. Beachten Sie, dass dieses Skript auf dem Hauptsystem ohne irgendeine Sandbox ausgeführt wird.\fR .PP Falls ein Skript die Erweiterung \f[CR].chroot\f[R] verwendet, wird \f[B]mkosi\f[R] ein \f[B]chroot\f[R](8) mittels \f[B]mkosi\-chroot\f[R] (siehe unten) durchführen, bevor das Skript ausgeführt wird. Falls beispielsweise \f[CR]mkosi.postinst.chroot\f[R] existiert, wird \f[B]mkosi\f[R] ein \f[B]chroot\f[R](8) in das Abbild durchführen und das Skript als Postinstallationsskript ausführen.\fR .PP Anstatt eines Skripts in einer einzelnen Datei wird \f[B]mkosi\f[R] auch alle Dateien in lexikographischer Reihenfolge aus geeignet benannten Verzeichnissen \f[CR].d\f[R] lesen, z.B.\ alle Dateien in einem Verzeichnis \f[CR]mkosi.build.d\f[R] würden als Bauskripte verwandt. Folgende Verzeichnisse werden unterstützt:\fR .IP \f[R]\[bu]\fR 2 \f[CR]mkosi.sync.d\f[R],\fR .IP \f[R]\[bu]\fR 2 \f[CR]mkosi.prepare.d\f[R],\fR .IP \f[R]\[bu]\fR 2 \f[CR]mkosi.build.d\f[R],\fR .IP \f[R]\[bu]\fR 2 \f[CR]mkosi.postinst.d\f[R],\fR .IP \f[R]\[bu]\fR 2 \f[CR]mkosi.finalize.d\f[R],\fR .IP \f[R]\[bu]\fR 2 \f[CR]mkosi.postoutput.d\f[R] und\fR .IP \f[R]\[bu]\fR 2 \f[CR]mkosi.clean.d\f[R].\fR .PP Dies kann mit der Erweiterung \f[CR].chroot\f[R] kombiniert werden, z.B.\ würde \f[CR]mkosi.build.d/01\-foo.sh\f[R] ohne Wechsel mittels \f[B]chroot\f[R](8) in das Abbild ausgeführt und \f[CR]mkosi.build.d/02\-bar.sh.chroot\f[R] würde nach dem zuerst erfolgten \f[B]chroot\f[R](8) in das Abbild ausgeführt.\fR .PP Von \f[B]mkosi\f[R] ausgeführte Skripte erhalten die folgenden Umgebungsvariablen:\fR .IP \f[R]\[bu]\fR 2 \f[CR]$ARCHITECTURE\f[R] enthält die Architektur aus der Einstellung \f[CR]Architecture=\f[R]. Falls \f[CR]Architecture=\f[R] nicht gesetzt ist, wird es die native Architektur der Wirtmaschine erhalten. Siehe die Dokumentation von \f[CR]Architecture=\f[R] für mögliche Werte dieser Variablen.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$QEMU_ARCHITECTURE\f[R] enthält die Architektur aus \f[CR]$ARCHITECTURE\f[R] in dem von \f[B]qemu\f[R] verwandten Format. Nützlich, um das Programm von Qemu zu finden (\f[CR]qemu\-system\-$QEMU_ARCHITECTURE\f[R]).\fR .IP \f[R]\[bu]\fR 2 \f[I]$EFI_ARCHITECTURE\f[R] enthält die Architektur aus \f[I]$ARCHITECTURE\f[R] in dem von \f[B]UEFI\f[R] verwandten Format. Auf Architekturen, die \f[B]UEFI\f[R] nicht unterstützen, ist sie nicht gesetzt.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$DISTRIBUTION\f[R] enthält die Distribution aus der Einstellung \f[CR]Distribution=\f[R].\fR .IP \f[R]\[bu]\fR 2 \f[CR]$RELEASE\f[R] enthält die Veröffentlichung aus der Einstellung \f[CR]Release=\f[R].\fR .IP \f[R]\[bu]\fR 2 \f[CR]$DISTRIBUTION_ARCHITECTURE\f[R] enthält die Architektur aus \f[CR]$ARCHITECTURE\f[R] in dem von der konfigurierten Distribution verwandten Format.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$PROFILES\f[R] enthält die Profile aus der Einstellung \f[CR]Profiles=\f[R] als eine Kommata\-getrennte Zeichenkette.\fR .IP \f[R]\[bu]\fR 2 \f[I]$CACHED\f[R] wird auf \f[B]1\f[R] gesetzt, falls ein zwischengespeichertes Abbild verfügbar ist, ansonsten auf \f[B]0\f[R].\fR .IP \f[R]\[bu]\fR 2 \f[CR]$CHROOT_SCRIPT\f[R] enthält den Pfad zu dem laufenden Skript, relativ zum Wurzelverzeichnis des Abbildes. Der primäre Anwendungsfall für diese Variable ist in der Kombination mit dem Skript \f[B]mkosi\-chroot\f[R]. Siehe die nachfolgende Beschreibung von \f[B]mkosi\-chroot\f[R] für weitere Informationen.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$SRCDIR\f[R] enthält den Pfad zu dem Verzeichnis, aus dem \f[B]mkosi\f[R] heraus aufgerufen wurde, wobei alle konfigurierten Bauquellen oben auf eingehängt sind. \f[CR]$CHROOT_SRCDIR\f[R] enthält den Wert, den \f[CR]$SRCDIR\f[R] nach Aufruf von \f[B]mkosi\-chroot\f[R] haben wird.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$BUILDDIR\f[R] ist nur definiert, falls \f[CR]mkosi.builddir\f[R] existiert und auf das zu verwendende Bauverzeichnis zeigt. Dies ist für alle Bausysteme, die Bauen außerhalb des Bau\-Baums unterstützen, nützlich, um bereits gebaute Artefakte von einem vorherigen Durchlauf wiederzuverwenden. \f[CR]$CHROOT_BUILDDIR\f[R] enthält den Wert, den \f[CR]$BUILDDIR\f[R] nach Aufruf von \f[B]mkosi\-chroot\f[R] haben wird.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$DESTDIR\f[R] ist ein Verzeichnis, in das sämtliche installierte und durch ein Bauskript erstellte Software abgelegt werden kann. Diese Variable wird nur gesetzt, wenn ein Bauskript ausgeführt wird. \f[CR]$CHROOT_DESTDIR\f[R] enthält den Wert, den \f[CR]$DESTDIR\f[R] nach Aufruf von \f[B]mkosi\-chroot\f[R] haben wird.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$OUTPUTDIR\f[R] zeigt auf das Vorbereitungsverzeichnis, das zum Speichern der während des Baus erstellten Bauartefakte verwandt wird. \f[CR]$CHROOT_OUTPUTDIR\f[R] enthält den Wert, den \f[CR]$OUTPUTDIR\f[R] nach Aufruf von \f[B]mkosi\-chroot\f[R] haben wird.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$PACKAGEDIR\f[R] zeigt auf das Verzeichnis, das das lokale Paketdepot enthält. Bauskripte können weitere Pakete zum lokalen Depot hinzufügen, indem sie Pakete nach \f[CR]$PACKAGEDIR\f[R] schreiben.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$ARTIFACTDIR\f[R] zeigt auf das Verzeichnis, das zur Weitergabe von Bauartefakten verwandt wird, die während des Baus erstellt wurden und die für die Verwendung durch Mkosi bereitgestellt werden. Dies ist ähnlich zu \f[CR]PACKAGEDIR\f[R], ist aber für Artefakte gedacht, die keine vom Paketverwalter verstandenen Pakete sein können, z.B. Initrds, die durch andere Initrd\-Generatoren neben Mkosi erstellt wurden. Bauskripte können weitere Artekfakte zu dem Verzeichnis hinzufügen, indem sie sie in \f[CR]$ARTIFACTDIR\f[R] ablegen. Dateien in diesem Verzeichnis sind für den aktuellen Bau verfügbar und werden nicht wie die Inhalte von \f[CR]$OUTPUTDIR\f[R] herauskopiert.\fR .RS 2 .PP \f[B]mkosi\f[R] wird auch bestimmte Unterverzeichnisse eines Artefaktverzeichnisses verwenden, um ihre Inhalte automatisch in bestimmten Schritten zu verwenden. Derzeit werden die folgenden zwei Unterverzeichnisse in dem Artefaktverzeichnis durch Mkosi verwandt:\fR .IP \f[R]\[bu]\fR 2 \f[CR]io.mkosi.microcode\f[R]: Alle Dateien in diesem Verzeichnis werden als Microcode\-Dateien verwandt, d.h. sie werden an die Initrds in lexikographischer Reihenfolge angehängt.\fR .IP \f[R]\[bu]\fR 2 \f[CR]io.mkosi.initrd\f[R]: Alle Dateien in diesem Verzeichnis werden als Initrds verwandt und in lexikographischer Reihenfolge aneinandergehängt.\fR .PP Es wird empfohlen, dass Benutzer von \f[CR]$ARTIFACTDIR\f[R] Dinge für ihre eigene Verwendung in ähnlichen Verzeichnissen mit eigenem Namensraum ablegen, z.B.\ \f[CR]lokal.mein.Namensraum\f[R].\fR .RE .IP \f[R]\[bu]\fR 2 \f[CR]$BUILDROOT\f[R] ist das Wurzelverzeichnis des gebauten Abbilds, optional mit der Bauüberlagerung oben auf eingehängt, abhängig vom Skript, das ausgeführt wird.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$WITH_DOCS\f[R] ist entweder \f[CR]0\f[R] oder \f[CR]1\f[R], abhängig davon, ob der Bau eines Abbildes mit oder ohne Dokumentation angefordert wurde (\f[CR]WithDocs=yes\f[R]). Ein Bauskript sollte die Installation sämtlicher Paketdokumentationen nach \f[CR]$DESTDIR\f[R] unterdrücken, falls \f[CR]$WITH_DOCS\f[R] auf \f[CR]0\f[R] gesetzt ist.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$WITH_TESTS\f[R] ist entweder \f[CR]0\f[R] oder \f[CR]1\f[R], abhängig davon, ob ein Bau mit oder ohne laufende Test\-Suite angefordert wurde (\f[CR]WithTests=no\f[R]). Ein Bauskript sollte die Ausführung jeder Einheiten\- oder Integrationstests unterlassen, falls \f[CR]$WITH_TESTS\f[R] auf \f[CR]0\f[R] gesetzt ist.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$WITH_NETWORK\f[R] ist entweder \f[CR]0\f[R] oder \f[CR]1\f[R], abhängig davon, ob ein Bau mit oder ohne Netzwerkanbindung ausgeführt wird (\f[CR]WithNetwork=no\f[R]). Ein Bauskript sollte sämtliche Netzwerkkommunikation unterlassen, falls \f[CR]$WITH_NETWORK\f[R] auf \f[CR]0\f[R] gesetzt ist.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$SOURCE_DATE_EPOCH\f[R] wird definiert falls erbeten (\f[CR]SourceDateEpoch=TIMESTAMP\f[R], \f[CR]Environment=SOURCE_DATE_EPOCH=TIMESTAMP\f[R] oder die Umgebungsvariable auf dem Wirtsystem \f[CR]$SOURCE_DATE_EPOCH\f[R]). Dies ist nützlich, um Bauten wiederholbar zu machen. Siehe .UR https://reproducible\-builds.org/specs/source\-date\-epoch/ SOURCE_DATE_EPOCH .UE \ zu weiteren Informationen.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$MKOSI_UID\f[R] bzw. \f[CR]$MKOSI_GID\f[R] sind die UID bzw. GID des Benutzers, der \f[B]mkosi\f[R] aufrief.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$MKOSI_CONFIG\f[R] ist eine Datei, die eine JSON\-Zusammenfassung der Einstellungen des aktuellen Abbildes enthält. Diese Datei kann innerhalb von Skripten ausgewertet werden, um Zugriff auf alle Einstellungen des aktuellen Abbildes zu erhalten.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$IMAGE_ID\f[R] enthält den Kennzeichner aus der Einstellung \f[CR]ImageId=\f[R] oder \f[CR]\-\-image\-id=\f[R].\fR .IP \f[R]\[bu]\fR 2 \f[CR]$IMAGE_VERSION\f[R] enthält die Version aus der Einstellung \f[CR]ImageVersion=\f[R] oder \f[CR]\-\-image\-version=\f[R].\fR .IP \f[R]\[bu]\fR 2 \f[B]$MKOSI_DEBUG\f[R] ist entweder \f[B]0\f[R] oder \f[B]1\f[R], abhängig davon, ob Fehlersuchausgabe aktiviert ist.\fR .PP In dieser Tabelle können Sie ersehen, welches Skript welche Umgebungsvariable erhält: .PP .TS tab(@); lw(17.4n) cw(7.8n) cw(4.8n) cw(6.6n) cw(5.4n) cw(7.2n) cw(7.2n) cw(8.4n) cw(5.4n). T{ Variable T}@T{ \f[CR]configure\fR T}@T{ \f[CR]sync\fR T}@T{ \f[CR]prepare\fR T}@T{ \f[CR]build\fR T}@T{ \f[CR]postinst\fR T}@T{ \f[CR]finalize\fR T}@T{ \f[CR]postoutput\fR T}@T{ \f[B]clean\fR T} \f[R]_\fR T{ \f[CR]ARCHITECTURE\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]ARTIFACTDIR\fR T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ T} T{ \f[CR]BUILDDIR\fR T}@T{ T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ T} T{ \f[CR]BUILDROOT\fR T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ T} T{ \f[CR]CACHED\fR T}@T{ T}@T{ \f[R]✓\fR T}@T{ T}@T{ T}@T{ T}@T{ T}@T{ T}@T{ T} T{ \f[CR]CHROOT_BUILDDIR\fR T}@T{ T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ T}@T{ T}@T{ T}@T{ T} T{ \f[CR]CHROOT_DESTDIR\fR T}@T{ T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ T}@T{ T}@T{ T}@T{ T} T{ \f[CR]CHROOT_OUTPUTDIR\fR T}@T{ T}@T{ T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ T} T{ \f[CR]CHROOT_SCRIPT\fR T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ T} T{ \f[CR]CHROOT_SRCDIR\fR T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ T} T{ \f[I]MKOSI_DEBUG\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]DESTDIR\fR T}@T{ T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ T}@T{ T}@T{ T}@T{ T} T{ \f[CR]DISTRIBUTION\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]DISTRIBUTION_ARCHITECTURE\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[I]EFI_ARCHITECTURE\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]IMAGE_ID\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]IMAGE_VERSION\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]MKOSI_CONFIG\fR T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]MKOSI_GID\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]MKOSI_UID\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]OUTPUTDIR\fR T}@T{ T}@T{ T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]PACKAGEDIR\fR T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ T} T{ \f[CR]PROFILES\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ \f[R]✓\fR T} T{ \f[CR]QEMU_ARCHITECTURE\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ T}@T{ T}@T{ T}@T{ T}@T{ T}@T{ T} T{ \f[CR]RELEASE\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]SOURCE_DATE_EPOCH\fR T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ \f[R]✓\fR T} T{ \f[CR]SRCDIR\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]WITH_DOCS\fR T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ T}@T{ T}@T{ T} T{ \f[CR]WITH_NETWORK\fR T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ T} T{ \f[CR]WITH_TESTS\fR T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ T}@T{ T}@T{ T} .TE .PP Zusätzlich werden bei der Skript\-Ausführung einige Skripte über den \f[CR]$PATH\f[R] verfügbar gemacht, um häufige Anwendungsfälle zu vereinfachen.\fR .IP \f[R]\[bu]\fR 2 \f[B]mkosi\-chroot\f[R]: Dieses Skript wird ein \f[B]chroot\f[R](8) in das Abbild durchführen und den angegebenen Befehl ausführen. Zusätzlich zum \f[B]chroot\f[R](8) in das Abbild wird es auch verschiedene Dateien und Verzeichnisse in das Abbild einhängen (\f[CR]$SRCDIR\f[R], \f[CR]$DESTDIR\f[R], \f[CR]$BUILDDIR\f[R], \f[CR]$OUTPUTDIR\f[R], \f[CR]$CHROOT_SCRIPT\f[R]) und die entsprechenden Umgebungsvariablen ändern, um auf die Orte innerhalb des Abbilds zu zeigen. Es wird auch APIVFS\-Dateisysteme einhängen (\f[CR]/proc\f[R], \f[CR]/dev\f[R], …), um sicherzustellen, dass in der Chroot ausgeführte Skripte und Werkzeuge korrekt funktionieren. Falls erbeten leitet es auch \f[CR]/etc/resolv.conf\f[R] vom Wirt in die Chroot weiter, so dass DNS\-Auflösung innerhalb der Chroot funktioniert. Nachdem sich der Befehl \f[B]mkosi\-chroot\f[R] beendet, werden verschiedene Einhängepunkte bereinigt.\fR .RS 2 .PP Verwenden Sie beispielsweise folgendes, um \f[B]ls\f[R](1) innerhalb des Abbilds aufzurufen:\fR .IP .EX mkosi\-chroot ls … .EE .PP Um das gesamte Skript innerhalb des Abbildes auszuführen, fügen Sie die Endung \f[CR].chroot\f[R] zu dem Namen hinzu (\f[CR]mkosi.build.chroot\f[R] anstatt \f[CR]mkosi.build\f[R], usw.).\fR .RE .IP \f[R]\[bu]\fR 2 Für alle unterstützten Paketverwalter (\f[B]dnf\f[R], \f[B]rpm\f[R](8), \f[B]apt\f[R](8), \f[B]dpkg\f[R](1), \f[B]pacman\f[R](8), \f[B]zypper\f[R](8)) werden Skripte mit dem gleichen Namen in \f[CR]$PATH\f[R] abgelegt, um sicherzustellen, dass diese Befehle auf dem Wurzelverzeichnis des Abbildes mit der vom Benutzer bereitgestellten Konfiguration anstelle auf dem Wirtsystem agieren. Dies bedeutet, dass Sie aus einem Skript z.B. \f[CR]dnf install vim\f[R] durchführen können, um Vim in das Abbild zu installieren.\fR .RS 2 .PP Zusätzlich werden \f[CR]mkosi\-install\f[R], \f[CR]mkosi\-reinstall\f[R], \f[CR]mkosi\-upgrade\f[R] und \f[CR]mkosi\-remove\f[R] die entsprechende Aktion des Paketverwalters, der zum Baus des Abbilds verwandt wird, aufrufen.\fR .RE .IP \f[R]\[bu]\fR 2 \f[B]git\f[R](1) wird automatisch mit \f[CR]safe.directory=*\f[R] aufgerufen, um Berechtigungsfehler bei der Ausführung als Benutzer root in einem Benutzernamensraum zu vermeiden.\fR .IP \f[R]\[bu]\fR 2 Beim Aufruf außerhalb des Abbildes werden \f[B]useradd\f[R](8) und \f[B]groupadd\f[R](8) automatisch mit \f[CR]\-\-root=$BUILDROOT\f[R] aufgerufen.\fR .PP Wenn Skripte ausgeführt werden, werden alle noch schreibbaren Verzeichnisse schreibgeschützt gemacht (\f[CR]/home\f[R], \f[CR]/var\f[R], \f[CR]/root\f[R], …) und nur die minimale Menge an Verzeichnissen, die schreibbar bleiben müssen, bleiben schreibbar. Dies dient dazu sicherzustellen, dass die Skripte nicht das Wirtsystem durcheinander bringen können, wenn \f[B]mkosi\f[R] als Root ausgeführt wird.\fR .PP Beachten Sie, dass alle Quellverzeichnisse bei der Ausführung der Skripte flüchtig werden, was bedeutet, das alle Änderungen an den Quellverzeichnissen während der Ausführung der Skripte verworfen werden, wenn die Skripte mit der Ausführung fertig sind. Verwenden Sie die Ausgabe\-, Bau\- oder Zwischenspeicherverzeichnisse, falls Sie Daten zwischen Bauten weiternutzen wollen. .SH DATEIEN Um den Bau von Abbildern für Entwicklungsversionen Ihrer Projekte zu erleichtern, kann \f[B]mkosi\f[R] Konfigurationsdaten aus dem lokalen Verzeichnis unter der Annahme, dass es im einen \f[I]Quell\f[R]\-Baum aufgerufen wurde, lesen. Insbesondere werden die folgenden Dateien verwandt, falls sie im lokalen Verzeichnis existieren:\fR .IP \f[R]\[bu]\fR 2 Das Verzeichnis \f[I]mkosi.skeleton/\f[R] oder das Archiv \f[I]mkosi.skeleton.tar\f[R] können zum Einfügen von Dateien in das Abbild verwandt werden. Die Dateien werden \f[I]vor\f[R] der Installation der Distributionspakete in das Abbild kopiert. Dies ermöglicht die frühe Bereitstellung von Dateien, beispielsweise zur Konfiguration des Paketverwalters oder um Systemd\-Voreinstellungen zu setzen.\fR .RS 2 .PP Bei der Verwendung des Verzeichnisses werden Dateieigentümerschaften nicht erhalten: alle kopierten Dateien werden root gehören. Um Eigentümerschaften beizubehalten, verwenden Sie ein Tar\-Archiv. .RE .IP \[bu] 2 Das Verzeichnis \f[I]mkosi.extra/\f[R] oder das Archiv \f[I]mkosi.extra.tar\f[R] können zum Einfügen zusätzlicher Dateien in das Abbild verwandt werden, ergänzend zu den Inhalten der Distributionen. Sie sind ähnlich zu \f[CR]mkosi.skeleton/\f[R] und \f[CR]mkosi.skeleton.tar\f[R], aber die Dateien werden in den Verzeichnisbaum des Abbildes kopiert, \f[I]nachdem\f[R] das Betriebssystem installiert wurde.\fR .RS 2 .PP Bei der Verwendung des Verzeichnisses werden Dateieigentümerschaften nicht erhalten: alle kopierten Dateien werden root gehören. Um Eigentümerschaften beizubehalten, verwenden Sie ein Tar\-Archiv. .RE .IP \[bu] 2 Das Verzeichnis \f[I]mkosi.sandbox/\f[R] oder das Archiv \f[I]mkosi.sandbox.tar\f[R] können zur Konfiguration des Paketverwalters verwandt werden, ohne dass diese Dateien in das Abbild eingefügt werden. Falls die Dateien in das Abbild eingefügt werden sollten, sollte stattdessen \f[CR]mkosi.skeleton/\f[R] und \f[CR]mkosi.skeleton.tar\f[R] verwandt werden.\fR .RS 2 .PP Bei der Verwendung des Verzeichnisses werden Dateieigentümerschaften nicht erhalten: alle kopierten Dateien werden root gehören. Um Eigentümerschaften beizubehalten, verwenden Sie ein Tar\-Archiv. .RE .IP \[bu] 2 Die Nspawn\-Einstellungsdatei \f[I]mkosi.nspawn\f[R] wird an den gleichen Ort wie die Ausgabeabbilddatei kopiert, falls sie existiert. Dies ist nützlich, da Nspawn nach Einstellungsdateien neben den von ihm gestarteten Abbildern nach zusätzlichen Container\-Laufzeiteinstellungen sucht.\fR .IP \f[R]\[bu]\fR 2 Das Verzeichnis \f[I]mkosi.cache/\f[R] wird automatisch als Paket\-Herunterlade\-Zwischenspeicher verwandt, falls es existiert, um wiederholte Läufe des Werkzeugs zu beschleunigen.\fR .IP \f[R]\[bu]\fR 2 Das Verzeichnis \f[I]mkosi.builddir/\f[R] wird automatisch als Bauverzeichnis außerhalb des Quellbaums verwandt, falls es existiert und falls die Baubefehle in den Skripten \f[CR]mkosi.build\f[R] dies unterstützen. Insbesondere wird dieses Verzeichnis in den Bau\-Container eingehängt und die Umgebungsvariable \f[CR]$BUILDDIR\f[R] darauf gesetzt, wenn die Bauskripte aufgerufen werden. Ein Bauskript kann dann dieses Verzeichnis als Bauverzeichnis verwenden, für \f[B]automake\f[R](1)\- oder \f[B]ninja\f[R](1)\-artige Bauten außerhalb des Quellbaums. Dies beschleunigt den Bau deutlich, insbesondere wenn \f[B]mkosi\f[R] im inkrementellen Modus (\f[CR]\-i\f[R]) verwandt wird; nicht nur das Abbild und die Bau\-Überlagerung, sondern auch der Baubaum wird zwischen nachfolgenden Aufrufen wiederverwandt. Beachten Sie, dass die Umgebungsvariable \f[CR]$BUILDDIR\f[R] nicht gesetzt wird, falls dieses Verzeichnis nicht existiert und es den Bauskripten überlassen bleibt zu entscheiden, ob im Quellbaum oder außerhalb des Quellbaums gebaut und welches Verzeichnis verwandt wird.\fR .IP \f[R]\[bu]\fR 2 Die Datei \f[I]mkosi.rootpw\f[R] kann zur Bereitstellung des Passworts für den Benutzer root des Abbildes verwandt werden. Falls dem Passwort \f[CR]hashed:\f[R] vorangestellt ist, wird es als bereits gehashtes 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).\fR .IP \f[R]\[bu]\fR 2 Die Datei \f[I]mkosi.passphrase\f[R] stellt die Passphrase bereit, die bei der Auswahl der LUKS\-Verschlüsselung verwandt werden soll. Sie sollte die Passphrase wortwörtlich enthalten und nicht auf einem Zeilenumbruch enden (d.h. im gleichen Format wie \f[B]cryptsetup\f[R](8) und \f[CR]/etc/crypttab\f[R] die Passphrasendatei erwarten). Die Datei muss den Zugriffsmodus 0600 oder geringer haben.\fR .IP \f[R]\[bu]\fR 2 Die Dateien \f[I]mkosi.crt\f[R] und \f[I]mkosi.key\f[R] enthalten ein X.509\-Zertifikat und den privaten PEM\-Schlüssel, die verwandt werden, wenn Signaturen benötigt werden (UEFI SecureBoot, Verity, …).\fR .IP \f[R]\[bu]\fR 2 Das Verzeichnis \f[I]mkosi.output/\f[R] wird zum Speichern aller Bauartefakte verwandt.\fR .IP \f[R]\[bu]\fR 2 Das Verzeichnis \f[I]mkosi.credentials/\f[R] wird als Quelle zusätzlicher Zugangsberechtigungen ähnlich zu der Option \f[CR]Credentials=\f[R] verwandt. Für jede Datei in dem Verzeichnis wird der Dateiname als Zugangsberechtigungsname verwandt und die Dateiinhalte werden der Zugangsberechtigungswert oder, falls die Datei ausführbar ist, wird \f[B]mkosi\f[R] die Datei ausführen und die Ausgabe auf der Standardausgabe wird als Zugangsberechtigungswert verwandt. Die Ausgabe auf der Standardfehlerausgabe wird ignoriert. Mit \f[CR]Credentials=\f[R] konfigurierte Zugangsberechtigungen haben Vorrang vor Dateien in \f[CR]mkosi.credentials\f[R].\fR .IP \f[R]\[bu]\fR 2 Das Verzeichnis \f[I]mkosi.repart/\f[R] wird als Quelle für \f[B]systemd\-repart\f[R](8)\-Partitionsdefinitionsdateien verwandt, die an \f[B]systemd\-repart\f[R](8) beim Bau eines Abbilds übergeben werden. Falls es nicht existiert und die Einstellung \f[CR]RepartDirectories=\f[R] nicht konfiguriert ist, wird \f[B]mkosi\f[R] folgende Partitionsdefinitionsdateien als Voreinstellung verwenden:\fR .RS 2 .PP \f[CR]00\-esp.conf\f[R] (falls ein startfähiges Abbild erstellt wird):\fR .IP .EX \f[B][Partition]\f[R] Type=esp Format=vfat CopyFiles=/boot:/ CopyFiles=/efi:/ SizeMinBytes=512M SizeMaxBytes=512M\fR .EE .PP \f[CR]05\-bios.conf\f[R] (falls ein BIOS\-startfähiges Abbild erstellt wird):\fR .IP .EX \f[B][Partition]\f[R] \f[I]# UUID der Grub\-BIOS\-Systemstartpartition, die Grub bei GPTs benötigt,\f[R] \f[I]# um sich selbst dort einzubetten.\f[R] Type=21686148\-6449\-6e6f\-744e\-656564454649 SizeMinBytes=1M SizeMaxBytes=1M\fR .EE .PP \f[CR]10\-root.conf\fR .IP .EX \f[B][Partition]\f[R] Type=root Format= CopyFiles=/ Minimize=guess\fR .EE .PP Beachten Sie, dass keine der Vorgabe\-Partitionsdefinitionen verwandt wird, falls entweder \f[CR]mkosi.repart/\f[R] gefunden oder \f[CR]RepartDirectories=\f[R] verwandt wird.\fR .RE .PP Alle diese Dateien sind optional. .PP Beachten Sie, dass der Ort aller dieser Dateien auch mittels Aufruf von Befehlszeilenschaltern und als Einstellungen in \f[CR]mkosi.conf\f[R] konfiguriert werden kann, falls für ein Projekt die Vorgabeeinstellungen nicht akzeptabel sind.\fR .SH ZWISCHENSPEICHERUNG \f[B]mkosi\f[R] unterstützt drei verschiedene Zwischenspeicher zur Beschleunigung von wiederholenden Neubauten von Abbildern. Konkret:\fR .IP \f[R]1.\fR 3 Der Paketzwischenspeicher des Paketverwalters der Distribution kann zwischen Bauten zwischengespeichert werden. Dies wird mit der Option \f[CR]\-\-cache\-directory=\f[R] oder dem Verzeichnis \f[CR]mkosi.cache/\f[R] konfiguriert. Diese Form des Zwischenspeicherns verlässt sich auf den Paketverwalter der Distribution und speichert Distributionspakete (RPM, DEB, …) nach ihrem Herunterladen, aber bevor sie entpackt werden, zwischen.\fR .IP \f[R]2.\fR 3 Falls mittels \f[B]\-\-incremental=\f[R] der inkrementelle Modus aktiviert ist, werden zwischengespeicherte Kopien des abschließenden Abbildes und Bauüberlagerungen erstellt, direkt vor dem Hereinkopieren der Bauquellen (für Bau\-Überlagerungen) oder vor dem Hereinkopieren von durch \f[B]mkosi.build\f[R] erstellten Artefakten (für das abschließende Abbild). Diese Art der Zwischenspeicherung erlaubt das Umgehen des zeitaufwändigen Schritts des Paket\-Entpackens der Distributions\-Paketverwalter, ist aber nur wirksam, falls die Liste der zu verwendenden Pakete stabil bleibt, sich die Bauquellen und deren Skripte aber regelmäßig ändern. Beachten Sie, dass dieser Zwischenspeicher manuell geleert werden muss: immer, wenn die Paketliste geändert wird, müssen die zwischengespeicherten Abbilder manuell vor dem nächsten Neubau mittels des Schalters \f[B]\-f\f[R] entfernt werden.\fR .IP \f[R]3.\fR 3 Schließlich können zwischen mehreren Bauten das Verzeichnis der Bauartefakte mittels des Verzeichnisses \f[CR]mkosi.builddir/\f[R] gemeinsam verwandt werden. Dieses Verzeichnis ermöglicht es Systemen wie Meson, bereits kompilierte Quellen aus einem vorherigen Bau zu verwenden und damit den Bauprozess eines Bauskriptes \f[CR]mkosi.build\f[R] zu beschleunigen.\fR .PP Der Paketzwischenspeicher und der inkrementelle Modus sind in jedem Fall nützlich. Der abschließende Zwischenspeicher ist nur anwendbar, wenn \f[B]mkosi\f[R] mit einem Quellbaum und Bauskript verwandt wird. Sind alle drei zusammen aktiviert, dann ist die Durchlaufzeit für Abbildbauten minimal, da nur die Quelldateien neu kompiliert werden müssen.\fR .SH WERKZEUGBÄUME Werkzeugbäume sind sekundäre Abbilder, die \f[B]mkosi\f[R] zum Bau der tatsächlichen Abbilder verwenden kann. Dies ist nützlich, damit Bauten von Abbildern reproduzierbarer werden, aber erlaubt auch den Einsatz neuerer Werkzeuge, die in der Distribution des Hauptsystems, auf dem \f[B]mkosi\f[R] läuft, noch nicht verfügbar sind. .PP Werkzeugbäume können mittels der Option \f[B]ToolsTree=\f[R] oder dem Verzeichnis \f[I]mkosi.tools\f[R] bereitgestellt oder automatisch durch \f[B]mkosi\f[R] gebaut werden, falls auf \f[B]ToolsTree=yes\f[R] gesetzt. In den meisten Anwendungsfällen reicht das Setzen hiervon aus, um die Vorgabewerkzeugbäume zu verwenden und der Einsatz eines Werkzeugbaums wird empfohlen.\fR .PP Vollständig angepasste Werkzeugbäume könne wie jedes andere \f[B]mkosi\f[R]\-Abbild gebaut werden, aber \f[B]mkosi\f[R] stellt ein eingebauten Einbindung bereit, die die Vorgabe\-Werkzeugbaumpakete bereitstellt: .IP .EX mkosi \-\-include=mkosi\-tools \-\-format=directory .EE .PP Werkzeugbäume, einschließlich von Vorgabewerkzeugbäumen, können mittels der verschiedenen Variablen \f[B]ToolsTree*=\f[R] sowie der Konfigurationsdatei oder dem Konfigurationsverzeichnis \f[I]mkosi.tools.conf\f[R] weiter angepasst werden. Das Ausgabeformat für Werkzeugbäume kann derzeit über die Konfigurationsdateien nicht geändert werden.\fR .PP Die nachfolgende Tabelle zeigt, für welche Distributionen Standard\-Werkzeugbaumpakete definiert sind und welche Pakete in diese Standardwerkzeugbäume aufgenommen werden:\fR .PP .TS tab(@); lw(18.8n) cw(6.0n) cw(6.0n) cw(6.0n) cw(4.5n) cw(6.0n) cw(4.5n) cw(7.5n) cw(10.5n). T{ T}@T{ Fedora T}@T{ CentOS T}@T{ Debian T}@T{ Kali T}@T{ Ubuntu T}@T{ Arch T}@T{ openSUSE T}@T{ postmarketOS T} _ T{ \f[CR]acl\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]apt\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ T} T{ \f[CR]archlinux\-keyring\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ T} T{ \f[CR]attr\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]bash\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]btrfs\-progs\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]ca\-certificates\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]coreutils\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]cpio\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]createrepo_c\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]curl\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]debian\-keyring\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ \f[R]✓\fR T} T{ \f[CR]diffutils\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]distribution\-gpg\-keys\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]dnf\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]dosfstools\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]e2fsprogs\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]edk2\-ovmf\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]erofs\-utils\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]findutils\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]git\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]grep\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]grub\-tools\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ T} T{ \f[CR]jq\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]kali\-archive\-keyring\fR T}@T{ T}@T{ T}@T{ T}@T{ \f[R]✓\fR T}@T{ T}@T{ T}@T{ T}@T{ T} T{ \f[CR]kmod\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]less\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]mtools\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]nano\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]opensc\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]openssh\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]openssl\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]pkcs11\-provider\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]perf\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]sed\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]pacman\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ \f[R]✓\fR T} T{ \f[B]p11\-kit\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]policycoreutils\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]qemu\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]sbsigntools\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]socat\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]squashfs\-tools\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]strace\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]swtpm\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]systemd\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]ukify\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]tar\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]ubuntu\-keyring\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ T} T{ \f[CR]util\-linux\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]virtiofsd\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]virt\-firmware\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]xfsprogs\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]xz\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]zstd\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T} T{ \f[CR]zypper\fR T}@T{ \f[R]✓\fR T}@T{ T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ \f[R]✓\fR T}@T{ T} .TE .SH "BAUEN MEHRERER ABBILDER" Falls das Verzeichnis \f[CR]mkosi.images/\f[R] existiert, wird \f[B]mkosi\f[R] einzelne Unterabbild\-Konfigurationen daraus laden und jede davon bauen. Abbildkonfigurationen können entweder Verzeichnisse sein, die \f[B]mkosi\f[R]\-Konfigurationsdateien enthalten, oder reguläre Dateien mit der Erweiterung \f[CR].conf\f[R].\fR .PP Wenn Abbildkonfigurationen in \f[CR]mkosi.images/\f[R] gefunden werden, wird \f[B]mkosi\f[R] die in den Einstellungen \f[CR]Dependencies=\f[R] des Hauptabbilds festgelegten Abbilder und alle ihre Abhängigkeiten (oder alle davon, falls keine Abbilder explizit mit \f[CR]Dependencies=\f[R] in der Hauptabbildkonfiguration konfiguriert wurden) bauen. Um Abhängigkeiten zwischen Unterabbildern hinzuzufügen, kann auch die Einstellung \f[CR]Dependencies=\f[R] verwandt werden. Unterabbilder werden immer vor dem Hauptabbild gebaut.\fR .PP Wenn Abbilder definiert sind, wird \f[B]mkosi\f[R] zuerst die Hauptabbildkonfiguration (Konfiguration außerhalb des Verzeichnisses \f[I]mkosi.images/\f[R]) einlesen, gefolgt von der Abbild\-spezifischen Konfiguration.\fR .PP Für den Standard\-Werkzeugbaum und das Hauptabbild gelten mehrere »multiverselle« Einstellungen, die nicht getrennt vom Hauptabbild konfiguriert werden können: .IP \[bu] 2 \f[B]RepositoryKeyCheck=\fR .IP \f[R]\[bu]\fR 2 \f[B]RepositoryKeyFetch=\fR .IP \f[R]\[bu]\fR 2 \f[B]SourceDateEpoch=\fR .IP \f[R]\[bu]\fR 2 \f[B]CacheOnly=\fR .IP \f[R]\[bu]\fR 2 \f[B]WorkspaceDirectory=\fR .IP \f[R]\[bu]\fR 2 \f[B]PackageCacheDirectory=\fR .IP \f[R]\[bu]\fR 2 \f[CR]BuildSources=\fR .IP \f[R]\[bu]\fR 2 \f[CR]BuildSourcesEphemeral=\fR .IP \f[R]\[bu]\fR 2 \f[CR]ProxyClientCertificate=\fR .IP \f[R]\[bu]\fR 2 \f[B]ProxyClientKey=\fR .IP \f[R]\[bu]\fR 2 \f[B]ProxyExclude=\fR .IP \f[R]\[bu]\fR 2 \f[B]ProxyPeerCertificate=\fR .IP \f[R]\[bu]\fR 2 \f[B]ProxyUrl=\fR .PP Mehrere »allgemeine« Einstellungen gelten für das Hauptabbild und seine Unterabbilder und können für Unterabbilder nicht separat konfiguriert werden. Die folgenden Einstellungen sind allgemein und können in Unterabbildern nicht konfiguriert werden: .IP \[bu] 2 \f[CR]Architecture=\fR .IP \f[R]\[bu]\fR 2 \f[B]BuildDirectory=\fR .IP \f[R]\[bu]\fR 2 \f[B]CacheDirectory=\fR .IP \f[R]\[bu]\fR 2 \f[B]Distribution=\fR .IP \f[R]\[bu]\fR 2 \f[B]ExtraSearchPaths=\fR .IP \f[R]\[bu]\fR 2 \f[B]Incremental=\fR .IP \f[R]\[bu]\fR 2 \f[B]LocalMirror=\fR .IP \f[R]\[bu]\fR 2 \f[B]Mirror=\fR .IP \f[R]\[bu]\fR 2 \f[CR]OutputDirectory=\fR .IP \f[R]\[bu]\fR 2 \f[B]OutputMode=\fR .IP \f[R]\[bu]\fR 2 \f[B]PackageDirectories=\fR .IP \f[R]\[bu]\fR 2 \f[B]Release=\fR .IP \f[R]\[bu]\fR 2 \f[CR]RepartOffline=\fR .IP \f[R]\[bu]\fR 2 \f[CR]Repositories=\fR .IP \f[R]\[bu]\fR 2 \f[CR]SandboxTrees=\fR .IP \f[R]\[bu]\fR 2 \f[CR]ToolsTree=\fR .IP \f[R]\[bu]\fR 2 \f[CR]ToolsTreeCertificates=\fR .IP \f[R]\[bu]\fR 2 \f[CR]UseSubvolumes=\fR .IP \f[R]\[bu]\fR 2 \f[CR]SecureBootCertificate=\fR .IP \f[R]\[bu]\fR 2 \f[CR]SecureBootCertificateSource=\fR .IP \f[R]\[bu]\fR 2 \f[CR]SecureBootKey=\fR .IP \f[R]\[bu]\fR 2 \f[CR]SecureBootKeySource=\fR .IP \f[R]\[bu]\fR 2 \f[CR]VerityCertificate=\fR .IP \f[R]\[bu]\fR 2 \f[CR]VerityCertificateSource=\fR .IP \f[R]\[bu]\fR 2 \f[CR]VerityKey=\fR .IP \f[R]\[bu]\fR 2 \f[CR]VerityKeySource=\fR .IP \f[R]\[bu]\fR 2 \f[CR]VolatilePackageDirectories=\fR .IP \f[R]\[bu]\fR 2 \f[CR]WithNetwork=\fR .IP \f[R]\[bu]\fR 2 \f[CR]WithTests\fR .PP Es gibt auch Einstellungen, die an Unterabbilder weitergegeben werden, aber außer Kraft gesetzt werden können. Für diese Einstellungen haben Werte, die explizit im Unterabbild konfiguriert werden Vorrang vor Werten, die auf der Befehlszeile oder in der Konfiguration des Hauptabbildes konfiguriert werden. Derzeit werden die folgenden Einstellungen an Unterabbilder weitergegeben, können dort aber außer Kraft gesetzt werden: .IP \[bu] 2 \f[CR]Profiles=\fR .IP \f[R]\[bu]\fR 2 \f[CR]ImageId=\fR .IP \f[R]\[bu]\fR 2 \f[CR]ImageVersion=\fR .IP \f[R]\[bu]\fR 2 \f[CR]SectorSize=\fR .IP \f[R]\[bu]\fR 2 \f[B]CacheKey=\fR .IP \f[R]\[bu]\fR 2 \f[B]BuildKey=\fR .IP \f[R]\[bu]\fR 2 \f[B]CompressLevel=\fR .IP \f[R]\[bu]\fR 2 \f[CR]SignExpectedPcrKey=\fR .IP \f[R]\[bu]\fR 2 \f[CR]SignExpectedPcrKeySource=\fR .IP \f[R]\[bu]\fR 2 \f[CR]SignExpectedPcrCertificate=\fR .IP \f[R]\[bu]\fR 2 \f[CR]SignExpectedPcrCertificateSource=\fR .PP Zusätzlich gibt es verschiedene Einstellungen, die nur in dem Hauptabbild konfiguriert werden können, aber nicht an Unterabbilder weitergegeben werden: .IP \[bu] 2 \f[B]MinimumVersion=\fR .IP \f[R]\[bu]\fR 2 \f[B]PassEnvironment=\fR .IP \f[R]\[bu]\fR 2 \f[CR]ToolsTreeDistribution=\fR .IP \f[R]\[bu]\fR 2 \f[CR]ToolsTreeRelease=\fR .IP \f[R]\[bu]\fR 2 \f[B]ToolsTreeProfiles=\fR .IP \f[R]\[bu]\fR 2 \f[B]ToolsTreeMirror=\fR .IP \f[R]\[bu]\fR 2 \f[B]ToolsTreeRepositories=\fR .IP \f[R]\[bu]\fR 2 \f[B]ToolsTreeSandboxTrees=\fR .IP \f[R]\[bu]\fR 2 \f[B]ToolsTreePackages=\fR .IP \f[R]\[bu]\fR 2 \f[B]ToolsTreePackageDirectories=\fR .IP \f[R]\[bu]\fR 2 \f[B]History=\fR .IP \f[R]\[bu]\fR 2 Jede Einstellung in dem Abschnitt \f[B][Runtime]\f[R]\fR .PP Abbilder können sich auf Ausgaben von Abbildern beziehen, von denen sie abhängen. Insbesondere wird \f[B]mkosi\f[R] für die folgenden Optionen nur prüfen, ob die Eingabe genau vor dem Bau des Abbildes existiert:\fR .IP \f[R]\[bu]\fR 2 \f[B]BaseTrees=\fR .IP \f[R]\[bu]\fR 2 \f[B]ExtraTrees=\fR .IP \f[R]\[bu]\fR 2 \f[B]Initrds=\fR .PP Um sich auf die Ausgaben von den Abhängigkeiten eines Abbildes zu beziehen, konfigurieren Sie einfach jede dieser Optionen mit einem relativen Pfad zu der zu verwendenden Ausgabe in dem Ausgabeverzeichnis der Abhängigkeit. Oder verwenden Sie den Kennzeichner \f[CR]%O\f[R], um sich auf das Ausgabeverzeichnis zu beziehen.\fR .PP Ein gutes Beispiel, wie mehrere Abbilder gebaut werden können, kann in dem Depot von .UR https://github.com/systemd/systemd/tree/main/mkosi/mkosi.images Systemd .UE gefunden werden. .SH UMGEBUNGSVARIABLEN .IP \[bu] 2 \f[CR]$MKOSI_LESS\f[R] setzt Optionen für \f[B]less\f[R](1) außer Kraft, wenn es durch \f[B]mkosi\f[R] zur seitenweisen Darstellung der Ausgabe verwandt wird.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$MKOSI_DNF\f[R] kann dazu verwandt werden, das als \f[B]dnf\f[R] verwandte Programm außer Kraft zu setzen. Diese ist besonders für die Auswahl zwischen \f[B]dnf\f[R] und \f[B]dnf5\f[R] nützlich.\fR .IP \f[R]\[bu]\fR 2 \f[CR]$EPEL_MIRROR\f[R] kann zum Außerkraftsetzen des Ortes des Standard\-Spiegels für das Epel\-Depot verwandt werden, wenn \f[CR]Mirror=\f[R] eingesetzt wird. Standardmäßig schaut \f[B]mkosi\f[R] nach dem Epel\-Depot im Unterverzeichnis \f[CR]fedora\f[R] des Elternverzeichnisses des in \f[CR]Mirror=\f[R] festgelegten Spiegels. Falls der Spiegel beispielsweise auf \f[CR]https://mirror.net/centos\-stream\f[R] gesetzt ist, wird \f[B]mkosi\f[R] nach dem Epel\-Depot in \f[CR]https://mirror.net/fedora/epel\f[R] suchen.\fR .IP \f[R]\[bu]\fR 2 \f[CR]SYSEXT_SCOPE\f[R] und \f[CR]CONFEXT_SCOPE\f[R] können zum Außerkraftsetzen des Vorgabewertes der entsprechenden Datei \f[CR]extension\-release\f[R] beim Bau einer Systemerweiterung oder Konfigurationserweiterung verwandt werden. Standardmäßig wird der Wert auf \f[CR]initrd system portable\f[R] gesetzt.\fR .SH BEISPIELE Ein rohes \f[I]GPT\f[R]\-Abbild mit \f[B]ext4\f[R](5) als \f[CR]image.raw\f[R] erstellen und ausführen:\fR .IP .EX # mkosi \-p systemd \-i boot .EE .PP Ein startfähiges \f[I]GPT\f[R]\-Abbild als \f[CR]foobar.raw\f[R] erstellen und ausführen:\fR .IP .EX $ mkosi \-d fedora \-p kernel\-core \-p systemd \-p systemd\-boot \-p udev \-o foobar.raw # mkosi \-\-output foobar.raw boot $ mkosi \-\-output foobar.raw vm .EE .PP Ein »\f[I]Fedora Linux\f[R]«\-Abbild in einem einfachen Verzeichnis erstellen und ausführen:\fR .IP .EX # mkosi \-\-distribution fedora \-\-format directory boot .EE .PP Ein komprimiertes Abbild \f[CR]image.raw.xz\f[R] mit installiertem SSH erstellen und eine Prüfsummendatei hinzufügen:\fR .IP .EX $ mkosi \-\-distribution fedora \-\-format disk \-\-checksum=yes \-\-compress\-output=yes \-\-package=openssh\-clients .EE .PP Innerhalb eines Quellverzeichnis eines \f[B]automake\f[R](1)\-basierenden Projekts \f[B]mkosi\f[R] so konfigurieren, dass der einfache Aufruf von \f[B]mkosi\f[R] ohne Parameter ein Betriebssystemabbild erstellt, das eine gebaute Version des Projekts in seinem aktuellen Zustand enthält:\fR .IP .EX $ cat >mkosi.conf <mkosi.build <, include /aufgelöster/pfad/zu/mkosi flags=(default_allow) { userns, } .EE .SH "HÄUFIG GESTELLTE FRAGEN (FAQ)" .IP \[bu] 2 Warum funktioniert auf Debian/Kali/Ubuntu KVM mit \f[CR]mkosi vm\f[R] nicht?\fR .RS 2 .PP Während es bei anderen Distributionen kein Problem gibt, auf \f[CR]/dev/kvm\f[R] zuzugreifen, ist es unter Debian/Kali/Ubuntu nur für Benutzer in der Gruppe \f[CR]kvm\f[R] erlaubt. Da \f[B]mkosi\f[R] einen Benutzernamensraum beim Betrieb ohne Privilegien abtrennt, verliert es den Zugriff auf die Gruppe \f[CR]kvm\f[R], selbst wenn der aufrufende Benutzer in der Gruppe kvm war, denn zum Zeitpunkt, zu dem \f[B]qemu\f[R] gestartet wird, gibt es auf \f[CR]/dev/kvm\f[R] keinen Zugriff mehr. Um das zu umgehen, können Sie die Berechtigungen auf den Geräteknoten auf \f[CR]0666\f[R] ändern, was ausreicht, damit KVM ohne Privilegien funktioniert. Damit diese Änderungen über Neustarts hinweg erhalten bleibt, kopieren Sie \f[CR]/usr/lib/tmpfiles.d/static\-nodes\-permissions.conf\f[R] nach \f[CR]/etc/tmpfiles.d/static\-nodes\-permissions.conf\f[R] und ändern Sie den Modus von \f[CR]/dev/kvm\f[R] von \f[CR]0660\f[R] auf \f[CR]0666\f[R].\fR .RE .IP \f[R]\[bu]\fR 2 Wie füge ich zu einem Abbild einen normalen Benutzer hinzu? .RS 2 .PP Sie können den nachfolgenden Schnipsel in ein post\-installation\-Skript hinzufügen: .IP .EX useradd \-\-create\-home \-\-user\-group $USER \-\-password \[dq]$(openssl passwd \-stdin \-6 <$USER_PASSWORD_FILE)\[dq] .EE .PP Beachten Sie, dass seit Systemd v256 \f[B]systemd\-homed\-firstboot.service\f[R](1) die Erstellung eines normalen Benutzers beim ersten Systemstart anfragt, falls es aktiviert ist und keine normalen Benutzer existieren.\fR .RE .IP \f[R]\[bu]\fR 2 Warum sehe ich beim Bau von Abbildern Fehler beim \f[B]chown\f[R](1) von Dateien? .RS 2 .PP Erfolgt die Ausführung nicht als Root, kann Ihr Benutzer keine Eigentümerschaft von Dateien für beliebige Eigentümer ändern. Verschiedene Distributionen liefern immer noch Dateien in ihren Paketen aus, die nicht dem Benutzer root gehören. Erfolgt die Ausführung nicht als Root, bildet \f[B]mkosi\f[R] den aktuellen Benutzer beim Aufruf des Paketverwalters auf root ab, was bedeutet, dass die Änderung der Eigentümerschaft auf root funktionieren wird, aber die Änderung der Eigentümerschaft auf jeden anderen Benutzer oder jede andere Gruppe fehlschlagen wird. .PP Beachten Sie, dass die Aufrufe von \f[B]chown\f[R](1) nur bei der Ausführung von Paketverwaltern unterdrückt werden, aber nicht bei der Ausführung von Skripten. Falls dies z.B.\ für ein Bauskript benötigt wird, können Sie die Variable \f[CR]MKOSI_CHROOT_SUPPRESS_CHOWN\f[R] auf den Wert true (\f[CR]1\f[R], \f[CR]yes\f[R], \f[CR]true\f[R]) setzen, um die Aufrufe von \f[B]chown\f[R](1) in den Skripten \f[B]mkosi\-chroot\f[R] und \&\f[CR].chroot\f[R] zu unterdrücken.\fR .PP Falls dieses Verhalten dazu führt, dass sich in Ihrem Abbild betriebene Anwendungen nicht korrekt verhalten, könnten Sie \f[B]mkosi\f[R] als Root ausführen, wodurch dieses Problem vermieden wird. Falls der Betrieb von \f[B]mkosi\f[R] als Root nicht gewünscht ist, können Sie alternativ \f[CR]unshare \-\-map\-auto \-\-map\-current\-user \-\-setuid 0 \-\-setgid 0\f[R] verwenden, um Root in einem Benutzernamensraum mit mehr als einem Benutzer zu werden, unter der Annahme, dass die UID/GID\-Abbildungen in \f[CR]/etc/subuid\f[R] und \f[CR]/etc/subgid\f[R] korrekt konfiguriert sind. Beachten Sie, dass der Betrieb von \f[B]mkosi\f[R] als Root oder mit \f[CR]unshare\f[R] bedeutet, dass alle von \f[B]mkosi\f[R] erzeugten Ausgabedateien nicht mehr ihrem aktuellen Benutzer gehören.\fR .PP Für \f[B]systemd\f[R](1)\-Dienste, die Verzeichnisse in \f[CR]/var\f[R] benötigen, die dem Benutzer und der Gruppe des Dienstes gehören können diese Verzeichnisse in Paketen ausgeliefert oder mittels \f[B]systemd\-tmpfiles\f[R](8) erstellt werden. Beachten Sie, das die Verwendung von \f[CR]StateDirectory=\f[R], \f[CR]CacheDirectory=\f[R] oder \f[CR]LogsDirectory=\f[R] in der Dienstedatei eine Alternative dazu darstellt. Dies weist \f[B]systemd\f[R](1) an, die Verzeichnisse zu erstellen, wenn es erstmalig den Dienst startet.\fR .PP Alternativ können die Direktiven \f[CR]z\f[R] oder \f[CR]Z\f[R] für \f[B]systemd\-tmpfiles\f[R](8) verwandt werden, um verschiedene Verzeichnisse und Dateien mittels \f[B]chown\fR(1) auf den Eigentümer umzuschreiben, wenn das System erstmalig startet.\fR .RE .IP \f[R]\[bu]\fR 2 Warum sagt \f[CR]portablectl inspect \f[R]/\f[CR]systemd\-dissect \f[R] das mein portierbarer Dienst gar keiner sei?\fR .RS 2 .PP \f[B]systemd\-dissect\f[R](1) und \f[CR]portablectl inspect\f[R] prüfen auf \f[CR]PORTABLE_PREFIXES=\f[R] in \f[B]os\-release\f[R](5) und erkennen den portierbaren Dienst nicht als solchen, wenn der Schlüssel fehlt. Es wird dann ein x unter \f[I]Use as\f[R] im Falle von \f[B]systemd\-dissect\f[R](1) oder \f[CR]n/a\f[R] unter \f[I]Portable Service\f[R] für \f[B]portablectl\f[R](1) angezeigt.\fR .PP Da es keine gute Voreinstellung für diesen Schlüssel gibt und das erstellte portierbare Diensteabbild sich weiterhin korrekt anhängt, selbst wenn der Schlüssel nicht gesetzt ist, wird \f[B]mkosi\f[R] keinen setzen.\fR .PP Sie können in der Datei \f[B]os\-release\f[R](5) selbst in einem Postinst\-Skript \f[CR]PORTABLE_PREFIXES=\f[R] setzen.\fR .RE .SH REFERENZEN .IP \[bu] 2 .UR https://github.com/systemd/mkosi/ Primäres Mkosi\-Git\-Depot auf GitHub .UE .IP \[bu] 2 .UR https://0pointer.net/blog/mkosi\-a\-tool\-for\-generating\-os\-images.html mkosi \[em] A Tool for Generating OS Images .UE \ Einleitende Blog\-Veröffentlichung von Lennart Poettering .IP \[bu] 2 .UR https://lwn.net/Articles/726655/ The mkosi OS generation tool .UE \ LWN\-Artikel .SH "SIEHE AUCH" \f[B]systemd\-nspawn\f[R](1), \f[B]systemd\-repart\f[R](8), \f[B]dnf\f[R](8)\fR .PP .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. .PP Diese Übersetzung ist Freie Dokumentation; lesen Sie die .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. .PP Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die .MT debian-l10n-german@lists.debian.org Mailingliste der Übersetzer .ME .