These are not actually needed or installed, so delete them from the
build directory, so that inside an image one can do:
apt install --reinstall /work/build/*.deb
Follow-up for 690a85b1d4
The new link-executor-shared option is similar to the existing
link-udev-shared: when set to false, we link to the static versions of our
internal libraries.
The resulting exuctor binary is fairly large, about as large as libsystemd-core
(14 MB without lto, 8 with lto).
This is intended as a workaround for the fuckup with the pinned executor
binary:
when an upgrade is performed, the package manager will install new version of
the libraries and new version of the code, and some time later reexecute the
managers. This creates a window when the pinned executor binary will fail to
execute. There are two factors which make the issue easier to hit:
- when the distribution uses a finely-grained shared-lib-tag. E.g. Fedora
uses version-release as the tag, which means that the issue occurs on
every package upgrade. This is the right thing to do, because the
ABI of our internal libraries is not stable at all, so replacing the
library from a different version in place creates a window where our
programs may crash or misbehave.
- when the distribution doesn't immediately reexec all the managers after
upgrade. In early versions of systemd, we used to hammer the machine during
upgrade, doing daemon-reexecs repeatedly. This works, but is ugly and
wasteful. Doing the reexecs while the upgrade is in progres also creates a
window where a mix of old and new configs or both is loaded. Users are
particularly annoyed by those reloads if there is some issue in the
configuration causing us to emit warnings on every reexec. Doing the
reexecs once after the new configuration and libraries have been put
in place is nicer.
The pinning of the executor binary breaks upgrades and in particular
it penalizes the distributions which make use of the features which
were previously added to avoid bugs and inefficiency during upgrades.
When the executor is linked statically, there is a smaller chance that it'll
fail to load libraries. The issue can still occur because other libraries, not
our own, are linked dynamically.
By itself, this is not useful. I'm making this a separate commit to
make debugging easier. It turns out that meson does static libraries
using references, so the "static library" a tiny stub stub that refers
to the object files on disk and this has negligible cost:
$ ls -lhd build/src/core/libsystemd-core-257.{a,so}
-rw-r--r-- 1 zbyszek zbyszek 36K Jul 3 16:54 build/src/core/libsystemd-core-257.a
-rwxr-xr-x 1 zbyszek zbyszek 6.1M Jul 3 16:54 build/src/core/libsystemd-core-257.so
Our variables for internal libraries are named 'libfoo' for the shared lib
variant, and 'libfoo_static' for the static lib variant. The only exception was
libbasic, because we didn't have a shared variant for it. But let's rename it
for consitency. This makes the build config easier to understand.
Previously, the order was quite chaotic, even sometimes interleaved with
entirely unrelated switches. Let's clean this up and use the same order
as in the spec.
This doesn't change anything real, but I think it's a worthy clean-up in
particular as this order is documented as the PCR measurement order of
these sections, hence there's actually a bit of relevance to always
communicate the same order everywhere.
The patch is originally from Brenton Simpson, I (Lennart) just added some
comments and rebased it.
I didn't test this, but the patch looks so obviously right to me, that
I think we should just merge it, instead of delaying this further. In
the worst case noone notices, in the best case this makes sd-boot work
reasonably nicely on devices that only have a hadware power key + volume
rocker.
Fixes: #30598
Replaces: #31135
At this point we have a clearer model:
* systemd-measure should be used for measuring UKIs on vendor build
systems, i.e. only cover stuff predictable by the OS vendor, and
identical on all systems. And that is pretty much only PCR 11.
* systemd-pcrlock should cover the other PCRs, which carry inherently
local information, and can only be predicted locally and not already
on vendor build systems.
Because of that, let's not bother with any PCRs except for 11 in
systemd-measure. This was added at a time where systemd-pcrlock didn't
exist yet, and hence it wasn't clear how this will play out in the end.
Let's simplify the code a bit, and parse Type 2 entries in a function of
its own, separate from the directory enumeration.
This closely follows a similar split we did a long time ago for Type 1.
This is just refactoring, no real code change.
While we write data to this parameter, it's not really a return
parameter, we after all do not fully set it, we just fill in some
fields. Hence it must be initialized beforehand.
According to our coding style only parameters that are purely used for
returning something should be named "ret_xyz", hence this one should not
be.
(We'll later rely on the current behaviour that it leaves array entries
for which we find no sections untouched, hence leave behaviour as is,
just rename the parameters to something more appropriate).
(Since we are dropping the "ret_" prefix of "ret_sections", let's rename
the old "section" parameter at the same time to "section_names", to make
clearer what it is about).
With the latest mkosi, mkosi -t none can be used to rerun the build
script without messing with a previously built image. This allows
one to run "mkosi -t disk -f qemu" in one terminal to build and boot
an image in qemu and then run "mkosi -t none" in another terminal to
rebuild the packages. If one then has "RuntimeBuildSources=yes" set
in their mkosi configuration, the build directory is mounted into the
virtual machine, which means that one can then run "dnf upgrade
/work/build/*.rpm" from within the VM to install the new packages.
This allows for quickly iterating on changes without having to rebuild
the image all the time.
We'll probably want to document this at some point, but let's start
with making it possible by copying the built packages to the build directory.
Currently if git merge-base fails we'll hide the error and exit with
exit status 0. Let's make we only exit early if git merge-base exits
with 1 which indicates the current commit is not on the target branch.
Any other error is considered fatal.
Two very similar devices, with two functions - a regular camera and IR.
The peculiarity of their infrared camera is that it uses a color image
format (YUYV), although it is essentially black and white.
The IR camera interface differs from the regular camera interface by name:
"HP Wide Vision FHD Camera: HP W" for the regular camera and
"HP Wide Vision FHD Camera: HP I" for an infrared camera
Therefore, glob *I is used to separate the IR camera
* f9fe17dbde Use vmlinux.h from kernel-devel
* 9cbad936a6 Pull in openssl-devel-engine
* 8ae009f929 Only add Requires on python3-zstd on Fedora
* 750e910c7c Drop BuildRequires on python3-zstd
These are required by the bpf_tracing.h header in libbpf, see
https://github.com/libbpf/libbpf/blob/master/src/bpf_tracing.h.
bpf_tracing.h does have a few fallbacks in case __TARGET_ARCH_XXX
is not defined but recommends using the __TARGET_ARCH macros instead
so let's do that.
We calculate the amount of uncompressed data we can write by taking the limits
into account and halving it to ensure there's room for switching to compression
on the fly when storing cores on a tmpfs (eg: due read-only rootfs).
But the logic is flawed, as taking into account the size of the tmpfs storage
was applied after the halving, so in practice when an uncompressed core file
was larger than the tmpfs, we fill it and then fail.
Rearrange the logic so that the halving is done after taking into account
the tmpfs size.
Be explicit with the type, and more inline with our other code, that
likes to indicate the string char width in the name.
Also, switch to a fixed size type, since EFI variables should really be
binary exact the same on all archs.
These functions after all write EFI UTF-16 strings, i.e. are relatively
high-level, hence give them a specific name indicating the type, to
match our other helpers that have similar type suffixes.