Bug#919390: udev: network interface gets ID_NET_NAME even when NAME has been set by /etc/udev/rules.d/70-persistent-net.rules

[Michal Hocko]

Package: udev
Version: 240-2
Severity: normal

Hi,
when updating from an older udev version I have noticed that my ethernet
interface got renamed to autogenerated (ID_NET_NAME) name even though I
have /etc/udev/rules.d/70-persistent-net.rules to rename it based on
the mac address as follows:

# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="28:f1:0e:31:04:16", KERNEL=="eth*", NAME="lan0"

The kernel log says that this gets applied:
[    3.563937] e1000e 0000:00:1f.6 lan0: renamed from eth0
[...]
[    4.043437] e1000e 0000:00:1f.6 enp0s31f6: renamed from lan0

Downgrading to 232-25+deb9u7 or adding net.ifnames=0 to kernel cmd line
makes the problem go away.

Let me know if you need an additional information.

Thanks!

-- Package-specific info:

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.0.0-rc1-00001-g3bd6e94bec12 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages udev depends on:
ii  adduser      3.118
ii  libacl1      2.2.52-3+b1
ii  libblkid1    2.33.1-0.1
ii  libc6        2.28-2
ii  libkmod2     25-2
ii  libselinux1  2.8-1+b1
ii  libudev1     240-2
ii  lsb-base     10.2018112800
ii  util-linux   2.33.1-0.1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
pn  systemd  <none>

-- debconf information:
  udev/title/upgrade:
  udev/sysfs_deprecated_incompatibility:
  udev/reboot_needed:
  udev/new_kernel_needed: false

-- 
Michal Hocko