[Bug 2019221] Re: System fails to boot due to early OpenVSwitch Forwarding Unit service start

[Frode Nordahl]

The referenced kernel bug 2004262 does indeed look relevant to the
description of the problem, would you be able to try the proposed kernel
fix and see if that solves your problem?

** Changed in: openvswitch (Ubuntu)
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to openvswitch in Ubuntu.
https://bugs.launchpad.net/bugs/2019221

Title:
  System fails to boot due to early OpenVSwitch Forwarding Unit service
  start

Status in openvswitch package in Ubuntu:
  Incomplete

Bug description:
  I am experiencing an issue with Ubuntu 22.04 LTS after upgrading from kernel version 5.15.0-65-generic to 5.15.0-69-generic. The system fails to boot, hanging at the OpenVSwitch Forwarding Unit service.
  Aftre reverting to 5.15.0-65-generic all fine.

  OVS version 2.17.5

  The system has a bond configured with LACP (802.3ad) mode. The
  OpenVSwitch bridge (br-ex) is bound to this bond. Through
  investigation, I found that the issue seems to be caused by the bond
  not starting before the OpenVSwitch Forwarding Unit service starts. As
  a result, the OpenVSwitch Forwarding Unit service fails to start,
  which subsequently causes network services to fail to start as well.

  If I boot into recovery mode, wait for the bond to start, and then
  manually start the OpenVSwitch Forwarding Unit service and apply the
  netplan configuration (netplan apply), all network services start
  correctly. This suggests that the bonding module is being loaded after
  the OpenVSwitch Forwarding Unit service starts.

  To rectify this, I attempted to modify the OpenVSwitch service to
  explicitly wait for the bond interface to be initialized by adding the
  following lines to /lib/systemd/system/openvswitch-switch.service:

  makefile
  Copy code
  Wants=sys-subsystem-net-devices-bond0.device
  After=sys-subsystem-net-devices-bond0.device
  Unfortunately, this did not resolve the issue.

  I also tried changing the bond mode to active-backup, but the issue
  persists.

  Logs indicate the error message: "Timed out waiting for device
  /sys/subsystem/net/devices/bond0" during startup, even though the bond
  interface appears to be available (as confirmed by checking
  /proc/net/bonding/bond0).

  I suspect that the OpenVSwitch service might be starting before
  systemd-networkd fully initializes the bond interface. I've also
  considered the possibility that the issue might be related to netplan
  configuration or recent changes in its operation.

  I can't find any error logs in ovs or netplan that clearly point to a
  problem. I only find errors with timeouts.

  Could you please provide guidance on how to ensure that the bond
  interface fully initializes before the OpenVSwitch service starts?
  Alternatively, could this be a bug that needs to be addressed in a
  future update?P erhaps this is due to Bonding or Netplan logic or
  Bonding driver(which is sewn into the kernel, if I'm not mistaken)?

  P.S. If I bind an interface (ens3f1, for example), not a bond, to the
  bridge of OVS (br-ex), the system boots normally.

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