[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
This bug was fixed in the package systemd - 229-4ubuntu21 --- systemd (229-4ubuntu21) xenial; urgency=medium * networkd: do not uncoditionally apply NOARP. * networkd: fix size of MTUBytes so that it does not overwrites ARP. * Fixes regression-updates LP: #1727301 -- Dimitri John Ledkov Fri, 27 Oct 2017 09:21:18 +0100 ** Changed in: systemd (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Fix Released Status in systemd package in Ubuntu: Invalid Status in systemd source package in Xenial: Fix Released Status in systemd source package in Zesty: Invalid Status in systemd source package in Artful: Invalid Status in systemd source package in Bionic: Invalid Bug description: [Impact] * Setting [Link] MTUBytes= in .network file has a side-effect of overflowing and setting NOARP flag. This is not intended behaviour / regression. * Trying to fix above by setting ARP=on fails to work as tristate is incorrectly acted upon by unconditionally adding NOARP flag * This is a regression in -updates. [Affected Users] * Those who use networkd * Do not use netplan (as that sets mtubytes in the .link files, not in the .network) * Specify MTUBytes in .network file (not in the .link file) [Test Case] * Configure an ethernet device with a .network file alone * e.g. Match by mac address and perform DHCP * Add [Link] section to the .network file which changes MTUBytes * Device brought up using this configuration should not have NOAPR flag in the output of iproute link output * Further add ARP=off to that .network file, the link should have NOARP flag * Further add ARP=on to that .network file, the link should not have NOARP flag A test script is attached, that given an interface can abuse it to validate all of the above. [Regression Potential] * These are upstream fixes for ARP= key that are part of zesty and up [Other Info] * Upstream fixes https://github.com/systemd/systemd/commit/b8b40317d0355bc70bb23a6240a36f3630c4952b.patch https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
the updates-proposed build works in my case as well -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Fix Released Status in systemd package in Ubuntu: Invalid Status in systemd source package in Xenial: Fix Committed Status in systemd source package in Zesty: Invalid Status in systemd source package in Artful: Invalid Status in systemd source package in Bionic: Invalid Bug description: [Impact] * Setting [Link] MTUBytes= in .network file has a side-effect of overflowing and setting NOARP flag. This is not intended behaviour / regression. * Trying to fix above by setting ARP=on fails to work as tristate is incorrectly acted upon by unconditionally adding NOARP flag * This is a regression in -updates. [Affected Users] * Those who use networkd * Do not use netplan (as that sets mtubytes in the .link files, not in the .network) * Specify MTUBytes in .network file (not in the .link file) [Test Case] * Configure an ethernet device with a .network file alone * e.g. Match by mac address and perform DHCP * Add [Link] section to the .network file which changes MTUBytes * Device brought up using this configuration should not have NOAPR flag in the output of iproute link output * Further add ARP=off to that .network file, the link should have NOARP flag * Further add ARP=on to that .network file, the link should not have NOARP flag A test script is attached, that given an interface can abuse it to validate all of the above. [Regression Potential] * These are upstream fixes for ARP= key that are part of zesty and up [Other Info] * Upstream fixes https://github.com/systemd/systemd/commit/b8b40317d0355bc70bb23a6240a36f3630c4952b.patch https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
$ dpkg -l | grep 229-4 ii libpam-systemd:amd64229-4ubuntu21 amd64system and service manager - PAM module ii libsystemd-dev:amd64229-4ubuntu21 amd64systemd utility library - development files ii libsystemd0:amd64 229-4ubuntu21 amd64systemd utility library ii libudev-dev:amd64 229-4ubuntu21 amd64libudev development files ii libudev1:amd64 229-4ubuntu21 amd64libudev shared library ii systemd 229-4ubuntu21 amd64system and service manager ii systemd-sysv229-4ubuntu21 amd64system and service manager - SysV links ii udev229-4ubuntu21 amd64/dev/ and hotplug management daemon Executed the attached regression-apr.sh script against my eht0 interface, all 4 test cases reported good. Previously at least one of them failed. ** Tags removed: verification-needed verification-needed-xenial ** Tags added: verification-done verification-done-xenial ** Description changed: [Impact] * Setting [Link] MTUBytes= in .network file has a side-effect of overflowing and setting NOARP flag. This is not intended behaviour / regression. * Trying to fix above by setting ARP=on fails to work as tristate is incorrectly acted upon by unconditionally adding NOARP flag * This is a regression in -updates. + + [Affected Users] + + * Those who use networkd + + * Do not use netplan (as that sets mtubytes in the .link files, not in the .network) + + * Specify MTUBytes in .network file (not in the .link file) [Test Case] * Configure an ethernet device with a .network file alone * e.g. Match by mac address and perform DHCP * Add [Link] section to the .network file which changes MTUBytes * Device brought up using this configuration should not have NOAPR flag in the output of iproute link output * Further add ARP=off to that .network file, the link should have NOARP flag * Further add ARP=on to that .network file, the link should not have NOARP flag A test script is attached, that given an interface can abuse it to validate all of the above. [Regression Potential] * These are upstream fixes for ARP= key that are part of zesty and up [Other Info] * Upstream fixes https://github.com/systemd/systemd/commit/b8b40317d0355bc70bb23a6240a36f3630c4952b.patch https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Fix Released Status in systemd package in Ubuntu: Invalid Status in systemd source package in Xenial: Fix Committed Status in systemd source package in Zesty: Invalid Status in systemd source package in Artful: Invalid Status in systemd source package in Bionic: Invalid Bug description: [Impact] * Setting [Link] MTUBytes= in .network file has a side-effect of overflowing and setting NOARP flag. This is not intended behaviour / regression. * Trying to fix above by setting ARP=on fails to work as tristate is incorrectly acted upon by unconditionally adding NOARP flag * This is a regression in -updates. [Affected Users] * Those who use networkd * Do not use netplan (as that sets mtubytes in the .link files, not in the .network) * Specify MTUBytes in .network file (not in the .link file)
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
** Tags removed: regression-updates ** Tags added: regression-update -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Fix Released Status in systemd package in Ubuntu: Invalid Status in systemd source package in Xenial: Fix Committed Status in systemd source package in Zesty: Invalid Status in systemd source package in Artful: Invalid Status in systemd source package in Bionic: Invalid Bug description: [Impact] * Setting [Link] MTUBytes= in .network file has a side-effect of overflowing and setting NOARP flag. This is not intended behaviour / regression. * Trying to fix above by setting ARP=on fails to work as tristate is incorrectly acted upon by unconditionally adding NOARP flag * This is a regression in -updates. [Affected Users] * Those who use networkd * Do not use netplan (as that sets mtubytes in the .link files, not in the .network) * Specify MTUBytes in .network file (not in the .link file) [Test Case] * Configure an ethernet device with a .network file alone * e.g. Match by mac address and perform DHCP * Add [Link] section to the .network file which changes MTUBytes * Device brought up using this configuration should not have NOAPR flag in the output of iproute link output * Further add ARP=off to that .network file, the link should have NOARP flag * Further add ARP=on to that .network file, the link should not have NOARP flag A test script is attached, that given an interface can abuse it to validate all of the above. [Regression Potential] * These are upstream fixes for ARP= key that are part of zesty and up [Other Info] * Upstream fixes https://github.com/systemd/systemd/commit/b8b40317d0355bc70bb23a6240a36f3630c4952b.patch https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
Hello Markus, or anyone else affected, Accepted systemd into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/229-4ubuntu21 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-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. 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: systemd (Ubuntu Xenial) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Fix Released Status in systemd package in Ubuntu: Invalid Status in systemd source package in Xenial: Fix Committed Status in systemd source package in Zesty: Invalid Status in systemd source package in Artful: Invalid Status in systemd source package in Bionic: Invalid Bug description: [Impact] * Setting [Link] MTUBytes= in .network file has a side-effect of overflowing and setting NOARP flag. This is not intended behaviour / regression. * Trying to fix above by setting ARP=on fails to work as tristate is incorrectly acted upon by unconditionally adding NOARP flag * This is a regression in -updates. [Test Case] * Configure an ethernet device with a .network file alone * e.g. Match by mac address and perform DHCP * Add [Link] section to the .network file which changes MTUBytes * Device brought up using this configuration should not have NOAPR flag in the output of iproute link output * Further add ARP=off to that .network file, the link should have NOARP flag * Further add ARP=on to that .network file, the link should not have NOARP flag A test script is attached, that given an interface can abuse it to validate all of the above. [Regression Potential] * These are upstream fixes for ARP= key that are part of zesty and up [Other Info] * Upstream fixes https://github.com/systemd/systemd/commit/b8b40317d0355bc70bb23a6240a36f3630c4952b.patch https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
** Description changed: [Impact] - * Setting [Link] MTUBytes= in .network file has a side-effect of + * Setting [Link] MTUBytes= in .network file has a side-effect of overflowing and setting NOARP flag. This is not intended behaviour / regression. - * Trying to fix above by setting ARP=on fails to work as tristate is + * Trying to fix above by setting ARP=on fails to work as tristate is incorrectly acted upon by unconditionally adding NOARP flag - * This is a regression in -updates. + * This is a regression in -updates. [Test Case] * Configure an ethernet device with a .network file alone - * e.g. Match by mac address and perform DHCP - * Add [Link] section to the .network file which changes MTUBytes - * Device brought up using this configuration should not have NOAPR flag in the output of iproute link output + * e.g. Match by mac address and perform DHCP + * Add [Link] section to the .network file which changes MTUBytes + * Device brought up using this configuration should not have NOAPR flag in the output of iproute link output + * Further add ARP=off to that .network file, the link should have NOARP flag + * Further add ARP=on to that .network file, the link should not have NOARP flag - * Further add ARP=off to that .network file, the link should have NOARP flag - * Further add ARP=on to that .network file, the link should not have NOARP flag + A test script is attached, that given an interface can abuse it to + validate all of the above. [Regression Potential] * These are upstream fixes for ARP= key that are part of zesty and up [Other Info] * Upstream fixes https://github.com/systemd/systemd/commit/b8b40317d0355bc70bb23a6240a36f3630c4952b.patch https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux ** Attachment added: "regression-arp.sh" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1727301/+attachment/4997738/+files/regression-arp.sh -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Fix Released Status in systemd package in Ubuntu: Invalid Status in systemd source package in Xenial: In Progress Status in systemd source package in Zesty: Invalid Status in systemd source package in Artful: Invalid Status in systemd source package in Bionic: Invalid Bug description: [Impact] * Setting [Link] MTUBytes= in .network file has a side-effect of overflowing and setting NOARP flag. This is not intended behaviour / regression. * Trying to fix above by setting ARP=on fails to work as tristate is incorrectly acted upon by unconditionally adding NOARP flag * This is a regression in -updates. [Test Case] * Configure an ethernet device with a .network file alone * e.g. Match by mac address and perform DHCP * Add [Link] section to the .network file which changes MTUBytes * Device brought up using this configuration should not have NOAPR flag in the output of iproute link output * Further add ARP=off to that .network file, the link should have NOARP flag * Further add ARP=on to that .network file, the link should not have NOARP flag A test script is attached, that given an interface can abuse it to validate all of the above. [Regression Potential] * These are upstream fixes for ARP= key that are part of zesty and up [Other Info] * Upstream fixes https://github.com/systemd/systemd/commit/b8b40317d0355bc70bb23a6240a36f3630c4952b.patch https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
** Description changed: [Impact] - * Incomplete cherrypick of ARP functionality in networkd resulted in an - undesired side-effect, specifically NOARP flag started to be applied - unconditionally, specifically when it should not have, resulting in loss - of network connectivity. + * Setting [Link] MTUBytes= in .network file has a side-effect of + overflowing and setting NOARP flag. This is not intended behaviour / + regression. - * This is a regression in -updates. + * Trying to fix above by setting ARP=on fails to work as tristate is + incorrectly acted upon by unconditionally adding NOARP flag + + * This is a regression in -updates. [Test Case] - * Configure a bond using networkd - * Upgrade - * Make sure NOARP flag is not set on the interfaces / bond + * Configure an ethernet device with a .network file alone + * e.g. Match by mac address and perform DHCP + * Add [Link] section to the .network file which changes MTUBytes + * Device brought up using this configuration should not have NOAPR flag in the output of iproute link output + + + * Further add ARP=off to that .network file, the link should have NOARP flag + * Further add ARP=on to that .network file, the link should not have NOARP flag [Regression Potential] - * This is an upstream fix for this issue. + * These are upstream fixes for ARP= key that are part of zesty and up [Other Info] - - * Upstream fix + + * Upstream fixes + https://github.com/systemd/systemd/commit/b8b40317d0355bc70bb23a6240a36f3630c4952b.patch https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch - - * Original bug report + + * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Fix Released Status in systemd package in Ubuntu: Invalid Status in systemd source package in Xenial: In Progress Status in systemd source package in Zesty: Invalid Status in systemd source package in Artful: Invalid Status in systemd source package in Bionic: Invalid Bug description: [Impact] * Setting [Link] MTUBytes= in .network file has a side-effect of overflowing and setting NOARP flag. This is not intended behaviour / regression. * Trying to fix above by setting ARP=on fails to work as tristate is incorrectly acted upon by unconditionally adding NOARP flag * This is a regression in -updates. [Test Case] * Configure an ethernet device with a .network file alone * e.g. Match by mac address and perform DHCP * Add [Link] section to the .network file which changes MTUBytes * Device brought up using this configuration should not have NOAPR flag in the output of iproute link output * Further add ARP=off to that .network file, the link should have NOARP flag * Further add ARP=on to that .network file, the link should not have NOARP flag [Regression Potential] * These are upstream fixes for ARP= key that are part of zesty and up [Other Info] * Upstream fixes https://github.com/systemd/systemd/commit/b8b40317d0355bc70bb23a6240a36f3630c4952b.patch https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1727301/+subscriptions -- Mailing list: https://laun
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
** Changed in: systemd (Ubuntu Zesty) Status: Confirmed => Invalid ** Changed in: systemd (Ubuntu Bionic) Status: Confirmed => Invalid ** Changed in: systemd (Ubuntu Artful) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Fix Released Status in systemd package in Ubuntu: Invalid Status in systemd source package in Xenial: In Progress Status in systemd source package in Zesty: Invalid Status in systemd source package in Artful: Invalid Status in systemd source package in Bionic: Invalid Bug description: [Impact] * Setting [Link] MTUBytes= in .network file has a side-effect of overflowing and setting NOARP flag. This is not intended behaviour / regression. * Trying to fix above by setting ARP=on fails to work as tristate is incorrectly acted upon by unconditionally adding NOARP flag * This is a regression in -updates. [Test Case] * Configure an ethernet device with a .network file alone * e.g. Match by mac address and perform DHCP * Add [Link] section to the .network file which changes MTUBytes * Device brought up using this configuration should not have NOAPR flag in the output of iproute link output * Further add ARP=off to that .network file, the link should have NOARP flag * Further add ARP=on to that .network file, the link should not have NOARP flag [Regression Potential] * These are upstream fixes for ARP= key that are part of zesty and up [Other Info] * Upstream fixes https://github.com/systemd/systemd/commit/b8b40317d0355bc70bb23a6240a36f3630c4952b.patch https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
The ppa package works for my use case. Maybe add this test-case to QA. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Fix Released Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Xenial: In Progress Status in systemd source package in Zesty: Confirmed Status in systemd source package in Artful: Confirmed Status in systemd source package in Bionic: Confirmed Bug description: [Impact] * Incomplete cherrypick of ARP functionality in networkd resulted in an undesired side-effect, specifically NOARP flag started to be applied unconditionally, specifically when it should not have, resulting in loss of network connectivity. * This is a regression in -updates. [Test Case] * Configure a bond using networkd * Upgrade * Make sure NOARP flag is not set on the interfaces / bond [Regression Potential] * This is an upstream fix for this issue. [Other Info] * Upstream fix https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
** Changed in: systemd (Ubuntu Zesty) Status: Fix Released => Confirmed ** Changed in: systemd (Ubuntu Bionic) Status: Fix Released => Confirmed ** Changed in: systemd (Ubuntu Zesty) Importance: Undecided => Critical ** Changed in: systemd (Ubuntu Artful) Status: Fix Released => Confirmed ** Changed in: systemd (Ubuntu Artful) Importance: Undecided => Critical -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Fix Released Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Xenial: In Progress Status in systemd source package in Zesty: Confirmed Status in systemd source package in Artful: Confirmed Status in systemd source package in Bionic: Confirmed Bug description: [Impact] * Incomplete cherrypick of ARP functionality in networkd resulted in an undesired side-effect, specifically NOARP flag started to be applied unconditionally, specifically when it should not have, resulting in loss of network connectivity. * This is a regression in -updates. [Test Case] * Configure a bond using networkd * Upgrade * Make sure NOARP flag is not set on the interfaces / bond [Regression Potential] * This is an upstream fix for this issue. [Other Info] * Upstream fix https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
aha, i need to specify anything that requires to call the code path to adjust any flags from non default. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: In Progress Status in systemd source package in Zesty: Fix Released Status in systemd source package in Artful: Fix Released Status in systemd source package in Bionic: Fix Released Bug description: [Impact] * Incomplete cherrypick of ARP functionality in networkd resulted in an undesired side-effect, specifically NOARP flag started to be applied unconditionally, specifically when it should not have, resulting in loss of network connectivity. * This is a regression in -updates. [Test Case] * Configure a bond using networkd * Upgrade * Make sure NOARP flag is not set on the interfaces / bond [Regression Potential] * This is an upstream fix for this issue. [Other Info] * Upstream fix https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
I have packages built with above patch applied, which I suspect is the missing portion to fix this. It is available from this ppa https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3015 $ sudo add-apt-repository ppa:ci-train-ppa-service/3015 $ sudo apt-get update I am failing to reproduce the reported regression, with quite similar setup. (See below). Am I missing some sysctls to reproduce the regression? Or are my bonds/vlans/ethernet not suitable to trigger this regression? # ip link 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: enp3s0f0: mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000 link/ether 4a:fd:00:df:13:a3 brd ff:ff:ff:ff:ff:ff 3: enp3s0f1: mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000 link/ether 4a:fd:00:df:13:a3 brd ff:ff:ff:ff:ff:ff 4: bond0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 4a:fd:00:df:13:a3 brd ff:ff:ff:ff:ff:ff 5: bond0.204@bond0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether bc:76:4e:20:69:4c brd ff:ff:ff:ff:ff:ff 6: bond0.104@bond0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether bc:76:4e:20:68:3d brd ff:ff:ff:ff:ff:ff # dpkg -l | grep 229-4ubuntu20 ii libpam-systemd:amd64 229-4ubuntu20 amd64system and service manager - PAM module ii libsystemd0:amd64 229-4ubuntu20 amd64systemd utility library ii libudev1:amd64 229-4ubuntu20 amd64libudev shared library ii systemd229-4ubuntu20 amd64system and service manager ii systemd-sysv 229-4ubuntu20 amd64system and service manager - SysV links ii udev 229-4ubuntu20 amd64/dev/ and hotplug management daemon ==> 10-netplan-bond0.104.netdev <== [NetDev] Name=bond0.104 MACAddress=bc:76:4e:20:68:3d Kind=vlan [VLAN] Id=104 ==> 10-netplan-bond0.104.network <== [Match] Name=bond0.104 [Network] Address=172.99.85.226/30 Address=2001:4802:78fd:33:be76:4eff:fe20:683d/64 [Route] Destination=0.0.0.0/0 Gateway=172.99.85.225 [Route] Destination=::/0 Gateway=2001:4802:78fd:33::1 ==> 10-netplan-bond0.204.netdev <== [NetDev] Name=bond0.204 MACAddress=bc:76:4e:20:69:4c Kind=vlan [VLAN] Id=204 ==> 10-netplan-bond0.204.network <== [Match] Name=bond0.204 [Network] Address=10.184.228.158/30 [Route] Destination=10.176.0.0/12 Gateway=10.184.228.157 [Route] Destination=10.208.0.0/12 Gateway=10.184.228.157 ==> 10-netplan-bond0.netdev <== [NetDev] Name=bond0 Kind=bond [Bond] Mode=802.3ad MIIMonitorSec=100 TransmitHashPolicy=layer3+4 ==> 10-netplan-bond0.network <== [Match] Name=bond0 [Network] VLAN=bond0.204 VLAN=bond0.104 ==> 10-netplan-enp3s0f0.link <== [Match] MACAddress=58:20:b1:00:b8:4c [Link] Name=enp3s0f0 WakeOnLan=off MTUBytes=1500 ==> 10-netplan-enp3s0f0.network <== [Match] MACAddress=58:20:b1:00:b8:4c Name=enp3s0f0 [Network] DNS=69.20.0.196 DNS=69.20.0.164 Bond=bond0 LinkLocalAddressing=no IPv6AcceptRA=no ==> 10-netplan-enp3s0f1.link <== [Match] MACAddress=58:20:b1:00:b8:4d [Link] Name=enp3s0f1 WakeOnLan=off MTUBytes=1500 ==> 10-netplan-enp3s0f1.network <== [Match] MACAddress=58:20:b1:00:b8:4d Name=enp3s0f1 [Network] DNS=69.20.0.196 DNS=69.20.0.164 Bond=bond0 LinkLocalAddressing=no IPv6AcceptRA=no -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: In Progress Status in systemd source package in Zesty: Fix Released Status in systemd source package in Artful: Fix Released Status in systemd source package in Bionic: Fix Released Bug description: [Impact] * Incomplete cherrypick of ARP functionality in networkd resulted in an undesired side-effect, specifically NOARP flag started to be applied unconditionally, specifically when it should not have, resulting in loss of network connectivity. * This is a regression in -updates. [Test Case] * Configure a bond using networkd * Upgrade * Make sure NOARP flag is not set on the interfaces / bond [Regression Potential] * This is an upstream fix for this issue. [Other Info] * Upstream fix https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
** Changed in: systemd Status: Unknown => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: In Progress Status in systemd source package in Zesty: Fix Released Status in systemd source package in Artful: Fix Released Status in systemd source package in Bionic: Fix Released Bug description: [Impact] * Incomplete cherrypick of ARP functionality in networkd resulted in an undesired side-effect, specifically NOARP flag started to be applied unconditionally, specifically when it should not have, resulting in loss of network connectivity. * This is a regression in -updates. [Test Case] * Configure a bond using networkd * Upgrade * Make sure NOARP flag is not set on the interfaces / bond [Regression Potential] * This is an upstream fix for this issue. [Other Info] * Upstream fix https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
** Description changed: + [Impact] + + * Incomplete cherrypick of ARP functionality in networkd resulted in an + undesired side-effect, specifically NOARP flag started to be applied + unconditionally, specifically when it should not have, resulting in loss + of network connectivity. + + * This is a regression in -updates. + + [Test Case] + + * Configure a bond using networkd + * Upgrade + * Make sure NOARP flag is not set on the interfaces / bond + + [Regression Potential] + + * This is an upstream fix for this issue. + + [Other Info] + + * Upstream fix + https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch + + * Original bug report + this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux ** Changed in: systemd (Ubuntu) Importance: Undecided => Critical ** Also affects: systemd (Ubuntu Artful) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Bionic) Importance: Critical Status: Confirmed ** Also affects: systemd (Ubuntu Zesty) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Xenial) Status: New => In Progress ** Changed in: systemd (Ubuntu Xenial) Importance: Undecided => Critical ** Changed in: systemd (Ubuntu Zesty) Status: New => Fix Released ** Changed in: systemd (Ubuntu Artful) Status: New => Fix Released ** Changed in: systemd (Ubuntu Bionic) Status: Confirmed => Fix Released ** Changed in: systemd (Ubuntu Xenial) Assignee: (unassigned) => Dimitri John Ledkov (xnox) ** Changed in: systemd (Ubuntu Xenial) Milestone: None => xenial-updates -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Unknown Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: In Progress Status in systemd source package in Zesty: Fix Released Status in systemd source package in Artful: Fix Released Status in systemd source package in Bionic: Fix Released Bug description: [Impact] * Incomplete cherrypick of ARP functionality in networkd resulted in an undesired side-effect, specifically NOARP flag started to be applied unconditionally, specifically when it should not have, resulting in loss of network connectivity. * This is a regression in -updates. [Test Case] * Configure a bond using networkd * Upgrade * Make sure NOARP flag is not set on the interfaces / bond [Regression Potential] * This is an upstream fix for this issue. [Other Info] * Upstream fix https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch * Original bug report this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
I am suspecting the following cherrypick is missing in xenial: https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch will prepare a PPA with this fix applied, and will expedite an sru with this fix in. ** Bug watch added: github.com/systemd/systemd/issues #3890 https://github.com/systemd/systemd/issues/3890 ** Also affects: systemd via https://github.com/systemd/systemd/issues/3890 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd: Unknown Status in systemd package in Ubuntu: Confirmed Bug description: this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
I could solve this issue by rebuilding the debian packages without two patches: - networkd-add-support-to-configure-NOARP-ARP-for-interface.patch - networkd-bond-support-primary-slave-and-active-slave-4873.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd package in Ubuntu: Confirmed Bug description: this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
We have the same problem without bond configured. After upgrading to systemd 229-4ubuntu20 NOARP is set to our network interfaces. The machine has two network interfaces and the configuration is very simple: # 50-ens5f0.network [Match] MACAddress=24:8a:7:11:50:a8 [Link] MTUBytes=9000 [Network] Address=10.32.34.34/30 DHCP=no LinkLocalAddressing=no IPv6AcceptRA=no # 50-ens5f1.network [Match] MACAddress=24:8a:7:11:50:a9 [Link] MTUBytes=9000 [Network] Address=10.32.33.126/30 DHCP=no LinkLocalAddressing=no IPv6AcceptRA=no # ip link 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ens5f0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 24:8a:07:11:50:a8 brd ff:ff:ff:ff:ff:ff 3: ens5f1: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 24:8a:07:11:50:a9 brd ff:ff:ff:ff:ff:ff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd package in Ubuntu: Confirmed Bug description: this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
We are also affected by this suddenly after systemd upgrade the network was gone, had to go in via serial console. We are only using networkd because Martin Pitt said in the run-up to the 16.04 release that networkd would be supported and to be used in the next LTS release. # networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether carrier configured 3 eth1 ether carrier configured 4 eth2 ether carrier configured 5 eth3 ether carrier configured 6 eth4 ether no-carrier configured 7 eth5 ether no-carrier configured 8 bond0ether off unmanaged 9 bond1ether routableconfigured 9 links listed. # head /etc/systemd/network/* -n 20 ==> /etc/systemd/network/bond1.netdev <== [NetDev] Name=bond1 Kind=bond [Bond] Mode=802.3ad MIIMonitorSec=100 TransmitHashPolicy=layer3+4 LACPTransmitRate=1 ==> /etc/systemd/network/bond1.network <== [Match] Name=bond1 [Link] MTUBytes=9000 [Network] LinkLocalAddressing=no [Network] Address=10.230.0.4/22 Gateway=10.230.0.1 ==> /etc/systemd/network/eth.network <== [Match] Name=eth* [Network] Bond=bond1 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd package in Ubuntu: Confirmed Bug description: this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
the networking is configured via systemd-networkd. bonding module is loaded with 'max_bonds=0' to address upcoming systemd change https://github.com/systemd/systemd/issues/6184 pre-upgrade: # networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether carrier configuring 3 eth1 ether carrier configuring 4 bond0ether routableconfigured 5 bond0.200ether routableconfigured # ip link 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 9000 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000 link/ether 5a:42:ff:c5:26:61 brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 9000 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000 link/ether 5a:42:ff:c5:26:61 brd ff:ff:ff:ff:ff:ff 4: bond0: mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 5a:42:ff:c5:26:61 brd ff:ff:ff:ff:ff:ff 5: bond0.200@bond0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 5a:42:ff:c5:26:61 brd ff:ff:ff:ff:ff:ff interfaces(.d) and netplan are empty and unused/disabled /etc/systemd/network: # cat eth1.network [Match] Name=eth1 [Network] Bond=bond0 # cat eth0.network [Match] Name=eth0 [Network] Bond=bond0 # cat bond0.netdev [NetDev] Name=bond0 Kind=bond [Bond] Mode=802.3ad MIIMonitorSec=0.1s LACPTransmitRate=fast UpDelaySec=0.2s DownDelaySec=0.2s # cat bond0.network [Match] Name=bond0 [Address] Address=192.168.1.100/24 [Route] Gateway=192.168.1.1 [Network] VLAN=bond0.200 [Link] MTUBytes=9000 # cat bond0.200.netdev [NetDev] Name=bond0.200 Kind=vlan [VLAN] Id=200 # cat bond0.200.network [Match] Name=bond0.200 [Address] Address=10.10.0.100/16 [Route] Gateway=10.10.0.1 [Link] MTUBytes=9000 After upgrade: # networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether carrier configuring 3 eth1 ether carrier configuring 4 bond0ether routableconfigured 5 bond0.200ether routableconfigured However, the link of eth0, eth1 and the bond and vlan interface changes to NOARP # ip link 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 9000 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000 link/ether 5a:42:ff:c5:26:61 brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 9000 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000 link/ether 5a:42:ff:c5:26:61 brd ff:ff:ff:ff:ff:ff 4: bond0: mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 5a:42:ff:c5:26:61 brd ff:ff:ff:ff:ff:ff 5: bond0.200@bond0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 5a:42:ff:c5:26:61 brd ff:ff:ff:ff:ff:ff ** Bug watch added: github.com/systemd/systemd/issues #6184 https://github.com/systemd/systemd/issues/6184 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd package in Ubuntu: Confirmed Bug description: this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: systemd (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd package in Ubuntu: Confirmed Bug description: this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces
How are eth0/eth1/bond0 configured? Do you use netplan and networkd? Do you use ifupdown? Can you paste the output of $ networkctl? Copies of the configuration e.g.: /etc/network/interfaces /etc/network/interfaces.d/* /etc/netplan/* /run/systemd/network/* /etc/systemd/network/* -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1727301 Title: 229-4ubuntu20 added ARP option breaks existing bonding interfaces Status in systemd package in Ubuntu: New Bug description: this breaks existing configurations with bonding on upgrading from 229-4ubuntu19 to 229-4ubuntu20 on xenial as bond interfaces are now by default configured without ARP. Hence you suddenly lose network connectivity on upgrade. Very bad for a SRU. Plus adding "ARP=yes" to the Link section of a .network file does not work. Before this update, bond interfaces (specifically 802.3ad) were defaulting to ARP enabled. After the upgrade, they are created with NOARP set on the link. pre-upgrade: eth0: eth1: bond0: post-upgrade: eth0: eth1: bond0: Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1727301/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp