This bug was fixed in the package systemd - 245.4-4ubuntu3.21
---
systemd (245.4-4ubuntu3.21) focal; urgency=medium
* udev: avoid NIC renaming race with kernel (LP: #2002445)
Files:
-
debian/patches/lp2002445-netlink-do-not-fail-when-new-interface-name-is-already-us.patch
This autopkgtest run for systemd from 245.4-4ubuntu3.21 focal-proposed
shows that armhf is passing again:
https://autopkgtest.ubuntu.com/results/autopkgtest-
focal/focal/armhf/s/systemd/20230327_104352_bc3ad@/log.gz.
** Tags removed: verification-needed verification-needed-focal
** Tags added:
Hello Stefan, or anyone else affected,
Accepted systemd into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.21 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
** Merge proposal linked:
https://code.launchpad.net/~enr0n/ubuntu/+source/systemd/+git/systemd/+merge/438988
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1991285
Thanks for reviewing, Steve.
I took a closer look at this. The failure is indeed caused by the
container environment, and not something specific to the armhf arch. In
particular, the lxd images ship with a non-empty /etc/fstab which
contains an entry for a disk label that is not present:
To proceed with this SRU, I would like to have some analysis of what
makes this an armhf-only failure. Is it to do with the fact that armhf
autopkgtests run in a container and others do not? If so, it seems to
me that a more correct fix for the test is to detect that we're running
in a container
** Description changed:
+ [Impact]
+ The armhf autopkgtests currently fail in Focal due to this, and failures are
not marked as regressions. This limits our ability to catch other regressions
on armhf.
+
+ [Test Plan]
+ The boot-and-services autopkgtest should not fail on armhf. Specifically,
** Merge proposal linked:
https://code.launchpad.net/~enr0n/ubuntu/+source/systemd/+git/systemd/+merge/437809
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1991285
** Also affects: linux (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: systemd (Ubuntu Focal)
Importance: Undecided => Low
** Changed in: systemd (Ubuntu Focal)
Status: New =>
It appears the last time this worked was around linux 5.4.0-122-generic,
e.g. this test run: https://autopkgtest.ubuntu.com/results/autopkgtest-
focal/focal/armhf/s/systemd/20220907_155827_ae562@/log.gz.
Then we start seeing it around 5.4.0.128.129, e.g. this test run:
Here's a bit more information about the service failure:
-- Logs begin at Sun 2022-09-25 00:05:05 UTC, end at Thu 2022-09-29 12:03:20
UTC. --
Sep 29 12:02:57 autopkgtest-lxd-fexenj systemd-remount-fs[74]: mount: /: can't
find LABEL=cloudimg-rootfs.
Sep 29 12:02:57 autopkgtest-lxd-fexenj
** Tags added: foundations-triage-discuss
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1991285
Title:
systemd/245.4-4ubuntu3.18 ADT test failure with
Log entries from failure:
==
FAIL: test_no_failed (__main__.ServicesTest)
No failed units
--
Traceback (most recent call last):
File
To me it looks like the boot-and-services sub-tests got a lot less
reliable on armhf in Focal. The previous systemd version had a higher
chance of passing those. There always was root-unittests which required
multiple attempts. But now from about 10 attempts there was one which
had root-unittests
14 matches
Mail list logo
