netplan yaml for rpi groovy server prevents usb ethernet

[Paul Larson]

When booting an rpi that does not have built-in ethernet (such as cm3, rpi3a+, etc) with the release candidate images for groovy, no ethernet interface is configured after starting when a usb ethernet dongle is used. The interface is detected, but not configured.

In /etc/netplan/50-cloud-init.yaml for the groovy image it has:
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        eth0:
            dhcp4: true
            match:
                driver: bcmgenet smsc95xx lan78xx
            optional: true
            set-name: eth0
    version: 2

This did used to work correctly in focal, probably because the driver restriction wasn't present. This is the yaml that was generated for the focal image:
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    ethernets:
        eth0:
            dhcp4: true
            optional: true
    version: 2

In my case, the usb dongle I have seems to use the ax88179_178a driver, but presumably others would fail in the same way.

[Ubuntu QA Website (ubuntuqa)]

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

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

[Dan Watkins (oddbloke)]

Hey Paul,

Thanks for the bug report! If you could run `cloud-init collect-logs` on an affected machine and attach the tarball here, we can dig into this more based on that info.

Cheers,

Dan

[Dan Watkins (oddbloke)]

(Oh, and I should say: please move this back to New once you've attached the tarball!)

[Launchpad Janitor (janitor)]

[Expired for cloud-init (Ubuntu) because there has been no activity for 60 days.]

[Paul Larson (pwlars)]

I didn't see the log request here. However this also seems to affect hirsute. I'm posting the cloud-init collect-logs tarball for hirsute on rpi3a+. The other thing that changed right before this started happening, is that net.ifnames=0 is (intentionally) no longer used. AIUI, the intent on rpi devices is that built-in ethernet adapters should all still get eth0 as a name, but usb ones are ok to have predictable names.

[James Falcon (falcojr)]

Is there a netplan configuration that does work for you? If you take the netplan configuration that worked on focal and move to groovy/hirsute, does that work?

[Paul Larson (pwlars)]

No, I think part of the problem is that net.ifnames=0 was dropped. So it's not simply a matter of configuring eth0 anymore. On built-in eth interfaces, it does some matching to locate the correct interface and rename it to eth0 as appropriate, but I think this is because there's some more predictability with built-in eth than with usb attached ones.

[Dan Watkins (oddbloke)]

In the cloud-init log, I see:

2021-04-19 06:58:24,455 - stages.py[DEBUG]: applying net config names for {'version': 2, 'ethernets': {'eth0': {'match': {'driver': 'bcmgenet smsc95xx lan78xx'}, 'set-name': 'eth0', 'dhcp4': True, 'optional': True}}}
2021-04-19 06:58:24,456 - __init__.py[DEBUG]: no interfaces to rename

"driver" there can't be a space-separated list: netplan expects it to be a single item (though globs are permitted): https://github.com/canonical/netplan/blob/master/netplan/cli/utils.py#L215

I think what's happening is that, because there is no longer an "eth0" interface in the system, cloud-init/netplan are using the match clause (whereas previously they would just have identified that they already _had_ eth0). It doesn't find an interface using the driver named "bcmgenet smsc95xx lan78xx" (of course, as that's three driver names concatenated together), so it (correctly) concludes that there is no config that matches NICs in this system and proceeds under that assumption.

So: I think this is somewhere between a bug in that network configuration and a feature request in netplan (and therefore cloud-init), to update the semantics of the driver clause to support matching on multiple drivers somehow.

Does that sound right? (I'll move this to Incomplete, please do move this back to New once you've responded!)

[Paul Larson (pwlars)]

I don't think that driver matching is still happening. Something else seems to be responsible for conditionally fixing the name to be eth0 when it's one of those well-known built-in ethernet drivers for rpi. AIUI, this is done because by convention, people like to take an sd card and move it from one rpi to another and expect things to just work.

For usb eth, we don't have the limited set of known on-board ethernet drivers, so as far as I've heard, there's not a good way to just "do the right thing" there, and currently requires manual configuration. Still, I have to wonder if there's something nicer we could do. I do see in the logs for systemd-networkd that something seems to be renaming my usb eth dongle to eth1 (this is currently connected to an RPI 4 that has its own eth0), and then later renames it back to a predictable name.
Apr 21 23:28:29 ubuntu systemd[1]: Starting Network Service...
Apr 21 23:28:29 ubuntu systemd-networkd[1685]: Enumeration completed
Apr 21 23:28:29 ubuntu systemd-networkd[1685]: enx000ec6c41f57: Interface name change detected, enx000ec6c41f5
7 has been renamed to eth1.
Apr 21 23:28:29 ubuntu systemd[1]: Started Network Service.
Apr 21 23:28:29 ubuntu systemd-networkd[1685]: eth1: Interface name change detected, eth1 has been renamed to
enx000ec6c41f57.

[Launchpad Janitor (janitor)]

[Expired for cloud-init (Ubuntu) because there has been no activity for 60 days.]