man/systemd-sysext.xml

   1 <?xml version='1.0'?> <!--*-nxml-*-->
   2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
   3   "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
   4 <!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
   5
   6 <refentry id="systemd-sysext" conditional='ENABLE_SYSEXT'
   7     xmlns:xi="http://www.w3.org/2001/XInclude">
   8
   9   <refentryinfo>
  10     <title>systemd-sysext</title>
  11     <productname>systemd</productname>
  12   </refentryinfo>
  13
  14   <refmeta>
  15     <refentrytitle>systemd-sysext</refentrytitle>
  16     <manvolnum>8</manvolnum>
  17   </refmeta>
  18
  19   <refnamediv>
  20     <refname>systemd-sysext</refname>
  21     <refname>systemd-sysext.service</refname>
  22     <refname>systemd-confext</refname>
  23     <refname>systemd-confext.service</refname>
  24     <refpurpose>Activates System Extension Images</refpurpose>
  25   </refnamediv>
  26
  27   <refsynopsisdiv>
  28     <cmdsynopsis>
  29       <command>systemd-sysext</command>
  30       <arg choice="opt" rep="repeat">OPTIONS</arg>
  31       <arg choice="plain">COMMAND</arg>
  32     </cmdsynopsis>
  33
  34     <para><filename>systemd-sysext.service</filename></para>
  35
  36     <cmdsynopsis>
  37       <command>systemd-confext</command>
  38       <arg choice="opt" rep="repeat">OPTIONS</arg>
  39       <arg choice="plain">COMMAND</arg>
  40     </cmdsynopsis>
  41
  42     <para><filename>systemd-confext.service</filename></para>
  43   </refsynopsisdiv>
  44
  45   <refsect1>
  46     <title>Description</title>
  47
  48     <para><command>systemd-sysext</command> activates/deactivates system extension images. System extension
  49     images may – dynamically at runtime — extend the <filename>/usr/</filename> and
  50     <filename>/opt/</filename> directory hierarchies with additional files. This is particularly useful on
  51     immutable system images where a <filename>/usr/</filename> and/or <filename>/opt/</filename> hierarchy
  52     residing on a read-only file system shall be extended temporarily at runtime without making any
  53     persistent modifications.</para>
  54
  55     <para>System extension images should contain files and directories similar in fashion to regular
  56     operating system tree. When one or more system extension images are activated, their
  57     <filename>/usr/</filename> and <filename>/opt/</filename> hierarchies are combined via
  58     <literal>overlayfs</literal> with the same hierarchies of the host OS, and the host
  59     <filename>/usr/</filename> and <filename>/opt/</filename> overmounted with it ("merging"). When they are
  60     deactivated, the mount point is disassembled — again revealing the unmodified original host version of
  61     the hierarchy ("unmerging"). Merging thus makes the extension's resources suddenly appear below the
  62     <filename>/usr/</filename> and <filename>/opt/</filename> hierarchies as if they were included in the
  63     base OS image itself. Unmerging makes them disappear again, leaving in place only the files that were
  64     shipped with the base OS image itself.</para>
  65
  66     <para>Files and directories contained in the extension images outside of the <filename>/usr/</filename>
  67     and <filename>/opt/</filename> hierarchies are <emphasis>not</emphasis> merged, and hence have no effect
  68     when included in a system extension image. In particular, files in the <filename>/etc/</filename> and
  69     <filename>/var/</filename> included in a system extension image will <emphasis>not</emphasis> appear in
  70     the respective hierarchies after activation.</para>
  71
  72     <para>System extension images are strictly read-only by default. On mutable host file systems,
  73     <filename>/usr/</filename> and <filename>/opt/</filename> hierarchies become read-only while extensions
  74     are merged, unless mutability is enabled. Mutability may be enabled via the <option>--mutable=</option>
  75     option; see "Mutability" below for more information.</para>
  76
  77     <para>System extensions are supposed to be purely additive, i.e. they are supposed to include only files
  78     that do not exist in the underlying basic OS image. However, the underlying mechanism (overlayfs) also
  79     allows overlaying or removing files, but it is recommended not to make use of this.</para>
  80
  81     <para>System extension images may be provided in the following formats:</para>
  82
  83     <orderedlist>
  84       <listitem><para>Plain directories or btrfs subvolumes containing the OS tree</para></listitem>
  85       <listitem><para>Disk images with a GPT disk label, following the <ulink
  86       url="https://uapi-group.org/specifications/specs/discoverable_partitions_specification">Discoverable Partitions Specification</ulink></para></listitem>
  87       <listitem><para>Disk images lacking a partition table, with a naked Linux file system (e.g. erofs,
  88       squashfs or ext4)</para></listitem>
  89     </orderedlist>
  90
  91     <para>These image formats are the same ones that
  92     <citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>
  93     supports via its <option>--directory=</option>/<option>--image=</option> switches and those that the
  94     service manager supports via <option>RootDirectory=</option>/<option>RootImage=</option>. Similar to
  95     them they may optionally carry Verity authentication information.</para>
  96
  97     <para>System extensions are searched for in the directories
  98     <filename>/etc/extensions/</filename>, <filename>/run/extensions/</filename> and
  99     <filename>/var/lib/extensions/</filename>. The first two listed directories are not suitable for
 100     carrying large binary images, however are still useful for carrying symlinks to them. The primary place
 101     for installing system extensions is <filename>/var/lib/extensions/</filename>. Any directories found in
 102     these search directories are considered directory based extension images; any files with the
 103     <filename>.raw</filename> suffix are considered disk image based extension images. When invoked in the
 104     initrd, the additional directory <filename>/.extra/sysext/</filename> is included in the directories that
 105     are searched for extension images. Note however, that by default a tighter image policy applies to images
 106     found there, though, see below. This directory is populated by
 107     <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry> with
 108     extension images found in the system's EFI System Partition.</para>
 109
 110     <para>During boot OS extension images are activated automatically, if the
 111     <filename>systemd-sysext.service</filename> is enabled. Note that this service runs only after the
 112     underlying file systems where system extensions may be located have been mounted. This means they are not
 113     suitable for shipping resources that are processed by subsystems running in earliest boot. Specifically,
 114     OS extension images are not suitable for shipping system services or
 115     <citerefentry><refentrytitle>systemd-sysusers</refentrytitle><manvolnum>8</manvolnum></citerefentry>
 116     definitions. See the <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> page
 117     for a simple mechanism for shipping system services in disk images, in a similar fashion to OS
 118     extensions. Note the different isolation on these two mechanisms: while system extension directly extend
 119     the underlying OS image with additional files that appear in a way very similar to as if they were
 120     shipped in the OS image itself and thus imply no security isolation, portable services imply service
 121     level sandboxing in one way or another. The <filename>systemd-sysext.service</filename> service is
 122     guaranteed to finish start-up before <filename>basic.target</filename> is reached; i.e. at the time
 123     regular services initialize (those which do not use <varname>DefaultDependencies=no</varname>), the files
 124     and directories system extensions provide are available in <filename>/usr/</filename> and
 125     <filename>/opt/</filename> and may be accessed.</para>
 126
 127     <para>Note that there is no concept of enabling/disabling installed system extension images: all
 128     installed extension images are automatically activated at boot. However, you can place an empty directory
 129     named like the extension (no <filename>.raw</filename>) in <filename>/etc/extensions/</filename> to "mask"
 130     an extension with the same name in a system folder with lower precedence.</para>
 131
 132     <para>A simple mechanism for version compatibility is enforced: a system extension image must carry a
 133     <filename>/usr/lib/extension-release.d/extension-release.<replaceable>NAME</replaceable></filename>
 134     file, which must match its image name, that is compared with the host <filename>os-release</filename>
 135     file: the contained <varname>ID=</varname> fields have to match unless <literal>_any</literal> is set
 136     for the extension. If the extension <varname>ID=</varname> is not <literal>_any</literal>, the
 137     <varname>SYSEXT_LEVEL=</varname> field (if defined) has to match. If the latter is not defined, the
 138     <varname>VERSION_ID=</varname> field has to match instead. If the extension defines the
 139     <varname>ARCHITECTURE=</varname> field and the value is not <literal>_any</literal> it has to match the kernel's
 140     architecture reported by <citerefentry><refentrytitle>uname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
 141     but the used architecture identifiers are the same as for <varname>ConditionArchitecture=</varname>
 142     described in <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 143     <varname>EXTENSION_RELOAD_MANAGER=</varname> can be set to 1 if the extension requires a service manager reload after application
 144     of the extension. Note that for the reasons mentioned earlier:
 145     <ulink url="https://systemd.io/PORTABLE_SERVICES">Portable Services</ulink> remain
 146     the recommended way to ship system services.
 147
 148     System extensions should not ship a <filename>/usr/lib/os-release</filename> file (as that would be merged
 149     into the host <filename>/usr/</filename> tree, overriding the host OS version data, which is not desirable).
 150     The <filename>extension-release</filename> file follows the same format and semantics, and carries the same
 151     content, as the <filename>os-release</filename> file of the OS, but it describes the resources carried
 152     in the extension image.</para>
 153
 154     <para>The <command>systemd-confext</command> concept follows the same principle as the
 155     <citerefentry><refentrytitle>systemd-sysext</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 156     functionality but instead of working on <filename>/usr</filename> and <filename>/opt</filename>,
 157     <command>confext</command> will extend only <filename>/etc</filename>. Files and directories contained
 158     in the confext images outside of the <filename>/etc/</filename> hierarchy are <emphasis>not</emphasis>
 159     merged, and hence have no effect when included in the image. Formats for these images are of the
 160     same as sysext images. The merged hierarchy will be mounted with <literal>nosuid</literal> and
 161     (if not disabled via <option>--noexec=false</option>) <literal>noexec</literal>.</para>
 162
 163     <para>Just like sysexts, confexts are strictly read-only by default. Merging confexts on mutable host
 164     file systems will result in <filename>/etc/</filename> becoming read-only. As with sysexts, mutability
 165     can be enabled via the <option>--mutable=</option> option. Refer to "Mutability" below for more
 166     information.</para>
 167
 168     <para>Confexts are looked for in the directories <filename>/run/confexts/</filename>,
 169     <filename>/var/lib/confexts/</filename>, <filename>/usr/lib/confexts/</filename> and
 170     <filename>/usr/local/lib/confexts/</filename>. The first listed directory is not suitable for
 171     carrying large binary images, however is still useful for carrying symlinks to them. The primary place
 172     for installing configuration extensions is <filename>/var/lib/confexts/</filename>. Any directories found
 173     in these search directories are considered directory based confext images; any files with the
 174     <filename>.raw</filename> suffix are considered disk image based confext images.</para>
 175
 176     <para>Again, just like sysext images, the confext images will contain a
 177     <filename>/etc/extension-release.d/extension-release.<replaceable>NAME</replaceable></filename>
 178     file, which must match the image name (with the usual escape hatch of
 179     the <varname>user.extension-release.strict</varname>
 180     <citerefentry project='man-pages'><refentrytitle>xattr</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
 181     and again with content being one or more of <varname>ID=</varname>, <varname>VERSION_ID=</varname>, and
 182     <varname>CONFEXT_LEVEL</varname>. Confext images will then be checked and matched against the base OS
 183     layer.</para>
 184   </refsect1>
 185
 186   <refsect1>
 187     <title>Uses</title>
 188
 189     <para>The primary use case for system images are immutable environments where debugging and development
 190     tools shall optionally be made available, but not included in the immutable base OS image itself (e.g.
 191     <citerefentry project='man-pages'><refentrytitle>strace</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 192     and
 193     <citerefentry project='man-pages'><refentrytitle>gdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 194     shall be an optionally installable addition in order to make debugging/development easier). System
 195     extension images should not be misunderstood as a generic software packaging framework, as no dependency
 196     scheme is available: system extensions should carry all files they need themselves, except for those
 197     already shipped in the underlying host system image. Typically, system extension images are built at the
 198     same time as the base OS image — within the same build system.</para>
 199
 200     <para>Another use case for the system extension concept is temporarily overriding OS supplied resources
 201     with newer ones, for example to install a locally compiled development version of some low-level
 202     component over the immutable OS image without doing a full OS rebuild or modifying the nominally
 203     immutable image. (e.g. "install" a locally built package with <command>DESTDIR=/var/lib/extensions/mytest
 204     make install &amp;&amp; systemd-sysext refresh</command>, making it available in
 205     <filename>/usr/</filename> as if it was installed in the OS image itself.) This case works regardless if
 206     the underlying host <filename>/usr/</filename> is managed as immutable disk image or is a traditional
 207     package manager controlled (i.e. writable) tree.</para>
 208
 209     <para>With systemd-confext one can perform runtime reconfiguration of OS services.
 210     Sometimes, there is a need to swap certain configuration parameter values or restart only a specific
 211     service without deployment of new code or a complete OS deployment. In other words, we want to be able
 212     to tie the most frequently configured options to runtime updateable flags that can be changed without a
 213     system reboot. This will help reduce servicing times when there is a need for changing the OS configuration.
 214     It also provides a reliable tool for managing configuration because all old configuration files disappear when
 215     the systemd-confext image is removed.</para></refsect1>
 216
 217   <refsect1>
 218     <title>Mutability</title>
 219     <para>By default, merging system extensions on mutable host file systems will render <filename>/usr/</filename>
 220     and <filename>/opt/</filename> hierarchies read-only. Merging configuration extensions will have the same
 221     effect on <filename>/etc/</filename>. Mutable mode allows writes to these locations when extensions are
 222     merged.</para>
 223
 224     <para>The following modes are supported:
 225     <orderedlist>
 226       <listitem><para><option>disabled</option>: Force immutable mode even if write routing directories exist
 227       below <filename>/var/lib/extensions.mutable/</filename>. This is the default.</para></listitem>
 228       <listitem><para><option>auto</option>: Automatic mode. Mutability is disabled by default and only
 229       enabled if a corresponding write routing directory exists below
 230       <filename>/var/lib/extensions.mutable/</filename>.</para></listitem>
 231       <listitem><para><option>enabled</option>: Force mutable mode and automatically create write routing
 232       directories below <filename>/var/lib/extensions.mutable/</filename> when required.</para></listitem>
 233       <listitem><para><option>import</option>: Force immutable mode like <option>disabled</option> above, but
 234       merge the contents of directories below <filename>/var/lib/extensions.mutable/</filename> into the host
 235       file system.</para></listitem>
 236       <listitem><para><option>ephemeral</option>: Force mutable mode like <option>enabled</option> above, but
 237       instead of using write routing directory below <filename>/var/lib/extensions.mutable/</filename>,
 238       <command>systemd-sysext</command> will use empty ephemeral directories. This means that the
 239       modifications made in the merged hierarchies will be gone when the hierarchies are
 240       unmerged.</para></listitem>
 241       <listitem><para><option>ephemeral-import</option>: Force mutable mode like <option>ephemeral</option>
 242       above, but instead of ignoring the contents of write routing directories under
 243       <filename>/var/lib/extensions.mutable/</filename>, merge them into the host file system, like
 244       <option>import</option> does.</para></listitem>
 245     </orderedlist>
 246     See "Options" below on specifying modes using the <option>--mutable=</option> command line option.</para>
 247
 248     <para>With exception of the ephemeral mode, the mutable mode routes writes to subdirectories in
 249     <filename>/var/lib/extensions.mutable/</filename>.
 250     <simplelist type="horiz">
 251       <member>Writes to <filename>/usr/</filename> are directed to <filename>/var/lib/extensions.mutable/usr/</filename></member>,
 252       <member>writes to <filename>/opt/</filename> are directed to <filename>/var/lib/extensions.mutable/opt/</filename>, and</member>
 253       <member>writes to <filename>/etc/</filename> land in <filename>/var/lib/extensions.mutable/etc/</filename>.</member>
 254     </simplelist></para>
 255
 256     <para>If <filename>usr/</filename>, <filename>opt/</filename>, or <filename>etc/</filename>
 257     in <filename>/var/lib/extensions.mutable/</filename> are symlinks, then writes are directed to the
 258     symlinks' targets.
 259     Consequently, to retain mutability of a host file system, create symlinks
 260     <simplelist type="horiz">
 261       <member><filename>/var/lib/extensions.mutable/etc/</filename> → <filename>/etc/</filename></member>
 262       <member><filename>/var/lib/extensions.mutable/usr/</filename> → <filename>/usr/</filename></member>
 263       <member><filename>/var/lib/extensions.mutable/opt/</filename> → <filename>/opt/</filename></member>
 264     </simplelist>
 265     to route writes back to the original base directory hierarchy.</para>
 266
 267     <para>Alternatively, a temporary file system may be mounted to
 268     <filename>/var/lib/extensions.mutable/</filename>, or symlinks in
 269     <filename>/var/lib/extensions.mutable/</filename> may point to sub-directories on a temporary file system
 270     (e.g. below <filename>/tmp/</filename>) to only allow ephemeral changes. Note that this is not the same
 271     as ephemeral mode, because the temporary file system will still exist after unmerging.</para>
 272
 273     <xi:include href="version-info.xml" xpointer="v256"/>
 274   </refsect1>
 275
 276   <refsect1>
 277     <title>Commands</title>
 278
 279     <para>The following commands are understood by both the sysext and confext concepts:</para>
 280
 281     <variablelist>
 282       <varlistentry>
 283         <term><option>status</option></term>
 284
 285         <listitem><para>When invoked without any command verb, or when <option>status</option> is specified
 286         the current merge status is shown, separately (for both <filename>/usr/</filename> and
 287         <filename>/opt/</filename> of sysext and for <filename>/etc/</filename> of confext).</para>
 288
 289         <xi:include href="version-info.xml" xpointer="v248"/></listitem>
 290       </varlistentry>
 291
 292       <varlistentry>
 293         <term><option>merge</option></term>
 294         <listitem><para>Merges all currently installed system extension images into
 295         <filename>/usr/</filename> and <filename>/opt/</filename>, by overmounting these hierarchies with an
 296         <literal>overlayfs</literal> file system combining the underlying hierarchies with those included in
 297         the extension images. This command will fail if the hierarchies are already merged. For confext, the merge
 298         happens into the <filename>/etc/</filename> directory instead.</para>
 299
 300         <xi:include href="version-info.xml" xpointer="v248"/></listitem>
 301       </varlistentry>
 302
 303       <varlistentry>
 304         <term><option>unmerge</option></term>
 305         <listitem><para>Unmerges all currently installed system extension images from
 306         <filename>/usr/</filename> and <filename>/opt/</filename> for sysext and <filename>/etc/</filename>,
 307         for confext, by unmounting the <literal>overlayfs</literal> file systems created by <option>merge</option>
 308         prior.</para>
 309
 310         <xi:include href="version-info.xml" xpointer="v248"/></listitem>
 311       </varlistentry>
 312
 313       <varlistentry>
 314         <term><option>refresh</option></term>
 315         <listitem><para>A combination of <option>unmerge</option> and <option>merge</option>: if already
 316         mounted the existing <literal>overlayfs</literal> instance is unmounted temporarily, and then
 317         replaced by a new version. This command is useful after installing/removing system extension images,
 318         in order to update the <literal>overlayfs</literal> file system accordingly. If no system extensions
 319         are installed when this command is executed, the equivalent of <option>unmerge</option> is executed,
 320         without establishing any new <literal>overlayfs</literal> instance.
 321         Note that currently there's a brief moment where neither the old nor the new <literal>overlayfs</literal>
 322         file system is mounted. This implies that all resources supplied by a system extension will briefly
 323         disappear — even if it exists continuously during the refresh operation.</para>
 324
 325         <xi:include href="version-info.xml" xpointer="v248"/></listitem>
 326       </varlistentry>
 327
 328       <varlistentry>
 329         <term><option>list</option></term>
 330
 331         <listitem><para>A brief list of installed extension images is shown.</para>
 332
 333         <xi:include href="version-info.xml" xpointer="v248"/></listitem>
 334       </varlistentry>
 335
 336       <xi:include href="standard-options.xml" xpointer="help" />
 337       <xi:include href="standard-options.xml" xpointer="version" />
 338     </variablelist>
 339   </refsect1>
 340
 341   <refsect1>
 342     <title>Options</title>
 343
 344     <variablelist>
 345       <varlistentry>
 346         <term><option>--root=</option></term>
 347
 348         <listitem><para>Operate relative to the specified root directory, i.e. establish the
 349         <literal>overlayfs</literal> mount not on the top-level host <filename>/usr/</filename> and
 350         <filename>/opt/</filename> hierarchies for sysext or <filename>/etc/</filename> for confext,
 351         but below some specified root directory.</para>
 352
 353         <xi:include href="version-info.xml" xpointer="v248"/></listitem>
 354       </varlistentry>
 355
 356       <varlistentry>
 357         <term><option>--force</option></term>
 358
 359         <listitem><para>When merging system extensions into <filename>/usr/</filename> and
 360         <filename>/opt/</filename> for sysext and <filename>/etc/</filename> for confext,
 361         ignore version incompatibilities, i.e. force merging regardless of
 362         whether the version information included in the images matches the host or not.</para>
 363
 364         <xi:include href="version-info.xml" xpointer="v248"/></listitem>
 365       </varlistentry>
 366
 367       <varlistentry>
 368         <term><option>--image-policy=<replaceable>policy</replaceable></option></term>
 369
 370         <listitem><para>Takes an image policy string as argument, as per
 371         <citerefentry><refentrytitle>systemd.image-policy</refentrytitle><manvolnum>7</manvolnum></citerefentry>. The
 372         policy is enforced when operating on system extension disk images. If not specified defaults to
 373         <literal>root=verity+signed+encrypted+unprotected+absent:usr=verity+signed+encrypted+unprotected+absent</literal>
 374         for system extensions, i.e. only the root and <filename>/usr/</filename> file systems in the image
 375         are used. For configuration extensions defaults to
 376         <literal>root=verity+signed+encrypted+unprotected+absent</literal>. When run in the initrd and
 377         operating on a system extension image stored in the <filename>/.extra/sysext/</filename> directory a
 378         slightly stricter policy is used by default: <literal>root=signed+absent:usr=signed+absent</literal>,
 379         see above for details.</para>
 380
 381         <xi:include href="version-info.xml" xpointer="v254"/></listitem>
 382       </varlistentry>
 383
 384       <varlistentry>
 385         <term><option>--mutable=<replaceable>BOOL</replaceable>|<replaceable>auto</replaceable>|<replaceable>import</replaceable></option></term>
 386         <listitem><para>Set mutable mode.</para>
 387
 388         <variablelist>
 389           <varlistentry>
 390             <term><option>no</option></term>
 391             <listitem><para>force immutable mode even with write routing directories present.
 392             This is the default.</para>
 393             <xi:include href="version-info.xml" xpointer="v256"/></listitem>
 394           </varlistentry>
 395
 396           <varlistentry>
 397             <term><option>auto</option></term>
 398             <listitem><para>enable mutable mode individually for <filename>/usr/</filename>,
 399             <filename>/opt/</filename>, and <filename>/etc/</filename> if write routing sub-directories
 400             or symlinks are present in <filename>/var/lib/extensions.mutable/</filename>; disable otherwise.
 401             See "Mutability" above for more information on write routing.</para>
 402             <xi:include href="version-info.xml" xpointer="v256"/></listitem>
 403           </varlistentry>
 404
 405           <varlistentry>
 406             <term><option>yes</option></term>
 407             <listitem><para>force mutable mode. Write routing directories will be created in
 408             <filename>/var/lib/extensions.mutable/</filename> if not present.</para>
 409             <xi:include href="version-info.xml" xpointer="v256"/></listitem>
 410           </varlistentry>
 411
 412           <varlistentry>
 413             <term><option>import</option></term>
 414             <listitem><para>immutable mode, but with contents of write routing directories in
 415             <filename>/var/lib/extensions.mutable/</filename> also merged into the host file system.</para>
 416             <xi:include href="version-info.xml" xpointer="v256"/></listitem>
 417           </varlistentry>
 418
 419           <varlistentry>
 420             <term><option>ephemeral</option></term>
 421             <listitem><para>force mutable mode, but with contents of write routing directories in
 422             <filename>/var/lib/extensions.mutable/</filename> being ignored, and modifications of the host
 423             file system being discarded after unmerge.</para>
 424             <xi:include href="version-info.xml" xpointer="v256"/></listitem>
 425           </varlistentry>
 426
 427           <varlistentry>
 428             <term><option>ephemeral-import</option></term>
 429             <listitem><para>force mutable mode, with contents of write routing directories in
 430             <filename>/var/lib/extensions.mutable/</filename> being merged into the host file system, but
 431             with the modifications made to the host file system being discarded after unmerge.</para>
 432             <xi:include href="version-info.xml" xpointer="v256"/></listitem>
 433           </varlistentry>
 434         </variablelist>
 435
 436         <xi:include href="version-info.xml" xpointer="v256"/></listitem>
 437       </varlistentry>
 438
 439       <varlistentry>
 440         <term><option>--noexec=<replaceable>BOOL</replaceable></option></term>
 441
 442         <listitem><para>When merging configuration extensions into <filename>/etc/</filename> the
 443         <literal>MS_NOEXEC</literal> mount flag is used by default. This option can be used to disable
 444         it.</para>
 445
 446         <xi:include href="version-info.xml" xpointer="v254"/></listitem>
 447       </varlistentry>
 448
 449       <varlistentry>
 450         <term><option>--no-reload</option></term>
 451
 452         <listitem>
 453           <para>When used with <command>merge</command>,
 454           <command>unmerge</command> or <command>refresh</command>, do not reload daemon
 455           after executing the changes even if an extension that is applied requires a reload via the
 456           <varname>EXTENSION_RELOAD_MANAGER=</varname> set to 1.</para>
 457
 458         <xi:include href="version-info.xml" xpointer="v255"/>
 459         </listitem>
 460       </varlistentry>
 461
 462       <xi:include href="standard-options.xml" xpointer="no-pager" />
 463       <xi:include href="standard-options.xml" xpointer="no-legend" />
 464       <xi:include href="standard-options.xml" xpointer="json" />
 465     </variablelist>
 466   </refsect1>
 467
 468   <refsect1>
 469     <title>Exit status</title>
 470
 471     <para>On success, 0 is returned.</para>
 472   </refsect1>
 473
 474   <refsect1>
 475     <title>See Also</title>
 476     <para><simplelist type="inline">
 477       <member><citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
 478       <member><citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
 479       <member><citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry></member>
 480       <member><citerefentry><refentrytitle>importctl</refentrytitle><manvolnum>1</manvolnum></citerefentry></member>
 481     </simplelist></para>
 482   </refsect1>
 483
 484 </refentry>