← Back to team overview

group.of.nepali.translators team mailing list archive

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

 

@admcleod

Based on feedback from IBM i'm going to withdraw this update. The
ordering of the flags is correct, as long as one activates the flag
needed to have bridge_role attribute available before onlining the
device.

Specifically one should use:

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

meaning... enable layer2 networking, which creates a bunch of attributes
specific to layer2 mode, including the bridge_role. Then set
bridge_role. Then online the device.

Testing this out here locally results in race free boots, without any
changes to the code.

Could you please try out above command in your preseeds without using
packages from proposed?

Regards,

Dimitri.

** Tags removed: verification-needed
** Tags added: verification-failed

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

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

** Changed in: s390-tools (Ubuntu)
       Status: Fix Released => Confirmed

** Changed in: s390-tools (Ubuntu Zesty)
       Status: Fix Released => Confirmed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1618463

Title:
  udev race condition with qeth device and bridge_role

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in s390-tools package in Ubuntu:
  Confirmed
Status in s390-tools source package in Xenial:
  Incomplete
Status in s390-tools source package in Yakkety:
  Incomplete
Status in s390-tools source package in Zesty:
  Confirmed

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@10-13-3-10:/var/log# cat /sys/devices/qeth/0.0.c003/bridge_role
  none
  root@10-13-3-10:/var/log# echo primary > /sys/devices/qeth/0.0.c003/bridge_role
  root@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-z-systems/+bug/1618463/+subscriptions