like:
src/shared/install.c: In function ‘unit_file_lookup_state’:
src/shared/install.c:1861:16: warning: ‘r’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
return r < 0 ? r : state;
^
src/shared/install.c:1796:13: note: ‘r’ was declared here
int r;
^
renameat2() exists since Linux 3.15 but btrfs support for the flag
RENAME_NOREPLACE was added later.
This patch implements a fallback when renameat2() returns EINVAL.
EINVAL is the error returned when the filesystem does not support one of
the flags.
This adds --template= to duplicate an OS tree as btrfs snpashot and run
it
This also adds --ephemeral or -x to create a snapshot of an OS tree and
boot that, removing it after exit.
loop_write() didn't follow the usual systemd rules and returned status
partially in errno and required extensive checks from callers. Some of
the callers dealt with this properly, but many did not, treating
partial writes as successful. Simplify things by conforming to usual rules.
Previously it would recursively copy the entire tree in, and descend
into subdirectories even if the destination already exists. Let's do
what the documentation says and not do that.
If files down the tree shall be copied too, they should get their own
"C" lines.
systemd-sysusers is a tool to reconstruct /etc/passwd and /etc/group
from static definition files that take a lot of inspiration from
tmpfiles snippets. These snippets should carry information about system
users only. To make sure it is not misused for normal users these
snippets only allow configuring UID and gecos field for each user, but
do not allow configuration of the home directory or shell, which is
necessary for real login users.
The purpose of this tool is to enable state-less systems that can
populate /etc with the minimal files necessary, solely from static data
in /usr. systemd-sysuser is additive only, and will never override
existing users.
This tool will create these files directly, and not via some user
database abtsraction layer. This is appropriate as this tool is supposed
to run really early at boot, and is only useful for creating system
users, and system users cannot be stored in remote databases anyway.
The tool is also useful to be invoked from RPM scriptlets, instead of
useradd. This allows moving from imperative user descriptions in RPM to
declarative descriptions.
The UID/GID for a user/group to be created can either be chosen dynamic,
or fixed, or be read from the owner of a file in the file system, in
order to support reconstructing the correct IDs for files that shall be
owned by them.
This also adds a minimal user definition file, that should be
sufficient for most basic systems. Distributions are expected to patch
these files and augment the contents, for example with fixed UIDs for
the users where that's necessary.
Kay Sievers