@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
_______________________________________________
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
