Unterbefehle¶

Die folgenden Unterbefehle werden erkannt:

init

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

summary

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

cat-config

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

build

Baut das Abbild basierend auf den auf der Befehlszeile und in den Konfigurationsdateien übergebenen Einstellungen. Dieser Befehl ist die Vorgabe, falls kein Unterbefehl explizit angegeben ist. 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 mkosi durch --.

shell

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

boot

Ähnlich wie shell, startet systemd(1) im Abbild mittels systemd-nspawn(1) anstatt eine Shell zu öffnen. Nach dem Unterbefehl boot 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 -- von den normalen Optionen ab.

vm

Ähnlich wie boot, verwendet aber den konfigurierten Monitor für virtuelle Maschinen (standardmäßig qemu), um das Abbild zu starten, d.h. anstelle einer Container-Virtualisierung wird eine Virtualisierung einer virtuellen Maschine verwandt. Wie zusätzliche Befehlszeilenargumente interpretiert werden hängt von dem konfigurierten Monitor für virtuelle Maschinen ab. Weitere Informationen finden Sie in VirtualMachineMonitor=. Um zusätzliche Optionen an den konfigurierten Monitor für virtuelle Maschinen zu übergeben, trennen Sie diese von den normalen Optionen mittels -- ab.

ssh

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

journalctl

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

coredumpctl

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

sysupdate

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

sandbox

Ruft beliebige Befehle innerhalb der gleichen Umgebung auf, die zur Ausführung anderer Unterbefehle wie boot, shell, vm und weiteren verwandt wird. Dies bedeutet, dass /usr durch /usr vom Werkzeugbaum ersetzt wird, falls einer verwandt wird, während ansonsten alles andere am Ort verbleibt. Falls kein Befehl bereitgestellt wird, wird $SHELL oder bash(1), falls $SHELL nicht gesetzt ist, ausgeführt. Um zusätzliche Optionen an den angegebenen Befehl zu übergeben, trennen Sie diese durch -- von den regulären Optionen.

clean

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

serve

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

burn <Gerät>

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

bump

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

genkey

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

documentation

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

completion

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

dependencies

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

latest-snapshot

Gibt den neuesten verfügbaren Schnappschuss in dem konfigurierten Spiegel aus.

help

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

Reine Befehlszeilenoptionen¶

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

--force, -f

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

--directory=, -C

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

--debug

Aktiviert zusätzliche Fehlersuchausgaben.

--debug-shell

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

--debug-workspace

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

--debug-sandbox

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

--version

Zeigt die Paketversion.

--help, -h

Zeigt einen kurzen Hinweis zum Aufruf.

--genkey-common-name=

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

--genkey-valid-days=

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

--auto-bump=, -B

Falls angegeben wird die Version erhöht und falls der Bau erfolgreich ist, wird die Version nach mkosi.version auf eine Art ähnlich zum Unterbefehl bump 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.

--doc-format

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

--json

Zeigt die zusammenfassende Ausgabe als JSON-SEQ.

--wipe-build-dir, -w

Vernichtet vor dem Bau des Abbildes das Bauverzeichnis, falls eines konfiguriert ist.

--rerun-build-scripts, -R

Führt die Bauskripte erneut aus. Benötigt die aktivierte Option Incremental= und das Abbild muss bereits einmal gebaut worden sein. Falls History= aktiviert ist, wird der Verlauf von dem vorherigen Bau erneut verwandt und kein neuer Verlauf geschrieben.

Unterstützte Ausgabeformate¶

Die folgenden Ausgabeformate werden unterstützt:

•

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

•

Einfaches Verzeichnis, enthält den Betriebssystembaum (Verzeichnis)

•

TAR-Archiv (tar)

•

CPIO-Archiv (cpio)

•

Vereinigtes Kernelabbild (UKI)

•

… und viele weitere. Informationen hierzu in der nachfolgenden Beschreibung für Format=.

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

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

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

Konfigurationseinstellungen¶

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

Die Konfiguration wird in der folgenden Reihenfolge ausgewertet:

•

Die Befehlszeilenargumente werden ausgewertet.

•

mkosi.local.conf und mkosi.local werden ausgewertet, falls sie existieren. Diese Datei und das Verzeichnis sollte in .gitignore (oder äquivalent) sein und sind für lokale Konfiguration gedacht.

•

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

•

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

•

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

•

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

•

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

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

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

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

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

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

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

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

[Match]
Format=|disk
Format=|directory
[Match]
Architecture=|x86-64
Architecture=|arm64
    

Der Abschnitt [TriggerMatch] kann zur Anzeige von auslösenden Ü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 debian und die Veröffentlichung bookworm ist oder falls die Distribution ubuntu und die Veröffentlichung noble ist.

[TriggerMatch]
Distribution=debian
Release=bookworm
[TriggerMatch]
Distribution=ubuntu
Release=noble
    

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

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

Es gibt auch Unterstützung für die Abschnitte [Assert] und [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 [Assert] in einer Datei sowie mindestens ein Abschnitt [TriggertAssert] müssen erfüllt sein oder das Auswerten der Konfiguration wird fehlschlagen.

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

Abschnitt [Distribution]¶

Distribution=, --distribution=, -d

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

Release=, --release=, -r

Die Veröffentlichung der im Abbild zu installierenden Distribution. Die genaue Syntax des akzeptierten Arguments hängt von der verwandten Distribution ab und ist entweder eine numerische Zeichenkette (im Falle von Fedora Linux, CentOS, …, z.B. 29) oder ein Versionsname der Distribution (im Falle von Debian, Kali, Ubuntu, …, z.B. artful). Standardmäßig die neuste Version der ausgewählten Distribution oder die Version, die auf der Wirtmaschine läuft, falls sie mit einer konfigurierten Distribution übereinstimmt.

Architecture=, --architecture=

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

Mirror=, --mirror=, -m

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

Snapshot=

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 latest-snapshot, um den neusten verfügbaren Schnappschuss zu ermitteln.

LocalMirror=, --local-mirror=

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

RepositoryKeyCheck=, --repository-key-check=

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

RepositoryKeyFetch=, --repository-key-fetch=

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

Repositories=, --repositories=

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

Abschnitt [Output]¶

Format=, --format=, -t

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

ManifestFormat=, --manifest-format=

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

Output=, --output=, -o

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

OutputExtension=, --output-extension=

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.

CompressOutput=, --compress-output=

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

CompressLevel=, --compress-level=

Konfiguriert die zu verwendende Komprimierungsstufe. Akzeptiert eine Ganzzahl. Die möglichen Werte hängen von der verwandten Komprimierung ab.

OutputDirectory=, --output-directory=, -O

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

OutputMode=, --output-mode=

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

ImageVersion=, --image-version=

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

ImageId=, --image-id=

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

SplitArtifacts=, --split-artifacts

Die Artekfaktypen, die aus dem endgültigen Abbild herausgenommen werden sollen. Eine Kommata-getrennte Liste, die aus uki, kernel, initrd, os-release, prcs, partitions, roothash, kernel-modules-initrd, repart-definitions und tar besteht. Beim Bauen eines selbststartenden Abbildes entsprechen kernel und initrd ihren im Abbild (oder dem UKI) gefundenen Artefakten, während uki das gesamte UKI herauskopiert. Falls pcrs angegeben ist, wird eine JSON-Datei, die den vorberechneten TPM2-Hash enthält, entsprechend der https://uapi-group.org/specifications/specs/unified_kernel_image/#json-format-for-pcrsig UKI-Spezifikation rausgeschrieben. Dies wird zur Offline-Signatur verwandt.

RepartDirectories=, --repart-directory=

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

SectorSize=, --sector-size=

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

Overlay=, --overlay

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

Seed=, --seed=

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

CleanScripts=, --clean-script=

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

Abschnitt [Content]¶

Packages=, --package=, -p

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

BuildPackages=, --build-package=

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

VolatilePackages=, --volatile-package=

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

PackageDirectories=, --package-directory=

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

VolatilePackageDirectories=, --volatile-package-directory=

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

WithRecommends=, --with-recommends=

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

WithDocs=, --with-docs

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

BaseTrees=, --base-tree=

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

SkeletonTrees=, --skeleton-tree=

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

ExtraTrees=, --extra-tree=

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

RemovePackages=, --remove-package=

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

RemoveFiles=, --remove-files=

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

CleanPackageMetadata=, --clean-package-metadata=

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

SourceDateEpoch=, --source-date-epoch=

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

SyncScripts=, --sync-script=

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

PrepareScripts=, --prepare-script=

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

BuildScripts=, --build-script=

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

PostInstallationScripts=, --postinst-script=

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

FinalizeScripts=, --finalize-script=

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

PostOutputScripts=, --postoutput-script

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

Bootable=, --bootable=

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

Bootloader=, --bootloader=

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

BiosBootloader=, --bios-bootloader=

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

ShimBootloader=, --shim-bootloader=

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

UnifiedKernelImages=, --unified-kernel-images=

Gibt an, ob vereinigte Kernelabbilder verwandt werden sollen, wenn Bootloader= auf systemd-boot oder grub gesetzt ist. Akzeptiert none, unsigned, signed oder auto. Standardmäßig auto. Falls unsigned oder signed, werden vereinigte Kernelabbilder immer verwandt und der Bau wird fehlschlagen, falls eine der für den Bau von vereinigten Kernelabbildern benötigten Komponenten fehlt. Falls auf auto gesetzt, werden vereinigte Kernelabbilder verwandt, falls alle benötigten Komponenten verfügbar sind. Andernfalls werden stattdessen Typ-1-Einträge, wie in der Systemstartladerspezifikation definiert, verwandt. Falls deaktiviert, werden Typ-1-Einträge immer verwandt. Bootloader= wird auf eine der signierten Varianten gesetzt, ein vorab gebautes UKI wird durchsucht und der Bau wird fehlschlagen, falls es nicht gefunden werden kann, außer wenn UnifiedKernelImages= auf unsigned gesetzt ist. In diesem Fall wird das UKI lokal gebaut. Dies ist nützlich, wenn dies mit der auf custom gesetzten Laufzeitoption Firmware= kombiniert wird, so dass der lokal signierte Schlüssel in der UEFI-Datenbank registriert wird.

UnifiedKernelImageFormat=, --unified-kernel-image-format=

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

UnifiedKernelImageProfiles=, --uki-profile=

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

Initrds=, --initrd

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

InitrdProfiles=, --initrd-profile=

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.

InitrdPackages=, --initrd-package=

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

InitrdVolatilePackages=, --initrd-volatile-package=

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

Devicetrees=, --devicetrees=

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

Splash=, --splash=

Wenn gesetzt, wird der Systemstart-Startbildschirm für alle durch mkosi gebauten vereinigten Kernelabbilder aus dem angegebenen Pfad innerhalb des Abbilds aufgenommen.

MicrocodeHost=, --microcode-host=

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

KernelCommandLine=, --kernel-command-line=

Verwendet beim Bau von Abbildern die angegebene Kernelbefehlszeile.

KernelModules=, --kernel-modules=

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

KernelModulesInitrd=, --kernel-modules-initrd=

Logischer Wert, standardmäßig aktiviert (true). Falls beim Bau eines Abbildes aktiviert, wird mkosi eine zusätzliche Initrd für jedes von ihm zusammengebaute vereinigte Kernelabbild erstellen. Diese Initrd enthält nur Module 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.

KernelInitrdModules=, --kernel-modules-initrd-include=

Wie KernelModules=, legt aber die in der Initrd einzubindenden Kernelmodule fest.

FirmwareFiles=, --firmware-files=

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

Locale=, --locale=, LocaleMessages=, --locale-messages=, Keymap=, --keymap=, Timezone=, --timezone=, Hostname=, --hostname=, RootShell=, --root-shell=

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

RootPassword=, --root-password=

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

Autologin=, --autologin=, -a

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

MakeInitrd=, --make-initrd=

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

Ssh=, --ssh=

Gibt an, ob eine Socket-Unit für sshd(8) und passende Dienste in dem endgültigen Abbild installiert werden sollen. Akzeptiert entweder always, never, auto oder runtime. Standardmäßig auto.

SELinuxRelabel=, --selinux-relabel=

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

MachineId=, --machine-id=

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

Abschnitt [Validation]¶

SecureBoot=, --secure-boot

Signiert systemd-boot(7) (falls es noch nicht signiert ist) und sämtliche vereinigten Kernelabbilder für UEFI SecureBoot.

SecureBootAutoEnroll=, --secure-boot-auto-enroll=

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

SecureBootKey=, --secure-boot-key=

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

SecureBootCertificate=, --secure-boot-certificate=

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

SecureBootSignTool=, --secure-boot-sign-tool

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

Verity=, --verity=

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

VerityKey=, --verity-key=

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

VerityCertificate=, --verity-certificate=

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

SignExpectedPcr=, --sign-expected-pcr

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

SignExpectedPcrKey=, --sign-expected-pcr-key=

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

SignExpectedPcrCertificate=, --sign-expected-pcr-certificate=

Pfad zu einer X.509-Datei, die das Zertifikat zum Signieren der erwarteten PCR-Signatur enthält.

SecureBootKeySource=, --secure-boot-key-source=, VerityKeySource=, --verity-key-source=, SignExpectedPcrKeySource=, --sign-expected-key-source=

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

SecureBootCertificateSource=, --secure-boot-certificate-source=, VerityCertificateSource=, --verity-certificate-source=, SignExpectedPcrCertificateSource=, --sign-expected-certificate-source=

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

Passphrase=, --passphrase

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

Checksum=, --checksum

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

Sign=, --sign

Signiert nach Fertigstellung die erstellte SHA256SUMS mittels gpg(1).

OpenPGPTool=, --openpgp-tool

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

Key=, --key=

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

Abschnitt [Build]¶

ToolsTree=, --tools-tree=

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

ToolsTreeDistribution=, --tools-tree-distribution=

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

ToolsTreeRelease=, --tools-tree-release=

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

ToolsTreeProfiles=, --tools-tree-profile=

Setzt die für den Standard-Werkzeugbaum zu aktivierende Profile. Akzeptiert eine Kommate-getrennte Liste, die aus devel, misc, package-manager und runtime besteht. Standardmäßig sind alle Profile außer devel aktiviert.

ToolsTreeMirror=, --tools-tree-mirror=

Setzt den für den Standardwerkzeugbaum zu verwendenden Spiegel. Standardmäßig wird der Standardspiegel für die Werkzeugbaumdistribution verwandt.

ToolsTreeRepositories=, --tools-tree-repository

Identisch zu Repositories=, aber für den Standardwerkzeugbaum.

ToolsTreeSandboxTrees=, --tools-tree-sandbox-tree

Identisch zu SandboxTrees=, aber für den Standardwerkzeugbaum.

ToolsTreePackages=, --tools-tree-package=

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

ToolsTreePackageDirectories=, --tools-tree-package-directory=

Identisch zu PackageDirectories=, aber für den Standardwerkzeugbaum.

ToolsTreeCertificates=, --tools-tree-certificates=

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

ExtraSearchPaths=, --extra-search-path=

Liste von durch Doppelpunkt getrennten Pfaden, in denen vor dem regulären Suchpfad $PATH nach Werkzeugen gesucht wird.

Incremental=, --incremental=, -i

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

CacheOnly=, --cache-only=

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

SandboxTrees=, --sandbox-tree=

Akzeptiert eine Kommata-getrennte Liste von Doppelpunkt-getrennten Pfadpaaren. Der erste Pfad jedes Paares bezieht sich auf ein Verzeichnis, das in die Sandbox von mkosi 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 mkosi.sandbox/ in dem lokalen Verzeichnis gefunden wird, wird es für diesen Zweck mit dem Wurzelverzeichnis als Ziel verwandt (siehe auch den nachfolgenden Abschnitt DATEIEN).

WorkspaceDirectory=, --workspace-directory=

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

CacheDirectory=, --cache-directory=

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

CacheKey=, --cache-key=

Legt das Unterverzeichnis innerhalb des Zwischenspeicherverzeichnisses fest, in dem das zwischengespeicherte Abbild gespeichert werden soll. Dies kann sowohl die normalen Kennzeichner (siehe Kennzeichner) als auch besondere 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 &d~&r~&a~&I.

PackageCacheDirectory=, --package-cache-dir

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

BuildDirectory=, --build-directory=

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

BuildKey=, --build-key=

Legt das Unterverzeichnis innerhalb des Bauverzeichnisses fest, in dem die inkrementellen Bauten gespeichert werden sollen. Dies kann sowohl die normalen Kennzeichner (siehe Kennzeichner) als auch besondere 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 CacheKey= unterstützt werden. Das Standardformat für diesen Parameter lautet &d~&r~&a.

UseSubvolumes=, --use-subvolumes=

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

RepartOffline=, --repart-offline=

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

History=, --history=

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

BuildSources=, --build-sources=

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

BuildSourcesEphemeral=, --build-sources-ephemeral=

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

Environment=, --environment=

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

EnvironmentFiles=, --env-file=

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

WithTests=, --without-tests, -T

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

WithNetwork=, --with-network=

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

ProxyUrl=, --proxy-url=

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

ProxyExclude=, --proxy-exclude=

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

ProxyPeerCertificate=, --proxy-peer-certificate=

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

ProxyClientCertificate=, --proxy-client-certificate=

Konfiguriert eine Datei, die das zur Authentifizierung des Clients mit dem Proxy verwandte Zertifikat enthält.

ProxyClientKey=, --proxy-client-key=

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

Abschnitt [Runtime] (früher als Abschnitt [Host] bekannt)¶

NSpawnSettings=, --settings=

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

VirtualMachineMonitor=, --vmm=

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

Console=, --console=

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

CPUs=, --cpus=

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

RAM=, --ram=

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

MaxMem=, --maxmem=

Konfiguriert die maximale Speichermenge, die der Gast insgesamt einsetzen darf (RAM + Hotplug-Speichergeräte). Standardmäßig die konfigurierte RAM-Größe.

KVM=, --kvm=

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

CXL=, --cxl=

Konfiguriert, ob CXL-Geräte für eine angegebene Maschine aktiviert werden. Nur gültig, falls die Architektur cxl unterstützt. Akzeptiert einen logischen Wert. Standardmäßig false.

VSock=, --vsock=

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

VSockCID=, --vsock-cid=

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

TPM=, --tpm=

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

Removable=, --removable=

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

Firmware=, --firmware=

Configures the virtual machine firmware to use. Takes one of uefi, uefi-secure-boot, bios, linux, linux-noinitrd or auto. Defaults to auto. When set to uefi, the OVMF firmware without secure boot support is used. When set to uefi-secure-boot, the OVMF firmware with secure boot support is used. When set to bios, the default SeaBIOS firmware is used. When set to linux, direct kernel boot is used. See the Linux= option for more details on which kernel image is used with direct kernel boot. linux-noinitrd is identical to linux except that no initrd is used. When set to auto, uefi-secure-boot is used if possible and linux otherwise.

FirmwareVariables=, --firmware-variables=

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

Linux=, --linux=

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

Drives=, --drive=

Add a drive. Takes a colon-delimited string of format <id>:<size>[:<directory>[:<options>[:<file-id>[:<flags>]]]]. id specifies the ID assigned to the drive. This can be used as the drive= property in various qemu devices. size specifies the size of the drive. This takes a size in bytes. Additionally, the suffixes K, M and G can be used to specify a size in kilobytes, megabytes and gigabytes respectively. directory optionally specifies the directory in which to create the file backing the drive. If unset, the file will be created under /var/tmp. options optionally specifies extra comma-delimited properties which are passed verbatim to qemu’s -blockdev option. file-id specifies the ID of the file backing the drive. If unset, this defaults to the drive ID. Drives with the same file ID will share the backing file. The directory and size of the file will be determined from the first drive with a given file ID. flags takes a comma-separated list of drive flags which currently only supports persist. persist determines whether the drive will be persisted across qemu invocations. The files backing the drives will be created with the schema /<directory>/mkosi-drive-<machine-or-image-name>-<file-id>. You can skip values by setting them to the empty string, specifying e.g. myfs:1G::::persist will create a persistent drive under /var/tmp/mkosi-drive-main-myfs.

QemuArgs=

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

Ephemeral=, --ephemeral

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

Credentials=, --credential=

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

KernelCommandLineExtra=, --kernel-command-line-extra=

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

RuntimeTrees=, --runtime-tree=

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

RuntimeSize=, --runtime-size=

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

RuntimeNetwork=, --runtime-network=

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

RuntimeBuildSources=, --runtime-build-sources=

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

BindUser=, --bind-user=

Bindet das Home-Verzeichnis des aktuellen Benutzers in den Container/die VM. Akzeptiert einen logischen Wert. Standardmäßig deaktiviert.

UnitProperties=, --unit-property=

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

SshKey=, --ssh-key=

Path to the X.509 private key in PEM format to use to connect to a virtual machine started with mkosi vm and built with the Ssh= option enabled (or with systemd-ssh-generator installed) via the mkosi ssh command. If not configured and mkosi.key exists in the working directory, it will automatically be used for this purpose. Run mkosi genkey to automatically generate a key in mkosi.key.

SshCertificate=, --ssh-certificate=

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

Machine=, --machine=

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

Register=, --register=

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

ForwardJournal=, --forward-journal=

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

StorageTargetMode=, --storage-target-mode=

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

SysupdateDirectory=, --sysupdate-directory=

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

Abschnitt [Match]¶

Profiles=

Übereinstimmung mit den konfigurierten Profilen.

Distribution=

Übereinstimmung mit der konfigurierten Distribution.

Release=

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

Architecture=

Matches against the configured architecture. If this condition is used and no architecture has been explicitly configured yet, the host architecture is used. Architecture=uefi can be used to match against any architecture that supports UEFI.

Repositories=

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

PathExists=

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

ImageId=

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

ImageVersion=

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

Bootable=

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

Format=

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

SystemdVersion=

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

BuildSources=

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

HostArchitecture=

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

ToolsTreeDistribution=

Übereinstimmung mit der konfigurierten Werkzeugbaum-Distribution.

ToolsTreeRelease=

Übereinstimmung mit der konfigurierten Werkzeugbaum-Veröffentlichung.

Environment=

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

Image=

Vergleicht mit dem aktuellen (Unter-)Abbild. Der Name des Unterabbilds ist sein Name in mkosi.images/ (ohne die Endung .conf). Der Name des Abbilds auf oberster Ebene lautet main. Der Haupteinsatzfall ist die 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 Image=main gesteuert werden.

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:

[Include]¶

Include=, --include=, -I

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

Abschnitt [Config]¶

Profiles=, --profile=

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

Dependencies=, --dependency=

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

MinimumVersion=, --minimum-version=

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

ConfigureScripts=, --configure-script=

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

PassEnvironment=, --pass-environment=

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

Abschnitt [UKIProfile]¶

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

Profile=

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

Cmdline=

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

SignExpectedPcr=

Signiert erwartete PCR-Messungen für dieses UKI-Profil. Akzeptiert einen logischen Wert. Standardmäßig aktiviert.

Kennzeichner¶

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

Es gibt auch von Einstellungen unabhängige Kennzeichner:

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

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

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

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

Unterstützte Distributionen¶

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

•

Fedora Linux

•

Debian

•

Kali Linux

•

Ubuntu

•

Arch Linux

•

openSUSE

•

Mageia

•

CentOS

•

RHEL

•

RHEL UBI

•

OpenMandriva

•

Rocky Linux

•

Alma Linux

•

Azure Linux

•

postmarketOS

•

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

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

Derzeit paketiert Fedora Linux alle relevanten Werkzeuge seit Fedora 28.

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

Verschiedene Arten, mit vm zu starten¶

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

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

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

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

$ mkosi -d fedora --console=gui qemu
    

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

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

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

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

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

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

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