All autopkgtests for the newly accepted systemd (242-7ubuntu3.2) for eoan have finished running. The following regressions have been reported in tests triggered by the package:
gvfs/1.42.1-1ubuntu1 (amd64) systemd/242-7ubuntu3.2 (ppc64el) ndctl/unknown (armhf) casper/1.427 (amd64) netplan.io/0.98-0ubuntu1 (ppc64el) munin/unknown (armhf) linux-oem-osp1/5.0.0-1026.29 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/eoan/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- 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/1831787 Title: Bogus routes after DHCP lease change Status in netplan: Invalid Status in systemd: Unknown Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Disco: In Progress Status in systemd source package in Eoan: Fix Committed Bug description: [impact] networkd does not remove old route(s) after DHCP address change [test case] on a system using networkd, that is connected to a network where you can control the addresses that the DHCP server provides, setup system with networkd to get address via DHCP, e.g. [Match] Name=ens3 [Network] DHCP=ipv4 (re)start networkd or reboot, so the system gets an ipv4 DHCP address, and corresponding route to the gateway. Then on the dhcp server, change the subnet to a different subnet. On the client, once its renews its DHCP address, the server will provide a new address in the new subnet, and the client will add a new default route to the new gateway address. However, the old default route to the old gateway address isn't removed. Note this also happens without changing the entire subnet, but is more subtle as shown in the original description. [regression potential] this affects how networkd handles routes, so has the potential to leave a system with partial or incorrect networking, or no networking at all. Any regression would most likely occur during networkd (re)start or during renewal of a DHCP lease, or when an interface is brought up. [other info] original description: --- Netplan config: network: version: 2 renderer: networkd ethernets: eno4: dhcp4: no eno1np0: dhcp4: no addresses: - 172.16.0.2/24 bridges: br0: dhcp4: yes interfaces: - eno4 On initial boot, machine got 10.0.15.109 IP address: May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: Configured May 03 13:09:41 ceph2 systemd-networkd[29349]: br0: DHCPv4 address 10.0.15.109/23 via 10.0.15.253 At one point, DHCP server reserver this IP address and client eventually picked up new IP address: May 03 15:01:12 ceph2 systemd-networkd[1137]: br0: DHCPv4 address 10.0.15.128/23 via 10.0.15.253 This resulted in IP addresses: # ip -o a 1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever 1: lo inet6 ::1/128 scope host \ valid_lft forever preferred_lft forever 2: eno1np0 inet 172.16.0.2/24 brd 172.16.0.255 scope global eno1np0\ valid_lft forever preferred_lft forever 2: eno1np0 inet6 fe80::b226:28ff:fe53:56be/64 scope link \ valid_lft forever preferred_lft forever 6: br0 inet 10.0.15.128/23 brd 10.0.15.255 scope global dynamic br0\ valid_lft 503sec preferred_lft 503sec 6: br0 inet6 fe80::b8d7:5eff:fe6b:62a/64 scope link \ valid_lft forever preferred_lft forever So far, everything is fine. But, the routes on the machine are bogus: # ip r default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.109 metric 100 default via 10.0.15.253 dev br0 proto dhcp src 10.0.15.128 metric 100 10.0.14.0/23 dev br0 proto kernel scope link src 10.0.15.128 10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.109 metric 100 10.0.15.253 dev br0 proto dhcp scope link src 10.0.15.128 metric 100 172.16.0.0/24 dev eno1np0 proto kernel scope link src 172.16.0.2 routes with src 10.0.15.109 should have been removed when lease was renewed. I'm not sure if this is a bug in netplan or systemd. This is 18.04, systemd 37-3ubuntu10.21, netplan 0.40.1~18.04.4. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1831787/+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
