Thanks a lot for your work, Dan! Unfortunately, I wasn't able to pick up the new bug from here, sorry for that. (It appears I did not get any notification on your comments, need to check that)
The bridges are managed by OpenStack Neutron from Ubuntu cloud archives and with names derived from the network UUID in the cluster database. It might work for a very limited set of bridges, if they do not set different options. AFAIK, OpenStack Neutron is still working on supporting using external bridges (https://bugs.launchpad.net/neutron/+bug/1105488). As we have bridges on VLANs on bonded interfaces (currently managed with systemd-networkd), I will see if I have to replace that all or if there is an option to just have systemd-networkd not set nomaster... Thanks! -- 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/1929560 Title: link mac isn't set if already up Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Focal: Fix Released Status in systemd source package in Groovy: Fix Released Bug description: [impact] if link is already up, configured mac isn't set this also affects the master/nomaster configuration [test case] create .network config for the link, for example: [Match] Name=eth0 [Link] MACAddress=00:16:3e:ff:ff:ff [Network] DHCP=yes make sure the link is already up, and restart systemd-networkd: root@test-f:/etc/systemd/network# ip l show eth0 61: eth0@if62: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000 link/ether 00:16:3e:fc:b2:00 brd ff:ff:ff:ff:ff:ff link-netnsid 0 root@test-f:/etc/systemd/network# ip l set dev eth0 up root@test-f:/etc/systemd/network# ip l show eth0 61: eth0@if62: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 00:16:3e:fc:b2:00 brd ff:ff:ff:ff:ff:ff link-netnsid 0 root@test-f:/etc/systemd/network# systemctl restart systemd-networkd root@test-f:/etc/systemd/network# ip l show eth0 61: eth0@if62: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 00:16:3e:fc:b2:00 brd ff:ff:ff:ff:ff:ff link-netnsid 0 root@test-f:/etc/systemd/network# ip l set dev eth0 down root@test-f:/etc/systemd/network# ip l show eth0 61: eth0@if62: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000 link/ether 00:16:3e:fc:b2:00 brd ff:ff:ff:ff:ff:ff link-netnsid 0 root@test-f:/etc/systemd/network# systemctl restart systemd-networkd root@test-f:/etc/systemd/network# ip l show eth0 61: eth0@if62: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 00:16:3e:ff:ff:ff brd ff:ff:ff:ff:ff:ff link-netnsid 0 [regression potential] any regression would likely result in incorrectly set link mac and/or master, or failure to correctly set mac and/or master [scope] this is needed for g and earlier this is fixed upstream by commit e16e4b3bedc57919b3ecb4096e941709a5d39b8a which is included in v247 so this is fixed already in h and later [other info] this moves the configuration of the link mac and master out of the link_up() function, so this also allows repeated calls to link_up() without reconfiguring the link mac and master. That behavior is useful for the commits for bug 1664844 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1929560/+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
