Originally, the source code was copied under /root/src.
This home directory is part of root FS and the new mkosi building
paradigm has only ephemeral root FS that is generated lazily.
Any files placed on the root FS in the build environment are that
excluded from the final image.
It is useful to have source codes available in the image's runtime (not
build time) environment for debugging.
ExtraTrees= as used currently are ineffective, so change the destination
to copy files under /usr to achieve the intention.
gdb sees source files as:
> 1354 ../src/src/systemctl/systemctl.c: No such file or directory.
Modify gdb configration in the built image accordingly (that file cannot
be in /root neither) to resolve to the moved sources.
(Commit fdecbf7 ("Enable unprivileged image builds") envisions bind
mounting or virtiofsd for nspawn or qemu containers respectively.)
This is a follow-up for #28596.
I think the suggestion to use Type=exec uses too strong wording:
Type=exec has non-trivial drawbacks over Type=simple, and they deserve
to be mentioned.
Hence drop the <emphasis> and turn this around so that Type=exec is
*recommended*, but Type=simple is not expressly discouraged, because
there are plenty reasons to use it.
Add a brief discussion where Type=simple might be preferable.
Also, fix the outright unruth that Type=exec was the "simplest and
fastest", because it certainly is a lot, but not that.
For a userns root user to be able to access the credentials, both
the uid and gid of the credentials directory have to be mapped into
the userns. Currently, the credentials directory group is root, which
we obviously do not want to map in to a userns, so let's make sure
that the credentials directory and files are owned by the service
group instead, which can generally be safely mapped into the userns.
Since we use permissions mode 0600, this shouldn't cause any change
in who is able to access the credentials.
Fixes#28747
But the directories are changed from /dev/loop/by-ref/ -> /dev/disk/by-loop-ref/
and /dev/loop/by-inode/ -> /dev/disk/by-loop-inode/.
As /dev/loop/ is used by losetup command for other purpose.
See issue #28475.
This effectively reverts commits 9915cc6086,
5022fab15f, and
c0d998248e.
This update introduces the explicit Dependencies= setting, instead
of relying on implicit dependencies via alphanumerical ordering.
We also take the opportunity to rename the "final" preset to the
"system" preset, which seems like a better name.
This is supposed to be a help for compilers to apply optimizations on
functions where they can't determine whether they are const/pure on
their own. For static, local functions the compiler can do this on its
own easily however, hence the decoration with pure/const is just noise.
Let's drop it, and let the compiler to its thing better.
(Use it for exported functions, since compilers can't 'reach-over' into
other modules to determine if they are pure, except if LTO is used)
Our coding style says static variables suck except for very special
cases, i.e. things like the log level or very per-process stuff, such as
parsed version of cmdline args and such. sysusers departed from that as
one of the very few exceptions in our codebases: it keeps its
operational state in global variables.
Address that. Introduce a Context object that carries the fields that so
far have been global, and pass it around as needed.
This has the nice effect that state and configuration is clearly
separated in code, and we can very clearly see which functions mangle
state and which ones do not.
No actual codeflow changes, just refactoring.
The command is deprecated, as per NEWS of 254. Let's go one step further
and remove it from the help text and man page, so that people are not
inspired to use it at this time anymore.
This is how we usually have done this before: remove it from visibility,
but support it for a while still.
Otherwise, if for some reasons remount-fs is invoked even when fstab=no is
specified, mounts may get unexpected options from fstab.
For safety, let's parse the kernel command line option.
Currently, fstab-generator does not use fstab file parsers in
fstab-util.c. So, this is not necessary. Just for a possible
optimization in the case the parsers used in the future.
Michal Koutný
Luca Boccassi
Lennart Poettering
Franck Bui
Frantisek Sumsal
Daan De Meyer
Yu Watanabe
Mike Yuan
Xiaotian Wu
Zbigniew Jędrzejewski-Szmek