This bug was fixed in the package systemd - 237-3ubuntu10.50
---------------
systemd (237-3ubuntu10.50) bionic-security; urgency=medium
*
d/p/lp1937117-revert-lp1929560-network-move-set-MAC-and-set-nomaster-operations-out.patch:
Revert patch due to users expecting previous buggy behavior
(LP: #1937117)
-- Dan Streetman <ddstr...@canonical.com> Wed, 21 Jul 2021 14:51:38
-0400
--
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:
Fix Released
Status in systemd source package in Focal:
Fix Released
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
