Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70-persistent-network.rules

[pirlo]

[Impact]

 * Many server users upgraded from previous Ubuntu LTS series, such as 14.04 and 16.04, will be affected by this regression.

 * Because there is /etc/udev/rules/70-persistent-network.rules or /etc/udev/rules.d/70-persistent-net.rules generated by /lib/udev/write_net_rules left.

 * The previous SRU commit of LP: #1837700 doesn't cover this persistent network rule.

[Test Case]

 * It needs to have two Ethernet devices and provides /etc/udev/rules.d/70-persistent-net.rules as below.

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56", NAME="eth1"

[Regression Potential]

 * When users upgrade to next LTS 20.04, they may also encounter this issue because Debian has dropped the same patch.

 * We need to figure another way to avoid this regression for next LTS 20.04.

 * Adding back the origial patch from Debian will casue another issue. (LP: #1837700)

[Other Info]

Since the latest update from udev_237-3ubuntu10.25 and systemd_237-3ubuntu10.25 to udev_237-3ubuntu10.26 and systemd_237-3ubuntu10.26 the renaming of network interfaces by /etc/udev/rules/70-persistent-network.rules does not work.

/etc/udev/rules/70-persistent-network.rules:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:55", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:30:18:cb:5b:56", NAME="eth1"

/var/log/syslog:
systemd-udevd[423]: Error changing net interface name 'eth1' to 'eth0': File exists

When I downgrade the packages to the version with 237-3ubuntu10.25 the following messages are in /var/log/syslog:
Sep 4 13:10:09 brutus kernel: [ 4.518507] igb 0000:04:00.0 rename2: renamed from eth0
Sep 4 13:10:09 brutus kernel: [ 4.565081] igb 0000:07:00.0 eth0: renamed from eth1

The latest version does not rename the interfaces temporary if there is a conflict!

Manually installing the old packages with
dpkg -i libacl1_2.2.52-3_amd64.deb libsystemd0_237-3ubuntu10.25_amd64.deb libudev1_237-3ubuntu10.25_amd64.deb systemd_237-3ubuntu10.25_amd64.deb systemd-sysv_237-3ubuntu10.25_amd64.deb udev_237-3ubuntu10.25_amd64.deb
did fix the problem temporary.

[Dimitri John Ledkov (xnox)]

Neither .25 nor .26 are the most current systemd versions in bionic.

Can you please double check your version numbers?

Could you please try 237-3ubuntu10.28 and check if problem persists?

[Hans-Peter Schmidt (hps-ruetz)]

I had the same problem with 237-3ubuntu10.28 AND 237-3ubuntu10.26.

237-3ubuntu10.25 was the solution.

[pirlo (admin-pirlo)]

Same Problem with version .28!

[You-Sheng Yang (vicamo)]

That patch has also been obsoleted in Debian recently, and upstream systemd has no longer support 70-persistent-net.rules thing. Any reason you cannot move to new naming scheme?

[pirlo (admin-pirlo)]

A lot of dependencies and the new naming scheme is too unreliable because multiple servers are being served. with 70-persistent-net.rules we can trust the interfaces get the correct device name we need (until now).
If something like that is broken during a release change (18.04 to 19.04) it's ok (but not good) but during a simple package update basic functions should never get removed or broken!

[Robie Basak (racb)]

> Any reason you cannot move to new naming scheme?

Please remember that this report may represent a large number of affected users, most of whom are absent from this discussion. We want to avoid regressing stable release Ubuntu users as much as possible, and this generally means that we cannot break them during the lifetime of a supported Ubuntu release.

I think the first question that needs to be answered would be: any reason you cannot fix the original bug without breaking existing users?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Rex Tsai (chihchun)]

The user will have a 70-persistent-net.rules generated by /lib/udev/write_net_rules, when they upgraded from 14.04/12.04 to newer version. The server user may have the iptables rules or netowrk ip setting based on the persistent interface name. This is critical.

The regression is introduced in 237-3ubuntu10.26.

If we don't have a quick solution to support both 70-persistent-net.rules and same mac address.

We should quickly revert the changes back to the original version.

[1] 237-3ubuntu10.26 : systemd package : Ubuntu - https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.26
[2] Bug #1837700 “Dell system takes a long time to connect network w...” : Bugs : systemd package : Ubuntu - https://bugs.launchpad.net/bugs/1837700

[Chris Coulson (chrisccoulson)]

If this change is being reverted, it needs to be done via the security pocket rather than proposed, as Tuesday's security update was based on the version with this regression.

[Robert Ancell (robert-ancell)]

@chrisccoulson - I sponsored the changes as per normal, so they're in the queue for -proposed in bionic and disco. Can I upload to the security pocket? Does that just require debian/changelog to be changed?

[Chris Coulson (chrisccoulson)]

Rather than going through -proposed, it needs to go via one of our security PPAs (which are built without -updates) and then copied across, which is something I can do.

[Jamie Strandboge (jdstrand)]

FYI, this broke me as well. I have an 18.04 multi-nic system that went through several upgrades and was relying on /etc/udev/rules.d/70-persistent-net.rules to give me predictable eth* names where each eth* name was used as part of a bridge. The recent change regressed this since non-existent eth* entries were specified for the bridge which caused the bridges to never come up.

[Chris Coulson (chrisccoulson)]

I've uploaded the changes that were sponsored to proposed to https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa. Please reject the packages that are currently in the unapproved queue.

[Jamie Strandboge (jdstrand)]

> Please reject the packages that are currently in the unapproved queue.

Done

[Rex Tsai (chihchun)]

Is there anything we can do to speed up the process? What would be the next step to land the reverted version for the regression?

[Jamie Strandboge (jdstrand)]

@Rex and @Shih-Yuan, I believe Chris is planning to push this through -security in his morning.

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 237-3ubuntu10.29

---------------
systemd (237-3ubuntu10.29) bionic; urgency=medium

  * d/p/d/Revert-udev-network-device-renaming-immediately-give.patch:
    - udev: add Revert-udev-network-device-renaming-immediately-give.patch back
      Dropping this patch will cause the persistent network regression.
      (LP: #1842651)

 -- Shih-Yuan Lee (FourDollars) <email address hidden> Thu, 05 Sep 2019 11:59:51 +0800

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 240-6ubuntu5.7

---------------
systemd (240-6ubuntu5.7) disco; urgency=medium

  * d/p/d/Revert-udev-network-device-renaming-immediately-give.patch:
    - udev: add Revert-udev-network-device-renaming-immediately-give.patch back
      Dropping this patch will cause the persistent network regression.
      (LP: #1842651)

 -- Shih-Yuan Lee (FourDollars) <email address hidden> Thu, 05 Sep 2019 19:01:29 +0800

[pirlo (admin-pirlo)]

237-3ubuntu10.29 - works for me (Ubuntu 18.04.3 LTS, 4.15.0-51-generic)

Thank you!

[MichaelB (mrbou)]

Ok working, my problem was not directly related to this bug. Sorry, please forget my comment #20 and #21!