[Bug 1618463] Re: udev race condition with qeth device and bridge_role

[Brian Murray]

Hello Andrew, or anyone else affected,

Accepted s390-tools into yakkety-proposed. The package will build now
and be available at
https://launchpad.net/ubuntu/+source/s390-tools/1.36.1-0ubuntu2.1 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: s390-tools (Ubuntu Yakkety)
       Status: In Progress => Fix Committed

** Tags added: verification-needed

** Changed in: s390-tools (Ubuntu Xenial)
       Status: In Progress => Fix Committed

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

Title:
  udev race condition with qeth device and bridge_role

Status in s390-tools package in Ubuntu:
  Fix Released
Status in s390-tools source package in Xenial:
  Fix Committed
Status in s390-tools source package in Yakkety:
  Fix Committed
Status in s390-tools source package in Zesty:
  Fix Released

Bug description:
  [Impact]

   * bridge_role property setting is racy on boot

   * This results in incorrect bridge mode set on the devices,
  sometimes, which leads to lack of desired connectivity (e.g. bridging
  internet to containers)

   * The fix for this issue is to set bridge_role, only after the device
  is online

   * Unfortunately the udev rules are not regenerated, therefore
  affected systemd must manually remove and recreate chzdev rules

  [Test Case]

   * Remove qeth udev rules from /etc/udev/rules.d/
   * Enable qeth device using chzdev with a non-default bridge_role setting, e.g.:
     chzdev --no-root-update -pVe c003 bridge_role=primary;
   * Reboot and check that bridge_role setting is correctly set in the sysfs, e.g.:
     /sys/devices/qeth/0.0.c003/bridge_role

  [Regression Potential]

   * Minimal, the generated udev rules remain the same; the only
  difference in the generated udev rules is the ordering in setting the
  bridge_role attribute

  [Other Info]
   
   * Original bug report:

  Attempting to set bridge_role = primary with the following command in
  preseed:

  in-target chzdev --no-root-update -pVe c003 bridge_role=primary;

  ...works, and generates the following udev rule for this device:

  https://pastebin.canonical.com/164271/

  However, after reboot:

  systemd-udevd[2634]: error opening
  ATTR{/sys/devices/qeth/0.0.c003/bridge_role} for writing: Permission
  denied

  More logging:

  https://pastebin.canonical.com/164272/

  after the system has booted, we are able to write to the file and set
  bridge_role to primary:

  root at 10-13-3-10:/var/log# cat /sys/devices/qeth/0.0.c003/bridge_role
  none
  root at 10-13-3-10:/var/log# echo primary > /sys/devices/qeth/0.0.c003/bridge_role
  root at 10-13-3-10:/var/log# cat /sys/devices/qeth/0.0.c003/bridge_role
  primary

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/1618463/+subscriptions