In certain cases we might attempt to install a binary which is already
present in the test image, yet it's missing from the host system.
In such cases, let's check if the binary indeed exists in the image
before doing any other chcecks. If it does, immediately return with
success.
This was discovered during installation of
/usr/lib/systemd/systemd-bless-boot, which was not present in Ubuntu CI
(as the installed systemd was from the Ubuntu repositories), and the
binary itself was already in the image thanks to `ninja install`.
However, during extraction of binaries from the systemd service files,
another attempt to install this binary was made, which failed due to
`find_binary` being unable to find it.
The extended testsuite only works with UID=0. It contains of several
subdirectories named "test/TEST-??-*", which are run one by one.
To run the extended testsuite do the following:
$ ninja -C build # Avoid building anything as root later
$ sudo test/run-integration-tests.sh
ninja: Entering directory `/home/zbyszek/src/systemd/build'
ninja: no work to do.
--x-- Running TEST-01-BASIC --x--
+ make -C TEST-01-BASIC BUILD_DIR=/home/zbyszek/src/systemd/build clean setup run
make: Entering directory '/home/zbyszek/src/systemd/test/TEST-01-BASIC'
TEST CLEANUP: Basic systemd setup
TEST SETUP: Basic systemd setup
...
TEST RUN: Basic systemd setup [OK]
make: Leaving directory '/home/zbyszek/src/systemd/test/TEST-01-BASIC'
--x-- Result of TEST-01-BASIC: 0 --x--
--x-- Running TEST-02-CRYPTSETUP --x--
+ make -C TEST-02-CRYPTSETUP BUILD_DIR=/home/zbyszek/src/systemd/build clean setup run
If one of the tests fails, then $subdir/test.log contains the log file of
the test.
To run just one of the cases:
$ sudo make -C test/TEST-01-BASIC clean setup run
Specifying the build directory
==============================
If the build directory is not detected automatically, it can be specified
with BUILD_DIR=:
$ sudo BUILD_DIR=some-other-build/ test/run-integration-tests
or
$ sudo make -C test/TEST-01-BASIC BUILD_DIR=../../some-other-build/ ...
Note that in the second case, the path is relative to the test case directory.
An absolute path may also be used in both cases.
Configuration variables
=======================
TEST_NO_QEMU=1
Don't run tests under QEMU
TEST_NO_NSPAWN=1
Don't run tests under systemd-nspawn
TEST_NO_KVM=1
Disable QEMU KVM autodetection (may be necessary when you're trying to run the
*vanilla* QEMU and have both qemu and qemu-kvm installed)
QEMU_MEM=512M
Configure amount of memory for QEMU VMs (defaults to 512M)
QEMU_SMP=1
Configure number of CPUs for QEMU VMs (defaults to 1)
KERNEL_APPEND='...'
Append additional parameters to the kernel command line
NSPAWN_ARGUMENTS='...'
Specify additional arguments for systemd-nspawn
QEMU_TIMEOUT=infinity
Set a timeout for tests under QEMU (defaults to infinity)
NSPAWN_TIMEOUT=infinity
Set a timeout for tests under systemd-nspawn (defaults to infinity)
INTERACTIVE_DEBUG=1
Configure the machine to be more *user-friendly* for interactive debuggung
(e.g. by setting a usable default terminal, suppressing the shutdown after
the test, etc.)
The kernel and initramfs can be specified with $KERNEL_BIN and $INITRD.
(Fedora's or Debian's default kernel path and initramfs are used by default)
A script will try to find your QEMU binary. If you want to specify a different
one with $QEMU_BIN.
Debugging the qemu image
========================
If you want to log in the testsuite virtual machine, you can specify additional
kernel command line parameter with $KERNEL_APPEND and then log in as root.
$ sudo make -C test/TEST-01-BASIC KERNEL_APPEND="systemd.unit=multi-user.target" run
Root password is empty.
3cdb93d07b
