systemd-sysext

SYSTEMD-SYSEXT(8)               systemd-sysext               SYSTEMD-SYSEXT(8)

NAME
       systemd-sysext, systemd-sysext.service - Activates System Extension
       Images

SYNOPSIS
       systemd-sysext [OPTIONS...]

       systemd-sysext.service

DESCRIPTION
       systemd-sysext activates/deactivates system extension images. System
       extension images may - dynamically at runtime -- extend the /usr/ and
       /opt/ directory hierarchies with additional files. This is particularly
       useful on immutable system images where a /usr/ and/or /opt/ hierarchy
       residing on a read-only file system shall be extended temporarily at
       runtime without making any persistent modifications.

       System extension images should contain files and directories similar in
       fashion to regular operating system tree. When one or more system
       extension images are activated, their /usr/ and /opt/ hierarchies are
       combined via "overlayfs" with the same hierarchies of the host OS, and
       the host /usr/ and /opt/ overmounted with it ("merging"). When they are
       deactivated, the mount point is disassembled -- again revealing the
       unmodified original host version of the hierarchy ("unmerging").
       Merging thus makes the extension's resources suddenly appear below the
       /usr/ and /opt/ hierarchies as if they were included in the base OS
       image itself. Unmerging makes them disappear again, leaving in place
       only the files that were shipped with the base OS image itself.

       Files and directories contained in the extension images outside of the
       /usr/ and /opt/ hierarchies are not merged, and hence have no effect
       when included in a system extension image. In particular, files in the
       /etc/ and /var/ included in a system extension image will not appear in
       the respective hierarchies after activation.

       System extension images are strictly read-only, and the host /usr/ and
       /opt/ hierarchies become read-only too while they are activated.

       System extensions are supposed to be purely additive, i.e. they are
       supposed to include only files that do not exist in the underlying
       basic OS image. However, the underlying mechanism (overlayfs) also
       allows removing files, but it is recommended not to make use of this.

       System extension images may be provided in the following formats:

        1. Plain directories or btrfs subvolumes containing the OS tree

        2. Disk images with a GPT disk label, following the Discoverable
           Partitions Specification[1]

        3. Disk images lacking a partition table, with a naked Linux file
           system (e.g. squashfs or ext4)

       These image formats are the same ones that systemd-nspawn(1) supports
       via it's --directory=/--image= switches and those that the service
       manager supports via RootDirectory=/RootImage=. Similar to them they
       may optionally carry Verity authentication information.

       System extensions are automatically looked for in the directories
       /etc/extensions/, /run/extensions/, /var/lib/extensions/,
       /usr/lib/extensions/ and /usr/local/lib/extensions/. The first two
       listed directories are not suitable for carrying large binary images,
       however are still useful for carrying symlinks to them. The primary
       place for installing system extensions is /var/lib/extensions/. Any
       directories found in these search directories are considered directory
       based extension images, any files with the .raw suffix are considered
       disk image based extension images.

       During boot OS extension images are activated automatically, if the
       systemd-sysext.service is enabled. Note that this service runs only
       after the underlying file systems where system extensions are searched
       are mounted. This means they are not suitable for shipping resources
       that are processed by subsystems running in earliest boot.
       Specifically, OS extension images are not suitable for shipping system
       services or systemd-sysusers(8) definitions. See Portable Services[2]
       for a simple mechanism for shipping system services in disk images, in
       a similar fashion to OS extensions. Note the different isolation on
       these two mechanisms: while system extension directly extend the
       underlying OS image with additional files that appear in a way very
       similar to as if they were shipped in the OS image itself and thus
       imply no security isolation, portable services imply service level
       sandboxing in one way or another. The systemd-sysext.service service is
       guaranteed to finish start-up before basic.target is reached; i.e. at
       the time regular services initialize (those which do not use
       DefaultDependencies=no), the files and directories system extensions
       provide are available in /usr/ and /opt/ and may be accessed.

       Note that there is no concept of enabling/disabling installed system
       extension images: all installed extension images are automatically
       activated at boot.

       A simple mechanism for version compatibility is enforced: a system
       extension image must carry a
       /usr/lib/extension-release.d/extension-release.$name file, which must
       match its image name, that is compared with the host os-release file:
       the contained ID= fields have to match, as well as the SYSEXT_LEVEL=
       field (if defined). If the latter is not defined, the VERSION_ID= field
       has to match instead. System extensions should not ship a
       /usr/lib/os-release file (as that would be merged into the host /usr/
       tree, overriding the host OS version data, which is not desirable). The
       extension-release file follows the same format and semantics, and
       carries the same content, as the os-release file of the OS, but it
       describes the resources carried in the extension image.

USES
       The primary use case for system images are immutable environments where
       debugging and development tools shall optionally be made available, but
       not included in the immutable base OS image itself (e.g.  strace(1) and
       gdb(1) shall be an optionally installable addition in order to make
       debugging/development easier). System extension images should not be
       misunderstood as a generic software packaging framework, as no
       dependency scheme is available: system extensions should carry all
       files they need themselves, except for those already shipped in the
       underlying host system image. Typically, system extension images are
       built at the same time as the base OS image -- within the same build
       system.

       Another use case for the system extension concept is temporarily
       overriding OS supplied resources with newer ones, for example to
       install a locally compiled development version of some low-level
       component over the immutable OS image without doing a full OS rebuild
       or modifying the nominally immutable image. (e.g. "install" a locally
       built package with DESTDIR=/var/lib/extensions/mytest make install &&
       systemd-sysext refresh, making it available in /usr/ as if it was
       installed in the OS image itself.) This case works regardless if the
       underlying host /usr/ is managed as immutable disk image or is a
       traditional package manager controlled (i.e. writable) tree.

COMMANDS
       The following commands are understood:

       status
           When invoked without any command verb, or when status is specified
           the current merge status is shown, separately for both /usr/ and
           /opt/.

       merge
           Merges all currently installed system extension images into /usr/
           and /opt/, by overmounting these hierarchies with an "overlayfs"
           file system combining the underlying hierarchies with those
           included in the extension images. This command will fail if the
           hierarchies are already merged.

       unmerge
           Unmerges all currently installed system extension images from /usr/
           and /opt/, by unmounting the "overlayfs" file systems created by
           merge prior.

       refresh
           A combination of unmerge and merge: if already mounted the existing
           "overlayfs" instance is unmounted temporarily, and then replaced by
           a new version. This command is useful after installing/removing
           system extension images, in order to update the "overlayfs" file
           system accordingly. If no system extensions are installed when this
           command is executed, the equivalent of unmerge is executed, without
           establishing any new "overlayfs" instance. Note that currently
           there's a brief moment where neither the old nor the new
           "overlayfs" file system is mounted. This implies that all resources
           supplied by a system extension will briefly disappear -- even if it
           exists continuously during the refresh operation.

       list
           A brief list of installed extension images is shown.

       -h, --help
           Print a short help text and exit.

       --version
           Print a short version string and exit.

OPTIONS
       --root=
           Operate relative to the specified root directory, i.e. establish
           the "overlayfs" mount not on the top-level host /usr/ and /opt/
           hierarchies, but below some specified root directory.

       --force
           When merging system extensions into /usr/ and /opt/, ignore version
           incompatibilities, i.e. force merging regardless of whether the
           version information included in the extension images matches the
           host or not.

       --no-pager
           Do not pipe output into a pager.

       --no-legend
           Do not print the legend, i.e. column headers and the footer with
           hints.

       --json=MODE
           Shows output formatted as JSON. Expects one of "short" (for the
           shortest possible output without any redundant whitespace or line
           breaks), "pretty" (for a pretty version of the same, with
           indentation and line breaks) or "off" (to turn off JSON output, the
           default).

EXIT STATUS
       On success, 0 is returned.

SEE ALSO
       systemd(1), systemd-nspawn(1)

NOTES
        1. Discoverable Partitions Specification
           https://systemd.io/DISCOVERABLE_PARTITIONS

        2. Portable Services
           https://systemd.io/PORTABLE_SERVICES

systemd 249                                                  SYSTEMD-SYSEXT(8)