This adds back sd-boot builds by using meson compile targets directly.
We can do this now, because userspace binaries use the special
dependency that allows us to easily separate flags, so that we don't
pass anything to EFI builds that shouldn't be passed.
Additionally, we pass a bunch of flags to hopefully disable/override any
distro provided flags that should not be used for EFI binaries.
Fixes: #12275
This drops all mentions of gnu-efi and its manual build machinery. A
future commit will bring bootloader builds back. A new bootloader meson
option is now used to control whether to build sd-boot and its userspace
tooling.
Although udev rules are already being checked by rule-syntax-check.py
script, also check them using udevadm verify which performs more
thorough checks.
With this change we'll install a symlink /sbin/mount.ddi →
systemd-dissect. If invoked that way we'll do the equivalent of
systemd-dissect --mount.
This makes DDIs mountable directly via the "mount" command, by
specifying the "-t ddi" pseudo file system type. Moreover you can now
mount DDIs directly via /etc/fstab, by specifying "ddi" in the file
system column (3rd column).
IN C23, thread_local is a reserved keyword and we shall therefore
do nothing to redefine it. glibc has it defined for older standard
version with the right conditions.
v2 by Yu Watanabe:
Move the definition to missing_threads.h like the way we define e.g.
missing syscalls or missing definitions, and include it by the users.
Co-authored-by: Yu Watanabe <watanabe.yu+github@gmail.com>
When mkosi is run from git-worktree(1), the .git is not a repository
directory but a textfile pointing to the real git dir
(e.g. /home/user/systemd/.git/worktrees/systemd-worktree). This git dir
is not bind mounted into build environment and it fails with:
> fatal: not a git repository: /home/user/systemd/.git/worktrees/systemd-worktree
> test/meson.build:190:16: ERROR: Command `/usr/bin/env -u GIT_WORK_TREE /usr/bin/git --git-dir=/root/src/.git ls-files ':/test/dmidecode-dumps/*.bin'` failed with status 128.
There is already a fallback to use shell globbing instead of ls-files,
use it with git worktrees as well.
Most of the support for valgrind was under HAVE_VALGRIND_VALGRIND_H, i.e. we
would enable if the valgrind headers were found. The operations then we be
conditionalized on RUNNING_UNDER_VALGRIND.
But in a few places we had code which was conditionalized on VALGRIND, i.e. the
config option. I noticed because I compiled with -Dvalgrind=true on a machine
that didn't have valgrind.h, and the build failed because
RUNNING_UNDER_VALGRIND was not defined. My first idea was to add a check that
the header is present if the option is set, but it seems better to just remove
the option. The code to support valgrind is trivial, and if we're
!RUNNING_UNDER_VALGRIND, it has negligible cost. And the case of running under
valgrind is always some special testing/debugging mode, so we should just do
those extra steps to make valgrind output cleaner. Removing the option makes
things simpler and we don't have to think if something should be covered by the
one or the other configuration bit.
I had a vague recollection that in some places we used -Dvalgrind=true not
for valgrind support, but to enable additional cleanup under other sanitizers.
But that code would fail to build without the valgrind headers anyway, so
I'm not sure if that was still used. If there are uses like that, we can
extend the condition for cleanup_pools().
Although this slightly more verbose it makes it much easier to reason
about. The code that produces the tests heavily benefits from this.
Test lists are also now sorted by test name.
A lot of tests can be defined by just their filename. Moving into their
own list keeps things simpler, especially with the next commit. It also
makes it easier to keep the lists sorted.
Allow defining the default keymap to be used by
vconsole-setup through a build option. A template
vconsole.conf also gets populated by tmpfiles if
it doesn't exist.
This will warn if fake flexible arrays are re-introduced. I'm not using
-Werror=… because we may still get warnings when compiling against old kernel
headers. We can crank this up to error later.
-fstrict-flex-arrays means that the compiler doesn't have to assume that any
trailing array is a flex array. I.e. unless the array is declared without a
specified size, only indices in the declared range are valid.
-Warray-bounds turns on the warnings about out-of-bounds array accesses.
-Warray-bounds=2 does some more warnings, with higher false positive rate. But
it doesn't seem to yield any false positives in our codebase, so enable it.
clang supports -Warray-bounds, but not -Warray-bounds=2.
gcc supports both.
gcc-13 supports -fstrict-flex-arrays.
See https://people.kernel.org/kees/bounded-flexible-arrays-in-c for a long
discussion of use in the kernel.
Config options are -Ddefault-timeout-sec= and -Ddefault-user-timeout-sec=.
Existing -Dupdate-helper-user-timeout= is renamed to -Dupdate-helper-user-timeout-sec=
for consistency. All three options take an integer value in seconds. The
renaming and type-change of the option is a small compat break, but it's just
at compile time and result in a clear error message. I also doubt that anyone was
actually using the option.
This commit separates the user manager timeouts, but keeps them unchanged at 90 s.
The timeout for the user manager is set to 4/3*user-timeout, which means that it
is still 120 s.
Fedora wants to experiment with lower timeouts, but doing this via a patch would
be annoying and more work than necessary. Let's make this easy to configure.
The unlink command removes an entry from the ESP including
referenced files that are not referenced in other entries. That is
useful eg to have multiple entries that use the same kernel with
different options.
The cleanup command removes all files that are not referenced by any
entry.
These options allow measuring the volume key used for unlocking the
volume to a TPM2 PCR. This is ideally used for the volume key of the
root file system and can then be used to bind other resources to the
root file system volume in a secure way.
See: #24503
We converted to not using #ifdef for most of our defines because the syntax is
nicer and we are protected against typos and can set -Werror=undef. Let's do
the same for SD_BOOT. The define is nicely hidden in build.h for normal builds,
and for EFI builds we were already setting SD_BOOT on the commandline.
Some gymnastics were needed to import ukify as a module. Before the file
was templated, this was trivial: insert the directory in sys.path, call import.
But it's a real pain to import the unsuffixed file after processing. Instead,
the untemplated file is imported, which works well enough for tests and is
very simple.
The tests can be called via pytest:
PATH=build/:$PATH pytest -v src/ukify/test/test_ukify.py
or directly:
PATH=build/:$PATH src/ukify/test/test_ukify.py
or via the meson test machinery output:
meson test -C build test-ukify -v
or without verbose output:
meson test -C build test-ukify
Zekret files are obfuscated using base64.
The option is added because we have a similar one for kernel-install. This
program requires python, and some people might want to skip it because of this.
The tool is installed in /usr/lib/systemd for now, since the interface might
change.
A template file is used, but there is no .in suffix.
The problem is that we'll later want to import the file as a module
for tests, but recent Python versions make it annoyingly hard to import
a module from a file without a .py suffix. imp.load_sources() works, but it
is deprecated and throws warnings.
importlib.machinery.SourceFileLoader().load_module() works, but is also
deprecated. And the documented replacements are a maze of twisted little
callbacks that result in an empty module.
So let's take the easy way out, and skip the suffix which makes it easy
to import the template as a module after adding the directory to sys.path.
I'd like to use this as a basis for an exitrd:
When compiled with -Dstandalone-binaries=true -Db_lto=true -Dbuildtype=release,
the new file is 800k. It's more than I'd like, but still quite a bit less
than libsystemd-shared.so, which is 3800k.
