Lines Matching refs:image
15 their dependencies are packaged in an image, and are run directly from it.
29 or inside a raw disk image containing a Linux file system. This tree is called
30 the "image". It can be "attached" or "detached" from the system. When
31 "attached", specific systemd units from the image are made available on the
36 The OS tree/image can be created with any tool of your choice. For example, you
37 can use `dnf --installroot=` if you like, or `debootstrap`, the image format is
39 distribution images carry anyway. Or to say this differently: the image format
85 If you have a portable service image, maybe in a raw disk image called
94 1. It dissects the image, checks and validates the `os-release` file of the
95 image, and looks for all included unit files.
98 `.target`, `.timer` and `.path`. whose name begins with the image's name
100 This prefix name generated from the image name must be followed by a ".",
101 "-" or "@" character in the unit name. Or in other words, given the image
111 so on, relative to the image's root.
138 portable service is attached. If an image is moved, the `RootImage=` line
140 access to the image.
143 the drop-ins and the unit files associated with the image, and removes them.
150 useful in case an image gets upgraded, as it allows performing a `restart`
157 Note that portable services don't introduce any new image format, but most OS
159 requirements are made for an image that can be attached/detached with
166 2. The image must either be a plain sub-directory (or btrfs subvolume)
168 must be a raw disk image either containing only one, naked file system, or
169 an image with a partition table understood by the Linux kernel with only a
174 3. The image must at least contain one matching unit file, with the right name
177 image. (The implementation will check a couple of other paths too, but it's
180 4. The image must contain an os-release file, either in `/etc/os-release` or
183 5. The image must contain the files `/etc/resolv.conf` and `/etc/machine-id`
186 6. The image must contain directories `/proc/`, `/sys/`, `/dev/`, `/run/`,
191 if the image is built based on glibc, the dynamic loader needs to be
200 minimal image would be that complies with the requirements above, it could
224 If the image is writable, and some of the files or directories that are
229 Note that as no new image format or metadata is defined, it's very
232 single, unified image that:
237 2. Can be run as OS container, using `systemd-nspawn`, by booting the image
240 3. Can be booted directly as VM image, using a generic VM executor such as
246 image. To facilitate 3 and 4 you also need to include a boot loader in the
247 image. As mentioned, `mkosi -b` takes care of all of that for you, but any
248 other image generator should work too.
253 supported portable service prefixes for the image (see above). This is useful
255 from their contents as such), but is also useful to protect the image from
258 as this way the (not necessarily authenticated) image file name can be
259 validated against the (authenticated) image contents. If the field is not
260 specified the image will work fine, but is not necessarily recognizable as
261 portable service image, and any set of units included in the image may be
267 image, and are combined with OverlayFS at runtime, when they are attached. This
269 portable services can share the same 'runtime' image (libraries, tools) without
275 1. The base/OS image must contain an `os-release file`, either in `/etc/os-release`
278 2. The upper extension(s) image(s) must contain an extension-release file in
280 matching the base image.
282 3. The base/OS image does not need to have any unit files.
284 4. The upper extension(s) image(s) must at least contain one matching unit file each,
287 5. As with the base/OS image, the upper extension(s) image(s) must be a plain
288 sub-directory, a btrfs subvolume or a raw disk image.