UC20 images do not use predictable interface names on RPi4

[Jonathan Cave]

Image tested: http://cdimage.ubuntu.com/ubuntu-core/20/dangerous-beta/pending/ubuntu-core-20-arm64+raspi.img.xz

Boot the image and check the naming of the ethernet interfaces. On most devices (amd64, rpi3 etc) systemd predicatable interface naming is applied e.g. enxb827eb7d1eee. However on specifically RPi4 devices traditional naming is used e.g. eth0, eth1.

[Zygmunt Krynicki (zyga)]

This is probably something to target the appropriate gadget snap that has control over the kernel command line.

[Jonathan Cave (jocave)]

kernel cmdline on the device I have:

$ cat /proc/cmdline
 coherent_pool=1M 8250.nr_uarts=1 video=HDMI-A-1:1920x1080M@60,margin_left=48,margin_right=48,margin_top=48,margin_bottom=48 smsc95xx.macaddr=DC:A6:32:04:22:DA vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 dwc_otg.lpm_enable=0 console=ttyS0,115200 elevator=deadline rng_core.default_quality=700 vt.handoff=2 quiet splash quiet splash snapd_recovery_mode=run snapd_recovery_system=20200529 panic=-1 systemd.gpt_auto=0 rd.systemd.unit=basic.target

Note that net.ifnames=0 does not seem to be being passed to disable predictable names

[Dimitri John Ledkov (xnox)]

UC20 only uses predictable names. It is intentional to use stable names. There is nothing in the gadget about it. But rather kernel drivers, dtb, udev.

eth0 name is a bug. And it means udev failed to establish a predictable name for it.

I think we either need to add an additional policy file for it, to at least use mac based name and/or work with kernel & upstream to positively identify it.

[Juerg Haefliger (juergh)]

The default for both core20 and server is 'net.ifnames=0' which disables persistent network interface names so it's expected to see eth0 and wlan0.

cat /proc/cmdline
 coherent_pool=1M 8250.nr_uarts=1 bcm2708_fb.fbwidth=1280 bcm2708_fb.fbheight=1024 bcm2708_fb.fbswap=1 smsc95xx.macaddr=DC:A6:32:08:85:96 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 net.ifnames=0 dwc_otg.lpm_enable=0 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait fixrtc console=tty1 console=ttyS0,115200 quiet splash

However, if I drop 'net.ifnames=0' from cmdline.txt I *do* get a persistent name on a 3B+ but *not* on a 4B.

On a Pi 3B:

$ udevadm info /sys/class/net/enxb827eb3eabfb
P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/net/enxb827eb3eabfb
L: 0
E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.1/1-1.1.1:1.0/net/enxb827eb3eabfb
E: INTERFACE=enxb827eb3eabfb
E: IFINDEX=2
E: SUBSYSTEM=net
E: USEC_INITIALIZED=5428547
E: ID_MM_CANDIDATE=1
E: ID_NET_NAMING_SCHEME=v245
E: ID_NET_NAME_MAC=enxb827eb3eabfb
E: ID_OUI_FROM_DATABASE=Raspberry Pi Foundation
E: ID_VENDOR=0424
E: ID_VENDOR_ENC=0424
E: ID_VENDOR_ID=0424
E: ID_MODEL=7800
E: ID_MODEL_ENC=7800
E: ID_MODEL_ID=7800
E: ID_REVISION=0300
E: ID_SERIAL=0424_7800
E: ID_TYPE=generic
E: ID_BUS=usb
E: ID_USB_INTERFACES=:ff00ff:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=lan78xx
E: ID_USB_CLASS_FROM_DATABASE=Vendor Specific Class
E: ID_VENDOR_FROM_DATABASE=Microchip Technology, Inc. (formerly SMSC)
E: ID_PATH=platform-3f980000.usb-usb-0:1.1.1:1.0
E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_1_1_1_0
E: ID_NET_DRIVER=lan78xx
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/73-usb-net-by-mac.link
E: ID_NET_NAME=enxb827eb3eabfb
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/enxb827eb3eabfb
E: TAGS=:systemd:

$ udevadm test-builtin net_id /sys/class/net/enxb827eb3eabfb
Load module index
Parsed configuration file /usr/lib/systemd/network/99-default.link
Parsed configuration file /usr/lib/systemd/network/73-usb-net-by-mac.link
Created link configuration context.
Using default interface naming scheme 'v245'.
ID_NET_NAMING_SCHEME=v245
ID_NET_NAME_MAC=enxb827eb3eabfb
ID_OUI_FROM_DATABASE=Raspberry Pi Foundation
Unload module index
Unloaded link configuration context.

/usr/lib/systemd/network/73-usb-net-by-mac.link is the systemd policy file that handles the renaming of eth0.

On a Pi 4B:

$ udevadm info /sys/class/net/eth0
P: /devices/platform/scb/fd580000.ethernet/net/eth0
L: 0
E: DEVPATH=/devices/platform/scb/fd580000.ethernet/net/eth0
E: INTERFACE=eth0
E: IFINDEX=2
E: SUBSYSTEM=net
E: USEC_INITIALIZED=2348632
E: ID_MM_CANDIDATE=1
E: ID_NET_NAMING_SCHEME=v245
E: ID_NET_NAME_MAC=enxdca632088596
E: ID_OUI_FROM_DATABASE=Raspberry Pi Trading Ltd
E: ID_PATH=platform-fd580000.ethernet
E: ID_PATH_TAG=platform-fd580000_ethernet
E: ID_NET_DRIVER=bcmgenet
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
E: TAGS=:systemd:

$ udevadm test-builtin net_id /sys/class/net/eth0
Load module index
Parsed configuration file /usr/lib/systemd/network/99-default.link
Parsed configuration file /usr/lib/systemd/network/73-usb-net-by-mac.l...

[durex (durexlw)]

Wow, am I glad I found this thread... I've been spending literally days trying to find out why I didn't get the predictable names. Never thought it would be a bug.

I have to say: whoever works on the predictable naming scheme is doing a very noble job... not having these predictable names is just a nightmare.

Can I do something to help? I'd like to see you guys succeed in this one.

[durex (durexlw)]

As a sidenote: once the 'net.ifnames=0' is removed, indeed the eth0 and wlan0 still get their old 'eth0' and 'wlan0' names, but aside the aesthetics: the whole purpose of the predictable naming suddenly does function: all USB cards get a predictable name, based on MAC Address... so I'm guessing that's why the status of this bug is 'invalid'. Thanks to whomever worked on this. Works beautifully and makes life a whole lot easier!

[Dan Streetman (ddstreet)]

please reopen if this is still an issue