[Bug 1982218] Autopkgtest regression report (systemd/249.11-0ubuntu3.10)

Fri Aug 25 22:43:26 UTC 2023

All autopkgtests for the newly accepted systemd (249.11-0ubuntu3.10) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

apt/2.4.10 (armhf)
casync/2+20201210-1build1 (ppc64el)
comitup/1.15-1 (armhf)
dbus/1.12.20-2ubuntu4.1 (armhf)
initramfs-tools/0.140ubuntu13.4 (s390x)
linux-azure-5.19/5.19.0-1027.30~22.04.2 (arm64)
linux-gcp-6.2/6.2.0-1011.11~22.04.3 (arm64)
linux-lowlatency/5.15.0-83.92 (arm64)
linux-lowlatency-hwe-5.19/5.19.0-1030.30 (arm64)
linux-nvidia-tegra/5.15.0-1016.16 (arm64)
linux-oracle-5.19/5.19.0-1027.30 (arm64)
mkosi/unknown (s390x)
munin/2.0.57-1ubuntu2 (armhf)
netplan.io/0.105-0ubuntu2~22.04.3 (arm64)
prometheus-postfix-exporter/unknown (s390x)
samba/2:4.15.13+dfsg-0ubuntu1.4 (arm64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/jammy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1982218

Title:
  wait-online does not correctly identify managed links

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Lunar:
  Fix Committed

Bug description:
  [Impact]

  systemd-networkd-wait-online will exit prematurely when the --any flag
  is passed, due to an incorrect patch in Ubuntu that is supposed to
  make systemd-networkd-wait-online exit when *no* links are managed.

  [Test Plan]

  This test uses a VM managed by libvirt. In this scenario we have the
  "default" network which provides DHCP to the VM, and the "no-dhcp"
  network which does not provide DHCP.

  To setup the VM (this assumes Jammy, but the same steps apply for
  Lunar using appropriate names and install media):

  1. Define the default and no-dhcp networks:

  $ cat > /tmp/net-default.xml << EOF
  <network>
    <name>default</name>
    <uuid>04260896-2701-422d-84e0-8e0df1122db3</uuid>
    <forward mode='nat'/>
    <bridge name='virbr0' stp='on' delay='0'/>
    <mac address='52:54:00:bd:9f:3a'/>
    <ip address='192.168.122.1' netmask='255.255.255.0'>
      <dhcp>
        <range start='192.168.122.2' end='192.168.122.254'/>
      </dhcp>
    </ip>
  </network>
  $ virsh net-create --file /tmp/net-default.xml
  $ cat > /tmp/net-default.xml << EOF
  <network>
    <name>no-dhcp</name>
    <uuid>2c047740-caab-4c90-8421-70da6732a759
  </uuid>
    <forward mode='nat'/>
    <bridge name='virbr1' stp='on' delay='0'/>
    <mac address='52:54:00:ac:12:45'/>
    <ip address='172.16.1.1' netmask='255.255.0.0'>
    </ip>
  </network>
  $ virsh net-create --file /tmp/net-no-dhcp.xml
  $ virsh net-start --network default
  $ virst net-start --network no-dhcp

  2. Create the VM using virt-install:

  virt-install \
  --connect=qemu:///system \
  --name=jammy \
  --arch=x86_64 \
  --cpu=host-passthrough \
  --ram=4096 \
  --vcpus=1 \
  --disk=path=/var/lib/libvirt/images/jammy.qcow2,size=24,format=qcow2,sparse=true,bus=virtio \
  --virt-type=kvm \
  --accelerate \
  --hvm \
  --cdrom=/tmp/ubuntu-22.04.2-live-server-amd64.iso \
  --os-type=linux \
  --os-variant=generic \
  --graphics=spice \
  --input=tablet \
  --network=network=default,model=virtio \
  --video=qxl \
  --noreboot

  3. Complete the installation steps. Reboot the VM.

  Run the test:

  1. Detach the network interface so that the test starts with no
  interfaces attached:

  $ virsh detach-interface $VM network

  2. In the VM, write a network config for all en* links to use DHCP:

  $ cat > /etc/systemd/network/10-dhcp.network << EOF
  [Match]
  Name=en*

  [Network]
  DHCP=yes
  EOF

  3. Restart systemd-networkd:

  $ systemctl restart systemd-networkd

  4. On the host, attach an interface to the VM on the no-dhcp network,
  so that an IP is not assigned:

  $ virsh attach-interface $VM network no-dhcp

  5. Back in the VM, confirm that the device is in the
  degraded/configuring state:

  $ networkctl
  networkctl
  IDX LINK TYPE     OPERATIONAL SETUP
    1 lo   loopback carrier     unmanaged
    8 ens3 ether    degraded    configuring

  2 links listed.

  6. Run systemd-networkd-wait-online --any, and confirm that it does
  timeout instead of returning while the device is is still not
  configured:

  $ /lib/systemd/systemd-networkd-wait-online --any --timeout=10
  Timeout occurred while waiting for network connectivity.

  7. Confirm that the device is STILL in the degraded/configuring state:

  $ networkctl
  IDX LINK TYPE     OPERATIONAL SETUP
    1 lo   loopback carrier     unmanaged
    8 ens3 ether    degraded    configuring

  2 links listed.

  8. Now, leave systemd-network-wait-online --any running while we
  attach another interface:

  $ /lib/systemd/systemd-networkd-wait-online --any --timeout=0

  9. On the host, attach another interface to the VM on the default
  network, so that DHCP assigns the interface an IP:

  $ virsh attach-interface $VM network default

  10. Back in the VM, the systemd-networkd-wait-online process should
  have exited with success, and networkctl should show the new link as
  configured, while the old one is still configuring:

  $ /lib/systemd/systemd-networkd-wait-online --any --timeout=0
  $ echo $?
  0
  $ networkctl
  IDX LINK TYPE     OPERATIONAL SETUP
    1 lo   loopback carrier     unmanaged
    8 ens3 ether    degraded    configuring
    9 ens9 ether    routable    configured

  3 links listed.

  [Where problems could occur]

  This patch we want to remove is totally confined to systemd-networkd-
  wait-online, so that's where we would see problems. From what I can
  tell, the patch is no longer doing what it was intended to do. E.g.
  running systemd-networkd-wait-online on a desktop install, where
  systemd-networkd does not manage links, results in a timeout. It only
  works with the --any flag, but the --any flag did not exist when the
  patch was written. If a user was relying on --any to make systemd-
  networkd-wait-online exit when no links are managed, they will see a
  change in behavior as a result of this change. However, the resulting
  behavior will be consistent with the manual page.

  [Original Description]

  Ubuntu's packaging of systemd-networkd-wait-online includes a patch
  (UBUNTU-wait-online-exit-if-no-links-are-managed) intended to exit if
  none of the present links are managed by systemd-networkd.  However,
  the patch fails to identify links in the "configuring" state, which
  implies they are managed, but not yet fully online.  This undermines
  the purpose of systemd-networkd-wait-online with the --any option,
  since at the time the systemd-networkd-wait-online service is started,
  managed links are _likely_ in a configuring, but-not-yet-configured
  state.

  Please see the attached patch.  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982218/+subscriptions