Note that the *proper* way to place eth0 into a bridge while also being under systemd-networkd management is to create a .netdev for the bridge and assign eth0 to it, e.g.:
$ cat 10-br0.netdev [NetDev] Name=br0 Kind=bridge cat 10-netplan-eth0.network [Match] Name=eth0 [Network] DHCP=ipv4 LinkLocalAddressing=ipv6 Bridge=br0 [DHCP] RouteMetric=100 UseMTU=true Or alternately, just remove the .network file for 'eth0' so it's not under systemd-networkd control, and manually and/or externally control it (i.e. manually bring up eth0 and manually place it into br0). ** Description changed: [impact] bug 1929560 fixed an error in setting/clearing an interface 'master' during systemd-networkd startup if the interface was already up, however for any users who have been relying on that bug to manually set an interface 'master' for an interface that's otherwise controlled by systemd-networkd, this will break their system by removing the interface from the 'master' on a systemd-networkd restart. For example, if a user has interface 'eth0' configured to be controlled by systemd-networkd, but then manually does 'ip l set dev eth0 master br0' to add it to the 'br0' bridge, previous behavior would leave 'eth0' in the bridge after a systemd-networkd restart, even though it should not be in the bridge based on the systemd-networkd configuration. The new behavior matches systemd-networkd behavior for all other aspects (i.e. networkd removes all addresses, routes, and other settings it doesn't know about or that are different from its configuration), however it breaks users expecting the previous incorrect behavior. [test case] configure systemd-networkd to control an interface that isn't set with any 'master', and start networkd. For example, an instance configured for DHCP. After networkd has started, manually set the interface 'master' to an existing bridge. Restart networkd, and check if the interface still has the bridge 'master' or not. + e.g., in a newly created cloud-image container, with normal netplan, + check the networkd control of eth0: + + root@lp1937117-f:~# networkctl list eth0 + IDX LINK TYPE OPERATIONAL SETUP + 159 eth0 ether routable configured + + create a new bridge and manually place eth0 into it: + + root@lp1937117-f:~# ip l add dev br0 type bridge + root@lp1937117-f:~# ip l set up dev br0 + root@lp1937117-f:~# ip l set dev eth0 master br0 + root@lp1937117-f:~# ip l show dev eth0 + 159: eth0@if160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP mode DEFAULT group default qlen 1000 + link/ether 00:16:3e:56:f8:07 brd ff:ff:ff:ff:ff:ff link-netnsid 0 + + now restart systemd-networkd, and check if eth0 remains under br0: + + root@lp1937117-f:~# systemctl restart systemd-networkd + root@lp1937117-f:~# ip l show dev eth0 + 159: eth0@if160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 + link/ether 00:16:3e:56:f8:07 brd ff:ff:ff:ff:ff:ff link-netnsid 0 + + [regression potential] the main potential is for problems for those with misconfigured systems, relying on specific previous incorrect behavior, specifically interfaces controlled by systemd-networkd in part, but also with manual configuration performed outside of systemd-networkd configuration. [scope] this is needed for bionic and focal to restore the previous incorrect behavior; the correct behavior should remain in impish, and (arguably) should remain in hirsute as well [other info] see bug 1929560 for details of the original bug -- 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/1937117 Title: misconfigured networkd may break after networkd restart Status in systemd package in Ubuntu: Invalid Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Bug description: [impact] bug 1929560 fixed an error in setting/clearing an interface 'master' during systemd-networkd startup if the interface was already up, however for any users who have been relying on that bug to manually set an interface 'master' for an interface that's otherwise controlled by systemd-networkd, this will break their system by removing the interface from the 'master' on a systemd-networkd restart. For example, if a user has interface 'eth0' configured to be controlled by systemd-networkd, but then manually does 'ip l set dev eth0 master br0' to add it to the 'br0' bridge, previous behavior would leave 'eth0' in the bridge after a systemd-networkd restart, even though it should not be in the bridge based on the systemd- networkd configuration. The new behavior matches systemd-networkd behavior for all other aspects (i.e. networkd removes all addresses, routes, and other settings it doesn't know about or that are different from its configuration), however it breaks users expecting the previous incorrect behavior. [test case] configure systemd-networkd to control an interface that isn't set with any 'master', and start networkd. For example, an instance configured for DHCP. After networkd has started, manually set the interface 'master' to an existing bridge. Restart networkd, and check if the interface still has the bridge 'master' or not. e.g., in a newly created cloud-image container, with normal netplan, check the networkd control of eth0: root@lp1937117-f:~# networkctl list eth0 IDX LINK TYPE OPERATIONAL SETUP 159 eth0 ether routable configured create a new bridge and manually place eth0 into it: root@lp1937117-f:~# ip l add dev br0 type bridge root@lp1937117-f:~# ip l set up dev br0 root@lp1937117-f:~# ip l set dev eth0 master br0 root@lp1937117-f:~# ip l show dev eth0 159: eth0@if160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP mode DEFAULT group default qlen 1000 link/ether 00:16:3e:56:f8:07 brd ff:ff:ff:ff:ff:ff link-netnsid 0 now restart systemd-networkd, and check if eth0 remains under br0: root@lp1937117-f:~# systemctl restart systemd-networkd root@lp1937117-f:~# ip l show dev eth0 159: eth0@if160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 00:16:3e:56:f8:07 brd ff:ff:ff:ff:ff:ff link-netnsid 0 [regression potential] the main potential is for problems for those with misconfigured systems, relying on specific previous incorrect behavior, specifically interfaces controlled by systemd-networkd in part, but also with manual configuration performed outside of systemd-networkd configuration. [scope] this is needed for bionic and focal to restore the previous incorrect behavior; the correct behavior should remain in impish, and (arguably) should remain in hirsute as well [other info] see bug 1929560 for details of the original bug To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1937117/+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
