[mantic] usb ethernet not working

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
https://iso.qa.ubuntu.com/qatracker/reports/bugs/2036841

What netplan configuration were you using? I managed to get an ethernet adapter working on mine but had to use something to match the enMACMACMAC name of the card:

network:
    ethernets:
        eth0:
            dhcp4: true
            optional: true
            set-name: eth0
            match:
              name: en*

The "set-name" is entirely optional, but if it's not there the card remains named "enMACMACMAC". The default netplan configuration won't work as the interface isn't named "eth0".

I haven't altered the netplan config, but I thought this used to work on past releases without manually modifying the netplan didn't it?

It may have worked years ago when we just mapped absolutely anything with an "en*" name to eth0, but that caused issues with people that wanted multiple eth interfaces on their Pi (e.g. the built-in one and another plugged into a USB port). Sometime around jammy (I think?) we changed to only map interfaces matching "en*" and *also* matching one of the drivers used by the Pi's built-in ethernet (currently bcmgenet, smsc95xx, and lan78xx).

However, this does mean any port that's plugged into USB that doesn't match this spec, needs an updated netplan config.

I'm seeing something bizarrely similar to this on the 3B+ with its built-in ethernet during ISO testing the mantic final server images, that I could swear wasn't occurring during the beta. The ethernet adapter is coming up with an enMACMACMAC name on boot, so the netplan configuration doesn't apply and cloud-init falls apart if it tries to do anything on the network..

The bizarre bit is that the netplan (and systemd network) configuration appear correct because "sudo netplan apply" after boot causes the enMACMACMAC interface to rename to eth0 (as it should be) and everything applies happily. But that's no good if the Pi is headless and someone's relying on ethernet to reach it!

These are not good:

Oct 10 15:07:15 ubuntu (udev-worker)[367]: eth0: /usr/lib/udev/rules.d/75-net-description.rules:6 Importing properties from results of builtin command 'net_id'
Oct 10 15:07:15 ubuntu (udev-worker)[367]: eth0: /usr/lib/udev/rules.d/75-net-description.rules:6 Failed to run builtin 'net_id': No such file or directory
Oct 10 15:07:15 ubuntu (udev-worker)[367]: eth0: /usr/lib/udev/rules.d/75-net-description.rules:8 Importing properties from results of builtin command 'usb_id'
Oct 10 15:07:15 ubuntu (udev-worker)[367]: eth0: Failed to access usb_interface: No such file or directory
Oct 10 15:07:15 ubuntu (udev-worker)[367]: eth0: /usr/lib/udev/rules.d/75-net-description.rules:8 Failed to run builtin 'usb_id': No such file or directory
Oct 10 15:07:15 ubuntu (udev-worker)[367]: eth0: /usr/lib/udev/rules.d/80-net-setup-link.rules:5 Importing properties from results of builtin command 'path_id'
Oct 10 15:07:15 ubuntu (udev-worker)[367]: eth0: /usr/lib/udev/rules.d/80-net-setup-link.rules:9 Importing properties from results of builtin command 'net_setup_link'
Oct 10 15:07:15 ubuntu (udev-worker)[367]: eth0: Failed to query name_assign_type: No such file or directory
Oct 10 15:07:15 ubuntu (udev-worker)[367]: eth0: Failed to get "name_assign_type" attribute, ignoring: No such file or directory
Oct 10 15:07:15 ubuntu (udev-worker)[367]: eth0: Failed to query addr_assign_type: No such file or directory
Oct 10 15:07:15 ubuntu (udev-worker)[367]: eth0: Failed to get "addr_assign_type" attribute, ignoring: No such file or directory
Oct 10 15:07:15 ubuntu (udev-worker)[367]: eth0: Link vanished while getting information, ignoring.

I've opened a separate issue (LP: #2038964) for my particular circumstance, as I don't think it's what Paul was seeing originally. It appears to be a udev race during boot causing multiple renames of the interface (with netplan losing the race and trying to apply the configuration to the "wrong" adapter).

Sorry, jiggling priorities on the wrong bug!