IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Let's consider the following case:
- the direction is down,
- no cached entry,
- the array has 5 entry objects,
- the function test_object() reutns TEST_LEFT for the 1st object,
- the 2nd, 3rd, and 4th objects are broken, so generic_array_bisect_step()
returns TEST_RIGHT for the object.
Then, previously, generic_array_bisect_step() updated the values like the following:
0th: (m = 5, left = 0, right = 4, i = 4) -> (m = 4, left = 0, right = 3, RIGHT)
1st: (m = 4, left = 0, right = 3, i = 1) -> (m = 4, left = 2, right = 3, LEFT)
2nd: (m = 4, left = 2, right = 3, i = 2) -> (m = 2, left = 2, right = 1, RIGHT) <- ouch!!
So, assert(left < right) in generic_array_bisect() was triggered.
See issue #30210.
In such situation, there is no matching entry in the array. By returning
TEST_GOTO_PREVIOUS, generic_array_bisect() handles the result so.
Fixes a bug introduced by ab8f553d1e.
Fixes#30210.
The errors are valid, since the file system is indeed not writable, but
we don't care about the missing coverage data in this case.
Follow-up to 4a43c2b3a1.
The previous patch 466266c does not make sense indeed, that is to say, if the SYSTEMD_READY is not recorded in the database, the GOTO="systemd_end" will not be applied.
The IMPORT{db} is actually a matching token, it returns false when there is no SYSTEMD_READY recorded in the database.
The previous patch 466266c tended to inherit the state of SYSTEMD_READY from the database and skip to the end of current rule file. But when the database does not contain SYSTEMD_READY, e.g., the dm-* is not set db_persistent during initrd and the database will be cleared after switching root, the following rules will still be applied not as expected.
This drops logs of failed unit tests in TEST-02-UNITTESTS from the journal,
as the expected logs from test-varlink-idl makes the post script fail.
Saving logs in journal is simply noisy, and we will output anyway after
qemu or nspawn finished by check_result_{qemu,nspawn}_unittests().
It's been there since the test was introduced and I'm not really sure
what was the original intention behind it, but it makes systemd sad:
[ 4.909056] systemd[1]: /usr/lib/systemd/tests/testdata/units/testsuite-44.service:13: Unknown key name 'LogTarget' in section 'Service', ignoring.
Turns out that redirecting a lot of output to the console can have some
funny effects, like random kernel soft lockups. I spotted this in
various CIs, but it remained almost entirely hidden thanks to
`softlockup_panic=1`, until 1a36d2672f which introduced a couple of
tests that log quite a lot in a short amount of time. This, in
combination with newer kernel version, which, for some reason, seem to
be more susceptible to such soft lockups, made the Arch Linux jobs soft
lockup quite a lot, see [0].
While debugging this I also noticed that runs which don't redirect
stdout/stderr to the console are noticeably faster, e.g.:
# TEST-71 nspawn + QEMU (KVM), StandardOutput=journal+console
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:24.64
# TEST-71 nspawn + QEMU (KVM), StandardOutput=journal
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:17.95
# TEST-71 nspawn + QEMU, StandardOutput=journal+console
Elapsed (wall clock) time (h:mm:ss or m:ss): 2:04.70
# TEST-71 nspawn + QEMU, StandardOutput=journal
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:44.48
# TEST-04 QEMU, StandardOutput=journal+console
Elapsed (wall clock) time (h:mm:ss or m:ss): 4:22.70
# TEST-04 QEMU, StandardOutput=console
Elapsed (wall clock) time (h:mm:ss or m:ss): 5:04.67
Given all this, let's effectively revert ba7abf79a5, and dump the
testsuite-related journal messages only after the test finishes, so they
don't go through the slow console.
Resolves: systemd/systemd-centos-ci#660
[0] https://github.com/systemd/systemd-centos-ci/issues/660
Let's save all journals from the test machine instead of calling export
on each journal file separately, which makes the code less complicated
(and probably faster).
The logic is taken from dump ratelimit: if the config changes, we discard the
counters. This allows the user apply new limits and "start from scratch" in
that case.
This actually makes StartLimitIntervalSec=infinity (or with a large interval)
work as expected, because the counter is maintained even if daemon-reload
operations are interleaved.
We have not tested if the settings actually filter DHCP servers.
Let's add a test case for the settings.
Note, the .network file used here has been unused since
0730e3767d. So, we can freely reuse it
without changing other test cases.
Closes#30107.
I'm pretty sure this is not the only case, but it's the one I recently
noticed. Even though we call ddebug() from a function, that function is
called before ddebug() is defined, resulting in the same issue as if we
called just ddebug() in its place, i.e.:
..//test-functions: line 276: ddebug: command not found
meson's `cpp_args` option is defined only if it detects a C++ compiler,
otherwise we get an error:
../test/fuzz/meson.build:56:28: ERROR: Tried to access unknown option 'cpp_args'.
Currently the test works only with policy shipped by Fedora, which makes
it pretty much useless in most of our CIs. Let's drop the custom module
and make the test more generic, so it works with the refpolicy as well,
which should allow us to run it on Arch and probably even in Ubuntu CI.
--tpm2-device-key= requires OpenSSL >= 3 with KDF-SS, so let's skip the
test if we're running with older OpenSSL.
+ systemd-cryptenroll --tpm2-device-key=/tmp/srk.pub --tpm2-pcrs=12:sha256=F5A5FD42D16A20302798EF6ED309979B43003D2320D9F0E8EA9831A92759FB4B /tmp/systemd-cryptsetup-H8y.IMAGE
Failed to find TPM2 pcrlock policy file 'pcrlock.json': No such file or directory
Allocating context for crypt device /tmp/systemd-cryptsetup-H8y.IMAGE.
Trying to open and read device /tmp/systemd-cryptsetup-H8y.IMAGE with direct-io.
Trying to open device /tmp/systemd-cryptsetup-H8y.IMAGE without direct-io.
Initialising device-mapper backend library.
Trying to load LUKS2 crypt type from device /tmp/systemd-cryptsetup-H8y.IMAGE.
Crypto backend (OpenSSL 1.1.1k FIPS 25 Mar 2021) initialized in cryptsetup library version 2.3.7.
Detected kernel Linux 4.18.0-521.el8.ppc64le ppc64le.
...
Failed to find TPM PCR public key file 'tpm2-pcr-public-key.pem': No such file or directory
Failed to read TPM2 PCR public key, proceeding without: No such file or directory
Can't find symbol Esys_TR_GetTpmHandle: /lib64/libtss2-esys.so.0: undefined symbol: Esys_TR_GetTpmHandle
libtss2-esys too old, does not include Esys_TR_GetTpmHandle.
Can't find symbol Esys_TR_GetTpmHandle: /lib64/libtss2-esys.so.0: undefined symbol: Esys_TR_GetTpmHandle
libtss2-esys too old, does not include Esys_TR_GetTpmHandle.
PolicyPCR calculated digest: 9a1f511fb94f030eb21d0332ef2739727bf0ead4ec26a204d15b09cdeb4b2555
Calculating sealed object.
Calculating encrypted seed for sealed object.
Calculating encrypted seed for ECC sealed object.
Calculating KDFe().
KDF-SS requires openssl >= 3.
Could not calculate KDFe: Operation not supported
Could not calculate encrypted seed: Operation not supported
Failed to seal to TPM2: Operation not supported
don't let the devices to be announced just as model "Linux". Let's instead
propagate the underlying block device's model. Also do something
reasonably smart for the serial and firmware version fields.
Prompted by #29972, because right now it's practically impossible to pass
-fno-sanitize=function to the fuzzer targets without some extensive
sed'ing.
This splits both c_args and cpp_args to separate arguments for
tools/meson-build.sh, because the other way would be to use `eval`, so
the space-separated but quoted strings passed to these options are not
split where they shouldn't, and I'd rather avoid using `eval` if
possible.
Also, this switches the positional arguments we pass to `meson setup`,
as they were in incorrect order (docs say it should be buildir followed
by sourcedir); meson is apparently clever enough to figure this out and
switch the arguments around if necessary, so it didn't complain.
