Mount units can do it, but the command line tool cannot, as it needs a
valid 'what'. If --tmpfs/-T if passed, parse the argument as 'where'
and send a literal 'tmpfs' as the 'what' if not specified.
This metadata (EXTENSION_RELOAD_MANAGER) can be set to "1" to reload the manager
when merging/refreshing/unmerging a system extension image. This can be useful in case the sysext
image provides systemd units that need to be loaded.
With `--no-reload`, one can deactivate the EXTENSION_RELOAD_MANAGER metadata interpretation.
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
install_subdir() does not copy symlinks but copies the file they
point to. We also get a very ugly warning in the meson install
output:
"""
Warning: trying to copy a symlink that points to a file. This will copy the file,
but this will be changed in a future version of Meson to copy the symlink as is. Please update your
build definitions so that it will not break when the change happens.
"""
Let's fix both problems at once by using rsync which does the right
thing. Verified by running systemd-dissect --mtree on both the install
output before and after and all the symlinks are now correctly preserved.
If someone reads /run/host/os-release at the exact same time it is being updated, and it
is large enough, they might read a half-written file. This is very unlikely as
os-release is typically small and very rarely changes, but it is not
impossible.
Bind mount a staging directory instead of the file, and symlink the file
into into, so that we can do atomic file updates and close this gap.
Atomic replacement creates a new inode, so existing bind mounts would
continue to see the old file, and only new services would see the new file.
The indirection via the directory allows to work around this, as the
directory is fixed and never changes so the bind mount is always valid,
and its content is shared with all existing services.
Fixes https://github.com/systemd/systemd/issues/28794
Follow-up for 3f37a82545
This makes tmpfiles, sysusers, and udevd invoked in the following order:
1. systemd-tmpfiles-setup-dev-early.service
Create device nodes gracefully, that is, create device nodes anyway
by ignoring unknown users and groups.
2. systemd-sysusers.service
Create users and groups, to make later invocations of tmpfiles and
udevd can resolve necessary users and groups.
3. systemd-tmpfiles-setup-dev.service
Adjust owners of previously created device nodes.
4. systemd-udevd.service
Process all devices. Especially to make block devices active and can
be mountable.
5. systemd-tmpfiles-setup.service
Setup basic filesystem.
Follow-up for b42482af90.
Fixes#28653.
Replaces #28681 and #28732.
This reverts commits 112a41b6ec,
3178698bb5, and
b768379e8b.
The commit 112a41b6ec introduces #28765,
as systemd-tmpfiles-setup.service has ordering after local-fs.target,
but usually the target requires block devices processed by udevd.
Hence, the service can only start after the block devices timed out.
Fixes#28765.
