uc22 rpi3 ethernet getting renamed on every boot

[Paul Larson]

On rpi3 with uc22 (just confirmed on the latest image from 20220406.1), the built-in ethernet interface should use generic names (i.e. eth0). On rpi4 this works as it should, and it uses eth0.

On the rpi3b+ I'm testing on, I saw it get enxea1a4588e236 on the first boot. On the second boot though, it got renamed to enx3a583dc734b6

The result of this, is that on rpi3 with uc22, if you only configure ethernet, then it will no longer work after you reboot. Since console-conf only runs on first boot, it will be stuck thinking it was unable to get an address. The netplan config file that is generated by console-conf references the device name, so it will still be looking for that original name:
network:
  ethernets:
    enxea1a4588e236:
      dhcp4: true
  version: 2
...

Fortunately, the wifi interface gets named wlan0 and does not get renamed every boot. So I was able to configure that interface and still get in to gather some information about this.
However, unless you use wifi, rpi3 devices will be useless after the first boot

[Paul Larson (pwlars)]

dmesg: https://paste.ubuntu.com/p/5MxvDqdBmx/

$ sudo journalctl -u systemd-networkd
Mar 25 14:32:40 ubuntu systemd[1]: Starting Network Configuration...
Mar 25 14:32:47 ubuntu systemd-networkd[448]: lo: Link UP
Mar 25 14:32:47 ubuntu systemd-networkd[448]: lo: Gained carrier
Mar 25 14:32:47 ubuntu systemd-networkd[448]: Enumeration completed
Mar 25 14:32:47 ubuntu systemd[1]: Started Network Configuration.
Mar 25 14:32:51 ubuntu systemd-networkd[448]: wlan0: Link UP
Mar 25 14:32:52 ubuntu systemd-networkd[448]: eth0: Interface name change detec>
Mar 25 14:33:17 ubuntu systemd-networkd[448]: wlan0: Connected WiFi access poin>
Mar 25 14:33:17 ubuntu systemd-networkd[448]: wlan0: Gained carrier
Mar 25 14:33:18 ubuntu systemd-networkd[448]: wlan0: DHCPv4 address 192.168.2.1>
Mar 25 14:33:18 ubuntu systemd-networkd[448]: wlan0: Gained IPv6LL

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

I have been testing this, and the interesting thing is that it does not happen for all RPi3. I have two, and things are fine for an RPi3 model b v1.2 (2015), but fail as described in an RPi3 model b+ (2017).

For the latter, the MAC changes on every boot, and that's why you get a different interface name every time. According to a comment from Dave, on UC a MAC used to be stored in the uboot environment and it was set by u-boot on start, but we do not have u-boot anymore in UC22.

This seems to be related (it mentions wifi but also somebody sees that for ethernet): https://forums.raspberrypi.com/viewtopic.php?t=237623 . It also mentions NetworkManager, but we don't include it in the image.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

A difference I see between my two RPi3 is that workin one has ID_NET_DRIVER=smsc95xx, while the non-working one has ID_NET_DRIVER=lan78xx. In the latter, I can see that there is actually a valid ethernet address available in the device tree:

$ od -t x1 /sys/firmware/devicetree/base/soc/usb@7e980000/usb1@1/usbether@1/local-mac-address
0000000 b8 27 eb 90 3c c0
0000006

and it can be checked that such address belong to the RPi foundation.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

After debugging the driver, it looked like it was not able to find the device tree node with the MAC address, and was therefore assigning a random MAC address. Further debugging showed that the device was actually being detected as an RPi3b instead of an RPi3b+:

$ cat /proc/device-tree/compatible
raspberrypi,3-model-b\0brcm,bcm2837\0

While in rpi jammy classic images you see:

$ cat /proc/device-tree/compatible
raspberrypi,3-model-b-plus\0brcm,bcm2837\0

Even though all firmware and device trees are the same. The only difference was that in UC22 we set os_prefix [1] to ask the firmware to load files from a different folder. After copying to the root of the seed partition kernel, initrd, device trees, and cmdline.txt files, I removed the os_prefix and rebooted. After that, an RPi3b+ is properly detected and the MAC has a fixed address. So, it turns out that this is a firmware bug in the implementation of os_prefix.

[1] https://www.raspberrypi.com/documentation/computers/config_txt.html#os_prefix

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

Reported upstream: https://github.com/raspberrypi/firmware/issues/1720

[Łukasz Zemczak (sil2100)]

Do we have any possible workaround for this issue in the meantime? I think Dimitri mentioned he wanted to try something in the initrd.

[Juerg Haefliger (juergh)]

Not sure if this is related but the vc4-fkms-v3d overlay is also not loaded.

[Juerg Haefliger (juergh)]

No workaround AFAICT. The Pi firmware incorrectly loads the DTB for the 3b instead of 3b+ if os_prefix is set.

[Juerg Haefliger (juergh)]

Needs new Pi firmware to handle longer os_prefix pathnames.