- Let's set the environment on the kernel command line so it applies
to initrd and main system.
- Let's add the necessary wrappers that are also added in test-functions.
Unlike test-functions we don't use gcc/clang to get the library path as
that requires installing gcc/clang in the initrd.
- Let's drop the hack to get journald writing to the console and have
it write to kmsg instead. We'll get the output either way.
- Stop removing libstdc++ and sanitizer libraries from Arch Linux
initrds and other images as it's required by the sanitizer libraries.
- Add a workaround for specifying extra meson options for opensuse
- Add a leak sanitizer suppression file as a workaround for a false
positive leak in verify_selinuxmnt() in libselinux. We do a soname match
because the stacktrace can't be properly symbolized on Debian.
This reverts commit e74a994ebf.
The description in that commit was confused, add-determinism was not broken
and was not causing any problems, except a log message.
Currently, Unit.freezer_state is always initialized to
FREEZER_RUNNING. While realizing cgroups for frozen units
was disabled in 7923e9493c,
the commit only checked for freezer_state of the unit inself,
meaning that newly-loaded units might be started and the kernel
would hang pid1 when trying to spawn sd-executor into sub-cgroup.
This can be easily reproduced by the following:
```console
# systemd-run --slice=test.slice sleep infinity
# systemctl freeze test.slice
# systemd-run --slice=test.slice sleep infinity
```
Therefore, let's correctly initialize Unit.freezer_state
based on the parent slice.
Now that we use KVM and don't use repart anymore to create a root
partition on first boot, let's see if we can use the same device timeout
for both local and CI runs.
Import magic.h from Linux 6.9 to get the definition of
BCACHEFS_SUPER_MAGIC. Update filesystems-gperf.gperf to add knowledge of
bcachefs.
This fixes the following error building against a bleeding edge kernel.
```
src/basic/meson.build:234:8: ERROR: Problem encountered: Unknown filesystems defined in kernel headers:
Filesystem found in kernel header but not in filesystems-gperf.gperf: BCACHEFS_SUPER_MAGIC
```
This prevents volume keys on the machine from repeating.
Full modalias:
```
$ cat /sys/class/dmi/id/modalias
dmi:bvnLENOVO:bvrMMCN36WW:bd03/26/2024:br1.36:efr1.30:svnLENOVO:pn21KH:pvrThinkBook16G6IRL:rvnLENOVO:rnLNVNB161216:rvrSDK0T76530WIN:cvnLENOVO:ct10:cvrThinkBook16G6IRL:skuLENOVO_MT_21KH_BU_idea_FM_ThinkBook16G6IRL:
```
We already have an entry for this mouse when it is connected via USB Bolt
receiver, now add a Bluetooth LE connection entry too.
This mouse model supports both connection types, with up to 3 connection
slots (to different hosts) per single mouse.
Since rpm 4.20 it tries to fix the permissions of all source files
in the sources. This takes forever and fails in our case with a
permission error. Since we don't want rpm touching our source files,
override the script to be a noop.
This was added for reproducible builds which we don't really care
about when building rpms in mkosi, so disable it from running as it's
broken and breaks our rpm builds.
The corresponding bug was fixed in rpm 4.20 (of which the alpha is in
rawhide as rpm 4.19.91) so skip the workaround when we detect a newer
rpm version.
Unfortunately, git submodules break in all sorts of ways:
- Various github workflows (dependabot, github pages) try to do a shallow
clone of git submodules which does not work at all when the git repository
is hosted on pagure (https://pagure.io/pagure/issue/5453,
https://github.com/dependabot/dependabot-core/issues/9391).
- If the git forge hosting the git repository uses SHA256, then it breaks our
usage of it as a submodule as SHA256 repositories cannot be used as submodules
in SHA1 repositories (src.opensuse.org moved to SHA256 which broke our usage of
opensuse's systemd spec as a submodule).
- git submodules completely break usage of git worktrees.
- ...
Let's avoid all these issues by just doing our own home grown implementation of
git submodules. We lose the automatic dependabot updates this way but since dependabot
fails to run more often that not with submodules we don't really lose anything.
Currently, we don't explicitly call unit_freezer_thaw(),
but rely on the destructor to thaw the frozen unit on
return. This has several problems though, one of them
being that we ignore the return value of ThawUnit(),
which is something we really shouldn't do here,
since such failure can easily leave the whole system
in unusable state. Moreover, the logging is kinda messy,
e.g. homed might log "Everything completed" yet immediately
followed by "Failed to thaw unit". Instead, we should log
consistently and at higher level, to make things more
debuggable.
Therefore, let's step away from the practice. Plus,
make UnitFreezer object heap-allocated, to match
with existing unit_freezer_new() and allow us to
use NULL to denote that the freezer is disabled.
