"Failed to dissect image: connection timed out" messages have been
appearing sporadically in mkosi CI. Let's enable debug logging to
help figure out why.
In journalctl we don't run the static destructors defined via
the STATIC_DESTRUCTOR_REGISTER() macro, since it requires a corresponding
static_destruct() call. In most cases this is handled by
the DEFINE_(TEST_)?MAIN*() macros, but journalctl defines its own main
function, so let's handle that as well.
$ valgrind --suppressions=valgrind.supp --show-leak-kinds=all --leak-check=full build/journalctl --no-pager -u system.slice -n 10 >/dev/null
==2778093== Memcheck, a memory error detector
==2778093== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2778093== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==2778093== Command: build/journalctl --no-pager -u system.slice -n 10
==2778093==
==2778093==
==2778093== HEAP SUMMARY:
==2778093== in use at exit: 8,221 bytes in 4 blocks
==2778093== total heap usage: 458 allocs, 454 frees, 255,182 bytes allocated
==2778093==
==2778093== 13 bytes in 1 blocks are still reachable in loss record 1 of 4
==2778093== at 0x484586F: malloc (vg_replace_malloc.c:381)
==2778093== by 0x4DA256D: strdup (strdup.c:42)
==2778093== by 0x4ADB747: strv_extend_with_size (strv.c:544)
==2778093== by 0x405386: strv_extend (strv.h:45)
==2778093== by 0x40816F: parse_argv (journalctl.c:933)
==2778093== by 0x40EAB5: main (journalctl.c:2111)
==2778093==
==2778093== 16 bytes in 1 blocks are still reachable in loss record 2 of 4
==2778093== at 0x484578A: malloc (vg_replace_malloc.c:380)
==2778093== by 0x484A70B: realloc (vg_replace_malloc.c:1437)
==2778093== by 0x4ADB2A3: strv_push_with_size (strv.c:423)
==2778093== by 0x4ADB620: strv_consume_with_size (strv.c:496)
==2778093== by 0x4ADB770: strv_extend_with_size (strv.c:548)
==2778093== by 0x405386: strv_extend (strv.h:45)
==2778093== by 0x40816F: parse_argv (journalctl.c:933)
==2778093== by 0x40EAB5: main (journalctl.c:2111)
==2778093==
==2778093== LEAK SUMMARY:
==2778093== definitely lost: 0 bytes in 0 blocks
==2778093== indirectly lost: 0 bytes in 0 blocks
==2778093== possibly lost: 0 bytes in 0 blocks
==2778093== still reachable: 29 bytes in 2 blocks
==2778093== suppressed: 8,192 bytes in 2 blocks
==2778093==
==2778093== For lists of detected and suppressed errors, rerun with: -s
==2778093== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
If UDP is blocked on the system (e.g. by iptables or BPF), the kernel will
return EPERM on some or all of the system calls (connect, sendmsg, etc.).
In this case, try to fall back to TCP, which hopefully will not be blocked.
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.
Salt was added in v253. We are not checking whether it was actually found
(non-zero size), so when an old tpm+pin enrollment is opened things go boom.
For good measure, check both the buffer and the size in both places.
Assertion 'saltlen > 0' failed at src/shared/tpm2-util.c:2490, function tpm2_util_pbkdf2_hmac_sha256(). Aborting.
__WORDSIZE does not seem to be documented anywhere, and is probably
meant to be used internally by glibc headers.
In systemd, it was only being used in warning messages. We can avoid
using it by rewording the messages slightly.
Fixes a build error with musl libc.
Bug: https://bugs.gentoo.org/894430
Before this, tests are split into two categories, system and user, but
both are running in fully privileged environment. Hence, unprivileged
user scope was mostly not covered by the test.
Let's run all tests in both system and user scopes, and drop capabilities
when Manager is running in user scope.
This also makes the host environment protected more from the test run.
At almost all places if diskseq is not supported we encode this as
diskseq zero. But in two places we got the check for that wrong,
assuming it was UINT64_MAX.
Fix that.