1. Manuals
  2. Tumbleweed
  3. man-pages-de
  4. mkosi(1)

Scroll to navigation

mkosi(1) mkosi(1)

BEZEICHNUNG

mkosi – Maßgeschneiderte Betriebssystemabbilder bauen

ÜBERSICHT

mkosi [Optionen…] summary

mkosi [Optionen…] build [Befehlszeile…]

mkosi [Optionen…] shell [Befehlszeile…]

mkosi [Optionen…] boot [nspawn settings…]

mkosi [Optionen…] qemu [Qemu-Parameter…]

mkosi [Optionen…] vmspawn [Vmspawn-Einstellungen…]

mkosi [Optionen…] ssh [Befehlszeile…]

mkosi [Optionen…] journalctl [Befehlszeile…]

mkosi [Optionen…] coredumpctl [Befehlszeile…]

mkosi [Optionen…] clean

mkosi [Optionen…] serve

mkosi [Optionen…] burn <Gerät>

mkosi [Optionen…] bump

mkosi [Optionen…] genkey

mkosi [Optionen…] documentation

mkosi [Optionen…] help

BESCHREIBUNG

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

Unterbefehle

Die folgenden Unterbefehle werden erkannt:

Gibt eine menschenlesbare Zusammenfassung aller für den Bau des Abbilds verwandten Optionena aus. Dies wird die Befehlszeile und mkosi.conf wie bei einem build auswerten, aber nur ausgeben, wofür es konfiguriert ist und nicht wirklich etwas bauen.
Dies baut das Abbild basierend auf den auf der Befehlszeile übergebenen oder aus den Konfigurationsdateien gelesenen Einstellungen. Diese Befehl ist die Vorgabe, falls kein Unterbefehl explizit angegeben ist. Falls irgenwelche Befehlszeilenargumente angegeben sind, werden sie direkt an das Bauskript übergeben, falls eines definiert ist.
Dies baut das Abbild, falls es noch nicht gebaut ist, und ruft dann systemd-nspawn(1) auf, um darin eine interaktive Shell-Eingabeauforderung zu erlanben. Nach dem Unterbefehl shell kann eine optionale Befehlszeile angegeben werden, die anstelle der Shell in dem Container aufgerufen werden soll. Verwenden Sie -f, um das Abbild bedingungslos vor dem Erlangen der Shell neuzubauen, siehe unten. Dieser Befehl muss als root ausgeführt werden.
Ähnlich wie shell, startet das Abbild aber mittels systemd-nspawn(1). Nach dem Unterbefehl boot kann eine optionale Befehlszeile angegeben werden, die zusätzliche Nspawn-Optionen sowie Argumente enthalten kann, die an die Kernelbefehlszeile des Init-Systems im Abbild übergeben werden.
Ähnlich wie boot, verwendet aber qemu, um das Abbild zu starten, d.h. anstelle einer Container-Virtualisierung wird eine Virtualisierung einer virtuellen Maschine verwandt. Dieser Unterbefehl wird nur für Plattenabbilder unterstützt, die ein Systemstartladeprogramm und CPIO-Abbilder enthalten, in denen ein Kernel installiert wurde. Für CPIO-Abbilder kann ein Kernel auch durch Übergabe des Qemu-Arguments -kernel an den Unterbefehl qemu bereitgestellt werden. Alle nach dem Unterbefehl qemu angegebenen Argumente werden an den Aufruf von qemu angehängt.
Ähnlich wie boot, verwendet aber systemd-vmspawn, um das Abbild zu starten, d.h. anstelle einer Container-Virtualisierung wird eine Virtualisierung einer virtuellen Maschine verwandt. Dieser Unterbefehl wird nur für platten- und Verzeichnisartige Abbilder unterstützt. Alle nach dem Unterbefehl vmspawn angegebenen Argumente werden an den Aufruf von systemd-vmspawn angehängt.
Wenn das Abbild mit der Option Ssh=yes gebaut wird, verbindet dieser Befehl die gestartete virtuelle Maschine (qemu) mittels SSH. Stellen Sie sicher, dass mkosi ssh mit der gleichen Konfiguration wie mkosi build ausgeführt wird, so dass es die notwendigen Informationen hat, um sich mit der laufenden virtuellen Maschine mittels SSH zu verbinden. Insbesondere wird der private SSH-Schlüssel aus der Einstellung SshKey= verwandt, um sich mit der virtuellen Maschine zu verbinden. Verwenden Sie mkosi genkey, um automatisch einen Schlüssel und ein Zertifikat zu erstellen, das von Mkosi aufgenommen wird. Alle nach dem Unterbefehl ssh übergebene Argumente werden als Argumente an den Aufruf von ssh(1) übergeben. Um sich mit einem Container zu verbinden, verwenden Sie machinectl login oder machinectl shell.
Verwendet journalctl(1), um das Journal innerhalb des Abbildes zu untersuchen. Alle nach dem Unterbefehl journalctl angegebenen Argumente werden an den Aufruf von journalctl(1) angehängt.
Verwendet coredumpctl(1), um nach Speicherauszügen innerhalb des Abbilds zu suchen. Alle nach dem Unterbefehl coredumpctl angegebenen Argumente werden an den Aufruf von coredumpctl(1) angehängt.
Entfernt aus vorherigen Bauläufen erstellte Bauartefakte. Falls mit -f kombiniert, werden auch inkrementelle Bauzwischenspeicher-Abbilder entfernt. Falls -f zweimal angegeben ist, werden sämtliche Paketzwischenspeicher entfernt.
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 ….
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.
Erhöht die Version des Abbildes aus mkosi.version und schreibt die resultierende Versionszeichenkette nach mkosi.version. Dies ist zur Implementierung eines einfachen Versionierungsschematas nützlich: jedes Mal, wenn dieser Unterbefehl aufgerufen wird, wird die Version als Vorbereitung für den nächsten Bau erhöht. Beachten Sie, dass --auto-bump/-B zum automatischen Erhöhen der Version nach jedem erfolgreichen Bau verwandt werden kann.
Erstellt ein Paar von SecureBoot-Schlüsseln zur Verwendung mit den Optionen SecureBootKey=/--secure-boot-key= und SecureBootCertificate=/--secure-boot-certificate=.
Zeigt die Dokumentation von mkosi an. Standardmäßig wird dieser Unterbefehl verschiedene Arten zur Ausgabe der Dokumentation ausprobieren, eine bestimmte Option kann mit der Option --doc-format ausgewählt werden. Paketierer von Distributionen wird empfohlen, eine Datei mkosi.1 in das Verzeichnis mkosi/resources des Python-Pakets abzulegen, falls sie dort fehlt, sowie sie im geeigneten Suchpfad für Handbuchseiten zu installieren. Die Handbuchseite kann aus der Markdown-Datei mkosi/resources/mkosi.md zum Beispiel mittels pandoc -t man -s -o mkosi.1 mkosi.md erstellt werden.
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.

Ersetzt beim Bau eines Abbildes die Ausgabedatei, falls sie bereits existiert. Standardmäßig verweigert mkosi eine Aktion, wenn ein Abbild und ein Ausgabeartefakt bereits existiert. Geben Sie diese Option einmal an, um alle Bauartefakte aus einem vorherigen Lauf vor dem Neubau des Abbildes zu entfernen. Falls inkrementelle Bauten aktiviert sind, wird zweimalige Angabe sicherstellen, dass inkrementelle Zwischenspeicherdateien auch entfernt werden, bevor der Neubau eingeleitet wird. Falls ein Paketzwischenspeicher verwandt wird (siehe auch den nachfolgenden Abschnitt Dateien) wird die dreimalige Angabe sicherstellen, dass auch der Paketzwischenspeicher entfernt wird, bevor der Neubau eingeleitet wird. Für die Aktion clean hat diese Option eine leicht andere Auswirkung: Standardmäßig wird der Unterbefehl nur Bauartefakte aus dem vorherigen Lauf entfernen, durch einmalige Angabe werden auch die inkrementellen Zwischenspeicherdateien gelöscht, bei doppelter Angabe wird auch der Paketezwischenspeicher entfernt.
Akzeptiert einen Pfad zu einem Verzeichnis. Bevor es etwas macht, 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.
Aktiviert zusätzliche Fehlersuchausgabe.
Falls die Ausführung eines Befehls in dem Abbild fehlschlägt, wird Mkosi eine interaktive Shell in dem Abbild starten, um weitere Fehlersuche zu ermöglichen.
Falls ein Fehler auftritt, wird das Arbeitsbereichsverzeichnis nicht gelöscht.
Zeigt die Paketversion.
Zeigt einen kurzen Hinweis zum Aufruf.
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.
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).
Falls angegeben wird nach jedem erfolgreichen Bau in Vorbereitung des nächsten Baus die Version auf eine ähnliche Art wie beim Unterbefehl bump erhöht. Dies ist für einfaches, lineares Versionsmanagement nützlich: jeder Bau in einer Reihe wird eine um eins gegenüber dem vorherigen Bau erhöhte Versionsnummer haben.
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.
Zeigt die zusammenfassende Ausgabe als JSON-SEQ.

Unterstützte Ausgabeformate

Die folgenden Ausgabeformate werden unterstützt:

•
Rohes GPT-Plattenabbild, mittels systemd-repart(8) (Platte) erstellt.
•
Einfaches Verzeichnis, enthält den Betriebssystembaum (Verzeichnis)
•
TAR-Archiv (tar)
•
CPIO-Archiv (cpio)

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

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

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

Konfigurationseinstellungen

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

Die Konfiguration wird in der folgenden Reihenfolge ausgewertet:

•
Die Befehlszeilenargumente werden ausgewertet
•
mkosi.local.conf wird ausgewertet, falls es existiert. Diese Datei sollte in gitignore (oder äquivalent) sein und ist für lokale Konfiguration gedacht.
•
Alle Vorgabepfade (abhängig von der Option) werden konfiguriert, falls der entsprechende Pfad existiert.
•
mkosi.conf wird ausgewertet, falls es in dem mit --directory= konfigurierten Verzeichnis liegt oder im aktuellen Verzeichnis, falls --directory= nicht verwandt wird.
•
mkosi.conf.d/ wird im gleichen Verzeichnis ausgewertet, falls sie existiert. Jedes Verzeichnis und jede Datei mit der Endung .conf in mkosi.conf.d/ wird ausgewertet. Jedes Verzeichnis in mkosi.conf.d wird ausgewertet, also ob es ein normales Verzeichnis auf der obersten Ebene wäre.

Beachten Sie, dass bei doppelter Konfiguration einer Einstellung die spätere Zuweisung die frühere Zuweisung außer Kraft setzt, außer die Zuweisung ist eine Listen-basierte Einstellung. Beachten Sie auch, dass vor v16 das Gegenteil passierte, wo eine frühere Zuweisung statt einer späteren Zuweisung verwandt worden wäre.

Einstellungen, die einen Listenwert 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.

Falls dem Namen einer Einstellung in der Konfigurationsdatei @ vorangestellt wird, konfiguriert sie den für diese Einstellung verwandten Vorgabewert, falls kein expliziter Vorgabewert gesetzt ist. Dies kann zum Setzen angepasster Vorgabewerte in Konfigurationsdateien verwandt werden, die weiterhin durch explizite Angabe der Einstellung auf der Befehlszeile außer Kraft gesetzt werden können.

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 Bedingunge 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. Beachten Sie auch, dass das Prüfen der Übereinstimmung mit einer Einstellung und das anschließende Ändern in einer anderen Konfigurationsdatei zu unerwarteten Ergebnissen führen kann.

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

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

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

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

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

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. Keine Übereinstimmungsabschnitte werden als wahr ausgewertet. Logisch bedeutet dies:

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

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

Abschnitt [Match]

Übereinstimmung mit dem konfigurierten Profil.
Übereinstimmung mit der konfigurierten Distribution.
Ü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.
Übereinstimmung mit der konfigurierten Architektur. Falls diese Bedingung verwandt wird und noch keine Architektur explizit konfiguriert wurde, wird die Architektur des Wirtsystems verwandt.
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.
Ü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.
Ü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 Abbildversoin explizit konfiguriert wurde, schlägt diese Bedingung fehl.
Übereinstiummung mit dem konfigurierten Wert für die Funktionalität Bootable=. Akzeptiert einen logischen Wert oder auto.
Übereinstimmung mit dem konfigurierten Wert für die Option Format=. Akzeptiert ein Ausgabeformat (siehe die Option Format=).
Ü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.
Akzeptiert einen Bauquellbaumpfad (siehe BuildSources=). Diese Übereinstimmung ist erfüllt, falls eine der konfigurierten Bauquellen diesen Zielpfad verwendet. Enthält beispielsweise eine Datei mkosi.conf Folgendes:
[Content]
BuildSources=../abc/qed:kernel

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

[Match]
BuildSources=kernel
Alle an diese Einstellung übergebenen absoluten Pfade werden relativ zum aktuellen Arbeitsverzeichnis interpretiert.
Übereinstimmung mit der grundständigen Architektur des Wirtrechners. Siehe die Einstellung Architecture= für eine Liste möglicher Werte.

Übereinstimmer Globs Umfangreicher Vergleich Vorgabe
Profile= no no Übereinstimmung schlägt fehl
Distribution= no no Übereinstimmung mit Distribution des Wirtsystems
Release= no no Übereinstimmung mit Veröffentlichung des Wirtsystems
Architecture= no no Übereinstimmung mit Architektur des Wirtsystems
PathExists= no no n.Z.
ImageId= yes no Übereinstimmung schlägt fehl
ImageVersion= no yes Übereinstimmung schlägt fehl
Bootable= no no Übereinstimmung mit automatischer Funktionalität
Format= no no Übereinstimmung mit Standardformat
SystemdVersion= no yes n.Z.
BuildSources= no no Übereinstimmung schlägt fehl
HostArchitecture= no no n.Z.

Abschnitt [Config]

Wählt das angegebene Profil aus. Ein Profil ist eine Konfigurationsdatei oder -Verzeichnis in dem Verzeichnis mkosi.profiles/. Wenn ausgewählt, wird diese Konfigurationsdatei oder das -Verzeichnis nach der Auswertung der Datei mkosi.conf, aber vor allen Ergänzungskonfigurationen in mkosi.conf.d/*.conf eingebunden.
Bindet zusätzliche Konfiguration aus der angegebenen Datei oder dem Verzeichnis ein. Die zusätzliche Konfiguration wird direkt nach der Auswertung der Einstellung eingebunden, außer wenn mittels @Include= eine Vorgabe gesetzt wird. In letzterem Fall wird die Konfiguration nach der Auswertung aller anderen Konfigurationsdateien eingebunden. Beachten Sie, dass jeder Pfad, der zusätzliche Konfiguration enthält, nur einmal ausgewertet wird, selbst wenn er mehr als einmal mit Include= eingebunden wird. Die eingebaute Konfiguration für die Standard-Mkosi-Initrd und dem Standardwerkzeugbaum kann durch Einbinden des wörtlichen Wertes mkosi-initrd bzw. mkosi-tools erfolgen. Beachten Sie: Eingebundene Namen, die mit einem der wörtlichen Zeichenketten mkosi- oder contrib- beginnen, sind für die Verwendung durch Mkosi selbst reserviert.
Identisch zu Include=, aber die zusätzlichen Konfigurationsdateien oder -verzeichnisse werden beim Bau der Standard-Initrd eingebunden.
Falls verwandt wird nur das angegebene Abbild gebaut. Kann mehrfach zum Bau mehrerer Abbilder verwandt werden. Alle angegeben Abbilder und ihre Abhängigkeiten werden gebaut. Falls nicht verwandt werden alle Abbilder gebaut. Siehe den Abschnitt Bau mehrerer Abbilder für weitere Informationen. Beachten Sie, dass dieser Abschnitt nur berücksichtigt wird, wenn er in der globalen Konfigurationsdatei verwandt wird. In Abbild-spezifischen Einstellungen hat er keine Auswirkung.
Die Abbilder, von denen dieses Abbild abhängt, festgelegt als Kommata-getrennte Liste. Alle in dieser Option konfigurierten Abbilder werden vor diesem Abbild gebaut und werden als Abhängigkeiten für dieses Abbild hereingezogen, wenn Images= verwandt wird.
Die minimale Version von Mkosi, die zum Bau dieser Konfiguration benötigt wird. Falls mehrfach angegeben, wird die höchste festgelegte Version verwandt.

Abschnitt [Distribution]

Die im Abbild zu installierende Distribution. Akzeptiert eines der folgenden Argumente: fedora, debian, ubuntu, arch, opensuse, mageia, centos, rhel, rhel-ubi, openmandriva, rocky, alma, custom. Falls nicht angegeben ist die Vorgabe die Distribution des Wirtsystems oder custom, falls die Distribution des Wirtsystems keine unterstützte Distribution ist.
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 nummerische Zeichenkette (im Falle von Fedora Linux, CentOS, …, z.B. 29) oder ein Versionsname der Distribution (im Falle von Debian, 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.
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 startbares Abbild erbeten wird. Beim Bau für eine fremde Architektur müssen Sie auch den Benutzermodus-Emulator für diese Architektur installieren und registrieren. Pro gebautem Abbild kann eine der folgenden Architekturen festgelegt werden: alpha, arc, arm, arm64, ia64, loongarch64, mips64-le, mips-le, parisc, ppc, ppc64, ppc64-le, riscv32, riscv64, s390, s390x, tilegx, x86, x86-64.
Der Spiegel für das Herunterladen der Distributionspakete. Erwartet eine Spiegel-URL als Argument. Falls nicht angegeben wird der Standard-Spiegel für die Distribution verwandt. Die Standard-Spiegel fürjede Distribution ist wie folgt (sofern nicht angegeben, wird der gleiche Spiegel für alle Architekturen verwandt):

X86-64 Aarch64
Debian http://deb.debian.org/debian
Arch https://geo.mirror.pkgbuild.com http://mirror.archlinuxarm.org
OpenSUSE http://download.opensuse.org
Ubuntu http://archive.ubuntu.com http://ports.ubuntu.com
Centos https://mirrors.centos.org
Rocky https://mirrors.rockylinux.org
Alma https://mirrors.almalinux.org
Fedora https://mirrors.fedoraproject.org
RHEL-ubi https://cdn-ubi.redhat.com
Mageia https://www.mageia.org
Openmandriva http://mirrors.openmandriva.org
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/arch-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.
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. Wird noch nicht für DNF-basierte Distributionen verwandt.
Aktiviert standardmäßig deaktivierte Paket-Depots. Dies kann zur Aktivierung der EPEL-Depots für CentOS oder anderer Komponenten der Debian/Ubuntu-Depots verwandt werden.
Akzeptiert entweder none, metadata oder always. 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 none gesetzt werden während des Baus die Paketmetadaten synchronisiert und die Pakete heruntergeladen.
PackageManagerTrees=, --package-manager-tree=
Diese Option spiegelt die obige Option SkeletonTrees= und hat die gleiche Vorgabe, falls nicht anders konfiguriert, aber installiert Dateien in ein Unterverzeichnis des Arbeitsplatz-Verzeichnisses anstelle des Betriebssystembaums. Dieses Unterverzeichnis des Arbeitsplatzbereichs wird zur Konfiguration des Paketverwalters verwandt. mkosi sucht nach Paketverwalterkonfiguration und zugehörigen Dateien in den konfigurierten Paketverwalterbäumen. Falls nicht anders festgelegt, wird es die Konfigurationsdateien an ihren kanonischen Orten in /usr oder /etc in den Paketverwalterbäumen verwenden. Es wird beispielsweise nach etc/dnf/dnf.conf in den Paketverwalterbäumen suchen, falls dnf zur Installation von Paketen verwandt wird. SkeletonTrees= und PackageManagerTrees= erfüllen ähnliche Rollen. Verwenden Sie SkeletonTrees=, falls Sie möchten, dass die Dateien im letztendlichen Abbild vorhanden sind. Verwenden Sie PackageManagerTrees=, falls Sie dies nicht möchten, d.h. wenn Sie eine Initrd bauen oder falls Sie sich auf Pfade außerhalb des Abbilds in Ihrer Depot-Konfiguration beziehen möchten.

Abschnitt [Output]

Das zu erstellende Abbild-Format. Entweder directory (zur direkten Erstellung eines Betriebssystemabbildes im lokalen Verzeichnis), tar (ähnlich, es wird aber ein Tarball des Betriebssystemabbildes erstellt), cpio (ähnlich, es wird aber ein Cpio-Archiv erstellt), disk (ein Blockgerät-Betriebssystemabbild mit einer GPT-Partitionstabelle), uki (ein vereinigtes Kernel-Abbild mit einem Betriebssystemabbild im PE-Abschnitt .initrd), esp (uki aber in einem Platten-Abbild mit nur einer ESP-Partition eingehüllt), sysext, confext, portable oder none (das Betriebssystem-Abbild ist nur als Bau-Artefakt zur Erstellung eines weiteren Artefaktes gedacht). Falls das Ausgabeformat disk verwandt wird, wird das Plattenabbild mittels systemd-repart(8) erstellt. Die zu verwendenden Repart-Partitions-Definitionsdateien können mittels der Einstellung RepartDirectories= oder mittels mkosi.repart/ konfiguriert werden. Wenn Verity-Partitionen mittels der Einstellung Verity= von systemd-repart(8) konfiguriert werden, wird Mkosi automatisch den Roothash der Verity-Hash-Partition aus der JSON-Ausgabe von systemd-repart(8) auswerten und ihn in die Kernel-Befehlszeile jedes durch Mkosi gebauten vereinigten Kernel-Abbildes aufnehmen.
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.
Für die erstellte Ausgabedatei oder das Ausgabeverzeichnis zu verwendender Name. Der angegebene Name wird allen Ausgaben vorangestellt. Standardmäßig image oder, falls ImageId= verwandt wird, wird dieser als standardmäßiger Ausgabename verwandt, optional wird die mit ImageVersion= angegebene Version angehängt. Beachten Sie, dass diese Option nicht die Konfiguration des Ausgabeverzeichnisses ermöglicht, verwenden Sie dafür OutputDirectory=. Beachten Sie, dass dies nur den Ausgabepräfix festlegt, der vollständige Ausgabename kann abhängig von dem festgelegten Ausgabeformat, der verwandten Komprimierung und Abbildversion image_7.8.raw.xz sein.
Konfiguriert die Komprimierung für das resultierende Abbild oder Archiv. Das Argument kann entweder ein logischer Wert oder ein Komprimierungsalgorithmus (xz, zstd) 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. 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, qemu bei der Verwendung dieser Option nicht verfügbar sind. Impliziert für tar, cpio, uki und esp.
Konfiguriert die zu verwendende Komprimierungsstufe. Akzeptiert eine Ganzzahl. Die möglichen Werte hängen von der verwandten Komprimierung ab.
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.
Pfad zu einem Verzeichnis, in dem temporär während eines Abbild-Baus benötigte Daten gespeichert werden. Dieses Verzeichnis sollte über genug Platz verfügen, das vollständige Betriebssystemabbild zu speichern, obwohl in den meisten Modi der tatsächlich verwandte Plattenplatz kleiner ist. Falls nicht angegeben, wird ein Unterverzeichnis von $XDG_CACHE_HOME (falls gesetzt), $HOME/.cache (falls gesetzt) oder /var/tmp verwandt. Nach jedem Bau werden die Daten in diesem Verzeichnis automatisch entfernt. Es ist sicher, die Inhalte dieses Verzeichnisses manuell zu entfernen, falls der Aufruf von mkosi anormal abgebrochen wurde (beispielsweise aufgrund eines Neustarts oder Stromausfalls).
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.
Akzeptiert einen Pfad zu einem Verzeichnis, das als Paketzwischenspeicherverzeichnis für den eingesetzten Distributionspaketverwalter verwandt wird. Falls nicht gesetzt, wird ein geeignetes Verzeichnis in dem Home-Verzeichnis des Benutzers oder des Systems verwandt.
Akzeptiert einen Pfad zu einem Verzeichnis, das als Bauverzeichnis für Bausysteme verwandt werden soll, die Bauen in separaten Verzeichnissen unterstützen (wie Meson). Das auf diese Art verwandte Verzeichnis wird zwischen mehreren Bauten gemeinsam benutzt und ermöglicht es dem Bausystem, Artefakte (wie Objektdateien, Programmen, …), die bei vorherigen Aufrufen erzeugt wurden, wiederzuverwenden. Die Bauskripte können den Pfad zu diesem Verzeichnis in der Umgebungsvariable $BUILDDIR finden. Dieses Verzeichnis wird in das Wurzelverzeichnis des Abbildes eingehängt, wenn mkosi-chroot während der Ausführung der Bauskripte aufgerufen wird. Falls diese Option nicht verwandt wird, aber das Verzeichnis mkosi.builddir/ im lokalen Verzeichnis gefunden wird, wird es automatisch für diesen Zweck verwandt (siehe auch den nachfolgenden Abschnitt Files).
Konfiguriert die Abbild-Version. Dies akzeptiert jede Zeichenkette, es wird aber empfohlen, eine Reihe von durch Punkten getrennte Komponenten festzulegen. Die Version kann auch in einer Datei mkosi.version konfiguriert werden. In diesem Fall kann sie bequem mit dem Unterbefehl bump oder der Option --auto-bump verwaltet 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 /etc/os-release oder ähnliche einzubauen, insbesondere in das darin befindliche Feld IMAGE_VERSION=).
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.
Falls angegeben und ein Plattenabbild gebaut wird, wird --split=yes an systemd-repart(8) übergeben, damit dies getrennte Partitionsdateien für jede konfigurierte Partition schreibt. Lesen Sie die Handbuchseite für weitere Informationen. Dies ist für A/B-Aktualisierungsszenarien nützlich, bei denen ein bestehendes Plattenabbild mit einer neuen Version einer Wurzel- oder /usr-Partition zusammen mit der zugehörigen Verity-Partition und einem vereinigten Kernel erweitert werden soll.
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.
Setzt die Standardsektorgröße, die systemd-repart(8) zum Bau eines Plattenabilds benutzt, außer Kraft.
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. Beachten Sie, dass Mkosi nicht unprivilegiert ausgeführt werden kann, wenn RepartOffline=no verwandt wird und der Abbild-Bau als Benutzer root außerhalb von Containern und mit auf dem Wirtsystem verfügbaren Loopack-Geräten erfolgt. Es gibt derzeit zwei bekannte Szenarien, bei denen RepartOffline=no verwandt werden muss. Das erste ist der Einsatz von Subvolumes= in einer Repart-Partitionsdefinitionsdatei, da Teildatenträger nicht ohne Loopback-Geräte erstellt werden können. Das zweite ist bei der Erstellung eines Systems mit SELinux und einer XFS-Wurzelpartition. Da mkfs.xfs(8) die Befüllung eines XFS-Dateisystems mit erweiterten Attributen nicht erlaubt, müssen Loopback-Geräte verwandt werden um sicherzustellen, dass erweiterte SELinux-Attribute im erstellten XFS-Dateisystem landen.
Bei der Verwendung zusammen mit BaseTrees= wird die Ausgabe nur aus Änderungen an den angegebenen Basisbäumen bestehen. Jeder Basisbaum wird als untere Lage in einer Overlayfs-Struktur angehängt und die Ausgabe wird die obere Lage, die am Anfang leer ist. Daher werden Dateien, die sich gegenüber dem Basisbaum nicht ändern, nicht in der abschließenden Ausgabe enthalten sein. Diese Option kann dazu verwandt werden, um Systemerweiterungen oder portable Dienste zu erstellen.
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 Kopiern 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.
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.
Akzeptiert einen Zeitstempel als Arugment. Setzt die Dateiveränderungszeiten aller Dateien auf diesen Zeitstempel zurück. 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.

Abschnitt [Content]

Installiert die angegebenen Distributionspakete (z.B. RPM, DEB, …) in das Abbild. Akzeptiert eine Kommata-getrennte Liste von Paketangaben. Diese Option kann mehrfach verwandt werden, dabei werden die angegebenen Paketlisten zusammengefasst. Verwenden Sie BuildPackages=, um Pakete anzugeben, die nur in einer Überlagerung installiert werden, die eingehängt ist, wenn die Vorbereitungsskripte mit dem Argument build ausgeführt werden und wenn die Bauskripte ausgeführt werden. Die Typen und die Syntax der erlaubten Paketfestlegungen hängen von dem Paketinstallierer ab (z.B. dnf(8) für rpm(8)-basierte Distributionen oder apt(8) für deb(5)-basierte Distributionen), sie kann aber den Paketnamen, Paketnamen mit Versionen und/oder Architektur, Paketnamen mit Globs, Pfade zu Paketen in dem Dateisystem, Paketgruppen und virtuelle Breitstellungen, einschließlich Dateipfaden, enthalten. Beispiel: Beim Einsatz einer Distribution, die dnf(8) verwendet, würde die folgende Konfiguration das Paket meson (in der neusten Version), die 32-bit-Version des Pakets libfdisk-devel, alle verfügbaren Pakete, die mit git- anfangen, ein systemd-RPM aus dem lokalen Dateisystem, eines der Pakete, das /usr/bin/ld bereitstellt, die Pakete in der Gruppe Development Tools und das Paket, das das Python-Modul mypy enthält, installieren.
Packages=meson


         libfdisk-devel.i686


         git-*


         prebuilt/rpms/systemd-249-rc1.local.rpm


         /usr/bin/ld


         @development-tools


         python3dist(mypy)

: Beachten Sie, dass die meisten Dateien des Wirtsystems nicht verfügbar sind, da Mkosi in einer Sandbox läuft und daher sämtliche lokale Pakete explizit mittels BuildSources= in die Sandbox eingehängt werden müssen. Existiert beispielsweise ein lokales Paket, das sich unter ../meine-Pakete/abc.rpm relativ zum Arbeitsverzeichnis von Mkosi befindet, dann könnte es wie folgt installiert werden:

BuildSources=../my-packages:my-packages-in-sandbox
Packages=my-packages-in-sandbox/abc.rpm
Ä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.
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. Beachten Sie, dass dieses lokale Depot auch bei der Ausführung von Skripten verfügbar gemacht wird. Bauskripte können weitere Pakete zu dem lokalen Depot hinzufügen, indem sie die gebauten Pakete in $PACKAGEDIR ablegen.
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).
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.
Akzeptiert eine Komma-getrennte Liste von Pfaden zu Verwendung als Basisbäume. Bei der Verwendung werden dieses Basisbäume in die Betriebssystembäume kopiert und formen die Basisdistribution anstelle der normalen Installation. Es werden nur zusätzliche Pakete ergänzend zu den bereits in den Basisbäumen installierten Paketen installiert. Beachten Sie, dass das Basisabbild weiterhin die Paketverwaltermetadaten durch Setzen von CleanPackageMetadata=no (siehe CleanPackageMetadata=) enthalten muss, damit das korrekt funktioniert. Anstelle eines Verzeichnisses kann eine Tar-Datei oder ein Plattenabbild bereitgestellt werden. In diesem Fall wird es in den Betriebssystembaum entpackt. Dieser Betriebsmodus erlaubt das explizite Setzen von Berechtigungen und Dateieigentümerschaften, insbesondere für Projekte, die in einem Versionssteuerungssystem wie git gespeichert sind, das die Metadaten für die Dateieigentümerschaft und den Zugriffsmodus für übergebene Dateien vollständig beibehält.
Akzeptiert eine Kommata-getrennte Liste von Doppelpunkt-getrennten Pfadpaaren. Der erste Pfad jedes Paares bezieht sich auf ein Verzeichnis, das in den Betriebssystembaum vor dem Aufruf des Paketverwalters kopiert werden soll. Der zweite Pfad in jedem Paar bezieht sich auf das Zielverzeichnis innerhalb des Abbildes. Falls der zweite Pfad nicht bereit gestellt wird, wird das Verzeichnis auf das Wurzelverzeichnis des Abbildes kopiert. Der zweite Pfad wird immer als ein absoluter Pfad interpretiert. Verwenden Sie dies, um Dateien und Verzeichnisse in den Betriebssystembaum einzufügen, bevor der Paketverwalter irgendwelche Pakete installiert. Falls das Verzeichnis mkosi.skeleton/ in dem lokalen Verzeichnis gefunden wird, wird es auch für diesen Zweck mit dem Wurzelverzeichnis als Ziel verwandt (siehe auch den nachfolgenden Abschnitt Dateien). Beachten Sie, dass die Gerüstverzeichnisse zwischengespeichert werden und alle Änderungen an den Gerüstverzeichnissen, nachdem das Abbild gebaut wurde (bei der Verwendung von Incremental=) nur angewandt werden, wenn das zwischengespeicherte Abbild neu gebaut wird (mittels -ff oder durch Ausführung von mkosi -f clean). Gemäß der obigen Basisbaumlogik kann anstelle eines Verzeichnisses auch eine Tar-Datei bereitgestellt werden. mkosi.skeleton.tar wird automatisch verwandt, falls es im lokalen Verzeichnis gefunden wird.
Akzeptiert eine Kommata-getrennte Liste von Doppelpunkt-getrennten Pfadpaaren. Der erste Pfad jedes Paares bezieht sich auf ein Verzeichnis, das vom Wirtsystem in das Abbild kopiert werden soll. Der zweite Pfad in jedem Paar bezieht sich auf das Zielverzeichnis innerhalb des Abbildes. Falls der zweite Pfad nicht bereit gestellt wird, wird das Verzeichnis auf das Wurzelverzeichnis des Abbildes kopiert. Der zweite Pfad wird immer als ein absoluter Pfad interpretiert. Verwenden Sie dies, um beliebige, mit der Distribution ausgelieferte Standardkonfigurationsdateien außer Kraft zu setzen. Falls das Verzeichnis mkosi.extra/ in dem lokalen Verzeichnis gefunden wird, wird es auch für diesen Zweck mit dem Wurzelverzeichnis als Ziel verwandt (siehe auch den nachfolgenden Abschnitt Dateien). Gemäß der obigen Basisbaumlogik kann anstelle eines Verzeichnisses auch eine Tar-Datei bereitgestellt werden. mkosi.extra.tar wird automatisch verwandt, falls es im lokalen Verzeichnis gefunden wird.
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.
Akzeptiert eine Kommata-getrennte Liste von Globs. Dateien im Abbild, die auf die Globs passen, werden am Ende vollständig entfernt.
Aktiviert/Deaktivert das Entfernen der Paketverwalter-Datenbanken und Depot-Metadaten am Ende der Installation. Kann als true, false oder (die Vorgabe) auto angegegeben werden. Bei auto werden die Paketverwalter-Datenbanken und Depot-Metadaten entfernt, falls das Programm des entsprechenden Paketverwalters am Ende der Installation nicht vorhanden ist.
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.
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.
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.
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.
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.
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.
Akzeptiert einen logischen Wert. Standardmäßig deaktiviert. Konfiguriert, ob Änderungen an Quellverzeichnissen (dem Arbeitsverzeichnis und dem mit BuildSources= konfigurierten) dauerhaft sind. Falls aktiviert, werden alle Quellverzeichnisse auf ihren Originalzustand zurückgesetzt, nachdem alle Skripte (außer Synchronisationsskripte) mit der Ausführung abgeschlossen wurden.
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.
Akzeptiert eine Kommate-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.
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.
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.
Akzeptiert einen logischen Wert oder auto. Aktiviert oder deaktiviert die Erstellung eines selbststartenden 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.
Akzeptiert entweder none, systemd-boot, uki oder grub. 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. Beachten Sie, dass Grub noch nicht in den ESP installiert wird, wenn Bootloader= auf grub gesetzt wird. Dies muss manuell in einem Postinstallations- oder Finalisierungsskript erfolgen. Das Grub-EFI-Programm sollte nach /efi/EFI/BOOT/BOOTX64.EFI (oder ähnlichem, abhängig von der Architektur) installiert werden und sollte so konfiguriert werden, dass es seine Konfiguration aus EFI/<Distribution>/grub.cfg im ESP lädt. Signierte und von Distributionen ausgelieferte Versionen von Grub werden standardmäßig ihre Konfigurationen von diesem Ort laden.
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 selbststartendes Abbild mit der Option Bootable= erbeten wird. Falls keine Repart-Partitionsdefinitionsdateien konfiguriert sind, wird Mkosi eine Grub-BIOS-Systemstartpartition und eine EFI-Systempartition zu den Standard-Partitionsdefinitionsdateien hinzufügen. Beachten Sie, dass diese Option sich nicht mit der Option Bootloader= gegenseitig ausschließt. Es ist möglich, ein Abbild zu haben, das sowohl unter UEFI als auch BIOS startet, indem sowohl Bootloader= als auch BiosBootloader= konfiguriert wird. Die Grub-BIOS-Systemstartpartition sollte die UUID 21686148-6449-6e6f-744e-656564454649 haben und mindestens 1 MB groß sein. Selbst wenn kein EFI-Systemstartladeprogramm installiert ist, wird dennoch ein ESP für BIOS-Systemstarts benötigt, da dort der Kernel, die Initrd und Grub-Module gespeichert werden.
Akzeptiert entweder none, unsigned oder signed. Standardmäßig none. Falls auf none gesetzt, werden Shim und MokManager nicht in das 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 unsignierte 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 Programm nicht erneut signieren. Beachten Sie, dass diese Option nur wirksam wird, wenn ein auf UEFI-Firmware startbares Abbild mittels anderer Optionen angefragt wird (Bootable=, Bootloader=). Beachten Sie, dass Mkosi nur bereits signierte Systemladeprogramme, Kernelabbilddateien und vereinigte Kernelabbilder installieren wird, wenn diese Option aktiviert ist, da selbstsignierte Programme von signierten Versionen von Shim nicht akzeptiert würden.
Gibt an, ob vereinigte Kernelabbilder verwandt werden sollen, wenn Bootloader= auf systemd-boot oder grub gesetzt ist. Akzeptiert einen logischen Wert oder auto. Standardmäßig auto. Falls aktiviert, werden vereinigte Kernelabbilder immer verwandt und der Bau wird fehlschlagen, falls eine der für den Bau von vereinigten Kernelabbildern benötigten Komponenten fehlt. Falls auf auto gesetzt, werden vereinigte Kernelabbilder verwandt, falls alle benötigten Komponten verfügbar sind. Andernfalls werden stattdessen Typ-1-Einträge, wie in der Systemladerspezifikation definiert, verwandt. Falls deaktiviert, werden Typ-1-Einträge immer verwandt.
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 Initirds angegeben sind und ein startbares Medium erbeten wurde, wird Mkosi automatisch eine Standard-Initrd bauen.
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.
Wenn auf wahr gesetzt, wird nur der Mikrocode für die CPU des Wirtsystems in dem Abbild aufgenommen.
Verwendet die angegebene Kernelbefehlszeile beim Bau der Abbilder. Standardmäßig console=ttyS0. Für arm, s390 und ppc wird ttyS0 durch ttyAMA0, ttysclp0 bzw. hvc0 ersetzt.
Akzeptiert eine Liste von Mustern regulärer Ausdrücke, die im Abbild aufzunehmende Kernelmodule festlegen. Die Muster sollten relativ zum Verzeichnis /usr/lib/modules/<kver>/kernel sein. Mkosi prüft überall im Modulpfad auf Übereinstimmung (z.B. passt i915 auf drivers/gpu/drm/i915.ko). Alle Module, die auf das angegebene Muster passen werden im Abbild aufgenommen. Alle Module und Firmwareabhängigkeiten des übereinstimmenden Moduls werden auch im Abbild aufgenommen. Diese Einstellung hat gegenüber KernelModulesExclude= Vorrang und ergibt nur in Kombination mit ihr Sinn, da standardmäßig alle Kernelmdoule im Abbild aufgenommen werden.
Akzeptiert eine Liste von Mustern regulärer Ausdrücke, die vom Abbild ausgeschlossen werden sollen. Verhält sich zu KernelModulesInclude= identisch, außer dass alle Module, die mit einem der angegebenen Muster übereinstimmen, vom Abbild ausgeschlossen werden.
Akzeptiert einen logischen Wert. Legt fest, ob die aktuell geladenen Module des Wirtsystems im Abbild aufgenommen werden sollen. Diese Einstellung hat gegenüber KernelModulesExclude= Vorrang und ergibt nur in Kombination mit ihr Sinn, da standardmäßig alle Kernelmdoule im Abbild aufgenommen werden.
Aktiviert/Deaktiviert beim Bau eines startbaren Abbilds die Erstellung von Kernelmodulen in der Initrd. Standardmäßig aktiviert. Falls aktiviert, wird beim Bau eines startbaren Abbilds für jeden Kernel, für den ein vereinigtes Kernelabbild zusammengebaut wird, eine zusätzliche Initrd erstellt, die nur die Kernelmodule für diese Kernelversion enthält und diese an die vorabgebaute Initrd angehängt. Dies ermöglicht es, Kernel-unabhängige Initrds zu erstellen, die mit den notwendigen kernelmodulen ergänzt werden, wenn das UKI zusammengebaut wird.
Wie KernelModulesInclude=, gilt aber für Kernelmodule, die Teil der Kernelmodul-Initrd sind.
Wie KernelModulesExclude=, gilt aber für Kernelmodule, die Teil der Kernelmodul-Initrd sind.
Wie KernelModulesIncludeHost=, gilt aber für Kernelmodule, die Teil der Kernelmodul-Initrd sind.
Die Einstellungen Locale=, --locale=, LocaleMessages=, --locale-messages=, Keymap=, --keymap=, Timezone=, --timezone=, Hostname=, --hostname=, RootShell=, --root-shell= entsprechen den identisch benannten Systemd-firstboot-Optionen. Siehe die Handbuchseite für zusätzliche Optionen. 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.
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. 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.
Aktiviert die automatische Anmeldung für den Benutzer root auf /dev/pts/0 (nspawn), /dev/tty1 und /dev/ttyS0.
Fügt /etc/initrd-release und /init zum Abbild hinzu, so dass es als ein Initramfs verwandt werden kann.
Falls angegeben wird eine sshd(8)-Socket-Unit und ein passender Dienst im letztendlichen Abbild installiert, das SSH über Vsock offenlegt. Beim Bau mit dieser Option und dem Betrieb des Abbilds mittels mkosi qemu kann der Befehl mkosi ssh zum Verbinden mit dem Container/der VM mittels SSH verwandt werden. Beachten Sie, dass Sie weiterhin sicherstellen müssen, dass Openssh im Abbild installiert ist, damit sich diese Option korrekt verhält. Führen Sie mkosi genkey aus, um automatisch ein X509-Zertifikat und private Schlüssel zu erzeugen, die von Mkosi zur Aktivierung vom SSH-Zugriff zu jeder virtuellen Maschine mittels mkosi ssh verwandt werden. Um auf mittels mkosi boot gestartete Abbilder zuzugreifen, verwenden Sie machinectl(1).
Legt fest, ob Dateien neu markiert werden sollen, um auf die SELinux-Richtlinie des Abbilds zu passen. Akzeptiert einen logischen Wert oder auto. Standardmäßig auto. Falls deaktiviert, werden Dateien nicht neu markiert. Falls aktiviert, muss eine SELinux-Richtlinie im Abbild installiert werden und setfiles(8) verfügbar sein, um Dateien zu markieren. Falls während setfiles(8) irgendein Fehler auftritt, wird der Bau fehlschlagen. Falls auf auto gesetzt, werden Dateien neu markiert, falls eine SELinux-Richtlinie im Abbild installiert und setfiles(8) verfügbar ist. Alle während setfiles(8) aufgetretenen Fehler werden ignoriert. Beachten Sie, dass bei der nicht priviligierten Ausführung setfiles(8) beim Setzen von allen Markierungen fehlschlagen wird, die nicht in der SELinux-Richtlinie des Wirtsystems sind. Um sicherzustellen, dass setfiles(8) ohne Fehler erfolgreich ist, führen Sie Mkosi als Root aus oder bauen Sie von einem Wirtsystem, das die gleichen SELinux-Richtlinie wie im zu bauenden Abbild verwendet.

Abschnitt [Validation]

Signiert systemd-boot(7) (falls es noch nicht signiert ist) und sämtliche vereinigten Kernelabbilder für UEFI SecureBoot.
Für die automatische Registrierung der Schlüssel für sicheren Systemstart in virtuellen Maschinen falls SecureBoot= verwandt wird, wie das in der Handbuchseite von 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.
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.
Quelle von SecureBootKey=, um OpenSSL-Einheiten zu unterstützen. Beispiel: --secure-boot-key-source=engine:pkcs11
Pfad zu der X.509-Datei, die das Zertifikat für das signierte UEFI-Kernelabbild enthält, falls SecureBoot= verwandt wird.
Werkzeug um Signieren von PE-Programmen für den sicheren Systemstart. Akzeptiert entweder sbsign, pesign oder auto. Standardmäßig auto. Falls auf auto gesetzt, wird (wenn verfügbar) entweder sbsign(1) oder pesign(1) verwandt, wobei sbsign(1) bevorzugt wird, wenn beide installiert sind.
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.
Quelle von VerityKey=, um OpenSSL-Engines zu unterstützen. Beispiel: --verity-key-source=engine:pkcs11
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.
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.
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.
Erstellt eine Datei SHA256SUMS über alle erstellten Artefakte, nachdem der Bau abgeschlossen ist.
Signiert nach Fertigstellung die erstellte SHA256SUMS mittels gpg(1).
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 [Host]

Aktiviert den inkrementellen 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 den Neubau eines zwischengespeicherten Abbilds zu erzwingen, kombinieren Sie -i mit -ff um sicherzustellen, dass das zwischengespeicherte Abbild zuerst entfernt und dann neu erstellt wird.
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.
Liste von durch Doppelpunkt getrennten Pfaden, in denen vor dem regulären Suchpfad $PATH nach Werkzeugen gesucht wird.
Falls aktiviert, wird Qemu mit seiner graphischen Oberfläche anstelle einer seriellen Konsole ausgeführt.
Bei der Verwendung mit dem Unterbefehl qemu setzt diese Option das Argument -smp von qemu, das die Anzahl der CPUs im Gast steuert. Standardmäßig 2.
Bei der Verwendung mit dem Unterbefehl qemu setzt diese Option das Argument -m von qemu, das die Speichermenge im Gast steuert. Standardmäßig 2G.
Bei der Verwendung mit dem Unterbefehl qemu legt diese Option fest, ob QEMU die KVM-Beschleunigung nutzen soll. Akzeptiert einen logischen Wert oder auto. Standardmäßig auto.
Bei der Verwendung mit dem Unterbefehl qemu legt diese Option fest, ob QEMU mit einem Vsock konfiguriert werden soll. Akzeptiert einen logischen Wert oder auto. Standardmäßig auto.
Bei der Verwendung mit dem Unterbefehl qemu legt diese Option die zu verwendende Verbindungskennung fest. Akzeptiert eine Zahl im Intervall [3, 0xFFFFFFFF) oder hash oder auto. Standardmäßig hash. 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. Beachten Sie, dass beim Setzen auf auto mkosi ssh nicht verwandt werden kann, da die ermittelte freie Verbindungskennung nicht beim vorhergehenden Systemstart ermittelt werden kann.
Bei der Verwendung mit dem Unterbefehl qemu legt diese Option fest, ob eine Instanz von swtpm(8) zur Verwendung als TPM mit Qemu gestartet werden soll. Diese benötigt ein installiertes swtpm(8) auf dem Wirtrechner. Akzeptiert einen logischen Wert oder auto. Standardmäßig auto.
Bei der Verwendung mit dem Unterbefehl qemu legt diese Option fest, ob das Abbild als CD-ROM-Laufwerk an die virtuelle Maschine angehängt werden soll. Akzeptiert einen logischen Wert. Standardmäßig no.
Bei der Verwendung mit dem Unterbefehl qemu legt diese Option die zu verwendende Firmware fest. Akzeptiert entweder uefi, uefi-secure-boot, bios, linux oder auto. Standardmäßig auto. Falls auf uefi gesetzt, wird die OVMF-Firmware ohne Unterstützung für sicheren Systemstart verwandt. Falls auf uefi-secure-boot gesetzt, wird die OVMF-Firmware mit Unterstützung für sicheren Systemstart verwandt. Falls auf bios gesetzt, wird die Standard-SeaBIOS-Firmware verwandt. Siehe die Option QemuKernel= für weitere Details darüber, welches Kernelabbild mit direktem Kernelsystemstart verwandt wird. Falls auf auto gesetzt wird falls möglich uefi-secure-boot und ansonsten linux verwandt.
Bei der Verwendung mit dem Unterbefehl qemu legt diese Option die Pfad zu der zu verwendenden Firmwarevariablendatei fest. 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-Firmware-Datei suchen und diese stattdessen verwenden. Falls auf microsoft gesetzt, wird eine Firmwarevariablendatei mit bereits registriertem sicheren Systemstartzertifikat von Microsoft verwandt. Falls auf custom gesetzt, wird eine Zertifikat für sicheren Systemstart von SecureBootCertificate= in die Standard-Firmwarevariablendatei registriert. virt-fw-vars aus dem Projekt virt-firmware kann zum Anpassen der OVMF-Variablendateien verwandt werden.
Setzt das für direkten Kernelsystemstart in Qemu zu verwendende Kernelabbild. Falls nicht angegeben wird Mkosi den über die Befehlszeile bereitgestellten Kernel (Option -kernel) oder den neusten Kernel, der im Abbild installiert wurde, verwenden (oder fehlschlagen, falls kein Kernel im Abbild installiert wurde). Beachten Sie, dass bei der Verwendung des Ausgabeformats cpio der direkte Kernelsystemstart unabhängig von der konfigurierten Firmware verwandt wird. Abhängig von der konfigurierten Firmware könnte Qemu den Kernel selbst starten oder die konfigurierte Firmware verwenden.
Fügt ein Qemu-Laufwerk hinzu. Akzeptiert eine Doppelpunkt-getrennte Zeichenkette im Format <Kennung>:<Größe>[:<Verzeichnis>[:<Optionen>]]. Kennung legt die dem Laufwerk zugeordnete Kennung fest. Diese kann als die Eigenschaft drive= in verschiedenen Qemu-Geräten verwandt werden. Größe legt die Größe des Laufwerks fest. Dies akzeptiert eine Größe in Byte. Zusätzliche können die Endungen K, M und G zur Festlegung einer Größe in Kilobyte, Megabyte bzw. Gigabyte verwandt werden. Verzeichnis legt optional das Verzeichnis fest, in dem das dem Laufwerk zugrunde liegende Verzeichnis erstellt werden soll. Optionen legen optional zusätzliche, durch Kommata getrennte Eigenschaften fest, die unverändert an die Option -drive von Qemu übergeben werden. Beispielhafte Verwendung:
[Host]
QemuDrives=btrfs:10G


           ext4:20G
QemuArgs=-device nvme,serial=btrfs,drive=btrfs


         -device nvme,serial=ext4,drive=ext4
Leerzeichen-begrenzte Liste von zusätzlich beim Aufruf von Qemu zu übergebenen Argumenten.
Bei der Verwendung mit den Unterbefehlen shell, boot oder qemu führt diese Option den angegeben 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)).
Setzt die an systemd-nspawn(1) bzw. Qemu bei der Verwendung von mkosi shell/boot oder mkosi qemu zu übergebenden Zugangsberechtigungen. Diese Option akzeptiert eine Leerzeichen getrennte Liste von Schlüssel=Wert-Zuweisungen.
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ätzliches Argument 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.
Falls angegeben, werden ACLS auf allen erstellten Wurzeldateisystemverzeichnissen erstellt, die dem Benutzer, der Mkosi ausführt, erlauben, diese ohne zusätzlich benötigte Privilegien zu entfernen.
Falls angegeben, werden von Mkosi ausgeführte Programme zum Bau und Starten eines Abbilds innerhalb des angegeben Baums statt im Wirtsystem nachgesucht. Verwenden Sie diese Option, um den Abbildbau reproduzierbarer zu machen, indem Sie immer die gleiche Version von Programmen zum Bau des letztendlichen Abbildes verwenden, anstelle der gerade im Wirtsystem installierten Version. Falls diese Option nicht verwandt wird, aber das Verzeichnis mkosi.tools/ im lokalen Verzeichnis gefunden wird, wird es automatisch für diesen Zweck mit dem Wurzelverzeichnis als Ziel verwandt. Beachten Sie, das beim Nachsuchen von Programmen in --tools-tree= nur /usr/bin und /usr/sbin berücksichtigt werden. Insbesondere werden durch --extra-search-path= festgelegte Pfade beim Nachsuchen von Programmen in dem angegebenen Werkzeugbaum ignoriert. Falls auf default gesetzt, wird Mkosi automatisch ein zusätzliches Werkzeugbaumabbild hinzufügen und es als Werkzeugbaum verwenden. Die nachfolgende Tabelle zeigt, für welche Distributionen Standard-Werkzeugbaumpakete definiert sind und welche Pakete in diese Standardwerkzeugbäume aufgenommen werden:

Fedora CentOS Debian Ubuntu Arch openSUSE
acl X X X X X X
apt X X X X X
archlinux-keyring X X X X
attr X X X X X X
bash X X X X X X
btrfs-progs X X X X X
bubblewrap X X X X X X
ca-certificates X X X X X X
coreutils X X X X X X
cpio X X X X X X
curl X X X X X X
debian-keyring X X X X X
diffutils X X X X X X
distribution-gpg-keys X X X
dnf X X X X X X
dnf-plugins-core X X X
dnf5 X
dnf5-plugins X
dosfstools X X X X X X
e2fsprogs X X X X X X
edk2-ovmf X X X X X X
erofs-utils X X X X X
findutils X X X X X X
git X X X X X X
grep X X X X X X
jq X X X X X X
kmod X X X X X X
less X X X X X X
mtools X X X X X X
nano X X X X X X
openssh X X X X X X
openssl X X X X X X
sed X X X X X X
pacman X X X X
pesign X X X X X X
policycoreutils X X X X X
qemu X X X X X X
sbsigntools X X X X X
socat X X X X X X
squashfs-tools X X X X X X
strace X X X X X X
swtpm X X X X X X
systemd X X X X X X
ukify X X X X X
tar X X X X X X
ubuntu-keyring X X X X X
util-linux X X X X X X
virtiofsd X X X X
virt-firmware X X X
xfsprogs X X X X X X
xz X X X X X X
zstd X X X X X X
zypper X X X X
Setzt die für den Standard-Werkzeugbaum zu verwendende Distribution. Standardmäßig wird die gleiche Distribution wie für das zu bauende Abbild verwandt, außer für CentOS- und Ubuntu-Abbilder, bei denen Fedora bzw. Debian verwandt werden.
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.
Setzt den für den Standardbaum zu verwendenen Spiegel. Standardmäßig wird der Standardspiegel für die Werkzeugbaumdistribution verwandt.
Identisch zu Repositories=, aber für den Standardwerkzeugbaum.
Identisch zu PackageManagerTrees=, aber für den Standardwerkzeugbaum.
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.
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 unterhalb von /root/src in der Maschine eingehängt. Falls der zweite Pfad relativ ist, wird er relativ zu /root/src in der Maschine interpretiert. Für jedes eingehängte Verzeichnis wird die UID und GID des Benutzers, der Mkosi ausführt, auf den Benutzer root in der Maschine abgebildet. Dies bedeutet, dass alle Dateien und Verzeichnise so erscheinen, als ob sie root in der Maschine gehören würden und alle neuen Dateien und Verzeichnisse, die von root in der Maschine in diesen Verzeichnissen erstellt werden, gehören auf der Wirtmaschine dem Benutzer, der Mkosi ausführt. Beachten Sie, dass bei der Verwendung von mkosi qemu mit dieser Funktionalität Systemd v254 oder neuer im Abbild installiert sein muss.
Falls angegeben werden Plattenabbilder bis zu der angegebenen Größe aufgewachsen, bevor sie mit systemd-nspawn(1) oder Qemu 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.
Akzeptiert einen logischen Wert oder auto. Legt fest, ob ein zusätzlicher Arbeitsbereich unter /var/tmp eingehängt werden soll. Falls aktiviert, wird ein praktisch unbegrenzter Arbeitsbereich unter /var/tmp zur Verfügung gestellt, wenn das Abbild mit mkosi qemu, mkosi boot oder mkosi shell gestartet wird. Beachten Sie, dass bei der Verwendung von mkosi qemu mit dieser Funktionalität Systemd v254 oder neuer im Abbild installiert sein muss.
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 qemu und mkosi vmspawn. Beachten Sie, dass bei der Verwendung von interface Mkosi nicht automatisch die Schnittstelle des Wirtsystems konfiguriert. Es wird erwartet, dass auf dem Wirtsystem eine hinreichend neue Version von systemd-networkd(8) läuft, die automatische die Schnittstelle des Links auf dem Wirtsystem konfiguriert.
Pfad zu dem privaten X.509-Schlüssel im PEM-Format, der für die Verbindung zu einer mit mkosi qemu gestarteten virtuellen Maschine verwandt werden soll und die mittels des Befehls mkosi ssh aktivierten Option Ssh= gebaut wurde. Falls nicht konfiguriert und mkosi.key im aktuellen Arbeitsverzeichnis existiert, wird dies automatisch für diesen Zweck verwandt. Führen Sie mkosi genkey aus, um automatisch einen Schlüssel in mkosi.key zu erstellen.
Pfad zu dem X.509-Zertifikat im PEM-Format zur Beistellung als öffentlicher SSH-Schlüsel in durch mkosi qemu 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.

Kennzeichner

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

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

Unterstützte Distributionen

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

•
Fedora Linux
•
Debian
•
Ubuntu
•
Arch Linux
•
openSUSE
•
Mageia
•
CentOS
•
RHEL
•
RHEL UBI
•
OpenMandriva
•
Rocky Linux
•
Alma Linux
•
None (Dazu muss der Benutzer ein bereits gebautes Rootfs bereitstellen)

Theoretisch kann jede Distribution auf dem Wirtrechner zum Bau der Abbilder, die jede andere Distribution enthalten können, verwandt werden, solange die notwendigen Werkzeuge verfügbar sind. Insbesondere jede Distribution, die apt paketiert, kann zum Bau von Abbildern von Debian 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.

Nutzungsablauf

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

1.
CLI-Optionen auswerten
2.
Konfigurationsdateien auswerten
3.
Falls nicht als root ausgeführt wird, wird der Benutzernamensraum abgetrennt und der in /etc/subuid und /etc/subgid konfigurierte Subuid-Bereich darein abgebildet.
4.
Abtrennen des Einhängenamensraums
5.
Schreibgeschütztes Einhängen der folgenden Verzeichnisse, falls sie existieren:
•
/usr
•
/etc
•
/opt
•
/srv
•
/boot
•
/efi
•
/media
•
/mnt

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

1.
Kopieren der Paketverwalterbäume in den Arbeitsbereich
2.
Synchronisieren der Depot-Metadaten des Paketverwalters
3.
Kopieren der Basisbäume (--base-tree=) in das Abbild
4.
Wiederbenutzung eines zwischengespeicherten Abbilds, falls verfügbar
5.
Kopieren eines Schnappschusses der Depot-Metadaten des Paketverwalters in das Abbild
6.
Kopieren von Gerüstbäumen (mkosi.skeleton) in das Abbild
7.
Installieren der Distributioon und Paketen in das Abbild
8.
Ausführen der Vorbereitungsskripte auf dem Abbild mit dem Argument final (mkosi.prepare)
9.
Installieren der Baupakete in der Überlagerung, falls irgendwelche Bauskripte konfiguriert sind
10.
Ausführen der Vorbereitungsskripte auf der Überlagerung mit dem Argument build, falls irgendwelche Bauskripte konfiguriert sind (mkosi.prepare)
11.
Zwischenspeichern des Abbilds, falls konfiguriert (--incremental)
12.
Ausführen der Bauskripte auf dem Abbild & der Überlagerung, falls irgendwelche Bauskripte konfiguriert sind (mkosi.build)
13.
Finalisieren des Baus, falls das Ausgabeformat none konfiguriert ist
14.
Kopieren der Bauskripteausgabe in das Abbild
15.
Kopieren der zusätzlichen Bäume in das Abbild (mkosi.extra)
16.
Ausführen der Post-Install-Skripte (mkosi.postinst)
17.
Schreiben der für Ssh=, Autologin= und MakeInitrd= benötigten Konfigurationsdateien
18.
Installiert systemd-boot(7) und konfiguriert sicheren Systemstart, falls konfiguriert (--secure-boot)
19.
systemd-sysusers ausführen
20.
systemd-tmpfiles ausführen
21.
systemctl preset-all ausführen
22.
depmod ausführen
23.
systemd-firstboot ausführen
24.
systemd-hwdb ausführen
25.
Pakete und Dateien entfernen (RemovePackages=, RemoveFiles=)
26.
SELinux-Neumarkierung ausführen, falls eine SELinux-Richtlinie installiert ist
27.
Finalisierungskripte ausführen (mkosi.finalize)
28.
Vereinigtes Kernelabbild ausführen, falls so konfiguriert
29.
Finales Ausgabeformat erstellen

Skripte

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

•
Falls mkosi.sync (SyncScripts=) existiert, wird es vor dem Bau des Abbildes ausgeführt. Dieses Skript kann zur Aktualisierung verschiedener, während des Baus verwandter Quellen eingesetzt werden. Ein Anwendungsszenario ist die Ausführung von git pull in verschiedenen Quelldepots vor dem Bau des Abbildes. Insbesondere gilt die Einstellung BuildSourcesEphemeral= nicht für Synchronisationsskripte, was bedeutet, dass Synchronisationsskripte zur Aktualisierung von Bauquellen verwandt werden können, selbst wenn BuildSourcesEphemeral= aktiviert ist.
•
Falls mkosi.prepare (PrepareScripts=) existiert, wird es zuerst mit dem Argument final aufgerufen, direkt nachdem die Software-Pakete installiert sind. Es wird ein zweites Mal mit dem Befehlszeilenparameter build aufgerufen, direkt nachdem die Baupakete installiert sind und die Bauüberlagerung oberhalb des Wurzelverzeichnisses des Abbildes eingehängt ist. Dieses Skript hat Netzwerkzugang und kann zur Installation von Paketen aus weiteren Quellen neben dem Paketverwalter der Distribution verwandt werden (z.B.  pip(1), npm(1), …), nachdem alle Software-Pakete installiert wurden, aber bevor das Abbild zwischengespeichert wird (falls der inkrementelle Modus aktiviert wurde). Im Gegensatz zur einer Allzweckinstallation ist die Installtion von Paketen in das System (pip install, npm install -g) anstelle in $SRCDIR sicher, da das Bauabbild nur für ein einzelnes Projekt verwandt wird und leicht entsorgt und neugebaut werden kann, und es daher kein Risiko von in Konflikt stehenden Abhängigkeiten und kein Risiko der Verunreinigung des Wirtsystems gibt.
•
Falls mkosi.build (BuildScripts=) existiert, wird es ausgeführt, wenn die Bauüberlagerung oberhalb des Wurzelverzeichnisses des Abbildes eingehängt wurde. Bei der Ausführung der Bauskripte zeigt $DESTDIR auf ein Verzeichnis, in dem die Skripte alle erstellten Dateien ablegen sollen, die dann im Abbild landen sollen. Beachten Sie, dass die Bausysteme, die auf make(1)/automake/meson(1) basieren, im Allgemeinen $DESTDIR berücksichtigen und damit der Bau von source-Bäumen sehr natürlich von statten geht. Nach der Ausführung des Bauskripts wird der Inhalt von $DESTDIR in das Abbild kopiert.
•
Falls mkosi.postinst (PostInstallationScripts=) existiert, wird es nach der Installation der (optionalen) Bau- und Zusatzbäume ausgeführt. Dieses Skript kann zur Veränderung des Abbilds ohne jede Beschränkung verwandt werden, nachdem alle Softwarepakete und Bauquellen installiert wurden.
•
Falls mkosi.finalize (FinalizeScripts=) existiert, wird es als letzten Schritt der Vorbereitung des Abbildes ausgeführt.

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

Von Mkosi ausgeführte Skripte erhalten die folgenden Umgebungsvariablen:

•
$ARCHITECTURE enthält die Architekturen aus der Einstellung Architecture=. Falls Architecture= nicht gesetzt ist, wird es die native Architektur der Wirtmaschine erhalten. Siehe die Dokumentation von Architecture= für mögliche Werte dieser Variablen.
•
$DISTRIBUTION enthält die Distribution aus der Einstellung Distribution=.
•
$RELEASE enthält die Veröffentlichung aus der Einstellung Release=.
•
$PROFILE enthält das Profile aus der Einstellung Profile=.
•
$CACHED= wird auf 1 gesetzt, falls ein zwischengespeichertes Abbild verfügbar ist, ansonsten auf 0.
•
$CHROOT_SCRIPT enthält den Pfad zu dem laufenden Skript, relativ zum Wurzelverzeichnis des Abbildes. Der primäre Anwendungsfall für diese Variable ist in der Kombination mit dem Skript mkosi-chroot. Siehe die nachfolgende Beschreibung von mkosi-chroot für weitere Informationen.
•
$SRCDIR enthält den Pfad zu dem Verzeichnis, aus dem Mkosi heraus aufgerufen wurde, wobei alle konfigurierten Bauquellen oben auf eingehängt sind. $CHROOT_SRCDIR enthält den Wert, den $SRCDIR nach Aufruf von mkosi-chroot haben wird.
•
$BUILDDIR ist nur definiert, falls mkosi.builddir existiert und auf das zu verwendende Bauverzeichnis zeigt. Dies ist für alle Bausysteme, die Bauen außerhalb des Bau-Baums unterstützen, nützlich, um bereits gebaute Artefakte von einem vorherigen Durchlauf wiederzuverwenden. $CHROOT_BUILDDIR enthält den Wert, den $BUILDDIR nach Aufruf von mkosi-chroot haben wird.
•
$DESTDIR ist ein Verzeichnis, in das sämtliche installierte und durch ein Bauskript erstellte Software abgelegt werden kann. Diese Variable wird nur gesetzt, wenn ein Bauskript ausgeführt wird. $CHROOT_DESTDIR enthält den Wert, den $DESTDIR nach Aufruf von mkosi-chroot haben wird.
•
$OUTPUTDIR zeigt auf das Vorbereitungsverzeichnis, das zum Speichern der während des Baus erstellten Bauartefakte verwandt wird. $CHROOT_OUTPUTDIR enthält den Wert, den $OUTPUTDIR nach Aufruf von mkosi-chroot haben wird.
•
$PACKAGEDIR zeigt auf das Verzeichnis, das das lokale Paketdepot enthält. Bauskripte können weitere Pakete zum lokalen Depot hinzufügen, indem Sie Pakete nach $PACKAGEDIR schreiben.
•
$BUILDROOT ist das Wurzelverzeichnis des gebauten Abbilds, optional mit der Bauüberlagerung oben auf eingehängt, abhängig vom Skript, das ausgeführt wird.
•
$WITH_DOCS ist entweder 0 oder 1, abhängig davon, ob der Bau eines Abbildes mit oder ohne Dokumentation angefordert wurde (WithDocs=yes). Ein Bauskript sollte die Installation sämtlicher Paketdokumentation nach $DESTDIR unterdrücken, falls $WITH_DOCS auf 0 gesetzt ist.
•
$WITH_TESTS ist entweder 0 oder 1, abhängig davon, ob ein Bau mit oder ohne laufende Test-Suite angefordert wurde (WithTests=no). Ein Bauskript sollte die Ausführung jeder Einheiten- oder Integrationstests vermeiden, falls $WITH_TESTS auf 0 gesetzt ist.
•
$WITH_NETWORK ist entweder 0 oder 1, abhängig davon, ob ein Bau mit oder ohne Netzwerkanbindung ausgeführt wird (WithNetwork=no). Ein Bauskript sollte sämtliche Netzwerkkommunikation unterlassen, falls $WITH_NETWORK auf 0 gesetzt ist.
•
$SOURCE_DATE_EPOCH wird definiert falls erbeten (SourceDateEpoch=TIMESTAMP, Environment=SOURCE_DATE_EPOCH=TIMESTAMP oder die Umgebungsvariable auf dem Wirtsystem $SOURCE_DATE_EPOCH). Dies ist nützlich, um Bauten wiederholbar zu machen. Siehe SOURCE_DATE_EPOCH  zu weiteren Informationen.
•
$MKOSI_UID bzw. $MKOSI_GID sind die UID und GID des Benutzers, der Mkosi aufgerufen hat, möglicherweise in eine UID in dem Benutzernamensraum, in dem Mkosi ausgeführt wird, übersetzt. Diese können zusammen mit setpriv(1) verwandt werden, um Befehle als der Benutzer auszuführen, der Mkosi aufrief (z.B. setpriv --reuid=$MKOSI_UID --regid=$MKOSI_GID --clear-groups <Befehl>).
•
$MKOSI_CONFIG ist eine Datei, die eine JSON-Zusammenfassung der Einstellungen des aktuellen Abbildes enthält. Diese Datei kann innerhalb von Skripten ausgewertet werden, um Zugriff auf alle Einstellungen des aktuellen Abbildes zu erhalten.

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

Variable mkosi.sync mkosi.prepare mkosi.build mkosi.postinst mkosi.finalize
_
ARCHITECTURE X X X X X
DISTRIBUTION X X X X X
RELEASE X X X X X
PROFILE X X X X X
CACHED X
CHROOT_SCRIPT X X X X
SRCDIR X X X X X
CHROOT_SRCDIR X X X X
BUILDDIR X
CHROOT_BUILDDIR X
DESTDIR X
CHROOT_DESTDIR X
OUTPUTDIR X X X
CHROOT_OUTPUTDIR X X X
BUILDROOT X X X X
WITH_DOCS X X
WITH_TESTS X X
WITH_NETWORK X X
SOURCE_DATE_EPOCH X X X X
MKOSI_UID X X X X X
MKOSI_GID X X X X X
MKOSI_CONFIG X X X X X

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

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

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

mkosi-chroot ls …

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

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

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

•
mkosi-as-caller: Dieses Skript verwendet setpriv(1), um vom Benutzer root im Benutzernamensraum, der für verschiedene Bauschritte verwandt wird, zurück zum ursprünglichen Benutzer zu schalten, der Mkosi aufrief. Dies ist nützlich, wenn Bausschritte aufgerufen werden sollen, die nach $BUILDDIR schreiben werden und es gewünscht ist, dass die Dateien dem aufrufenden Benutzer gehören.

Beispielsweise könnte ein vollständiges Skript mkosi.build wie folgt aussehen:

set -ex
mkosi-as-caller meson setup "$BUILDDIR/build" "$SRCDIR"
mkosi-as-caller meson compile -C "$BUILDDIR/build"
meson install -C "$BUILDDIR/build" --no-rebuild
•
git(1) wird automatisch mit safe.directory=* aufgerufen, um Berechtigungsfehler bei der Ausführung als Benutzer root in einem Benutzernamensraum zu vermeiden.
•
Beim Aufruf außerhalb des Abbildes werden useradd(8) und groupadd(8) automatisch mit --root=$BUILDROOT aufgerufen.

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

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

Dateien

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

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

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

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

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

•
Die Nspawn-Einstellungsdatei mkosi.nspawn wird an den gleichen Ort wie die Ausgabeabbilddatei kopiert, falls sie existiert. Dies ist nützlich, da Nspawn nach Einstellungsdateien neben den von ihm gestarteten Abbildern nach zusätzlichen Container-Laufzeiteinstellungen sucht.
•
The mkosi.cache/ directory, if it exists, is automatically used as package download cache, in order to speed repeated runs of the tool.
•
The mkosi.builddir/ directory, if it exists, is automatically used as out-of-tree build directory, if the build commands in the mkosi.build scripts support it. Specifically, this directory will be mounted into the build container, and the $BUILDDIR environment variable will be set to it when the build scripts are invoked. A build script may then use this directory as build directory, for automake-style or ninja-style out-of-tree builds. This speeds up builds considerably, in particular when mkosi is used in incremental mode (-i): not only the image and build overlay, but also the build tree is reused between subsequent invocations. Note that if this directory does not exist the $BUILDDIR environment variable is not set, and it is up to the build scripts to decide whether to do in in-tree or an out-of-tree build, and which build directory to use.
•
The mkosi.rootpw file can be used to provide the password for the root user of the image. If the password is prefixed with hashed: it is treated as an already hashed root password. The password may optionally be followed by a newline character which is implicitly removed. The file must have an access mode of 0600 or less. If this file does not exist, the distribution’s default root password is set (which usually means access to the root user is blocked).
•
The mkosi.passphrase file provides the passphrase to use when LUKS encryption is selected. It should contain the passphrase literally, and not end in a newline character (i.e. in the same format as cryptsetup and /etc/crypttab expect the passphrase files). The file must have an access mode of 0600 or less.
•
The mkosi.crt and mkosi.key files contain an X.509 certificate and PEM private key to use when signing is required (UEFI SecureBoot, verity, ...).
•
The mkosi.output/ directory is used to store all build artifacts.
•
The mkosi.credentials/ directory is used as a source of extra credentials similar to the Credentials= option. For each file in the directory, the filename will be used as the credential name and the file contents become the credential value, or, if the file is executable, mkosi will execute the file and the command’s output to stdout will be used as the credential value. Output to stderr will be ignored. Credentials configured with Credentials= take precedence over files in mkosi.credentials.
•
The mkosi.repart/ directory is used as the source for systemd-repart partition definition files which are passed to systemd-repart when building a disk image. If it does not exist and the RepartDirectories= setting is not configured, mkosi will default to the following partition definition files:

00-esp.conf (if we’re building a bootable image):

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

05-bios.conf (if we’re building a BIOS bootable image):

[Partition]
# UUID of the grub BIOS boot partition which grubs needs on GPT to
# embed itself into.
Type=21686148-6449-6e6f-744e-656564454649
SizeMinBytes=1M
SizeMaxBytes=1M

10-root.conf:

[Partition]
Type=root
Format=<distribution-default-filesystem>
CopyFiles=/
Minimize=guess

Note that if either mkosi.repart/ is found or RepartDirectories= is used, we will not use any of the default partition definitions.

All these files are optional.

Note that the location of all these files may also be configured during invocation via command line switches, and as settings in mkosi.conf, in case the default settings are not acceptable for a project.

CACHING

mkosi supports three different caches for speeding up repetitive re-building of images. Specifically:

1.
The package cache of the distribution package manager may be cached between builds. This is configured with the --cache-dir= option or the mkosi.cache/ directory. This form of caching relies on the distribution’s package manager, and caches distribution packages (RPM, DEB, ...) after they are downloaded, but before they are unpacked.
2.
If the incremental build mode is enabled with --incremental, cached copies of the final image and build overlay are made immediately before the build sources are copied in (for the build overlay) or the artifacts generated by mkosi.build are copied in (in case of the final image). This form of caching allows bypassing the time-consuming package unpacking step of the distribution package managers, but is only effective if the list of packages to use remains stable, but the build sources and its scripts change regularly. Note that this cache requires manual flushing: whenever the package list is modified the cached images need to be explicitly removed before the next re-build, using the -f switch.
3.
Finally, between multiple builds the build artifact directory may be shared, using the mkosi.builddir/ directory. This directory allows build systems such as Meson to reuse already compiled sources from a previous built, thus speeding up the build process of a mkosi.build build script.

The package cache and incremental mode are unconditionally useful. The final cache only apply to uses of mkosi with a source tree and build script. When all three are enabled together turn-around times for complete image builds are minimal, as only changed source files need to be recompiled.

Bau mehrerer Abbilder

If the mkosi.images/ directory exists, mkosi will load individual image configurations from it and build each of them. Image configurations can be either directories containing mkosi configuration files or regular files with the .conf extension.

When image configurations are found in mkosi.images/, mkosi will build the configured images and all of their dependencies (or all of them if no images were explicitly configured using Images=). To add dependencies between images, the Dependencies= setting can be used.

When images are defined, mkosi will first read the global configuration (configuration outside of the mkosi.images/ directory), followed by the image specific configuration. This means that global configuration takes precedence over image specific configuration.

Images can refer to outputs of images they depend on. Specifically, for the following options, mkosi will only check whether the inputs exist just before building the image:

•
BaseTrees=
•
PackageManagerTrees=
•
SkeletonTrees=
•
ExtraTrees=
•
ToolsTree=
•
Initrds=

To refer to outputs of a image’s dependencies, simply configure any of these options with a relative path to the output to use in the output directory of the dependency. Or use the %O specifier to refer to the output directory.

A good example on how to build multiple images can be found in the systemd  repository.

UMGEBUNGSVARIABLEN

•
$MKOSI_LESS overrides options for less when it is invoked by mkosi to page output.
•
$MKOSI_DNF can be used to override the executable used as dnf. This is particularly useful to select between dnf and dnf5.

BEISPIELE

Create and run a raw GPT image with ext4, as image.raw:

# mkosi -p systemd --incremental boot

Create and run a bootable GPT image, as foobar.raw:

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

Create and run a Fedora Linux image in a plain directory:

# mkosi --distribution fedora --format directory boot

Create a compressed image image.raw.xz with SSH installed and add a checksum file:

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

Inside the source directory of an automake-based project, configure mkosi so that simply invoking mkosi without any parameters builds an OS image containing a built version of the project in its current state:

$ cat >mkosi.conf <<EOF
[Distribution]
Distribution=fedora
[Output]
Format=disk
[Content]
Packages=kernel,systemd,systemd-udev,openssh-clients,httpd
BuildPackages=make,gcc,libcurl-devel
EOF
$ cat >mkosi.build <<EOF
#!/bin/sh
if [ "$container" != "mkosi" ]; then


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

Different ways to boot with qemu

The easiest way to boot a virtual machine is to build an image with the required components and let mkosi call qemu with all the right options:

$ mkosi -d fedora \


    --autologin \


    -p systemd-udev,systemd-boot,kernel-core \


    build
$ mkosi -d fedora qemu
…
fedora login: root (automatic login)
[root@fedora ~]#

The default is to boot with a text console only. In this mode, messages from the boot loader, the kernel, and systemd, and later the getty login prompt and shell all use the same terminal. It is possible to switch between the qemu console and monitor by pressing Ctrl-a c. The qemu monitor may for example be used to inject special keys or shut down the machine quickly.

To boot with a graphical window, add --qemu-qui:

$ mkosi -d fedora --qemu-gui qemu

A kernel may be booted directly with mkosi qemu -kernel ... -initrd ... -append '...'. This is a bit faster because no boot loader is used, and it is also easier to experiment with different kernels and kernel commandlines. Note that despite the name, qemu’s -append option replaces the default kernel commandline embedded in the kernel and any previous -append specifications.

The UKI is also copied into the output directory and may be booted directly:

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

When booting using an external kernel, we don’t need the kernel in the image, but we would still want the kernel modules to be installed.

It is also possible to do a direct kernel boot into a boot loader, taking advantage of the fact that systemd-boot(7) is a valid UEFI binary:

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

In this scenario, the kernel is loaded from the ESP in the image by systemd-boot.

REQUIREMENTS

mkosi is packaged for various distributions: Debian, Ubuntu, Arch Linux, Fedora Linux, OpenMandriva, Gentoo. Note that it has been a while since the last release and the packages shipped by distributions are very out of date. We currently recommend running mkosi from git until a new release happens.

mkosi currently requires systemd 254 to build bootable disk images.

When not using distribution packages make sure to install the necessary dependencies. For example, on Fedora Linux you need:

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

On Debian/Ubuntu it might be necessary to install the ubuntu-keyring, ubuntu-archive-keyring and/or debian-archive-keyring packages explicitly, in addition to apt, depending on what kind of distribution images you want to build.

Note that the minimum required Python version is 3.9.

Frequently Asked Questions (FAQ)

•
Why does mkosi qemu with KVM not work on Debian/Ubuntu?

While other distributions are OK with allowing access to /dev/kvm, on Debian/Ubuntu this is only allowed for users in the kvm group. Because mkosi unshares a user namespace when running unprivileged, even if the calling user was in the kvm group, when mkosi unshares the user namespace to run unprivileged, it loses access to the kvm group and by the time we start qemu we don’t have access to /dev/kvm anymore. As a workaround, you can change the permissions of the device nodes to 0666 which is sufficient to make KVM work unprivileged. To persist these settings across reboots, copy /usr/lib/tmpfiles.d/static-nodes-permissions.conf to /etc/tmpfiles.d/static-nodes-permissions.conf and change the mode of /dev/kvm from 0660 to 0666.

•
How do I add a regular user to an image?

You can use the following snippet in a post-installation script:

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

Note that from systemd v256 onwards, if enabled, systemd-homed-firstboot.service will prompt to create a regular user on first boot if there are no regular users.

REFERENCES

•

Primary mkosi git repository on GitHub

•

mkosi — A Tool for Generating OS Images  introductory blog post by Lennart Poettering

•

The mkosi OS generation tool  story on LWN

SIEHE AUCH

systemd-nspawn(1), dnf(8)

ÜBERSETZUNG

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

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

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer.