1SYSTEMD-SYSEXT(8) systemd-sysext SYSTEMD-SYSEXT(8)
2
6 systemd-sysext, systemd-sysext.service, systemd-confext, systemd-
7 confext.service - Activates System Extension Images
8
10 systemd-sysext [OPTIONS...] COMMAND
11 systemd-sysext.service
13 systemd-confext [OPTIONS...] COMMAND
15 systemd-confext.service
17
19 systemd-sysext activates/deactivates system extension images. System
20 extension images may – dynamically at runtime — extend the /usr/ and
21 /opt/ directory hierarchies with additional files. This is particularly
22 useful on immutable system images where a /usr/ and/or /opt/ hierarchy
23 residing on a read-only file system shall be extended temporarily at
24 runtime without making any persistent modifications.
25 System extension images should contain files and directories similar in
27 fashion to regular operating system tree. When one or more system
28 extension images are activated, their /usr/ and /opt/ hierarchies are
29 combined via "overlayfs" with the same hierarchies of the host OS, and
30 the host /usr/ and /opt/ overmounted with it ("merging"). When they are
31 deactivated, the mount point is disassembled — again revealing the
32 unmodified original host version of the hierarchy ("unmerging").
33 Merging thus makes the extension's resources suddenly appear below the
34 /usr/ and /opt/ hierarchies as if they were included in the base OS
35 image itself. Unmerging makes them disappear again, leaving in place
36 only the files that were shipped with the base OS image itself.
37 Files and directories contained in the extension images outside of the
39 /usr/ and /opt/ hierarchies are not merged, and hence have no effect
40 when included in a system extension image. In particular, files in the
41 /etc/ and /var/ included in a system extension image will not appear in
42 the respective hierarchies after activation.
43 System extension images are strictly read-only, and the host /usr/ and
45 /opt/ hierarchies become read-only too while they are activated.
46 System extensions are supposed to be purely additive, i.e. they are
48 supposed to include only files that do not exist in the underlying
49 basic OS image. However, the underlying mechanism (overlayfs) also
50 allows overlaying or removing files, but it is recommended not to make
51 use of this.
52 System extension images may be provided in the following formats:
54 1. Plain directories or btrfs subvolumes containing the OS tree
56 2. Disk images with a GPT disk label, following the Discoverable
58 Partitions Specification[1]
59 3. Disk images lacking a partition table, with a naked Linux file
61 system (e.g. erofs, squashfs or ext4)
62 These image formats are the same ones that systemd-nspawn(1) supports
64 via its --directory=/--image= switches and those that the service
65 manager supports via RootDirectory=/RootImage=. Similar to them they
66 may optionally carry Verity authentication information.
67 System extensions are searched for in the directories /etc/extensions/,
69 /run/extensions/ and /var/lib/extensions/. The first two listed
70 directories are not suitable for carrying large binary images, however
71 are still useful for carrying symlinks to them. The primary place for
72 installing system extensions is /var/lib/extensions/. Any directories
73 found in these search directories are considered directory based
74 extension images; any files with the .raw suffix are considered disk
75 image based extension images. When invoked in the initrd, the
76 additional directory /.extra/sysext/ is included in the directories
77 that are searched for extension images. Note however, that by default a
78 tighter image policy applies to images found there, though, see below.
79 This directory is populated by systemd-stub(7) with extension images
80 found in the system's EFI System Partition.
81 During boot OS extension images are activated automatically, if the
83 systemd-sysext.service is enabled. Note that this service runs only
84 after the underlying file systems where system extensions may be
85 located have been mounted. This means they are not suitable for
86 shipping resources that are processed by subsystems running in earliest
87 boot. Specifically, OS extension images are not suitable for shipping
88 system services or systemd-sysusers(8) definitions. See the Portable
89 Services Documentation[2] for a simple mechanism for shipping system
90 services in disk images, in a similar fashion to OS extensions. Note
91 the different isolation on these two mechanisms: while system extension
92 directly extend the underlying OS image with additional files that
93 appear in a way very similar to as if they were shipped in the OS image
94 itself and thus imply no security isolation, portable services imply
95 service level sandboxing in one way or another. The
96 systemd-sysext.service service is guaranteed to finish start-up before
97 basic.target is reached; i.e. at the time regular services initialize
98 (those which do not use DefaultDependencies=no), the files and
99 directories system extensions provide are available in /usr/ and /opt/
100 and may be accessed.
101 Note that there is no concept of enabling/disabling installed system
103 extension images: all installed extension images are automatically
104 activated at boot. However, you can place an empty directory named like
105 the extension (no .raw) in /etc/extensions/ to "mask" an extension with
106 the same name in a system folder with lower precedence.
107 A simple mechanism for version compatibility is enforced: a system
109 extension image must carry a
110 /usr/lib/extension-release.d/extension-release.$name file, which must
111 match its image name, that is compared with the host os-release file:
112 the contained ID= fields have to match unless "_any" is set for the
113 extension. If the extension ID= is not "_any", the SYSEXT_LEVEL= field
114 (if defined) has to match. If the latter is not defined, the
115 VERSION_ID= field has to match instead. If the extension defines the
116 ARCHITECTURE= field and the value is not "_any" it has to match the
117 kernel's architecture reported by uname(2) but the used architecture
118 identifiers are the same as for ConditionArchitecture= described in
119 systemd.unit(5). System extensions should not ship a
120 /usr/lib/os-release file (as that would be merged into the host /usr/
121 tree, overriding the host OS version data, which is not desirable). The
122 extension-release file follows the same format and semantics, and
123 carries the same content, as the os-release file of the OS, but it
124 describes the resources carried in the extension image.
125 The systemd-confext concept follows the same principle as the systemd-
127 sysext(1) functionality but instead of working on /usr and /opt,
128 confext will extend only /etc. Files and directories contained in the
129 confext images outside of the /etc/ hierarchy are not merged, and hence
130 have no effect when included in the image. Formats for these images are
131 of the same as sysext images. The merged hierarchy will be mounted with
132 "nosuid" and (if not disabled via --noexec=false) "noexec".
133 Confexts are looked for in the directories /run/confexts/,
135 /var/lib/confexts/, /usr/lib/confexts/ and /usr/local/lib/confexts/.
136 The first listed directory is not suitable for carrying large binary
137 images, however is still useful for carrying symlinks to them. The
138 primary place for installing configuration extensions is
139 /var/lib/confexts/. Any directories found in these search directories
140 are considered directory based confext images; any files with the .raw
141 suffix are considered disk image based confext images.
142 Again, just like sysext images, the confext images will contain a
144 /etc/extension-release.d/extension-release.$name file, which must match
145 the image name (with the usual escape hatch of xattr), and again with
146 content being one or more of ID=, VERSION_ID=, and CONFEXT_LEVEL.
147 Confext images will then be checked and matched against the base OS
148 layer.
149
151 The primary use case for system images are immutable environments where
152 debugging and development tools shall optionally be made available, but
153 not included in the immutable base OS image itself (e.g. strace(1) and
154 gdb(1) shall be an optionally installable addition in order to make
155 debugging/development easier). System extension images should not be
156 misunderstood as a generic software packaging framework, as no
157 dependency scheme is available: system extensions should carry all
158 files they need themselves, except for those already shipped in the
159 underlying host system image. Typically, system extension images are
160 built at the same time as the base OS image — within the same build
161 system.
162 Another use case for the system extension concept is temporarily
164 overriding OS supplied resources with newer ones, for example to
165 install a locally compiled development version of some low-level
166 component over the immutable OS image without doing a full OS rebuild
167 or modifying the nominally immutable image. (e.g. "install" a locally
168 built package with DESTDIR=/var/lib/extensions/mytest make install &&
169 systemd-sysext refresh, making it available in /usr/ as if it was
170 installed in the OS image itself.) This case works regardless if the
171 underlying host /usr/ is managed as immutable disk image or is a
172 traditional package manager controlled (i.e. writable) tree.
173 For the confext case, the OSConfig project aims to perform runtime
175 reconfiguration of OS services. Sometimes, there is a need to swap
176 certain configuration parameter values or restart only a specific
177 service without deployment of new code or a complete OS deployment. In
178 other words, we want to be able to tie the most frequently configured
179 options to runtime updateable flags that can be changed without a
180 system reboot. This will help reduce servicing times when there is a
181 need for changing the OS configuration.
182
184 The following commands are understood by both the sysext and confext
185 concepts:
186 status
188 When invoked without any command verb, or when status is specified
189 the current merge status is shown, separately (for both /usr/ and
190 /opt/ of sysext and for /etc/ of confext).
191 merge
193 Merges all currently installed system extension images into /usr/
194 and /opt/, by overmounting these hierarchies with an "overlayfs"
195 file system combining the underlying hierarchies with those
196 included in the extension images. This command will fail if the
197 hierarchies are already merged. For confext, the merge happens into
198 the /etc/ directory instead.
199 unmerge
201 Unmerges all currently installed system extension images from /usr/
202 and /opt/ for sysext and /etc/, for confext, by unmounting the
203 "overlayfs" file systems created by merge prior.
204 refresh
206 A combination of unmerge and merge: if already mounted the existing
207 "overlayfs" instance is unmounted temporarily, and then replaced by
208 a new version. This command is useful after installing/removing
209 system extension images, in order to update the "overlayfs" file
210 system accordingly. If no system extensions are installed when this
211 command is executed, the equivalent of unmerge is executed, without
212 establishing any new "overlayfs" instance. Note that currently
213 there's a brief moment where neither the old nor the new
214 "overlayfs" file system is mounted. This implies that all resources
215 supplied by a system extension will briefly disappear — even if it
216 exists continuously during the refresh operation.
217 list
219 A brief list of installed extension images is shown.
220 -h, --help
222 Print a short help text and exit.
223 --version
225 Print a short version string and exit.
226
228 --root=
229 Operate relative to the specified root directory, i.e. establish
230 the "overlayfs" mount not on the top-level host /usr/ and /opt/
231 hierarchies for sysext or /etc/ for confext, but below some
232 specified root directory.
233 --force
235 When merging system extensions into /usr/ and /opt/ for sysext and
236 /etc/ for confext, ignore version incompatibilities, i.e. force
237 merging regardless of whether the version information included in
238 the images matches the host or not.
239 --image-policy=policy
241 Takes an image policy string as argument, as per systemd.image-
242 policy(7). The policy is enforced when operating on system
243 extension disk images. If not specified defaults to
244 "root=verity+signed+encrypted+unprotected+absent:usr=verity+signed+encrypted+unprotected+absent"
245 for system extensions, i.e. only the root and /usr/ file systems in
246 the image are used. For configuration extensions defaults to
247 "root=verity+signed+encrypted+unprotected+absent". When run in the
248 initrd and operating on a system extension image stored in the
249 /.extra/sysext/ directory a slightly stricter policy is used by
250 default: "root=signed+absent:usr=signed+absent", see above for
251 details.
252 --noexec=BOOL
254 When merging configuration extensions into /etc/ the "MS_NOEXEC"
255 mount flag is used by default. This option can be used to disable
256 it.
257 --no-pager
259 Do not pipe output into a pager.
260 --no-legend
262 Do not print the legend, i.e. column headers and the footer with
263 hints.
264 --json=MODE
266 Shows output formatted as JSON. Expects one of "short" (for the
267 shortest possible output without any redundant whitespace or line
268 breaks), "pretty" (for a pretty version of the same, with
269 indentation and line breaks) or "off" (to turn off JSON output, the
270 default).
271
273 On success, 0 is returned.
274
276 systemd(1), systemd-nspawn(1), systemd-stub(7)
277
279 1. Discoverable Partitions Specification
280 https://uapi-group.org/specifications/specs/discoverable_partitions_specification
281 2. Portable Services Documentation
283 https://systemd.io/PORTABLE_SERVICES
284systemd 254 SYSTEMD-SYSEXT(8)