It seems that on Semaphore CI, running in Bullseye images, having
both Network-Manager and systemd-networkd enabled causes
'systemctl start network-online.target' to get stuck, and fail
the run. Disable networkd in those tests.
See: https://github.com/systemd/systemd/issues/22991
polkit.service is started on-demand via D-Bus activation. This means it
is not a good indicator if a boot was successful. Instead check if
NetworkManager is running as it is started via multi-user.target.
Closes: #934992
The check for is-system-running handles verifying that systemd completes
all its jobs during startup, making this test redundant. Also, since the
testbed can (and does) start more jobs after is-system-running, this test
can provide a false negative if any of those jobs continue running after
this check's timeout.
There is currently no delay to wait for is-system-running to reach running
or degraded, so it's very possible for there to be running jobs. This adds
a delay until is-system-running is 'running' or 'degraded', and gathers
extra artifacts if the system is 'degraded'.
Additional details are in this Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825997
Note that bug description states:
"This patch is not required for debian, because debian's boot-smoke does
not include the wait for systemctl is-system-running", however this patch
adds that wait, because without it, the check for running jobs can easily
fail, if the system isn't fully running yet.
Otherwise we'll catch some
Failed to resolve group 'render': Connection timed out
messages that happen in earlier boots during VM setup, before the
"render" group is created.
Fixes https://github.com/systemd/systemd/issues/11875
Use their $AUTOPKGTEST_* equivalents.
These were introduced in autopkgtest 4.0 (June 2016), and all our CI
systems use a much newer version.
Gbp-Dch: Short
When running tests for upstream PRs, this test often fails with
checking for connection timeouts
systemd-udevd[1228]: Failed to resolve group 'render': Connection timed out
Which is not the kind of timeout the test is looking for. Create the
group in the test to avoid this.
We explicitly don't create the group in systemd.postinst as we revert
the patch that introduces the group into the udev rules.
20 iterations take about 45 minutes in our cloud environment, so dial that down
for now. It's simple enough to bump back once we actually run into a hard to
reproduce boot failure, but it has not happened in a long time.
Gbp-Dch: Short
