Provided by: manpages-de_4.23.1-1_all 
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…] vmspawn [Vmspawn-Einstellungen…]
mkosi [Optionen…] ssh [Befehlszeile…]
mkosi [Optionen…] journalctl [Befehlszeile…]
mkosi [Optionen…] coredumpctl [Befehlszeile…]
mkosi [Optionen…] clean
mkosi [Optionen…] serve
mkosi [Optionen…] burn <Gerät>
mkosi [Optionen…] bump
mkosi [Optionen…] genkey
mkosi [Optionen…] documentation
mkosi [Optionen…] help
BESCHREIBUNG
mkosi ist ein Werkzeug zum leichten Bau angepasster Betriebssystemabbilder. Es ist kunstvolle Hülle für
dnf --installroot, apt, pacman und zypper, die Plattenabbilder mit einer Reihe von Schnickschack erstel‐
len 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 Konfigurati‐
onsdateien 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 dar‐
in eine interaktive Shell-Eingabeauforderung zu erlanben. Nach dem Unterbefehl shell kann eine op‐
tionale 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 qemu, um das Abbild zu starten, d.h. anstelle einer Contai‐
ner-Virtualisierung wird eine Virtualisierung einer virtuellen Maschine verwandt. Dieser Unterbe‐
fehl wird nur für Plattenabbilder unterstützt, die ein Systemstartladeprogramm und CPIO-Abbilder
enthalten, in denen ein Kernel installiert wurde. Für CPIO-Abbilder kann ein Kernel auch durch
Übergabe des Qemu-Arguments -kernel an den Unterbefehl qemu bereitgestellt werden. Alle nach dem
Unterbefehl qemu angegebenen Argumente werden an den Aufruf von qemu angehängt.
vmspawn
Ähnlich wie boot, verwendet aber systemd-vmspawn(1), um das Abbild zu starten, d.h. anstelle einer
Container-Virtualisierung wird eine Virtualisierung einer virtuellen Maschine verwandt. Dieser Un‐
terbefehl wird nur für platten- und verzeichnisartige Abbilder unterstützt. Alle nach dem Unterbe‐
fehl vmspawn angegebenen Argumente werden an den Aufruf von systemd-vmspawn(1) angehängt.
ssh Wenn das Abbild mit der Option Ssh=yes gebaut wird, verbindet dieser Befehl die gestartete virtu‐
elle Maschine (qemu) mittels SSH. Stellen Sie sicher, dass mkosi ssh mit der gleichen Konfigurati‐
on 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üs‐
sel aus der Einstellung SshKey= verwandt, um sich mit der virtuellen Maschine zu verbinden. Ver‐
wenden 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 ma‐
chinectl login oder machinectl shell.
journalctl
Verwendet journalctl(1), um das Journal innerhalb des Abbildes zu untersuchen. Alle nach dem Un‐
terbefehl journalctl angegebenen Argumente werden an den Aufruf von journalctl(1) angehängt.
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.
clean Entfernt aus vorherigen Bauläufen erstellte Bauartefakte. Falls mit -f kombiniert, werden auch in‐
krementelle Bauzwischenspeicher-Abbilder entfernt. Falls -f zweimal angegeben ist, werden sämtli‐
che 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 neuzubau‐
en, 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 Versionszeichen‐
kette 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 Ver‐
sion nach jedem erfolgreichen Bau verwandt werden kann.
genkey Erstellt ein Paar von SecureBoot-Schlüsseln zur Verwendung mit den Optionen SecureBootKey=/--secu‐
re-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 Ver‐
zeichnis mkosi/resources des Python-Pakets abzulegen, falls sie dort fehlt, sowie sie im geeigne‐
ten 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 wer‐
den.
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 ver‐
weigert 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 Datei‐
en) 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 Aus‐
wirkung: Standardmäßig wird der Unterbefehl nur Bauartefakte aus dem vorherigen Lauf entfernen,
durch einmalige Angabe werden auch die inkrementellen Zwischenspeicherdateien gelöscht, bei dop‐
pelter Angabe wird auch der Paketezwischenspeicher entfernt.
--directory=, -C
Akzeptiert einen Pfad zu einem Verzeichnis. Bevor es etwas macht, wechselt mkosi in dieses Ver‐
zeichnis. 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 ver‐
wandt wird. Standardmäßig mkosi of %u, wobei %u auf den Benutzernamen des Benutzer, der Mkosi auf‐
ruft, 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 Versions‐
management nützlich: jeder Bau in einer Reihe wird eine um eins gegenüber dem vorherigen Bau er‐
hö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 Mark‐
down-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/ ab‐
gelegt 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 Kopie‐
ren-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 Befehlszeilenpa‐
rameter ist auch eine Abkürzung mit einem Buchstaben erlaubt. In den Konfigurationsdateien muss die Ein‐
stellung in dem korrekten Abschnitt erfolgen, daher sind die Einstellungen nachfolgend gemäß des Ab‐
schnittes 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 äquiva‐
lent) sein und ist für lokale Konfiguration gedacht.
• Alle Vorgabepfade (abhängig von der Option) werden konfiguriert, falls der entsprechende Pfad exi‐
stiert.
• mkosi.conf wird ausgewertet, falls es in dem mit --directory= konfigurierten Verzeichnis liegt oder im
aktuellen Verzeichnis, falls --directory= nicht verwandt wird.
• mkosi.conf.d/ wird im gleichen Verzeichnis ausgewertet, falls sie existiert. Jedes Verzeichnis und jede
Datei mit der Endung .conf in mkosi.conf.d/ wird ausgewertet. Jedes Verzeichnis in mkosi.conf.d wird
ausgewertet, also ob es ein normales Verzeichnis auf der obersten Ebene wäre.
Beachten Sie, dass bei doppelter Konfiguration einer Einstellung die spätere Zuweisung die frühere Zuwei‐
sung außer Kraft setzt, außer die Zuweisung ist eine Listen-basierte Einstellung. Beachten Sie auch, dass
vor v16 das Gegenteil passierte, wo eine frühere Zuweisung statt einer späteren Zuweisung verwandt worden
wäre.
Einstellungen, die einen Listenwert akzeptieren, werden zusammengeführt, indem neue Werte an die bereits
konfigurierten Werte angehängt werden. Durch Zuweisung einer leeren Zeichenkette zu einer solchen Ein‐
stellung werden alle vorher zugewiesenen Werte entfernt und auch alle konfigurierten Standardwerte außer
Kraft gesetzt.
Falls dem Namen einer Einstellung in der Konfigurationsdatei @ vorangestellt wird, konfiguriert sie den
für diese Einstellung verwandten Vorgabewert, falls kein expliziter Vorgabewert gesetzt ist. Dies kann
zum Setzen angepasster Vorgabewerte in Konfigurationsdateien verwandt werden, die weiterhin durch expli‐
zite Angabe der Einstellung auf der Befehlszeile außer Kraft gesetzt werden können.
Um Konfigurationsdateien bedingt einzubinden, kann der Abschnitt [Match] verwandt werden. Ein Abschnitt
[Match] besteht aus einzelnen Bedingungen. Bedingungen können ein Weiterleitungssymbol (|) nach dem
Gleichheitszeichen verwenden (…=|…). Dadurch wird die Bedingung eine auslösende Bedingung. Die Konfigura‐
tionsdatei 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 Ausrufezei‐
chen vorangestellt wird, muss das Weiterleitungssymbol zuerst angegeben werden und anschließend das Aus‐
rufezeichen.
Beachten Sie, dass die Bedingungen in [Match] mit den aktuellen Werten einer bestimmten Einstellung ver‐
glichen werden und keine Änderungen an Einstellungen berücksichtigen, die in Konfigurationsdateien be‐
reits erfolgten, aber noch nicht ausgewertet wurden. Beachten Sie auch, dass das Prüfen der Übereinstim‐
mung mit einer Einstellung und das anschließende Ändern in einer anderen Konfigurationsdatei zu unerwar‐
teten Ergebnissen führen kann.
The [Match] section of a mkosi.conf file in a directory applies to the entire directory. If the conditi‐
ons 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 fol‐
genden 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 condi‐
tions 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, fal‐
se to disable.
Abschnitt [Match]
Profile=
Übereinstimmung mit dem konfigurierten Profil.
Distribution=
Übereinstimmung mit der konfigurierten Distribution.
Release=
Übereinstimmung mit der konfigurierten Distributionsveröffentlichung. Falls diese Bedingung ver‐
wandt 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.
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 Bedin‐
gung verwandt wird und noch keine Abbildkennung explizit konfiguriert wurde, schlägt diese Bedin‐
gung 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 specifi‐
cation. If no operator is prepended, the equality operator is assumed by default. If this conditi‐
on 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 For‐
mat= 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 as‐
sumed by default.
BuildSources=
Takes a build source target path (see BuildSources=). This match is satisfied if any of the confi‐
gured 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
The drop-in will be included.
Alle an diese Einstellung übergebenen absoluten Pfade werden relativ zum aktuellen Arbeitsver‐
zeichnis interpretiert.
HostArchitecture=
Matches against the host’s native architecture. See the Architecture= setting for a list of possi‐
ble values.
Übereinstimmer Globs Umfangreicher Ver‐ Vorgabe
gleich
─────────────────────────────────────────────────────────────────────────────────
Profile= no no Übereinstimmung schlägt
fehl
Distribution= no no Übereinstimmung mit Dis‐
tribution des Wirtsystems
Release= no no Übereinstimmung mit Ver‐
öffentlichung des Wirtsy‐
stems
Architecture= no no Übereinstimmung mit Ar‐
chitektur 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 auto‐
matischer Funktionalität
Format= no no Übereinstimmung mit Stan‐
dardformat
SystemdVersion= no yes n.Z.
BuildSources= no no Übereinstimmung schlägt
fehl
HostArchitecture= 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 mko‐
si.conf file, but before any mkosi.conf.d/*.conf drop in configuration.
Include=, --include=
Bindet zusätzliche Konfiguration aus der angegebenen Datei oder dem Verzeichnis ein. Die zusätzli‐
che Konfiguration wird direkt nach der Auswertung der Einstellung eingebunden, außer wenn mittels
@Include= eine Vorgabe gesetzt wird. In letzterem Fall wird die Konfiguration nach der Auswertung
aller anderen Konfigurationsdateien eingebunden. Beachten Sie, dass jeder Pfad, der zusätzliche
Konfiguration enthält, nur einmal ausgewertet wird, selbst wenn er mehr als einmal mit Include=
eingebunden wird. Die eingebaute Konfiguration für die Standard-Mkosi-Initrd und dem Standardwerk‐
zeugbaum kann durch Einbinden des wörtlichen Wertes mkosi-initrd bzw. mkosi-tools erfolgen. Beach‐
ten Sie: Eingebundene Namen, die mit einem der wörtlichen Zeichenketten mkosi- oder contrib- be‐
ginnen, sind für die Verwendung durch Mkosi selbst reserviert.
InitrdInclude=, --initrd-include=
Same as Include=, but the extra configuration files or directories are included when building the
default initrd.
Images=, --image=
Falls verwandt wird nur das angegebene Abbild gebaut. Kann mehrfach zum Bau mehrerer Abbilder ver‐
wandt werden. Alle angegeben Abbilder und ihre Abhängigkeiten werden gebaut. Falls nicht verwandt
werden alle Abbilder gebaut. Siehe den Abschnitt Bau mehrerer Abbilder für weitere Informationen.
Beachten Sie, dass dieser Abschnitt nur berücksichtigt wird, wenn er in der globalen Konfigurati‐
onsdatei verwandt wird. In Abbild-spezifischen Einstellungen hat er keine Auswirkung.
Dependencies=, --dependency=
The images that this image depends on specified as a comma-separated list. All images configured
in this option will be built before this image and will be pulled in as dependencies of this image
when Images= is used.
MinimumVersion=, --minimum-version=
Die minimale Version von Mkosi, die zum Bau dieser Konfiguration benötigt wird. Falls mehrfach an‐
gegeben, wird die höchste festgelegte Version verwandt.
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. art‐
ful). 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=
The architecture to build the image for. The architectures that are actually supported depends on
the distribution used and whether a bootable image is requested or not. When building for a for‐
eign architecture, you’ll also need to install and register a user mode emulator for that archi‐
tecture. One of the following architectures can be specified per image built: 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-Spie‐
gel fürjede Distribution ist wie folgt (sofern nicht angegeben, wird der gleiche Spiegel für alle
Architekturen verwandt):
X86-64 Aarch64
─────────────────────────────────────────────────────────────────────────────
Debian http://deb.debian.org/debian
arch https://geo.mirror.pkg‐ http://mirror.archlinux‐
build.com arm.org
Opensuse http://download.opensuse.org
Ubuntu http://archive.ubuntu.com http://ports.ubuntu.com
Centos https://mirrors.centos.org
Rocky https://mirrors.rocky‐
linux.org
Alma https://mirrors.almalinux.org
Fedora https://mirrors.fedorapro‐
ject.org
RHEL-ubi https://cdn-ubi.redhat.com
Mageia https://www.mageia.org
Openmandriva http://mirrors.openmandri‐
va.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=
Takes one of none, metadata or always. If always, the package manager is instructed not to contact
the network. This provides a minimal level of reproducibility, as long as the package cache is al‐
ready fully populated. If set to metadata, the package manager can still download packages, but we
won’t sync the repository metadata. If set to none, the repository metadata is synced and packages
can be downloaded during the build.
PackageManagerTrees=, --package-manager-tree=
This option mirrors the above SkeletonTrees= option and defaults to the same value if not configu‐
red otherwise, but installs the files to a subdirectory of the workspace directory instead of the
OS tree. This subdirectory of the workspace is used to configure the package manager. 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 loca‐
tions 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 PackageMana‐
gerTrees= fulfill similar roles. Use SkeletonTrees= if you want the files to be present in the fi‐
nal 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 reposi‐
tory configuration.
Abschnitt [Output]
Format=, --format=, -t
The image format type to generate. One of directory (for generating an OS image directly in a lo‐
cal directory), tar (similar, but a tarball of the OS image is generated), cpio (similar, but a
cpio archive is generated), disk (a block device OS image with a GPT partition table), uki (a uni‐
fied kernel image with the OS image in the .initrd PE section), esp (uki but wrapped in a disk
image with only an ESP partition), sysext, confext, portable or none (the OS image is solely in‐
tended as a build image to produce another artifact). If the disk output format is used, the disk
image is generated using systemd-repart. The repart partition definition files to use can be con‐
figured using the RepartDirectories= setting or via mkosi.repart/. When verity partitions are con‐
figured using systemd-repart’s Verity= setting, mkosi will automatically parse the verity hash
partition’s roothash from systemd-repart’s JSON output and include it in the kernel command line
of every unified kernel image built by mkosi.
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
Name to use for the generated output image file or directory. All outputs will be prefixed with
the given name. Defaults to image or, if ImageId= is specified, it is used as the default output
name, optionally suffixed with the version set with ImageVersion=. Note that this option does not
allow configuring the output directory, use OutputDirectory= for that. Note that this only speci‐
fies the output prefix, depending on the specific output format, compression and image version
used, the full output name might be image_7.8.raw.xz.
CompressOutput=, --compress-output=
Configure compression for the resulting image or archive. The argument can be either a boolean or
a compression algorithm (xz, zstd). zstd compression is used by default, except CentOS and deriva‐
tives up to version 8, which default to xz. Note that when applied to block device image types,
compression means the image cannot be started directly but needs to be decompressed first. This
also means that the shell, boot, qemu verbs are not available when this option is used. Implied
for tar, cpio, uki, and esp.
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 di‐
rectory mkosi.output/ exists in the local directory, it is automatically used for this purpose.
WorkspaceDirectory=, --workspace-dir=
Path to a directory where to store data required temporarily while building the image. This direc‐
tory should have enough space to store the full OS image, though in most modes the actually used
disk space is smaller. If not specified, a subdirectory of $XDG_CACHE_HOME (if set), $HOME/.cache
(if set) or /var/tmp is used. The data in this directory is removed automatically after each
build. It’s safe to manually remove the contents of this directory should an mkosi invocation be
aborted abnormally (for example, due to reboot/power failure).
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 ein‐
gesetzten Distributionspaketverwalter verwandt wird. Falls nicht gesetzt, wird ein geeignetes Ver‐
zeichnis 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=
Configure the image version. This accepts any string, but it is recommended to specify a series of
dot separated components. The version may also be configured in a file mkosi.version in which case
it may be conveniently managed via the bump verb or the --auto-bump option. When specified the
image version is included in the default output file name, i.e. instead of image.raw the default
will be image_0.1.raw for version 0.1 of the image, and similar. The version is also passed via
the $IMAGE_VERSION to any build scripts invoked (which may be useful to patch it into /etc/os-re‐
lease or similar, in particular the IMAGE_VERSION= field of it).
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 ver‐
sion). 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.freedesk‐
top.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 rela‐
tive 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=
Specifies whether to build disk images using loopback devices. Enabled by default. When enabled,
systemd-repart will not use loopback devices to build disk images. When disabled, systemd-repart
will always use loopback devices to build disk images. Note that when using RepartOffline=no mkosi
cannot run unprivileged and the image build has to be done as the root user outside of any contai‐
ners and with loopback devices available on the host system. There are currently two known scena‐
rios where RepartOffline=no has to be used. The first is when using Subvolumes= in a repart parti‐
tion definition file, as subvolumes cannot be created without using loopback devices. The second
is when creating a system with SELinux and an XFS root partition. Because mkfs.xfs does not sup‐
port populating an XFS filesystem with extended attributes, loopback devices have to be used to
ensure the SELinux extended attributes end up in the generated XFS filesystem.
Overlay=, --overlay
When used together with BaseTrees=, the output will consist only out of changes to the specified
base trees. Each base tree is attached as a lower layer in an overlayfs structure, and the output
becomes the upper layer, initially empty. Thus files that are not modified compared to the base
trees will not be present in the final output. This option may be used to create systemd system
extensions or portable services (https://uapi-group.org/specifications/specs/extension_image).
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=
Takes a timestamp as argument. Resets file modification times of all files to this timestamp. The
variable is also propagated to systemd-repart and scripts executed by mkosi. If not set explicit‐
ly, SOURCE_DATE_EPOCH from --environment and from the host environment are tried in that order.
This is useful to make builds reproducible. See SOURCE_DATE_EPOCH (https://reproducib‐
le-builds.org/specs/source-date-epoch/) for more information.
Abschnitt [Content]
Packages=, --package=, -p
Install the specified distribution packages (i.e. RPM, DEB, ...) in the image. Takes a comma sepa‐
rated 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 argu‐
ment 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, paths to packages in the file system, package groups, and virtual provides, including
file paths. 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-*
prebuilt/rpms/systemd-249-rc1.local.rpm
/usr/bin/ld
@development-tools
python3dist(mypy)
: Note that since mkosi runs in a sandbox with most of the host files unavailable, any local packages
have to be mounted into the sandbox explicitly using BuildSources=. For example, let’s say we have a lo‐
cal package located at ../my-packages/abc.rpm relative to the mkosi working directory, then we’d be able
to install it as follows:
BuildSources=../my-packages:my-packages-in-sandbox
Packages=my-packages-in-sandbox/abc.rpm
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 sy‐
stems, linkers and other build tools the mkosi.build scripts require to operate. Note that packa‐
ges listed here will be absent in the final image.
PackageDirectories=, --package-directory=
Specify directories containing extra packages to be made available during the build. mkosi will
create a local repository containing all packages in these directories and make it available when
installing packages or running scripts. Note that this local repository is also made available
when running scripts. Build scripts can add more packages to the local repository by placing the
built packages in $PACKAGEDIR.
WithRecommends=, --with-recommends=
Konfiguriert, ob empfohlene Pakete oder schwache Abhängigkeiten installiert werden, abhängig da‐
von, 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 distribu‐
tion package manager supports it documentation is not included in the image. The $WITH_DOCS envi‐
ronment variable passed to the mkosi.build scripts is set to 0 or 1 depending on whether this op‐
tion is enabled or disabled.
BaseTrees=, --base-tree=
Takes a comma separated list of paths to use as base trees. When used, these base trees are each
copied into the OS tree and form the base distribution instead of installing the distribution from
scratch. Only extra packages are installed on top of the ones already installed in the base trees.
Note that for this to work properly, the base image still needs to contain the package manager me‐
tadata by setting CleanPackageMetadata=no (see CleanPackageMetadata=). Instead of a directory, a
tar file or a disk image may be provided. In this case it is unpacked into the OS tree. This mode
of operation allows setting permissions and file ownership explicitly, in particular for projects
stored in a version control system such as git which retain full file ownership and access mode
metadata for committed files.
SkeletonTrees=, --skeleton-tree=
Takes a comma separated list of colon separated path pairs. The first path of each pair refers to
a directory to copy into the OS tree before invoking the package manager. The second path of each
pair refers to the target directory inside the image. If the second path is not provided, the di‐
rectory is copied on top of the root directory of the image. The second path is always interpreted
as an absolute path. Use this to insert files and directories into the OS tree before the package
manager installs any packages. If the mkosi.skeleton/ directory is found in the local directory it
is also used for this purpose with the root directory as target (also see the Files section be‐
low). 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=
Takes a comma separated list of colon separated path pairs. The first path of each pair refers to
a directory to copy from the host into the image. The second path of each pair refers to the tar‐
get directory inside the image. If the second path is not provided, the directory is copied on top
of the root directory of the image. The second path is always interpreted as an absolute path. Use
this to override any default configuration files shipped with the distribution. If the mkosi.ex‐
tra/ directory is found in the local directory it is also used for this purpose with the root di‐
rectory as target. (also see the Files section below). As with the base tree logic above, instead
of a directory, a tar file may be provided too. mkosi.extra.tar will be automatically used if
found in the local directory.
RemovePackages=, --remove-package=
Takes a comma-separated list of package specifications for removal, in the same format as Packa‐
ges=. The removal will be performed as one of the last steps. This step is skipped if CleanPacka‐
geMetadata=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 instal‐
lation. Can be specified as true, false, or auto (the default). With auto, package manager databa‐
ses 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-Installationsskrip‐
te 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.
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 directo‐
ry is mounted to /work/src.
BuildSourcesEphemeral=, --build-sources-ephemeral=
Takes a boolean. Disabled by default. Configures whether changes to source directories (The
working directory and configured using BuildSources=) are persisted. If enabled, all source direc‐
tories will be reset to their original state after scripts (except sync scripts) finish executing.
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 environ‐
ment 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 va‐
riables 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 pro‐
cess. 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 de‐
fault, 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 net‐
work.
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=
Takes one of none, systemd-boot, uki or grub. Defaults to systemd-boot. If set to none, no EFI
bootloader will be installed into the image. If set to systemd-boot, systemd-boot will be instal‐
led and for each installed kernel, a UKI will be generated and stored in EFI/Linux in the ESP. If
set to uki, a single UKI will be generated for the latest installed kernel (the one with the hig‐
hest version) which is installed to EFI/BOOT/BOOTX64.EFI in the ESP. If set to grub, for each in‐
stalled kernel, a UKI will be generated and stored in EFI/Linux in the ESP. For each generated
UKI, a menu entry is appended to the grub configuration in grub/grub.cfg in the ESP which chain‐
loads into the UKI. A shim grub.cfg is also written to EFI/<distribution>/grub.cfg in the ESP
which loads grub/grub.cfg in the ESP for compatibility with signed versions of grub which load the
grub configuration from this location. Note that we do not yet install grub to the ESP when Boot‐
loader= is set to grub. This has to be done manually in a postinst or finalize script. The grub
EFI binary should be installed to /efi/EFI/BOOT/BOOTX64.EFI (or similar depending on the architec‐
ture) and should be configured to load its configuration from EFI/<distribution>/grub.cfg in the
ESP. Signed versions of grub shipped by distributions will load their configuration from this lo‐
cation by default.
BiosBootloader=, --bios-bootloader=
Takes one of none or grub. Defaults to none. If set to none, no BIOS bootloader will be installed.
If set to grub, grub is installed as the BIOS boot loader if a bootable image is requested with
the Bootable= option. If no repart partition definition files are configured, mkosi will add a
grub BIOS boot partition and an EFI system partition to the default partition definition files.
Note that this option is not mutually exclusive with Bootloader=. It is possible to have an image
that is both bootable on UEFI and BIOS by configuring both Bootloader= and BiosBootloader=. The
grub BIOS boot partition should have UUID 21686148-6449-6e6f-744e-656564454649 and should be at
least 1MB. Even if no EFI bootloader is installed, we still need an ESP for BIOS boot as that’s
where we store the kernel, initrd and grub modules.
ShimBootloader=, --shim-bootloader=
Takes one of none, unsigned, or signed. Defaults to none. If set to none, shim and MokManager will
not be installed to the ESP. If set to unsigned, mkosi will search for unsigned shim and MokMana‐
ger EFI binaries and install them. If SecureBoot= is enabled, mkosi will sign the unsigned EFI bi‐
naries before installing thel. If set to signed, mkosi will search for signed EFI binaries and in‐
stall those. Even if SecureBoot= is enabled, mkosi won’t sign these binaries again. Note that this
option only takes effect when an image that is bootable on UEFI firmware is requested using other
options (Bootable=, Bootloader=). Note that when this option is enabled, mkosi will only install
already signed bootloader binaries, kernel image files and unified kernel images as self-signed
binaries would not be accepted by the signed version of shim.
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 al‐
ways 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 avail‐
able. Otherwise Type 1 entries as defined by the Boot Loader Specification will be used instead.
If disabled, Type 1 entries will always be used.
Initrds=, --initrd
Vom Benutzer bereitgestellte Initrd(s). Akzeptiert eine Kommata-getrennte Liste von Pfaden zu Ini‐
trd-Dateien. Diese Option kann mehrfach angewendet werden. Dann werden die aufgeführten Initrd-Li‐
sten kombiniert. Falls keine Initirds angegeben sind und ein startbares Medium erbeten wurde, wird
Mkosi automatisch eine Standard-Initrd bauen.
InitrdPackages=, --initrd-package=
Extra-Pakete, die in die Standard-Initrd installiert werden sollen. Akzeptiert eine Kommata-ge‐
trennte Liste von Paketspezifikationen. Diese Option kann mehrfach angewendet werden. Dann werden
die aufgeführten Paketlisten kombiniert.
MicrocodeHost=, --microcode-host=
Wenn auf wahr gesetzt, wird nur der Mikrocode für die CPU des Wirtsystems in dem Abbild aufgenom‐
men.
KernelCommandLine=, --kernel-command-line=
Use the specified kernel command line when building images. Defaults to console=ttyS0. For arm,
s390 and ppc, ttyS0 is replaced with ttyAMA0, ttysclp0 or hvc0, respectively.
KernelModulesInclude=, --kernel-modules-include=
Takes a list of regex patterns that specify kernel modules to include in the image. Patterns
should be relative to the /usr/lib/modules/<kver>/kernel directory. mkosi checks for a match any‐
where in the module path (e.g. i915 will match against drivers/gpu/drm/i915.ko). All modules that
match any of the specified patterns are included in the image. All module and firmware dependenci‐
es of the matched modules are included in the image as well. This setting takes priority over Ker‐
nelModulesExclude= and only makes sense when used in combination with it because all kernel modu‐
les are included in the image by default.
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 exclu‐
ded from the image.
KernelModulesIncludeHost=, --kernel-modules-include-host=
Takes a boolean. Specifies whether to include the currently loaded modules on the host system in
the image. This setting takes priority over KernelModulesExclude= and only makes sense when used
in combination with it because all kernel modules are included in the image by default.
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 er‐
stellt, 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 notwen‐
digen 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 ini‐
trd.
KernelModulesInitrdExclude=, --kernel-modules-initrd-exclude=
Like KernelModulesExclude=, but applies to the kernel modules included in the kernel modules ini‐
trd.
KernelModulesInitrdIncludeHost=, --kernel-modules-initrd-include-host=
Like KernelModulesIncludeHost=, 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=, Timezo‐
ne=, --timezone=, Hostname=, --hostname=, RootShell=, --root-shell= correspond to the identically
named systemd-firstboot options. See the systemd firstboot manpage (https://www.freedesk‐
top.org/software/systemd/man/systemd-firstboot.html) for more information. Additionally, where ap‐
plicable, the corresponding systemd credentials for these settings are written to /usr/lib/cred‐
store, 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
Enable autologin for the root user on /dev/pts/0 (nspawn), /dev/tty1 and /dev/ttyS0.
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 expo‐
se SSH over VSock. When building with this option and running the image using mkosi qemu, the mko‐
si 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 ma‐
chinectl.
SELinuxRelabel=, --selinux-relabel=
Specifies whether to relabel files to match the image’s SELinux policy. Takes a boolean value or
auto. Defaults to auto. If disabled, files will not relabeled. If enabled, an SELinux policy has
to be installed in the image and setfiles has to be available to relabel files. If any errors oc‐
cur during setfiles, the build will fail. If set to auto, files will be relabeled if an SELinux
policy is installed in the image and if setfiles is available. Any errors occurred during setfiles
will be ignored. Note that when running unprivileged, setfiles will fail to set any labels that
are not in the host’s SELinux policy. To ensure setfiles succeeds without errors, make sure to run
mkosi as root or build from a host system with the same SELinux policy as the image you’re buil‐
ding.
Abschnitt [Validation]
SecureBoot=, --secure-boot
Signiert systemd-boot(7) (falls es noch nicht signiert ist) und sämtliche vereinigten Kernelabbil‐
der 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 sy‐
stemd-boot man page (https://www.freedesktop.org/software/systemd/man/systemd-boot.html) if Secu‐
reBoot= is used. Note that systemd-boot will only do automatic secure boot key enrollment in vir‐
tual 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 speci‐
fied, the input type depends on the source.
SecureBootKeySource=, --secure-boot-key-source=
Quelle von SecureBootKey=, um OpenSSL-Einheiten zu unterstützen. Beispiel: --secu‐
re-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 au‐
to. 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 si‐
gnature 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 ei‐
ne 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 cryptset‐
up 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 key‐
ring.
Abschnitt [Host]
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 di‐
rectory 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.
QemuGui=, --qemu-gui=
Falls aktiviert, wird Qemu mit seiner graphischen Oberfläche anstelle einer seriellen Konsole aus‐
gefü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.
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. Ta‐
kes 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=
When used with the qemu verb, this option specifies the vsock connection ID to use. Takes a number
in the interval [3, 0xFFFFFFFF) or hash or auto. Defaults to hash. When set to hash, the connec‐
tion ID will be derived from the full path to the image. When set to auto, mkosi will try to find
a free connection ID automatically. Otherwise, the provided number will be used as is. Note that
when set to auto, mkosi ssh cannot be used as we cannot figure out which free connection ID we
found when booting the image earlier.
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 ma‐
chine 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, ue‐
fi-secure-boot, bios, linux, or auto. Defaults to auto. When set to uefi, the OVMF firmware wi‐
thout 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 alre‐
ady enrolled will be used. When set to custom, the secure boot certificate from SecureBootCertifi‐
cate= will be enrolled into the default firmware variables file. virt-fw-vars from the virt-firm‐
ware (https://gitlab.com/kraxel/virt-firmware) project can be used to customize OVMF variable
files.
QemuKernel=, --qemu-kernel=
Set the kernel image to use for qemu direct kernel boot. If not specified, mkosi will use the ker‐
nel provided via the command line (-kernel option) or latest the kernel that was installed into
the image (or fail if no kernel was installed into the image). Note that when the cpio output for‐
mat is used, direct kernel boot is used regardless of the configured firmware. Depending on the
configured firmware, qemu might boot the kernel itself or using the configured firmware.
QemuDrives=, --qemu-drive=
Add a qemu drive. Takes a colon-delimited string of format <id>:<size>[:<directory>[:<options>]].
id specifies the qemu id we assign to the drive. This can be used as the drive= property in va‐
rious qemu devices. size specifies the size of the drive. This takes a size in bytes. Additional‐
ly, the suffixes K, M and G can be used to specify a size in kilobytes, megabytes and gigabytes
respectively. directory optionally specifies the directory in which to create the file backing the
drive. options optionally specifies extra comma-delimited properties which are passed verbatim to
qemu’s -drive option. Example usage:
[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 key=value assignments.
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ätz‐
liches 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 entfer‐
nen.
ToolsTree=, --tools-tree=
If specified, programs executed by mkosi to build and boot an image are looked up inside the given
tree instead of in the host system. Use this option to make image builds more reproducible by al‐
ways using the same versions of programs to build the final image instead of whatever version is
installed on the host system. If this option is not used, but the mkosi.tools/ directory is found
in the local directory it is automatically used for this purpose with the root directory as tar‐
get. Note that when looking up binaries in --tools-tree=, only /usr/bin and /usr/sbin are conside‐
red. Specifically, paths specified by --extra-search-path= are ignored when looking up binaries in
the given tools tree. If set to default, mkosi will automatically add an extra tools tree image
and use it as the tools tree. The following table shows for which distributions default tools tree
packages are defined and which packages are included in those default tools trees:
Fedora CentOS Debian Ubuntu Arch openSUSE
─────────────────────────────────────────────────────────────────────────────────────────
acl X X X X X X
apt X X X X X
archlinux-keyring X X X X
attr X X X X X X
bash X X X X X X
btrfs-progs X X X X X
bubblewrap X X X X X X
ca-certificates X X X X X X
coreutils X X X X X X
cpio X X X X X X
curl X X X X X X
debian-keyring X X X X X
diffutils X X X X X X
distribution-gpg-keys X X X
dnf X X X X X X
dnf-plugins-core X X X
dnf5 X
dnf5-plugins X
dosfstools X X X X X X
e2fsprogs X X X X X X
edk2-ovmf X X X X X X
erofs-utils X X X X X
findutils X X X X X X
git X X X X X X
grep X X X X X X
jq X X X X X X
kmod X X X X X X
less X X X X X X
mtools X X X X X X
nano X X X X X X
openssh X X X X X X
openssl X X X X X X
sed X X X X X X
pacman X X X X
pesign X X X X X X
policycoreutils X X X X X
qemu X X X X X X
sbsigntools X X X X X
socat X X X X X X
squashfs-tools X X X X X X
strace X X X X X X
swtpm X X X X X X
systemd X X X X X X
ukify X X X X X
tar X X X X X X
ubuntu-keyring X X X X X
util-linux X X X X X X
virtiofsd X X X X
virt-firmware X X X
xfsprogs X X X X X X
xz X X X X X X
zstd X X X X X X
zypper X X X X
ToolsTreeDistribution=, --tools-tree-distribution=
Setzt die für den Standard-Werkzeugbaum zu verwendende Distribution. Standardmäßig wird die glei‐
che 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.
RuntimeTrees=, --runtime-tree=
Takes a colon separated pair of paths. The first path refers to a directory to mount into any ma‐
chine (container or VM) started by mkosi. The second path refers to the target directory inside
the machine. If the second path is not provided, the directory is mounted below /root/src in the
machine. If the second path is relative, it is interpreted relative to /root/src in the machine.
For each mounted directory, the uid and gid of the user running mkosi are mapped to the root user
in the machine. This means that all the files and directories will appear as if they’re owned by
root in the machine, and all new files and directories created by root in the machine in these di‐
rectories will be owned by the user running mkosi on the host. Note that when using mkosi qemu
with this feature systemd v254 or newer has to be installed in the image.
RuntimeSize=, --runtime-size=
If specified, disk images are grown to the specified size before they’re booted with sy‐
stemd-nspawn or qemu. Takes a size in bytes. Additionally, the suffixes K, M and G can be used to
specify a size in kilobytes, megabytes and gigabytes respectively.
RuntimeScratch=: --runtime-scratch=
Takes a boolean value or auto. Specifies whether to mount extra scratch space to /var/tmp. If en‐
abled, practically unlimited scratch space is made available under /var/tmp when booting the image
with mkosi qemu, mkosi boot or mkosi shell. Note that using this feature with mkosi qemu requires
systemd v254 or newer in the guest.
RuntimeNetwork=: --runtime-network=
Takes one of user, interface or none. Defaults to user. Specifies the networking to set up when
booting the image. user sets up usermode networking. interface sets up a virtual network connec‐
tion between the host and the image. This translates to a veth interface for mkosi shell and mkosi
boot and a tap interface for mkosi qemu and mkosi vmspawn. Note that when using interface, mkosi
does not automatically configure the host interface. It is expected that a recent version of sy‐
stemd-networkd is running on the host which will automatically configure the host interface of the
link.
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.
Kennzeichner
The current value of various settings can be accessed when parsing configuration files by using speci‐
fiers. 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
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 distributi‐
on, 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 --in‐
cremental 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. 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.
4. Abtrennen des Einhängenamensraums
5. Schreibgeschütztes Einhängen der folgenden Verzeichnisse, falls sie existieren:
• /usr
• /etc
• /opt
• /srv
• /boot
• /efi
• /media
• /mnt
Führen Sie dann für jedes Abbild die folgenden Schritte aus:
1. Kopieren der Paketverwalterbäume in den Arbeitsbereich
2. Synchronisieren der Depot-Metadaten des Paketverwalters
3. Copy base trees (--base-tree=) into the image
4. Wiederbenutzung eines zwischengespeicherten Abbilds, falls verfügbar
5. Kopieren eines Schnappschusses der Depot-Metadaten des Paketverwalters in das Abbild
6. Copy skeleton trees (mkosi.skeleton) into image
7. Installieren der Distributioon und Paketen in das Abbild
8. Run prepare scripts on image with the final argument (mkosi.prepare)
9. Installieren der Baupakete in der Überlagerung, falls irgendwelche Bauskripte konfiguriert sind
10. Run prepare scripts on overlay with the build argument if any build scripts are configured (mko‐
si.prepare)
11. Cache the image if configured (--incremental)
12. Run build scripts on image + overlay if any build scripts are configured (mkosi.build)
13. Finalize the build if the output format none is configured
14. Kopieren der Bauskripteausgabe in das Abbild
15. Copy the extra trees into the image (mkosi.extra)
16. Run post-install scripts (mkosi.postinst)
17. Write config files required for Ssh=, Autologin= and MakeInitrd=
18. Install systemd-boot and configure secure boot if configured (--secure-boot)
19. Run systemd-sysusers
20. Run systemd-tmpfiles
21. Run systemctl preset-all
22. Run depmod
23. Run systemd-firstboot
24. Run systemd-hwdb
25. Remove packages and files (RemovePackages=, RemoveFiles=)
26. SELinux-Neumarkierung ausführen, falls eine SELinux-Richtlinie installiert ist
27. Run finalize scripts (mkosi.finalize)
28. Vereinigtes Kernelabbild ausführen, falls so konfiguriert
29. Finales Ausgabeformat erstellen
Skripte
To allow for image customization that cannot be implemented using mkosi’s builtin features, mkosi sup‐
ports 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 name‐
space 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.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 Build‐
SourcesEphemeral= 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 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.
• $DISTRIBUTION contains the distribution from the Distribution= setting.
• $RELEASE contains the release from the Release= setting.
• $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 prima‐
ry 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 pre‐
vious 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 $DEST‐
DIR 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.
• $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 execut‐
ed (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, Environ‐
ment=SOURCE_DATE_EPOCH=TIMESTAMP or the host environment variable $SOURCE_DATE_EPOCH). This is useful
to make builds reproducible. See SOURCE_DATE_EPOCH (https://reproducib‐
le-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 --re‐
gid=$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.
In dieser Tabelle können Sie ersehen, welches Skript welche Umgebungsvariable erhält:
Variable mko‐ mkosi.prepa‐ mko‐ mkosi.post‐ mkosi.fina‐
si.sync re si.build inst lize
_
ARCHITECTURE X X X X X
DISTRIBUTION X X X X X
RELEASE X X X X X
PROFILE X X X X X
CACHED X
CHROOT_SCRIPT X X X X
SRCDIR X X X X X
CHROOT_SRCDIR X X X X
BUILDDIR X
CHROOT_BUILD‐ X
DIR
DESTDIR X
CHROOT_DESTDIR X
OUTPUTDIR X X X
CHROOT_OUTPUT‐ X X X
DIR
BUILDROOT X X X X
WITH_DOCS X X
WITH_TESTS X X
WITH_NETWORK X X
SOURCE_DATE_EPOCH X X X X
MKOSI_UID X X X X X
MKOSI_GID X X X X X
MKOSI_CONFIG X X X X X
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, $OUT‐
PUTDIR, $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 mko‐
si-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.).
• For all of the supported package managers except portage (dnf, rpm, apt, pacman, zypper), scripts of
the same name are put into $PATH that make sure these commands operate on the image’s root directory
with the configuration supplied by the user instead of on the host system. This means that from a
script, you can do e.g. dnf install vim to install vim into the image.
Additionally, mkosi-install, mkosi-reinstall, mkosi-upgrade and mkosi-remove will invoke the correspon‐
ding 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 Zwischenspeicherver‐
zeichnisse, falls Sie Daten zwischen Bauten weiternutzen wollen.
Dateien
Um den Bau von Abbildern für Entwicklungsversionen Ihres Projektes zu erleichtern, kann Mkosi Konfigura‐
tionsdaten 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 creati‐
on 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 Da‐
teien 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 Da‐
teien 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 addi‐
tional 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 bet‐
ween subsequent invocations. Note that if this directory does not exist the $BUILDDIR environment va‐
riable 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 pass‐
word is prefixed with hashed: it is treated as an already hashed root password. The password may optio‐
nally 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 crypt‐
setup 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 RepartDirecto‐
ries= 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 swit‐
ches, 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 distri‐
bution’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 mana‐
gers, 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 com‐
plete image builds are minimal, as only changed source files need to be recompiled.
Bau mehrerer Abbilder
If the mkosi.images/ directory exists, mkosi will load individual image configurations from it and build
each of them. Image configurations can be either directories containing mkosi configuration files or re‐
gular files with the .conf extension.
When image configurations are found in mkosi.images/, mkosi will build the configured images and all of
their dependencies (or all of them if no images were explicitly configured using Images=). To add depen‐
dencies between images, the Dependencies= setting can be used.
When images are defined, mkosi will first read the global configuration (configuration outside of the
mkosi.images/ directory), followed by the image specific configuration. This means that global configura‐
tion takes precedence over image specific configuration.
Images can refer to outputs of images they depend on. Specifically, for the following options, mkosi will
only check whether the inputs exist just before building the image:
• BaseTrees=
• PackageManagerTrees=
• SkeletonTrees=
• ExtraTrees=
• ToolsTree=
• Initrds=
To refer to outputs of a image’s dependencies, simply configure any of these options with a relative path
to the output to use in the output directory of the dependency. Or use the %O specifier to refer to the
output directory.
A good example on how to build multiple images can be found in the systemd (https://github.com/sy‐
stemd/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.
BEISPIELE
Create and run a raw GPT image with ext4, as image.raw:
# mkosi -p systemd --incremental boot
Create and run a bootable GPT image, as foobar.raw:
$ mkosi -d fedora -p kernel-core -p systemd -p systemd-boot -p udev -o foobar.raw
# mkosi --output foobar.raw boot
$ mkosi --output foobar.raw qemu
Create and run a Fedora Linux image in a plain directory:
# mkosi --distribution fedora --format directory boot
Create a compressed image image.raw.xz with SSH installed and add a checksum file:
$ mkosi --distribution fedora --format disk --checksum --compress-output --package=openssh-clients
Inside the source directory of an automake-based project, configure mkosi so that simply invoking mkosi
without any parameters builds an OS image containing a built version of the project in its current state:
$ cat >mkosi.conf <<EOF
[Distribution]
Distribution=fedora
[Output]
Format=disk
[Content]
Packages=kernel,systemd,systemd-udev,openssh-clients,httpd
BuildPackages=make,gcc,libcurl-devel
EOF
$ cat >mkosi.build <<EOF
#!/bin/sh
if [ "$container" != "mkosi" ]; then
exec mkosi-chroot "$CHROOT_SCRIPT" "$@"
fi
cd $SRCDIR
./autogen.sh
./configure --prefix=/usr
make -j `nproc`
make install
EOF
$ chmod +x mkosi.build
# mkosi --incremental boot
# systemd-nspawn -bi image.raw
Different ways to boot with qemu
The easiest way to boot a virtual machine is to build an image with the required components and let mkosi
call qemu with all the right options:
$ mkosi -d fedora \
--autologin \
-p systemd-udev,systemd-boot,kernel-core \
build
$ mkosi -d fedora qemu
…
fedora login: root (automatic login)
[root@fedora ~]#
The default is to boot with a text console only. In this mode, messages from the boot loader, the kernel,
and systemd, and later the getty login prompt and shell all use the same terminal. It is possible to
switch between the qemu console and monitor by pressing Ctrl-a c. The qemu monitor may for example be
used to inject special keys or shut down the machine quickly.
To boot with a graphical window, add --qemu-qui:
$ mkosi -d fedora --qemu-gui qemu
A kernel may be booted directly with mkosi qemu -kernel ... -initrd ... -append '...'. This is a bit fa‐
ster because no boot loader is used, and it is also easier to experiment with different kernels and ker‐
nel commandlines. Note that despite the name, qemu’s -append option replaces the default kernel com‐
mandline 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 sy‐
stemd-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, Gen‐
too. 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 Fe‐
dora 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 debi‐
an-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 allo‐
wed 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 anymo‐
re. 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/sta‐
tic-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-genera‐
ting-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.
mkosi(1)