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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The glibc stuff on ppc64le C8S is a little bit wild, as there are two
versions:
```
$ ldconfig -p | grep libc.so
libc.so.6 (libc6,64bit, hwcap: "power9", OS ABI: Linux 3.10.0) => /lib64/glibc-hwcaps/power9/libc-2.28.so
libc.so.6 (libc6,64bit, OS ABI: Linux 3.10.0) => /lib64/libc.so.6
```
and with `/etc/ld.so.cache` present all binaries use the first one:
```
$ ldd /bin/cat
linux-vdso64.so.1 (0x00007fffa8070000)
libc.so.6 => /lib64/glibc-hwcaps/power9/libc-2.28.so (0x00007fffa7e20000)
/lib64/ld64.so.2 (0x00007fffa8090000)
```
However, without the cache the binaries will fall back to `/lib64/libc.so.6`
which breaks tests that use the minimal verity images (like TEST-29),
because we install only the first version (that's shown by `ldd` at
the time the images are created):
```
[ 91.595343] testsuite-29.sh[747]: + portablectl --profile=trusted attach --now --runtime /usr/share/minimal_0.raw minimal-app0
Starting systemd-portabled.service...
[ OK ] Started systemd-portabled.service.
Starting minimal-app0-foo.service...
Starting minimal-app0.service...
[ 104.432217] cat[858]: cat: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
[ 104.435080] cat[857]: cat: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
[FAILED] Failed to start minimal-app0.service.
See 'systemctl status minimal-app0.service' for details.
```
```
$ chroot /var/tmp/systemd-test.nMHPfc/minimal/
/bin/bash: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
```
With the ldconfig's cache it seems to work as expected:
```
$ chroot /var/tmp/systemd-test.gVtYLg/minimal
bash-4.4# cat --version
cat (GNU coreutils) 8.30
...
```
The iscsi-init.service calls `sh` which might, in certain circumstances,
pull in instrumented systemd NSS modules causing `sh` to fail. Let's mitigate
this by pulling in an env file crafted by `create_asan_wrapper()` that
(among others) pre-loads ASan's DSO.
Since open-iscsi 2.1.2 [0] the initiator name should be generated via
a one-time service instead of distro package's post-install scripts.
However, some distros still use this approach even after this patch,
so prefer the already existing initiatorname.iscsi file if it exists.
[0] f37d5b653f
In most cases we refernced the concept as "initrd". Let's convert most
remaining uses of "initramfs" to "initrd" too, to stay internally
consistent.
This leaves "initramfs" only where it's relevant to explain historical
concepts or where "initramfs" is part of the API (i.e. in
/run/initramfs).
Follow-up for: b66a6e1a58
On certain systems the `install_libnss()` function might end up with an
empty list of libraries to install, which triggers an assertion in
`image_install()`:
```
I: Install libnss
..//test-functions: line 2721: 1: parameter null or not set
make: *** [Makefile:4: setup] Error 1
```
E.g.:
```
# LD_DEBUG=files getent passwd 2>&1 >/dev/null | sed -n '/calling init: .*libnss_/ {s!^.* /!/!; p}'
/lib64/libnss_sss.so.2
/lib64/libnss_systemd.so.2
# dnf -y remove sssd-client systemd-libs
# LD_DEBUG=files getent passwd 2>&1 >/dev/null | sed -n '/calling init: .*libnss_/ {s!^.* /!/!; p}'
<no output>
```
Let's handle this case gracefully.
Until now using the INTERACTIVE_DEBUG=yes stuff together with sanitizers
was almost impossible, since the console kept eating up our inputs or
not responding at all. After a painful day of debugging I noticed that
if we use a shell script in the initrd -> root transition, we might end up
with a plymouthd still running, which kept screwing with the tty.
E.g. with initrd -> wrapper -> systemd transition, where the `wrapper`
is a simple script:
```
exec -- /usr/lib/systemd/systemd "$@"
```
we'd end up with a stray plymouthd process after the bootup:
```
1 0 440 2 20 0 0 0 worker I ? 0:00 [kworker/5:2-ata_sff]
1 0 453 2 20 0 0 0 worker I ? 0:00 [kworker/9:2-rcu_gp]
5 0 456 1 20 0 7252 1960 do_epo S ? 0:00 @usr/sbin/plymouthd --mode=boot --pid-file=/run/plymouth/pid --attach-to-session
```
After killing it, the tty works finally as expected.
Set both timeouts to some reasonable values instead of just `infinity`
to provide some form of a safe-net in case the test goes haywire and the
environment didn't set the timeouts itself (like our CIs do).
to avoid scope clashing in case some previous test crashed and/or didn't
clean up properly. Currently all test machines are called `root`, since
the name is automagically derived from the container path (in this case
`/var/tmp/systemd-test.XXXXXX/root`).
E.g. (from Ubuntu CI):
```
[23:10:12] --x-- Running TEST-71-HOSTNAME --x--
make: Entering directory '/tmp/autopkgtest.5LjnBV/build.0mE/systemd/test/TEST-71-HOSTNAME'
+ make -C TEST-71-HOSTNAME setup run
TEST-71-HOSTNAME SETUP: test hostnamed
Reusing existing cached image /tmp/autopkgtest.5LjnBV/build.0mE/systemd/test/TEST-71-HOSTNAME/../default.img → /tmp/autopkgtest.5LjnBV/build.0mE/systemd/test/default.img
'/var/tmp/systemd-test.1yy2SS/default.img' -> '/tmp/autopkgtest.5LjnBV/build.0mE/systemd/test/default.img'
I: Masking supporting services
'/var/tmp/systemd-test.1yy2SS/root/etc/systemd/system/systemd-hwdb-update.service' -> '/dev/null'
'/var/tmp/systemd-test.1yy2SS/root/etc/systemd/system/systemd-journal-catalog-update.service' -> '/dev/null'
'/var/tmp/systemd-test.1yy2SS/root/etc/systemd/system/systemd-networkd.service' -> '/dev/null'
'/var/tmp/systemd-test.1yy2SS/root/etc/systemd/system/systemd-networkd.socket' -> '/dev/null'
'/var/tmp/systemd-test.1yy2SS/root/etc/systemd/system/systemd-resolved.service' -> '/dev/null'
TEST-71-HOSTNAME RUN: test hostnamed
+ env --unset=UNIFIED_CGROUP_HIERARCHY --unset=SYSTEMD_NSPAWN_UNIFIED_HIERARCHY timeout --foreground 1200 /bin/systemd-nspawn --register=no --kill-signal=SIGKILL --directory=/var/tmp/systemd-test.1yy2SS/root --setenv=SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-71.units:/usr/lib/systemd/tests/testdata/units: /lib/systemd/systemd systemd.unit=testsuite.target systemd.wants=testsuite-71.service systemd.wants=end.service
Spawning container root on /var/tmp/systemd-test.1yy2SS/root.
Press ^] three times within 1s to kill container.
Failed to allocate scope: Unit root.scope already exists.
E: nspawn failed with exit code 1
```
Some tests (like TEST-02) set a multiline string to $KERNEL_APPEND
(which is a valid thing to do), unfortunately we'd use only the first
line of it and throw the rest away, e.g:
```
$ printf "%s" "$x"
hello
this is a multiline
kernel command line
$ read -ra out <<< "$x"
$ printf "%s" "${out[@]}"
hello
```
Let's use readarray/mapfile instead to avoid this:
```
$ readarray out <<< "$x"
$ printf "%s" "${out[@]}"
hello
this is a multiline
kernel command line
```
When an extension image has binaries they should match the host
architecture. Currently there is no way to specify this requirement.
Introduce an ARCHITECTURE field in the extension's release file that
may be set to prevent loading on the wrong host architecture.
Since this new field is introduced late, we don't want to make
specifying it mandatory as it would break existing sysext images.
See https://github.com/systemd/systemd/issues/24061
A sysext image that merely contains static binaries has no dependency
on the host distribution and should be able to be used anywhere.
Support the special '_any' value for the ID field in the extension to
opt-out of ID and VERSION_ID/SYSEXT_LEVEL matching.
See https://github.com/systemd/systemd/issues/24061
Since the library is dlopen()ed by libpthread and required during
pthread_exit()/pthread_cancel(), let's install it explicitly if available to
avoid unexpected fails in tests. This also consolidates all related
workarounds for this library across the test scripts.
Bash allows only one handler per signal, so let's overcome this
limitation by having one dedicated EXIT signal which runs all registered
handlers from all over the place.
so we can run TEST-24 under sanitizers as well.
Also, when at it, use the 'named-fields' sfdisk format to make the code
a bit more descriptive without needing a manual.
- use test_append_files() to install additional commands
- drop use of expect
- include assert.sh and use assertions at several places
- use timeout command at several places
- always use logind-test-user
- etc
since we delete the guest journals as part of the save_journal() step in
check_result_common(), making journal inaccessible from the custom check
hooks.
Let's detect & wrap binaries which are linked against systemd DSOs and
we're running under ASan, since otherwise running such binaries ends
with:
```
==633==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
```
