1SYSTEMD-SYSEXT(8) systemd-sysext SYSTEMD-SYSEXT(8)
2
6 systemd-sysext, systemd-sysext.service - Activates System Extension
7 Images
8
10 systemd-sysext [OPTIONS...] COMMAND
11 systemd-sysext.service
13
15 systemd-sysext activates/deactivates system extension images. System
16 extension images may – dynamically at runtime — extend the /usr/ and
17 /opt/ directory hierarchies with additional files. This is particularly
18 useful on immutable system images where a /usr/ and/or /opt/ hierarchy
19 residing on a read-only file system shall be extended temporarily at
20 runtime without making any persistent modifications.
21 System extension images should contain files and directories similar in
23 fashion to regular operating system tree. When one or more system
24 extension images are activated, their /usr/ and /opt/ hierarchies are
25 combined via "overlayfs" with the same hierarchies of the host OS, and
26 the host /usr/ and /opt/ overmounted with it ("merging"). When they are
27 deactivated, the mount point is disassembled — again revealing the
28 unmodified original host version of the hierarchy ("unmerging").
29 Merging thus makes the extension's resources suddenly appear below the
30 /usr/ and /opt/ hierarchies as if they were included in the base OS
31 image itself. Unmerging makes them disappear again, leaving in place
32 only the files that were shipped with the base OS image itself.
33 Files and directories contained in the extension images outside of the
35 /usr/ and /opt/ hierarchies are not merged, and hence have no effect
36 when included in a system extension image. In particular, files in the
37 /etc/ and /var/ included in a system extension image will not appear in
38 the respective hierarchies after activation.
39 System extension images are strictly read-only, and the host /usr/ and
41 /opt/ hierarchies become read-only too while they are activated.
42 System extensions are supposed to be purely additive, i.e. they are
44 supposed to include only files that do not exist in the underlying
45 basic OS image. However, the underlying mechanism (overlayfs) also
46 allows overlaying or removing files, but it is recommended not to make
47 use of this.
48 System extension images may be provided in the following formats:
50 1. Plain directories or btrfs subvolumes containing the OS tree
52 2. Disk images with a GPT disk label, following the Discoverable
54 Partitions Specification[1]
55 3. Disk images lacking a partition table, with a naked Linux file
57 system (e.g. erofs, squashfs or ext4)
58 These image formats are the same ones that systemd-nspawn(1) supports
60 via its --directory=/--image= switches and those that the service
61 manager supports via RootDirectory=/RootImage=. Similar to them they
62 may optionally carry Verity authentication information.
63 System extensions are automatically looked for in the directories
65 /etc/extensions/, /run/extensions/, /var/lib/extensions/,
66 /usr/lib/extensions/ and /usr/local/lib/extensions/. The first two
67 listed directories are not suitable for carrying large binary images,
68 however are still useful for carrying symlinks to them. The primary
69 place for installing system extensions is /var/lib/extensions/. Any
70 directories found in these search directories are considered directory
71 based extension images, any files with the .raw suffix are considered
72 disk image based extension images.
73 During boot OS extension images are activated automatically, if the
75 systemd-sysext.service is enabled. Note that this service runs only
76 after the underlying file systems where system extensions may be
77 located have been mounted. This means they are not suitable for
78 shipping resources that are processed by subsystems running in earliest
79 boot. Specifically, OS extension images are not suitable for shipping
80 system services or systemd-sysusers(8) definitions. See the Portable
81 Services Documentation[2] for a simple mechanism for shipping system
82 services in disk images, in a similar fashion to OS extensions. Note
83 the different isolation on these two mechanisms: while system extension
84 directly extend the underlying OS image with additional files that
85 appear in a way very similar to as if they were shipped in the OS image
86 itself and thus imply no security isolation, portable services imply
87 service level sandboxing in one way or another. The
88 systemd-sysext.service service is guaranteed to finish start-up before
89 basic.target is reached; i.e. at the time regular services initialize
90 (those which do not use DefaultDependencies=no), the files and
91 directories system extensions provide are available in /usr/ and /opt/
92 and may be accessed.
93 Note that there is no concept of enabling/disabling installed system
95 extension images: all installed extension images are automatically
96 activated at boot. However, you can place an empty directory named like
97 the extension (no .raw) in /etc/extensions/ to "mask" an extension with
98 the same name in a system folder with lower precedence.
99 A simple mechanism for version compatibility is enforced: a system
101 extension image must carry a
102 /usr/lib/extension-release.d/extension-release.$name file, which must
103 match its image name, that is compared with the host os-release file:
104 the contained ID= fields have to match unless "_any" is set for the
105 extension. If the extension ID= is not "_any", the SYSEXT_LEVEL= field
106 (if defined) has to match. If the latter is not defined, the
107 VERSION_ID= field has to match instead. If the extension defines the
108 ARCHITECTURE= field and the value is not "_any" it has to match the
109 kernel's architecture reported by uname(2) but the used architecture
110 identifiers are the same as for ConditionArchitecture= described in
111 systemd.unit(5). System extensions should not ship a
112 /usr/lib/os-release file (as that would be merged into the host /usr/
113 tree, overriding the host OS version data, which is not desirable). The
114 extension-release file follows the same format and semantics, and
115 carries the same content, as the os-release file of the OS, but it
116 describes the resources carried in the extension image.
117
119 The primary use case for system images are immutable environments where
120 debugging and development tools shall optionally be made available, but
121 not included in the immutable base OS image itself (e.g. strace(1) and
122 gdb(1) shall be an optionally installable addition in order to make
123 debugging/development easier). System extension images should not be
124 misunderstood as a generic software packaging framework, as no
125 dependency scheme is available: system extensions should carry all
126 files they need themselves, except for those already shipped in the
127 underlying host system image. Typically, system extension images are
128 built at the same time as the base OS image — within the same build
129 system.
130 Another use case for the system extension concept is temporarily
132 overriding OS supplied resources with newer ones, for example to
133 install a locally compiled development version of some low-level
134 component over the immutable OS image without doing a full OS rebuild
135 or modifying the nominally immutable image. (e.g. "install" a locally
136 built package with DESTDIR=/var/lib/extensions/mytest make install &&
137 systemd-sysext refresh, making it available in /usr/ as if it was
138 installed in the OS image itself.) This case works regardless if the
139 underlying host /usr/ is managed as immutable disk image or is a
140 traditional package manager controlled (i.e. writable) tree.
141
143 The following commands are understood:
144 status
146 When invoked without any command verb, or when status is specified
147 the current merge status is shown, separately for both /usr/ and
148 /opt/.
149 merge
151 Merges all currently installed system extension images into /usr/
152 and /opt/, by overmounting these hierarchies with an "overlayfs"
153 file system combining the underlying hierarchies with those
154 included in the extension images. This command will fail if the
155 hierarchies are already merged.
156 unmerge
158 Unmerges all currently installed system extension images from /usr/
159 and /opt/, by unmounting the "overlayfs" file systems created by
160 merge prior.
161 refresh
163 A combination of unmerge and merge: if already mounted the existing
164 "overlayfs" instance is unmounted temporarily, and then replaced by
165 a new version. This command is useful after installing/removing
166 system extension images, in order to update the "overlayfs" file
167 system accordingly. If no system extensions are installed when this
168 command is executed, the equivalent of unmerge is executed, without
169 establishing any new "overlayfs" instance. Note that currently
170 there's a brief moment where neither the old nor the new
171 "overlayfs" file system is mounted. This implies that all resources
172 supplied by a system extension will briefly disappear — even if it
173 exists continuously during the refresh operation.
174 list
176 A brief list of installed extension images is shown.
177 -h, --help
179 Print a short help text and exit.
180 --version
182 Print a short version string and exit.
183
185 --root=
186 Operate relative to the specified root directory, i.e. establish
187 the "overlayfs" mount not on the top-level host /usr/ and /opt/
188 hierarchies, but below some specified root directory.
189 --force
191 When merging system extensions into /usr/ and /opt/, ignore version
192 incompatibilities, i.e. force merging regardless of whether the
193 version information included in the extension images matches the
194 host or not.
195 --no-pager
197 Do not pipe output into a pager.
198 --no-legend
200 Do not print the legend, i.e. column headers and the footer with
201 hints.
202 --json=MODE
204 Shows output formatted as JSON. Expects one of "short" (for the
205 shortest possible output without any redundant whitespace or line
206 breaks), "pretty" (for a pretty version of the same, with
207 indentation and line breaks) or "off" (to turn off JSON output, the
208 default).
209
211 On success, 0 is returned.
212
214 systemd(1), systemd-nspawn(1)
215
217 1. Discoverable Partitions Specification
218 https://uapi-group.org/specifications/specs/discoverable_partitions_specification
219 2. Portable Services Documentation
221 https://systemd.io/PORTABLE_SERVICES
222systemd 253 SYSTEMD-SYSEXT(8)