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-Einstellungen…]

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

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…] dependencies

mkosi [Optionen…] help

BESCHREIBUNG

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

Unterbefehle

Die folgenden Unterbefehle werden erkannt:

summary
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.
build
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.
shell
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.
boot
Ä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.
qemu
Ähnlich wie boot, verwendet aber den konfigurierten Monitor für virtuelle Maschinen (standardmäßig qemu) um das Abbild zu starten, d.h. anstelle einer Container-Virtualisierung wird eine Virtualisierung einer virtuellen Maschine verwandt. Wie zusätzliche Befehlszeilenargumente interpretiert werden hängt von dem konfigurierten Monitor für virtuelle Maschinen ab. Siehe VirtualMachineMonitor= für weitere Informationen.
ssh
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.

The Machine= option can be used to give the machine a custom hostname when booting it which can later be used to ssh into the image (e.g. mkosi --machine=mymachine qemu followed by mkosi --machine=mymachine ssh).

journalctl
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.

If ForwardJournal= is specified, this verb will operate on the forwarded journal instead of the journal inside the image.

coredumpctl
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.

If ForwardJournal= is specified, this verb will operate on the forwarded journal instead of the image. Note that this requires configuring systemd-coredump to store coredumps in the journal.

clean
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.
serve
Dies baut das Abbild, falls es noch nicht gebaut wurde und liefert dann das Ausgabeverzeichnis (d.h. normalerweise mkosi.output/, s.u.) über einen kleinen eingebauten HTTP-Server, der auf Port 8081 auf Anfragen wartet, aus. Kombinieren Sie dies mit -f, um das Abbild bedingungslos neuzubauen, bevor es ausgeliefert wird. Dieser Befehl ist für das Testen netzwerkbasierten Erwerbens von Betriebssystemabbildern nützlich, beispielsweise mittels machinectl pull-raw … und machinectl pull-tar ….
burn <Gerät>
Dies baut das Abbild, falls es noch nicht gebaut wurde und schreibt es dann auf das angegebene Blockgerät. Die Partitionsinhalte werden unverändert geschrieben, aber die GPT-Partitionstabelle wird korrigiert, so dass sie auf die Sektor- und Blockgrößen des angegebenen Mediums passt.
bump
Erhöht die Version des Abbildes aus mkosi.version und schreibt die resultierende Versionszeichenkette nach mkosi.version. Dies ist zur Implementierung eines einfachen Versionierungsschematas nützlich: jedes Mal, wenn dieser Unterbefehl aufgerufen wird, wird die Version als Vorbereitung für den nächsten Bau erhöht. Beachten Sie, dass --auto-bump/-B zum automatischen Erhöhen der Version nach jedem erfolgreichen Bau verwandt werden kann.
genkey
Erstellt ein Paar von SecureBoot-Schlüsseln zur Verwendung mit den Optionen SecureBootKey=/--secure-boot-key= und SecureBootCertificate=/--secure-boot-certificate=.
documentation
Zeigt die Dokumentation von mkosi 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.
dependencies
Gibt die Liste der von Mkosi zum Bauen und Starten von Abbildern benötigten Pakete aus.

Diese Liste kann direkt an einen Paketeverwalter weitergeleitet werden, um die Pakete zu installieren. Falls beispielsweise das Wirtsystem den dnf(8)-Paketverwalter verwendet, könnten die Pakete wie folgt installiert werden:

mkosi dependencies | xargs -d '\n' dnf install
    
help
Dieser Unterbefehl ist identisch zum nachfolgend dokumentierten Schalter --help: Er zeigt eine kurze Erklärung zur Verwendung.

Reine Befehlszeilenoptionen

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

--force, -f
Ersetzt beim Bau eines Abbildes die Ausgabedatei, falls sie bereits existiert. Standardmäßig verweigert mkosi eine Aktion, wenn ein Abbild 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.
--directory=, -C
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.
--debug=
Aktiviert zusätzliche Fehlersuchausgabe.
--debug-shell
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.
--debug-workspace=
Falls ein Fehler auftritt, wird das Arbeitsbereichsverzeichnis nicht gelöscht.
--version
Zeigt die Paketversion.
--help, -h
Zeigt einen kurzen Hinweis zum Aufruf.
--genkey-common-name=
Allgemeiner Name, der bei der Erzeugung von Schlüsseln mittels des Befehls genkey von Mkosi verwandt wird. Standardmäßig mkosi of %u, wobei %u auf den Benutzernamen des Benutzer, der Mkosi aufruft, erweitert wird.
--genkey-valid-days=
Anzahl an Tagen, die Schlüssel gültig bleiben sollen, wenn Schlüssel mit dem Befehl genkey von Mkosi erstellt werden. Standardmäßig zwei Jahre (730 Tage).
--auto-bump=, -B
Falls angegeben wird 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.
--doc-format
Das Format, in dem die Dokumentation angezeigt werden soll. Unterstützt die Werte markdown, man, pandoc, system und auto. Im Falle von markdown wird die Dokumentation im usrpünglichen Markdown-Format angezeigt. man zeigt die Dokumentation im Handbuchseitenformat, falls dies verfügbar ist. pandoc erstellt das Handbuchseitenformat dynamisch, falls pandoc(1) verfügbar ist. system zeigt die systemweite Handbuchseite für mkosi, die nicht zwingend der Version entspricht, die Sie verwenden, abhängig davon, wie mkosi installiert wurde. auto (die Vorgabe) wird alle Methoden in der Reihenfolge man, pandoc, markdown, system ausprobieren.
--json
Zeigt die zusammenfassende Ausgabe als JSON-SEQ.

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.
If a profile is defined, its configuration is parsed from the mkosi.profiles/ directory.
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.
Subimages are parsed from the mkosi.images directory if it exists.

Note that settings configured via the command line always override settings configured via configuration files. If the same setting is configured more than once via configuration files, later assignments override earlier assignments except for settings that take a collection of values. Also, settings read from mkosi.local.conf will override settings from configuration files that are parsed later but not settings specified on the CLI.

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

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

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

The [Match] section of a mkosi.conf file in a directory applies to the entire directory. If the conditions are not satisfied, the entire directory is skipped. The [Match] sections of files in mkosi.conf.d/ and mkosi.local.conf only apply to the file itself.

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
    

The [TriggerMatch] section can be used to indicate triggering match sections. These are identical to triggering conditions except they apply to the entire match section instead of just a single condition. As an example, the following will match if the distribution is debian and the release is bookworm or if the distribution is ubuntu and the release is focal.

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

The semantics of conditions in [TriggerMatch] sections is the same as in [Match], i.e. all normal conditions are joined by a logical AND and all triggering conditions are joined by a logical OR. When mixing [Match] and [TriggerMatch] sections, a match is achieved when all [Match] sections match and at least one [TriggerMatch] section matches. No match sections are valued as true. Logically this means:

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

Command line options that take no argument are shown without = in their long version. In the config files, they should be specified with a boolean argument: either 1, yes, or true to enable, or 0, no, false to disable.

Abschnitt [Distribution]

Distribution=, --distribution=, -d
The distribution to install in the image. Takes one of the following arguments: fedora, debian, ubuntu, arch, opensuse, mageia, centos, rhel, rhel-ubi, openmandriva, rocky, alma, custom. If not specified, defaults to the distribution of the host or custom if the distribution of the host is not a supported distribution.
Release=, --release=, -r
The release of the distribution to install in the image. The precise syntax of the argument this takes depends on the distribution used, and is either a numeric string (in case of Fedora Linux, CentOS, ..., e.g. 29), or a distribution version name (in case of Debian, Ubuntu, ..., e.g. artful). Defaults to a recent version of the chosen distribution, or the version of the distribution running on the host if it matches the configured distribution.
Architecture=, --architecture=
Die Architektur für die das Abbild gebaut wird. Die tatsächlich unterstützten Architekturen hängen von der verwandten Distribution ab und ob ein 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.

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

Die Standard-Spiegel fürjede Distribution sind 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
LocalMirror=, --local-mirror=
The mirror will be used as a local, plain and direct mirror instead of using it as a prefix for the full set of repositories normally supported by distributions. Useful for fully offline builds with a single repository. Supported on deb/rpm/arch based distributions. Overrides --mirror= but only for the local mkosi build, it will not be configured inside the final image, --mirror= (or the default repository) will be configured inside the final image instead.
RepositoryKeyCheck=, --repository-key-check=
Controls signature/key checks when using repositories, enabled by default. Useful to disable checks when combined with --local-mirror= and using only a repository from a local filesystem. Not used for DNF-based distros yet.
Repositories=, --repositories=
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.
CacheOnly=, --cache-only=
Akzeptiert entweder auto, metadata, always oder never. Standardmäßig auto. Falls always, wird der Paketverwalter angewiesen, das Netzwerk nicht zu kontaktieren. Dies stellt eine minimale Reproduzierbarkeitsstufe bereit, solang der Paketzwischenspeicher bereits vollständig gefüllt ist. Falls auf metadata gesetzt kann der Paketverwalter weiterhin Pakete herunterladen, aber nicht die Metadaten des Depots synchronisieren. Falls auf auto gesetzt werden während des Baus die Metadaten des Depots synchronisiert, außer es liegt ein zwischengespeichertes Abbild vor (siehe Incremental= und Pakete können heruntergeladen werden. Falls auf never gesetzt, werden während des Baus die Metadaten des Depots immer synchronisiert und Pakete können heruntergeladen werden.
PackageManagerTrees=, --package-manager-tree=
Akzeptiert eine Kommata-getrennte Liste von Doppelpunkt-getrennten Pfadpaaren. Der erste Pfad jedes Paares bezieht sich auf ein Verzeichnis, das vor Aufruf des Paketverwalters in den Betriebssystembaum kopiert werden soll. Diese Option ist ähnlich der Option SkeletonTrees=, installiert aber die Dateien in ein Unterverzeichnis des Arbeitsbereichsverzeichnisses statt in den Betriebssystembaum. Dieses Unterverzeichnis des Arbeitsbereichs wird zur Konfiguration des Paketverwalters verwandt. Falls das Verzeichnis mkosi.pkgmngr// in dem lokalen Verzeichnis gefunden wird, wird es für diesen Zweck mit dem Wurzelverzeichnis als Ziel verwandt (siehe auch den nachfolgenden Abschnitt Dateien). Falls überhaupt nicht konfiguriert, wird dieser Wert als Vorgabe den gleichen Wert wie SkeletonTrees= enthalten.

mkosi will look for the package manager configuration and related files in the configured package manager trees. Unless specified otherwise, it will use the configuration files from their canonical locations in /usr or /etc in the package manager trees. For example, it will look for etc/dnf/dnf.conf in the package manager trees if dnf is used to install packages.

SkeletonTrees= and PackageManagerTrees= fulfill similar roles. Use SkeletonTrees= if you want the files to be present in the final image. Use PackageManagerTrees= if you don’t want the files to be present in the final image, e.g. when building an initrd or if you want to refer to paths outside of the image in your repository configuration.

Abschnitt [Output]

Format=, --format=, -t
Das zu erstellende Abbild-Format. Entweder directory (zur direkten Erstellung eines Betriebssystemabbildes im lokalen Verzeichnis), tar (ähnlich, es wird aber ein Tarball des Betriebssystemabbildes erstellt), cpio (ähnlich, es wird aber ein Cpio-Archiv erstellt), disk (ein Blockgerät-Betriebssystemabbild mit einer GPT-Partitionstabelle), uki (ein vereinigtes Kernel-Abbild mit einem Betriebssystemabbild im PE-Abschnitt .initrd), esp (uki aber in einem Platten-Abbild mit nur einer ESP-Partition eingehüllt), oci (ein mit der OCI-Abbildspezifikation kompatibles Verzeichnis, 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.

If the none output format is used, the outputs from a previous build are not removed, but clean scripts (see CleanScripts=) are still executed. This allows rerunning a build script (see BuildScripts=) without removing the results of a previous build.

ManifestFormat=, --manifest-format=
The manifest format type or types to generate. A comma-delimited list consisting of json (the standard JSON output format that describes the packages installed), changelog (a human-readable text format designed for diffing). By default no manifest is generated.
Output=, --output=, -o
Für die erstellte Ausgabedatei oder das Ausgabeverzeichnis zu verwendender Name. Standardmäßig image oder, falls ImageId= verwandt wird, wird dieser als standardmäßiger Ausgabename verwandt, optional wird die mit ImageVersion= angegebene Version angehängt oder der Name des Abbildes wird gegenüber ImageId bevorzugt, falls ein bestimmtes Abbild aus mkosi.images gebaut wird. Beachten Sie, dass diese Option nicht die Konfiguration des Ausgabeverzeichnisses ermöglicht, verwenden Sie dafür OutputDirectory=.

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.

CompressOutput=, --compress-output=
Konfiguriert die Komprimierung für das resultierende Abbild oder Archiv. Das Argument kann entweder ein logischer Wert oder ein Komprimierungsalgorithmus (xz(1), zstd(1)) sein. Standardmäßig wird die Komprimierung zstd(1) sein, außer bei CentOS und abgeleiteten Distributionen bis Version 8, wo die Vorgabe xz(1) ist und OCI-Abbildern, bei denen die Vorgabe gzip(1) ist. Beachten Sie, dass das Abbild nicht direkt gestartet werden kann, wenn Komprimierung auf Plattenabbildtypen angewendet wird, sondern erst eine Dekomprimierung erfolgen muss. Das bedeutet auch, dass die Unterbefehle shell, boot, qemu bei der Verwendung dieser Option nicht verfügbar sind. Impliziert für tar, cpio, uki, esp und oci.
CompressLevel=, --compress-level=
Konfiguriert die zu verwendende Komprimierungsstufe. Akzeptiert eine Ganzzahl. Die möglichen Werte hängen von der verwandten Komprimierung ab.
OutputDirectory=, --output-dir=, -O
Path to a directory where to place all generated artifacts. If this is not specified and the directory mkosi.output/ exists in the local directory, it is automatically used for this purpose.
WorkspaceDirectory=, --workspace-dir=
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).

CacheDirectory=, --cache-dir=
Takes a path to a directory to use as the incremental cache directory for the incremental images produced when the Incremental= option is enabled. If this option is not used, but a mkosi.cache/ directory is found in the local directory it is automatically used for this purpose.
PackageCacheDirectory=, --package-cache-dir
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.
BuildDirectory=, --build-dir=
Takes a path to a directory to use as the build directory for build systems that support out-of-tree builds (such as Meson). The directory used this way is shared between repeated builds, and allows the build system to reuse artifacts (such as object files, executable, ...) generated on previous invocations. The build scripts can find the path to this directory in the $BUILDDIR environment variable. This directory is mounted into the image’s root directory when mkosi-chroot is invoked during execution of the build scripts. If this option is not specified, but a directory mkosi.builddir/ exists in the local directory it is automatically used for this purpose (also see the Files section below).
ImageVersion=, --image-version=
Konfiguriert die Abbild-Version. Dies akzeptiert jede Zeichenkette, es wird aber empfohlen, eine Reihe von durch Punkten getrennte Komponenten festzulegen. Die Version kann auch 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=).
ImageId=, --image-id=
Configure the image identifier. This accepts a freeform string that shall be used to identify the image with. If set the default output file will be named after it (possibly suffixed with the version). The identifier is also passed via the $IMAGE_ID to any build scripts invoked. The image ID is automatically added to /usr/lib/os-release.
SplitArtifacts=, --split-artifacts
If specified and building a disk image, pass --split=yes to systemd-repart to have it write out split partition files for each configured partition. Read the man (https://www.freedesktop.org/software/systemd/man/systemd-repart.html#--split=BOOL) page for more information. This is useful in A/B update scenarios where an existing disk image shall be augmented with a new version of a root or /usr partition along with its Verity partition and unified kernel.
RepartDirectories=, --repart-dir=
Paths to directories containing systemd-repart partition definition files that are used when mkosi invokes systemd-repart when building a disk image. If mkosi.repart/ exists in the local directory, it will be used for this purpose as well. Note that mkosi invokes repart with --root= set to the root of the image root, so any CopyFiles= source paths in partition definition files will be relative to the image root directory.
SectorSize=, --sector-size=
Setzt die Standardsektorgröße, die systemd-repart(8) zum Bau eines Plattenabilds benutzt, außer Kraft.
RepartOffline=, --repart-offline=
Legt fest, ob Plattenabbilder mittels Loopback-Geräten gebaut werden. Standardmäßig aktiviert. Wenn aktiviert, wird systemd-repart(8) keine Loopback-Geräte zum Bau von Plattenabbildern verwenden. Wenn deaktiviert, wird systemd-repart(8) immer Loopback-Geräte zum Bau von Plattenabbildern verwenden.

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.

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

Diese Option kann dazu verwandt werden, Systemerweiterungen oder portable Dienste (https://uapi-group.org/specifications/specs/extension_image) von systemd(8) zu erstellen.

UseSubvolumes=, --use-subvolumes=
Takes a boolean or auto. Enables or disables use of btrfs subvolumes for directory tree outputs. If enabled, mkosi will create the root directory as a btrfs subvolume and use btrfs subvolume snapshots where possible to copy base or cached trees which is much faster than doing a recursive copy. If explicitly enabled and btrfs is not installed or subvolumes cannot be created, an error is raised. If auto, missing btrfs or failures to create subvolumes are ignored.
Seed=, --seed=
Takes a UUID as argument or the special value random. Overrides the seed that systemd-repart(8) (https://www.freedesktop.org/software/systemd/man/systemd-repart.service.html) uses when building a disk image. This is useful to achieve reproducible builds, where deterministic UUIDs and other partition metadata should be derived on each build.
SourceDateEpoch=, --source-date-epoch=
Akzeptiert einen Zeitstempel in Sekunden seit dem UNIX-Epoch als Argument. Dateiveränderungszeiten aller Dateien werden auf diesen Wert festgestellt. 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 (https://reproducible-builds.org/specs/source-date-epoch/) für weitere Informationen.
CleanScripts=, --clean-script=
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als Bereinigungsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt Skripte für weitere Informationen.

Abschnitt [Content]

Packages=, --package=, -p
Install the specified distribution packages (i.e. RPM, DEB, ...) in the image. Takes a comma separated list of package specifications. This option may be used multiple times in which case the specified package lists are combined. Use BuildPackages= to specify packages that shall only be installed in an overlay that is mounted when the prepare scripts are executed with the build argument and when the build scripts are executed.

The types and syntax of package specifications that are allowed depend on the package installer (e.g. dnf for rpm-based distros or apt for deb-based distros), but may include package names, package names with version and/or architecture, package name globs, package groups, and virtual provides, including file paths.

See PackageDirectories= for information on how to make local packages available for installation with Packages=.

Example: when using a distro that uses dnf, the following configuration would install the meson package (in the latest version), the 32-bit version of the libfdisk-devel package, all available packages that start with the git- prefix, a systemd rpm from the local file system, one of the packages that provides /usr/bin/ld, the packages in the Development Tools group, and the package that contains the mypy python module.

Packages=meson

libfdisk-devel.i686
git-*
/usr/bin/ld
@development-tools
python3dist(mypy)
BuildPackages=, --build-package=
Similar to Packages=, but configures packages to install only in an overlay that is made available on top of the image to the prepare scripts when executed with the build argument and the build scripts. This option should be used to list packages containing header files, compilers, build systems, linkers and other build tools the mkosi.build scripts require to operate. Note that packages listed here will be absent in the final image.
VolatilePackages=, --volatile-package=
Similar to Packages=, but packages configured with this setting are not cached when Incremental= is enabled and are installed after executing any build scripts.

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

PackageDirectories=, --package-directory=
Legt Verzeichnisse fest, die zusätzliche Pakete enthalten, die während des Baus verfügbar gemacht werden sollen. mkosi wird ein lokales Depot mit allen Paketen aus diesen Verzeichnissen erstellen und es beim Installieren von Paketen oder Ausführen von Skripten verfügbar machen. Falls das Verzeichnis mkosi.packages/ in dem lokalen Verzeichnis gefunden wird, wird es auf für diesen Zweck verwandt.
VolatilePackageDirectories=, --volatile-package-directory=
Like PackageDirectories=, but any changes to the packages in these directories will not invalidate the cached images if Incremental= is enabled.

Additionally, build scripts can add more packages to the local repository by placing the built packages in $PACKAGEDIR. The packages placed in $PACKAGEDIR are shared between all image builds and thus available for installation in all images using VolatilePackages=.

WithRecommends=, --with-recommends=
Konfiguriert, ob empfohlene Pakete oder schwache Abhängigkeiten installiert werden, abhängig davon, wie sie vom verwandten Paketverwalter benannt werden. Standardmäßig werden empfohlene Pakete nicht installiert. Dies wird nur von Paketverwaltern unterstützt, die dieses Konzept unterstützen. Derzeit sind dies apt(8), dnf(8) und zypper(8).
WithDocs=, --with-docs
Include documentation in the image. Enabled by default. When disabled, if the underlying distribution package manager supports it documentation is not included in the image. The $WITH_DOCS environment variable passed to the mkosi.build scripts is set to 0 or 1 depending on whether this option is enabled or disabled.
BaseTrees=, --base-tree=
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.

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

Note that skeleton trees are cached and any changes to skeleton trees after a cached image has been built (when using Incremental=) are only applied when the cached image is rebuilt (by using -ff or running mkosi -f clean).

As with the base tree logic above, instead of a directory, a tar file may be provided too. mkosi.skeleton.tar will be automatically used if found in the local directory.

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

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.

RemovePackages=, --remove-package=
Takes a comma-separated list of package specifications for removal, in the same format as Packages=. The removal will be performed as one of the last steps. This step is skipped if CleanPackageMetadata=no is used.
RemoveFiles=, --remove-files=
Akzeptiert eine Kommata-getrennte Liste von Globs. Dateien im Abbild, die auf die Globs passen, werden am Ende vollständig entfernt.
CleanPackageMetadata=, --clean-package-metadata=
Enable/disable removal of package manager databases and repository metadata at the end of installation. Can be specified as true, false, or auto (the default). With auto, package manager databases and repository metadata will be removed if the respective package manager executable is not present at the end of the installation.
SyncScripts=, --sync-script=
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als Synchronisationsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt Skripte für weitere Informationen.
PrepareScripts=, --prepare-script=
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als Vorbereitungsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt Skripte für weitere Informationen.
BuildScripts=, --build-script=
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als Bauskripte für dieses Abbild verwandt werden. Siehe den Abschnitt Skripte für weitere Informationen.
PostInstallationScripts=, --postinst-script=
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als Post-Installationsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt Skripte für weitere Informationen.
FinalizeScripts=, --finalize-script=
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als Finalisierungsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt Skripte für weitere Informationen.
PostOutputScripts=, --postoutput-script
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als Post-Ausgabeskripte für dieses Abbild verwandt werden. Siehe den Abschnitt Skripte für weitere Informationen.
BuildSources=, --build-sources=
Takes a comma separated list of colon separated path pairs. The first path of each pair refers to a directory to mount from the host. The second path of each pair refers to the directory where the source directory should be mounted when running scripts. Every target path is prefixed with /work/src and all build sources are sorted lexicographically by their target before mounting, so that top level paths are mounted first. If not configured explicitly, the current working directory is mounted to /work/src.
BuildSourcesEphemeral=, --build-sources-ephemeral=
Akzeptiert einen logischen Wert. Standardmäßig deaktiviert. Konfiguriert, ob Änderungen an Quellverzeichnissen (dem Arbeitsverzeichnis und dem mit BuildSources= konfigurierten) dauerhaft sind. Falls aktiviert, werden nach der Ausführung aller Skripte eines bestimmten Typs (außer Synchronisationsskripte) alle Quellverzeichnisse auf ihren Originalzustand zurückgesetzt.
Environment=, --environment=
Adds variables to the environment that package managers and the prepare/build/postinstall/finalize scripts are executed with. Takes a space-separated list of variable assignments or just variable names. In the latter case, the values of those variables will be passed through from the environment in which mkosi was invoked. This option may be specified more than once, in which case all listed variables will be set. If the same variable is set twice, the later setting overrides the earlier one.
EnvironmentFiles=, --env-file=
Takes a comma-separated list of paths to files that contain environment variable definitions to be added to the scripting environment. Uses mkosi.env if it is found in the local directory. The variables are first read from mkosi.env if it exists, then from the given list of files and then from the Environment= settings.
WithTests=, --without-tests, -T
If set to false (or when the command-line option is used), the $WITH_TESTS environment variable is set to 0 when the mkosi.build scripts are invoked. This is supposed to be used by the build scripts to bypass any unit or integration tests that are normally run during the source build process. Note that this option has no effect unless the mkosi.build build scripts honor it.
WithNetwork=, --with-network=
When true, enables network connectivity while the build scripts mkosi.build are invoked. By default, the build scripts run with networking turned off. The $WITH_NETWORK environment variable is passed to the mkosi.build build scripts indicating whether the build is done with or without network.
Bootable=, --bootable=
Takes a boolean or auto. Enables or disables generation of a bootable image. If enabled, mkosi will install an EFI bootloader, and add an ESP partition when the disk image output is used. If the selected EFI bootloader (See Bootloader=) is not installed or no kernel images can be found, the build will fail. auto behaves as if the option was enabled, but the build won’t fail if either no kernel images or the selected EFI bootloader can’t be found. If disabled, no bootloader will be installed even if found inside the image, no unified kernel images will be generated and no ESP partition will be added to the image if the disk output format is used.
Bootloader=, --bootloader=
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.

BiosBootloader=, --bios-bootloader=
Akzeptiert entweder none oder grub. Standardmäßig none. Falls auf none gesetzt, wird kein BIOS-Systemstartprogramm installiert. Falls auf grub gesetzt, wird Grub als BIOS-Systemstartprogramm installiert, falls ein 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.

ShimBootloader=, --shim-bootloader=
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.

UnifiedKernelImages=, --unified-kernel-images=
Specifies whether to use unified kernel images or not when Bootloader= is set to systemd-boot or grub. Takes a boolean value or auto. Defaults to auto. If enabled, unified kernel images are always used and the build will fail if any components required to build unified kernel images are missing. If set to auto, unified kernel images will be used if all necessary components are available. Otherwise Type 1 entries as defined by the Boot Loader Specification will be used instead. If disabled, Type 1 entries will always be used.
UnifiedKernelImageFormat=, --unified-kernel-image-format=
Takes a filename without any path components to specify the format that unified kernel images should be installed as. This may include both the regular specifiers (see Specifiers) and special delayed specifiers, that are expanded during the installation of the files, which are described below. The default format for this parameter is &e-&k with -&h being appended if roothash= or usrhash= is found on the kernel command line and +&c if /etc/kernel/tries is found in the image.

Die folgenden Kennzeichner können außerdem verwendet werden:

Kennzeichner Wert
&& & character
&e Zugangsmerkmal
&k Kernelversion
&h roothash= or usrhash= value of kernel argument
&c Anzahl der Versuche, die für den Zähler für Systemstarts verwandt werden
Initrds=, --initrd
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 nach Initrds in einem Unterverzeichnis io.mkosi.initrd des Artefakt-Verzeichnisses nach Initrds suchen (siehe $ARTIFACTDIR in dem Abschnitt UMGEBUNGSVARIABLEN). Falls dort keine gefunden werden, wird Mkosi automatisch eine Standard-Initrd bauen.
InitrdPackages=, --initrd-package=
Extra-Pakete, die in die Standard-Initrd installiert werden sollen. Akzeptiert eine Kommata-getrennte Liste von Paketspezifikationen. Diese Option kann mehrfach angewendet werden. Dann werden die aufgeführten Paketlisten kombiniert.
InitrdVolatilePackages=, --initrd-volatile-package=
Similar to VolatilePackages=, except it applies to the default initrd.
MicrocodeHost=, --microcode-host=
Wenn auf wahr gesetzt, wird nur der Mikrocode für die CPU des Wirtsystems in dem Abbild aufgenommen.
KernelCommandLine=, --kernel-command-line=
Use the specified kernel command line when building images.

If the value of this setting contains the literals root=PARTUUID or mount.usr=PARTUUID, these are replaced with the partition UUID of the root or usr partition respectively. For example, root=PARTUUID would be replaced with root=PARTUUID=58c7d0b2-d224-4834-a16f-e036322e88f7 where 58c7d0b2-d224-4834-a16f-e036322e88f7 is the partition UUID of the root partition.

KernelModulesInclude=, --kernel-modules-include=
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.

If the special value default is used, the default kernel modules defined in the mkosi-initrd configuration are included as well.

If the special value host is used, the currently loaded modules on the host system are included as well.

Diese Einstellung hat gegenüber KernelModulesExclude= Vorrang und ergibt nur in Kombination mit ihr Sinn, da standardmäßig alle Kernelmdoule im Abbild aufgenommen werden.

KernelModulesExclude=, --kernel-modules-exclude=
Takes a list of regex patterns that specify modules to exclude from the image. Behaves the same as KernelModulesInclude= except that all modules that match any of the specified patterns are excluded from the image.
KernelModulesInitrd=, --kernel-modules-initrd=
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.
KernelModulesInitrdInclude=, --kernel-modules-initrd-include=
Like KernelModulesInclude=, but applies to the kernel modules included in the kernel modules initrd.
KernelModulesInitrdExclude=, --kernel-modules-initrd-exclude=
Like KernelModulesExclude=, but applies to the kernel modules included in the kernel modules initrd.
Locale=, --locale=, LocaleMessages=, --locale-messages=, Keymap=, --keymap=, Timezone=, --timezone=, Hostname=, --hostname=, RootShell=, --root-shell=
The settings Locale=, --locale=, LocaleMessages=, --locale-messages=, Keymap=, --keymap=, Timezone=, --timezone=, Hostname=, --hostname=, RootShell=, --root-shell= correspond to the identically named systemd-firstboot options. See the systemd firstboot manpage (https://www.freedesktop.org/software/systemd/man/systemd-firstboot.html) for more information. Additionally, where applicable, the corresponding systemd credentials for these settings are written to /usr/lib/credstore, so that they apply even if only /usr is shipped in the image.
RootPassword=, --root-password=,
Set the system root password. If this option is not used, but a mkosi.rootpw file is found in the local directory, the password is automatically read from it. If the password starts with hashed:, it is treated as an already hashed root password. The root password is also stored in /usr/lib/credstore under the appropriate systemd credential so that it applies even if only /usr is shipped in the image. To create an unlocked account without any password use hashed: without a hash.
Autologin=, --autologin
Aktiviert die automatische Anmeldung für den Benutzer root auf /dev/pts/0 (nspawn), /dev/tty1 und /dev/hvc0.
MakeInitrd=, --make-initrd
Add /etc/initrd-release and /init to the image so that it can be used as an initramfs.
Ssh=, --ssh
If specified, an sshd socket unit and matching service are installed in the final image that expose SSH over VSock. When building with this option and running the image using mkosi qemu, the mkosi ssh command can be used to connect to the container/VM via SSH. Note that you still have to make sure openssh is installed in the image to make this option behave correctly. Run mkosi genkey to automatically generate an X509 certificate and private key to be used by mkosi to enable SSH access to any virtual machines via mkosi ssh. To access images booted using mkosi boot, use machinectl.
SELinuxRelabel=, --selinux-relabel=
Legt fest, ob Dateien neu markiert werden sollen, um auf die SELinux-Richtlinie des Abbilds zu passen. Akzeptiert einen logischen Wert oder auto. Standardmäßig auto. Falls deaktiviert, werden Dateien nicht neu markiert. Falls aktiviert, muss eine SELinux-Richtlinie im Abbild installiert werden und setfiles(8) verfügbar sein, um Dateien zu markieren. Falls während setfiles(8) irgendein Fehler auftritt, wird der Bau fehlschlagen. Falls auf auto gesetzt, werden Dateien neu markiert, falls 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]

SecureBoot=, --secure-boot
Signiert systemd-boot(7) (falls es noch nicht signiert ist) und sämtliche vereinigten Kernelabbilder für UEFI SecureBoot.
SecureBootAutoEnroll=, --secure-boot-auto-enroll=
Set up automatic enrollment of the secure boot keys in virtual machines as documented in the systemd-boot man page (https://www.freedesktop.org/software/systemd/man/systemd-boot.html) if SecureBoot= is used. Note that systemd-boot will only do automatic secure boot key enrollment in virtual machines starting from systemd v253. To do auto enrollment on systemd v252 or on bare metal machines, write a systemd-boot configuration file to /efi/loader/loader.conf using an extra tree with secure-boot-enroll force or secure-boot-enroll manual in it. Auto enrollment is not supported on systemd versions older than v252. Defaults to yes.
SecureBootKey=, --secure-boot-key=
Path to the PEM file containing the secret key for signing the UEFI kernel image if SecureBoot= is used and PCR signatures when SignExpectedPcr= is also used. When SecureBootKeySource= is specified, the input type depends on the source.
SecureBootKeySource=, --secure-boot-key-source=
Quelle von SecureBootKey=, um OpenSSL-Einheiten zu unterstützen. Beispiel: --secure-boot-key-source=engine:pkcs11
SecureBootCertificate=, --secure-boot-certificate=
Path to the X.509 file containing the certificate for the signed UEFI kernel image, if SecureBoot= is used.
SecureBootSignTool=, --secure-boot-sign-tool
Tool to use to sign secure boot PE binaries. Takes one of sbsign, pesign or auto. Defaults to auto. If set to auto, either sbsign or pesign are used if available, with sbsign being preferred if both are installed.
VerityKey=, --verity-key=
Path to the PEM file containing the secret key for signing the verity signature, if a verity signature partition is added with systemd-repart. When VerityKeySource= is specified, the input type depends on the source.
VerityKeySource=, --verity-key-source=
Source of VerityKey=, to support OpenSSL engines. E.g.: --verity-key-source=engine:pkcs11
VerityCertificate=, --verity-certificate=
Pfad zu einer X.509-Datei, die das Zertifikat zum Signieren der Verity-Signatur enthält, falls eine Verity-Signaturpartition mittels systemd-repart(8) hinzugefügt wird.
SignExpectedPcr=, --sign-expected-pcr
Measure the components of the unified kernel image (UKI) using systemd-measure and embed the PCR signature into the unified kernel image. This option takes a boolean value or the special value auto, which is the default, which is equal to a true value if the systemd-measure binary is in PATH. Depends on SecureBoot= being enabled and key from SecureBootKey=.
Passphrase=, --passphrase
Specify the path to a file containing the passphrase to use for LUKS encryption. 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.
Checksum=, --checksum
Generate a SHA256SUMS file of all generated artifacts after the build is complete.
Sign=, --sign
Sign the generated SHA256SUMS using gpg after completion.
Key=, --key=
Select the gpg key to use for signing SHA256SUMS. This key must be already present in the gpg keyring.

Abschnitt [Host]

ProxyUrl=, --proxy-url=
Configure a proxy to be used for all outgoing network connections. Various tools that mkosi invokes and for which the proxy can be configured are configured to use this proxy. mkosi also sets various well-known environment variables to specify the proxy to use for any programs it invokes that may need internet access.
ProxyExclude=, --proxy-exclude=
Configure hostnames for which requests should not go through the proxy. Takes a comma separated list of hostnames.
ProxyPeerCertificate=, --proxy-peer-certificate=
Configure a file containing certificates used to verify the proxy. Defaults to the system-wide certificate store.

Currently, setting a proxy peer certificate is only supported when dnf or dnf5 is used to build the image.

ProxyClientCertificate=, --proxy-client-certificate=
Configure a file containing the certificate used to authenticate the client with the proxy.

Currently, setting a proxy client certificate is only supported when dnf or dnf5 is used to build the image.

ProxyClientKey=, --proxy-client-key=
Configure a file containing the private key used to authenticate the client with the proxy. Defaults to the proxy client certificate if one is provided.

Currently, setting a proxy client key is only supported when dnf or dnf5 is used to build the image.

Incremental=, --incremental=, -i
Enable incremental build mode. In this mode, a copy of the OS image is created immediately after all OS packages are installed and the prepare scripts have executed but before the mkosi.build scripts are invoked (or anything that happens after it). On subsequent invocations of mkosi with the -i switch this cached image may be used to skip the OS package installation, thus drastically speeding up repetitive build times. Note that while there is some rudimentary cache invalidation, it is definitely not perfect. In order to force rebuilding of the cached image, combine -i with -ff to ensure the cached image is first removed and then re-created.
NSpawnSettings=, --settings=
Specifies a .nspawn settings file for systemd-nspawn to use in the boot and shell verbs, and to place next to the generated image file. This is useful to configure the systemd-nspawn environment when the image is run. If this setting is not used but an mkosi.nspawn file found in the local directory it is automatically used for this purpose.
ExtraSearchPaths=, --extra-search-path=
List of colon-separated paths to look for tools in, before using the regular $PATH search path.
VirtualMachineMonitor=, --vmm=
Configures the virtual machine monitor to use. Takes one of qemu or vmspawn. Defaults to qemu.

When set to qemu, the image is booted with qemu. Most output formats can be booted in qemu. Any arguments specified after the verb are appended to the qemu invocation and are interpreted as extra qemu command line arguments.

Falls auf vmspawn gesetzt wird systemd-vmspawn(1) zum Hochfahren des Abbildes benutzt. vmspawn unterstützt nur Platten- und Verzeichnis-Typ-Abbilder. Alle nach dem Unterbefehl angegebenen Argumente werden an den Aufruf von systemd-vmspawn(1) angehängt und als zusätzliche Vmspawn-Optionen und zusätzliche Kernelbefehlszeilenargumente interpretiert.

QemuGui=, --qemu-gui=
Falls aktiviert, wird Qemu mit seiner graphischen Oberfläche anstelle einer seriellen Konsole ausgeführt.
QemuSmp=, --qemu-smp=
When used with the qemu verb, this options sets qemu’s -smp argument which controls the number of guest’s CPUs. Defaults to 2.

When set to 0, the number of CPUs available to the mkosi process will be used.

QemuMem=, --qemu-mem=
When used with the qemu verb, this options sets qemu’s -m argument which controls the amount of guest’s RAM. Defaults to 2G.
QemuKvm=, --qemu-kvm=
When used with the qemu verb, this option specifies whether QEMU should use KVM acceleration. Takes a boolean value or auto. Defaults to auto.
QemuVsock=, --qemu-vsock=
When used with the qemu verb, this option specifies whether QEMU should be configured with a vsock. Takes a boolean value or auto. Defaults to auto.
QemuVsockConnectionId=, --qemu-vsock-cid=
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.
QemuSwtpm=, --qemu-swtpm=
When used with the qemu verb, this option specifies whether to start an instance of swtpm to be used as a TPM with qemu. This requires swtpm to be installed on the host. Takes a boolean value or auto. Defaults to auto.
QemuCdrom=, --qemu-cdrom=
When used with the qemu verb, this option specifies whether to attach the image to the virtual machine as a CD-ROM device. Takes a boolean. Defaults to no.
QemuFirmware=, --qemu-firmware=
When used with the qemu verb, this option specifies which firmware to use. Takes one of uefi, uefi-secure-boot, bios, linux, or auto. Defaults to auto. When set to uefi, the OVMF firmware without secure boot support is used. When set to uefi-secure-boot, the OVMF firmware with secure boot support is used. When set to bios, the default SeaBIOS firmware is used. When set to linux, direct kernel boot is used. See the QemuKernel= option for more details on which kernel image is used with direct kernel boot. When set to auto, uefi-secure-boot is used if possible and linux otherwise.
QemuFirmwareVariables=, --qemu-firmware-variables=
When used with the qemu verb, this option specifies the path to the the firmware variables file to use. Currently, this option is only taken into account when the uefi or uefi-secure-boot firmware is used. If not specified, mkosi will search for the default variables file and use that instead.

When set to microsoft, a firmware variables file with the Microsoft secure boot certificates already enrolled will be used.

When set to custom, the secure boot certificate from SecureBootCertificate= will be enrolled into the default firmware variables file.

virt-fw-vars from the virt-firmware (https://gitlab.com/kraxel/virt-firmware) project can be used to customize OVMF variable files.

QemuKernel=, --qemu-kernel=
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.

QemuDrives=, --qemu-drive=
Fügt ein Qemu-Laufwerk hinzu. Akzeptiert eine Doppelpunkt-getrennte Zeichenkette im Format <Kennung>:<Größe>[:<Verzeichnis>[:<Optionen>[:<Dateikennung>]]]. 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. Dateikennung legt die Kennung der Datei fest, die dem Laufwerk zugrunde liegt. Laufwerke mit der gleichen Dateikennung haben eine gemeinsame zugrundeliegende Datei. Das Verzeichnis und die Größe der Datei wird aus dem ersten Laufwerk mit der angegebenen Dateikennung bestimmt.

Beispielhafte Verwendung:

[Host]
QemuDrives=btrfs:10G

ext4:20G QemuArgs=-device nvme,serial=btrfs,drive=btrfs
-device nvme,serial=ext4,drive=ext4
QemuArgs=
Leerzeichen-begrenzte Liste von zusätzlich beim Aufruf von Qemu zu übergebenen Argumenten.
Ephemeral=, --ephemeral
When used with the shell, boot, or qemu verbs, this option runs the specified verb on a temporary snapshot of the output image that is removed immediately when the container terminates. Taking the temporary snapshot is more efficient on file systems that support reflinks natively (btrfs or xfs) than on more traditional file systems that do not (ext4).
Credentials=, --credential=
Set credentials to be passed to systemd-nspawn or qemu respectively when mkosi shell/boot or mkosi qemu are used. This option takes a space separated list of values which can be either key=value pairs or paths. If a path is provided, if it is a file, the credential name will be the name of the file. If the file is executable, the credential value will be the output of executing the file. Otherwise, the credential value will be the contents of the file. If the path is a directory, the same logic applies to each file in the directory.

Note that values will only be treated as paths if they do not contain the delimiter (=).

KernelCommandLineExtra=, --kernel-command-line-extra=
Setzt zusätzliche Kernelbefehlszeilenargumente, die zur Laufzeit beim Starten des Abbilds an die Kernelbefehlszeile angehängt werden. Beim Systemstart in einen Container werden diese als zusä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.
Acl=, --acl=
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.
ToolsTree=, --tools-tree=
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.

Note if a binary is found in any of the paths configured with ExtraSearchPaths=, the binary will be executed on the host.

Falls auf default gesetzt, wird Mkosi automatisch ein zusätzliches Werkzeugbaumabbild hinzufügen und es als Werkzeugbaum verwenden.

Note that mkosi will only build a single default tools tree per build, even if multiple images are defined in mkosi.images with ToolsTree=default. The settings of the “last” image will apply to the default tools tree (usually the image defined last in mkosi.images and without any dependencies on other images).

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
apt
archlinux-keyring
attr
bash
btrfs-progs
bubblewrap
ca-certificates
coreutils
cpio
curl
debian-keyring
diffutils
distribution-gpg-keys
dnf
dnf-plugins-core
dnf5
dnf5-plugins
dosfstools
e2fsprogs
edk2-ovmf
erofs-utils
findutils
git
grep
grub-tools
jq
kmod
less
mtools
nano
openssh
openssl
sed
pacman
pesign
policycoreutils
qemu
sbsigntools
socat
squashfs-tools
strace
swtpm
systemd
ukify
tar
ubuntu-keyring
util-linux
virtiofsd
virt-firmware
xfsprogs
xz
zstd
zypper
ToolsTreeDistribution=, --tools-tree-distribution=
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.
ToolsTreeRelease=, --tools-tree-release=
Setzt die für den Standard-Werkzeugbaum zu verwendende Distributionsveröffentlichung. Standardmäßig wird die in Mkosi fest eingebaute Standard-Veröffentlichung für die Distribution verwandt.
ToolsTreeMirror=, --tools-tree-mirror=
Setzt den für den Standardbaum zu verwendenen Spiegel. Standardmäßig wird der Standardspiegel für die Werkzeugbaumdistribution verwandt.
ToolsTreeRepositories=, --tools-tree-repository
Identisch zu Repositories=, aber für den Standardwerkzeugbaum.
ToolsTreePackageManagerTrees=, --tools-tree-package-manager-tree=
Identisch zu PackageManagerTrees=, aber für den Standardwerkzeugbaum.
ToolsTreePackages=, --tools-tree-packages=
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.
ToolsTreeCertificates=, --tools-tree-certificates=
Specify whether to use certificates and keys from the tools tree. If enabled, /usr/share/keyrings, /usr/share/distribution-gpg-keys, /etc/pki, /etc/ssl, /etc/ca-certificates, /etc/pacman.d/gnupg and /var/lib/ca-certificates from the tools tree are used. Otherwise, these directories are picked up from the host.
RuntimeTrees=, --runtime-tree=
Akzeptiert eine Doppelpunkt-getrennte Liste von Pfaden. Der erste Pfad bezieht sich auf ein in jede von Mkosi zu startende Maschine (Container oder VM) einzuhängendes Verzeichnis. Der zweite Pfad bezieht sich auf das Zielverzeichnis innerhalb der Maschine. Falls der zweite Pfad nicht bereitgestellt wird, wird das Verzeichnis unter 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.

RuntimeSize=, --runtime-size=
Falls angegeben werden Plattenabbilder bis zu der angegebenen Größe aufgewachsen, wenn sie mit mkosi boot oder mkosi 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.
RuntimeScratch=, --runtime-scratch=
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.

RuntimeNetwork=, --runtime-network=
Akzeptiert entweder user, interface oder none. Standardmäßig user. Legt das beim Systemstart einzurichtende Netzwerk fest. user richtet Benutzermodus-Vernetzung ein. interface richtet eine virtuelle Netzwerkverbindung zwischen dem Wirtrechner und dem Abbild ein. Dies übersetzt sich in eine Veth-Schnittstelle für mkosi shell und mkosi boot und eine Tap-Schnittstelle für mkosi 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.

RuntimeBuildSources=, --runtime-build-sources=
Mount the build sources configured with BuildSources= and the build directory (if one is configured) to the same locations in /work that they were mounted to when running the build script when using mkosi boot or mkosi qemu.
UnitProperties=, --unit-property=
Configure systemd unit properties to add to the systemd scopes allocated when using mkosi boot or mkosi qemu. These are passed directly to the --property options of systemd-nspawn and systemd-run respectively.
SshKey=, --ssh-key=
Path to the X509 private key in PEM format to use to connect to a virtual machine started with mkosi qemu and built with the Ssh= option enabled via the mkosi ssh command. If not configured and mkosi.key exists in the working directory, it will automatically be used for this purpose. Run mkosi genkey to automatically generate a key in mkosi.key.
SshCertificate=, --ssh-certificate=
Path to the X509 certificate in PEM format to provision as the SSH public key in virtual machines started with mkosi qemu. If not configured and mkosi.crt exists in the working directory, it will automatically be used for this purpose. Run mkosi genkey to automatically generate a certificate in mkosi.crt.
Machine=, --machine=
Specify the machine name to use when booting the image. Can also be used to refer to a specific image when SSH-ing into an image (e.g. mkosi --image=myimage ssh).

Note that Ephemeral= has to be enabled to start multiple instances of the same image.

ForwardJournal=, --forward-journal=
Specify the path to which journal logs from containers and virtual machines should be forwarded. If the path has the .journal extension, it is interpreted as a file to which the journal should be written. Otherwise, the path is interpreted as a directory to which the journal should be written.

Note that systemd v256 or newer is required in the virtual machine for log forwarding to work.

Note that if a path with the .journal extension is given, the journal size is limited to 4G. Configure an output directory instead of file if your workload produces more than 4G worth of journal data.

Abschnitt [Match]

Profile=
Übereinstimmung mit dem konfigurierten Profil.
Distribution=
Übereinstimmung mit der konfigurierten Distribution.
Release=
Übereinstimmung mit der konfigurierten Distributionsveröffentlichung. Falls diese Bedingung verwandt wird und noch keine Distribution explizit konfiguriert wurde, wird die Distribution und Veröffentlichung der Wirtmaschine verwandt.
Architecture=
Übereinstimmung mit der konfigurierten Architektur. Falls diese Bedingung verwandt wird und noch keine Architektur explizit konfiguriert wurde, wird die Architektur des Wirtsystems verwandt.
Repositories=
Matches against repositories enabled with the Repositories= setting. Takes a single repository name.
PathExists=
Diese Bedingung ist erfüllt, wenn der angegebene Pfad existiert. Relative Pfade werden als relativ zum Elternverzeichnis der Konfigurationsdatei interpretiert, aus der diese Bedingung ausgelesen wurde.
ImageId=
Übereinstimmung mit der konfigurierten Abbildkennung, Globs werden unterstützt. Falls diese Bedingung verwandt wird und noch keine Abbildkennung explizit konfiguriert wurde, schlägt diese Bedingung fehl.
ImageVersion=
Matches against the configured image version. Image versions can be prepended by the operators ==, !=, >=, <=, <, > for rich version comparisons according to the UAPI group version format specification. If no operator is prepended, the equality operator is assumed by default. If this condition is used and no image version has been explicitly configured yet, this condition fails.
Bootable=
Matches against the configured value for the Bootable= feature. Takes a boolean value or auto.
Format=
Matches against the configured value for the Format= option. Takes an output format (see the Format= option).
SystemdVersion=
Matches against the systemd version on the host (as reported by systemctl --version). Values can be prepended by the operators ==, !=, >=, <=, <, > for rich version comparisons according to the UAPI group version format specification. If no operator is prepended, the equality operator is assumed by default.
BuildSources=
Takes a build source target path (see BuildSources=). This match is satisfied if any of the configured build sources uses this target path. For example, if we have a mkosi.conf file containing:
[Content]
BuildSources=../abc/qed:kernel
    

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

[Match]
BuildSources=kernel
    

Die Ergänzung wird aufgenommen.

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

HostArchitecture=
Matches against the host’s native architecture. See the Architecture= setting for a list of possible values.
ToolsTreeDistribution=
Übereinstimmung mit der konfigurierten Werkzeugbaum-Distribution.
Environment=
Matches against a specific key/value pair configured with Environment=. If no value is provided, check if the given key is in the environment regardless of which value it has.

This table shows which matchers support globs, rich comparisons and the default value that is matched against if no value has been configured at the time the config file is read:

Ü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.
ToolsTreeDistribution= no no Übereinstimmung mit Standard-Werkzeugbaum-Distribution
Environment= no no n.Z.

Abschnitt [Config]

Profile=, --profile=
Select the given profile. A profile is a configuration file or directory in the mkosi.profiles/ directory. When selected, this configuration file or directory is included after parsing the mkosi.conf file, but before any mkosi.conf.d/*.conf drop in configuration.
Include=, --include=, -I
Include extra configuration from the given file or directory. The extra configuration is included immediately after parsing the setting, except when used on the command line, in which case the extra configuration is included after parsing all command line arguments.

Note that each path containing extra configuration is only parsed once, even if included more than once with Include=.

The builtin configs for the mkosi default initrd and default tools tree can be included by including the literal value mkosi-initrd and mkosi-tools respectively.

Note: Include names starting with either of the literals mkosi- or contrib- are reserved for use by mkosi itself.

InitrdInclude=, --initrd-include=
Same as Include=, but the extra configuration files or directories are included when building the default initrd.
Dependencies=, --dependency=
Die Abbilder, von denen dieses Abbild abhängt, festgelegt als Kommata-getrennte Liste. Alle in dieser Option konfigurierten Abbilder werden vor diesem Abbild gebaut.

Wird diese Einstellung für das »Hauptabbild« angegeben, legt sie fest, welche Unterabbilder gebaut werden sollen. Siehe den Abschnitt Bau mehrerer Abbilder für weitere Informationen.

MinimumVersion=, --minimum-version=
Die minimale Version von Mkosi, die zum Bau dieser Konfiguration benötigt wird. Falls mehrfach angegeben, wird die höchste festgelegte Version verwandt.
ConfigureScripts=, --configure-script=
Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Programmen, die als Konfigurationsskripte für dieses Abbild verwandt werden. Siehe den Abschnitt Skripte für weitere Informationen.
PassEnvironment=, --pass-environment=
Akzeptiert eine Liste von durch Leerzeichen getrennten Umgebungsvariablennamen. Bei Bau mehrere Abbilder werden die aufgeführten Umgebungsvariablen an jedes einzelne Unterabbild übergeben, als ob sie »universelle« Einstellungen wären. Siehe den Abschnitt Bau mehrerer Abbilder für weitere Informationen.

Kennzeichner

The current value of various settings can be accessed when parsing configuration files by using specifiers. To write a literal % character in a configuration file without treating it as a specifier, use %%. The following specifiers are understood:

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

There are also specifiers that are independent of settings:

Kennzeichner Wert
%C Parent directory of current config file
%P Aktuelles Arbeitsverzeichnis
%D Directory that mkosi was invoked in

Finally, there are specifiers that are derived from a setting:

Kennzeichner Wert
%F Das Standarddateisystem der konfigurierten Distribution

Note that the current working directory changes as mkosi parses its configuration. Specifically, each time mkosi parses a directory containing a mkosi.conf file, mkosi changes its working directory to that directory.

Note that the directory that mkosi was invoked in is influenced by the --directory= command line argument.

The following table shows example values for the directory specifiers listed above:

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

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)

In theory, any distribution may be used on the host for building images containing any other distribution, as long as the necessary tools are available. Specifically, any distribution that packages apt may be used to build Debian or Ubuntu images. Any distribution that packages dnf may be used to build images for any of the rpm-based distributions. Any distro that packages pacman may be used to build Arch Linux images. Any distribution that packages zypper may be used to build openSUSE images. Other distributions and build automation tools for embedded Linux systems such as Buildroot, OpenEmbedded and Yocto Project may be used by selecting the custom distribution, and populating the rootfs via a combination of base trees, skeleton trees, and prepare scripts.

Derzeit paketiert Fedora Linux alle relevanten Werkzeuge seit Fedora 28.

Note that when not using a custom mirror, RHEL images can only be built from a host system with a RHEL subscription (established using e.g. subscription-manager).

Nutzungsablauf

Execution flow for mkosi build. Default values/calls are shown in parentheses. When building with --incremental mkosi creates a cache of the distribution installation if not already existing and replaces the distribution installation in consecutive runs with data from the cached one.

1.
CLI-Optionen auswerten
2.
Konfigurationsdateien auswerten
3.
Konfigurationsskripte ausführen (mkosi.configure)
4.
If we’re not running as root, unshare the user namespace and map the subuid range configured in /etc/subuid and /etc/subgid into it.
5.
Abtrennen des Einhängenamensraums
6.
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.
Ausführen der Synchronisierungsskripte (mkosi.sync)
4.
Copy base trees (--base-tree=) into the image
5.
Wiederbenutzung eines zwischengespeicherten Abbilds, falls verfügbar
6.
Kopieren eines Schnappschusses der Depot-Metadaten des Paketverwalters in das Abbild
7.
Copy skeleton trees (mkosi.skeleton) into image
8.
Installieren der Distributioon und Paketen in das Abbild
9.
Run prepare scripts on image with the final argument (mkosi.prepare)
10.
Installieren der Baupakete in der Überlagerung, falls irgendwelche Bauskripte konfiguriert sind
11.
Run prepare scripts on overlay with the build argument if any build scripts are configured (mkosi.prepare)
12.
Cache the image if configured (--incremental)
13.
Run build scripts on image + overlay if any build scripts are configured (mkosi.build)
14.
Finalize the build if the output format none is configured
15.
Kopieren der Bauskripteausgabe in das Abbild
16.
Copy the extra trees into the image (mkosi.extra)
17.
Run post-install scripts (mkosi.postinst)
18.
Write config files required for Ssh=, Autologin= and MakeInitrd=
19.
Install systemd-boot and configure secure boot if configured (--secure-boot)
20.
Run systemd-sysusers
21.
Run systemd-tmpfiles
22.
Run systemctl preset-all
23.
Run depmod
24.
Run systemd-firstboot
25.
Run systemd-hwdb
26.
Remove packages and files (RemovePackages=, RemoveFiles=)
27.
SELinux-Neumarkierung ausführen, falls eine SELinux-Richtlinie installiert ist
28.
Run finalize scripts (mkosi.finalize)
29.
Vereinigtes Kernelabbild ausführen, falls so konfiguriert
30.
Finales Ausgabeformat erstellen
31.
Ausführen der Post-Ausgabe-Skripte (mkosi.postoutput)

Skripte

To allow for image customization that cannot be implemented using mkosi’s builtin features, mkosi supports running scripts at various points during the image build process that can customize the image as needed. Scripts are executed on the host system as root (either real root or root within the user namespace that mkosi created when running unprivileged) with a customized environment to simplify modifying the image. For each script, the configured build sources (BuildSources=) are mounted into the current working directory before running the script in the current working directory. $SRCDIR is set to point to the current working directory. The following scripts are supported:

If mkosi.configure (ConfigureScripts=) exists, it is executed before building the image. This script may be used to dynamically modify the configuration. It receives the configuration serialized as JSON on stdin and should output the modified configuration serialized as JSON on stdout. Note that this script only runs when building or booting the image (build, qemu, boot and shell verbs). If a default tools tree is configured, it will be built before running the configure scripts and the configure scripts will run with the tools tree available. This also means that the modifications made by configure scripts will not be visible in the summary output.
If mkosi.sync (SyncScripts=) exists, it is executed before the image is built. This script may be used to update various sources that are used to build the image. One use case is to run git pull on various source repositories before building the image. Specifically, the BuildSourcesEphemeral= setting does not apply to sync scripts, which means sync scripts can be used to update build sources even if BuildSourcesEphemeral= is enabled.
If mkosi.prepare (PrepareScripts=) exists, it is first called with the final argument, right after the software packages are installed. It is called a second time with the build command line parameter, right after the build packages are installed and the build overlay mounted on top of the image’s root directory . This script has network access and may be used to install packages from other sources than the distro’s package manager (e.g. pip, npm, ...), after all software packages are installed but before the image is cached (if incremental mode is enabled). In contrast to a general purpose installation, it is safe to install packages to the system (pip install, npm install -g) instead of in $SRCDIR itself because the build image is only used for a single project and can easily be thrown away and rebuilt so there’s no risk of conflicting dependencies and no risk of polluting the host system.
If mkosi.build (BuildScripts=) exists, it is executed with the build overlay mounted on top of the image’s root directory. When running the build script, $DESTDIR points to a directory where the script should place any files generated it would like to end up in the image. Note that make/automake/meson based build systems generally honor $DESTDIR, thus making it very natural to build source trees from the build script. After running the build script, the contents of $DESTDIR are copied into the image.
If mkosi.postinst (PostInstallationScripts=) exists, it is executed after the (optional) build tree and extra trees have been installed. This script may be used to alter the images without any restrictions, after all software packages and built sources have been installed.
If mkosi.finalize (FinalizeScripts=) exists, it is executed as the last step of preparing an image.
If mkosi.postoutput (PostOutputScripts=) exists, it is executed right after all the output files have been generated, before they are finally moved into the output directory. This can be used to generate additional or alternative outputs, e.g. SHA256FILES or SBOM manifests.
If mkosi.clean (CleanScripts=) exists, it is executed right after the outputs of a previous build have been cleaned up. A clean script can clean up any outputs that mkosi does not know about (e.g. artifacts from SplitArtifacts=yes or RPMs built in a build script). Note that this script does not use the tools tree even if one is configured.

If a script uses the .chroot extension, mkosi will chroot into the image using mkosi-chroot (see below) before executing the script. For example, if mkosi.postinst.chroot exists, mkosi will chroot into the image and execute it as the post-installation script.

Von Mkosi ausgeführte Skripte erhalten die folgenden Umgebungsvariablen:

$ARCHITECTURE contains the architecture from the Architecture= setting. If Architecture= is not set, it will contain the native architecture of the host machine. See the documentation of Architecture= for possible values for this variable.
$QEMU_ARCHITECTURE contains the architecture from $ARCHITECTURE in the format used by qemu. Useful for finding the qemu binary ( qemu-system-$QEMU_ARCHITECTURE).
$DISTRIBUTION contains the distribution from the Distribution= setting.
$RELEASE contains the release from the Release= setting.
$DISTRIBUTION_ARCHITECTURE contains the architecture from $ARCHITECTURE in the format used by the configured distribution.
$PROFILE contains the profile from the Profile= setting.
$CACHED= is set to 1 if a cached image is available, 0 otherwise.
$CHROOT_SCRIPT contains the path to the running script relative to the image root directory. The primary usecase for this variable is in combination with the mkosi-chroot script. See the description of mkosi-chroot below for more information.
$SRCDIR contains the path to the directory mkosi was invoked from, with any configured build sources mounted on top. $CHROOT_SRCDIR contains the value that $SRCDIR will have after invoking mkosi-chroot.
$BUILDDIR is only defined if mkosi.builddir exists and points to the build directory to use. This is useful for all build systems that support out-of-tree builds to reuse already built artifacts from previous runs. $CHROOT_BUILDDIR contains the value that $BUILDDIR will have after invoking mkosi-chroot.
$DESTDIR is a directory into which any installed software generated by a build script may be placed. This variable is only set when executing a build script. $CHROOT_DESTDIR contains the value that $DESTDIR will have after invoking mkosi-chroot.
$OUTPUTDIR points to the staging directory used to store build artifacts generated during the build. $CHROOT_OUTPUTDIR contains the value that $OUTPUTDIR will have after invoking mkosi-chroot.
$PACKAGEDIR points to the directory containing the local package repository. Build scripts can add more packages to the local repository by writing the packages to $PACKAGEDIR.
$ARTIFACTDIR points to the directory that is used to pass around build artifacts generated during the build and make them available for use by mkosi. This is similar to PACKAGEDIR, but is meant for artifacts that may not be packages understood by the package manager, e.g. initrds created by other initrd generators than mkosi. Build scripts can add more artifacts to the directory by placing them in $ARTIFACTDIR. Files in this directory are only available for the current build and are not copied out like the contents of $OUTPUTDIR.

mkosi will also use certain subdirectories of an artifacts directory to automatically use their contents at certain steps. Currently the following two subdirectories in the artifact directory are used by mkosi:

io.mkosi.microcode: All files in this directory are used as microcode files, i.e. they are prepended to the initrds in lexicographical order.
io.mkosi.initrd: All files in this directory are used as initrds and joined in lexicographical order.

It is recommend users of $ARTIFACTDIR put things for their own use in a similar namespaced directory, e.h. local.my.namespace.

$BUILDROOT is the root directory of the image being built, optionally with the build overlay mounted on top depending on the script that’s being executed.
$WITH_DOCS is either 0 or 1 depending on whether a build without or with installed documentation was requested (WithDocs=yes). A build script should suppress installation of any package documentation to $DESTDIR in case $WITH_DOCS is set to 0.
$WITH_TESTS is either 0 or 1 depending on whether a build without or with running the test suite was requested (WithTests=no). A build script should avoid running any unit or integration tests in case $WITH_TESTS is 0.
$WITH_NETWORK is either 0 or 1 depending on whether a build without or with networking is being executed (WithNetwork=no). A build script should avoid any network communication in case $WITH_NETWORK is 0.
$SOURCE_DATE_EPOCH is defined if requested (SourceDateEpoch=TIMESTAMP, Environment=SOURCE_DATE_EPOCH=TIMESTAMP or the host environment variable $SOURCE_DATE_EPOCH). This is useful to make builds reproducible. See SOURCE_DATE_EPOCH (https://reproducible-builds.org/specs/source-date-epoch/) for more information.
$MKOSI_UID and $MKOSI_GID are the respectively the uid, gid of the user that invoked mkosi, potentially translated to a uid in the user namespace that mkosi is running in. These can be used in combination with setpriv to run commands as the user that invoked mkosi (e.g. setpriv --reuid=$MKOSI_UID --regid=$MKOSI_GID --clear-groups <command>)
$MKOSI_CONFIG is a file containing a json summary of the settings of the current image. This file can be parsed inside scripts to gain access to all settings for the current image.
$IMAGE_ID enthält den Kennzeichner aus der Einstellung ImageId= oder --image-id=.
$IMAGE_VERSION enthält die Version aus der Einstellung ImageVersion= oder --image-version=.

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

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

Additionally, when a script is executed, a few scripts are made available via $PATH to simplify common usecases.

mkosi-chroot: This script will chroot into the image and execute the given command. On top of chrooting into the image, it will also mount various files and directories ($SRCDIR, $DESTDIR, $BUILDDIR, $OUTPUTDIR, $CHROOT_SCRIPT) into the image and modify the corresponding environment variables to point to the locations inside the image. It will also mount APIVFS filesystems (/proc, /dev, ...) to make sure scripts and tools executed inside the chroot work properly. It also propagates /etc/resolv.conf from the host into the chroot if requested so that DNS resolution works inside the chroot. After the mkosi-chroot command exits, various mount points are cleaned up.

For example, to invoke ls inside of the image, use the following

mkosi-chroot ls …
    

To execute the entire script inside the image, add a “.chroot” suffix to the name (mkosi.build.chroot instead of mkosi.build, etc.).

Für alle unterstützten Paketverwalter (dnf, rpm(8), dpkg(1), 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.

Additionally, mkosi-install, mkosi-reinstall, mkosi-upgrade and mkosi-remove will invoke the corresponding operation of the package manager being used to built the image.

mkosi-as-caller: This script uses setpriv to switch from the user root in the user namespace used for various build steps back to the original user that called mkosi. This is useful when we want to invoke build steps which will write to $BUILDDIR and we want to have the files owned by the calling user.

For example, a complete mkosi.build script might be the following:

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 is automatically invoked with safe.directory=* to avoid permissions errors when running as the root user in a user namespace.
useradd and groupadd are automatically invoked with --root=$BUILDROOT when executed outside of the image.

When scripts are executed, any directories that are still writable are also made read-only (/home, /var, /root, ...) and only the minimal set of directories that need to be writable remain writable. This is to ensure that scripts can’t mess with the host system when mkosi is running as root.

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:

The mkosi.skeleton/ directory or mkosi.skeleton.tar archive may be used to insert files into the image. The files are copied before the distribution packages are installed into the image. This allows creation of files that need to be provided early, for example to configure the package manager or set systemd presets.

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.

The mkosi.extra/ directory or mkosi.extra.tar archive may be used to insert additional files into the image, on top of what the distribution includes in its packages. They are similar to mkosi.skeleton/ and mkosi.skeleton.tar, but the files are copied into the directory tree of the image after the OS was installed.

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.pkgmngr/ oder das Archiv mkosi.pkgmngr.tar können zum Konfigurieren des Paketverwalters verwandt werden, ohne die Dateien in das Abbild einzufügen. Falls die Dateien in das Abbild eingefügt werden sollen, sollte stattdessen mkosi.skeleton/ und mkosi.skeleton.tar verwandt werden.

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.

The mkosi.nspawn nspawn settings file will be copied into the same place as the output image file, if it exists. This is useful since nspawn looks for settings files next to image files it boots, for additional container runtime settings.
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 subimage 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 images specified in the Dependencies= setting of the main image and all of their dependencies (or all of them if no images were explicitly configured using Dependencies= in the main image configuration). To add dependencies between subimages, the Dependencies= setting can be used as well. Subimages are always built before the main image.

When images are defined, mkosi will first read the main image configuration (configuration outside of the mkosi.images/ directory), followed by the image specific configuration. Several “universal” settings apply to the main image and all its subimages and cannot be configured separately in subimages. The following settings are universal and cannot be configured in subimages (except for settings which take a collection of values which can be extended in subimages but not overridden):

Profile=
Distribution=
Release=
Architecture=
Mirror=
LocalMirror=
RepositoryKeyCheck=
Repositories=
CacheOnly=
PackageManagerTrees=
OutputDirectory=
WorkspaceDirectory=
CacheDirectory=
PackageCacheDirectory=
BuildDirectory=
ImageId=
ImageVersion=
SectorSize=
RepartOffline=
UseSubvolumes=
PackageDirectories=
VolatilePackageDirectories=
SourceDateEpoch=
BuildSources=
BuildSourcesEphemeral=
WithTests
WithNetwork=
VerityKey=
VerityKeySource=
VerityCertificate=
ProxyUrl=
ProxyExclude=
ProxyPeerCertificate=
ProxyClientCertificate=
ProxyClientKey=
Incremental=
ExtraSearchPaths=
Acl=
ToolsTree=
ToolsTreeCertificates=

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 (https://github.com/systemd/systemd/tree/main/mkosi.images) 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.
$EPEL_MIRROR can be used to override the default mirror location used for the epel repositories when Mirror= is used. By default mkosi looks for the epel repositories in the fedora subdirectory of the parent directory of the mirror specified in Mirror=. For example if the mirror is set to https://mirror.net/centos-stream mkosi will look for the epel repositories in https://mirror.net/fedora/epel.

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. Alternatively the machine can be shut down using Ctrl-a x.

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 (https://github.com/systemd/mkosi/)
mkosi — A Tool for Generating OS Images (https://0pointer.net/blog/mkosi-a-tool-for-generating-os-images.html) introductory blog post by Lennart Poettering
The mkosi OS generation tool (https://lwn.net/Articles/726655/) 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.