network-config doesn't apply on first boot with integrated ethernet controller

[DocSepp]

Bug report

During an OEM/QA run, one checkbox test is failing on one of our devices because it is using an integrated ethernet controller. Thus it automatically gets named eth0 and not something predictable like enP8p1s0.

The image we are testing is a preinstalled server image running cloud-init: https://git.launchpad.net/ubuntu-images/tree/ubuntu-server-tegra-igx.yaml?h=jammy

In order to circumvent this issue we wanted to implement a cloud-init network-config to match the interface to the driver and rename it manually to eno1. This works, but not on the first boot. On the first boot, the interface is still named eth0 and does not get an IP address even though cloud-init seems to have correctly generated the file /etc/netplan/50-cloud-init.yaml and then netplan generated /run/systemd/network/10-netplan-eth0.link and /run/systemd/network/10-netplan-eth0.network.

I found 3 ways to have the interface named correctly:

1. reboot the device
2. execute netplan apply which renames interfaces according to the netplan config either through udevadm test or ip link set dev <iface> <name>
3. ip link set down dev eth0; systemctl restart systemd-udev-trigger.service; ip link set up dev eno1

I also noticed that with the network not configured, it takes around 1 minute after the log in screen appears, for cloud-init to have finished setting up the configured user/password combination but this might be a separate issue.

Steps to reproduce the problem

Add the following lines to the image definition file above, rebuild, flash and execute first boot:

    network-config: |
      network:
        ethernets:
          eth0:
            dhcp4: true
            dhcp6: true
            match:
              driver: nvethernet
            set-name: eno1
        version: 2

Environment details

• Cloud-init version: 24.1.3-0ubuntu1~22.04.5
• Operating System Distribution: jammy
• Cloud provider, platform or installer type: NoCloud (I think)

cloud-init logs

cloud-init.tar.gz

[DocSepp]

Actually simply doing sudo udevadm test /sys/class/net/eth0 will already rename the interface correctly after boot

[TheRealFalcon]

After looking the logs, I don't think that this is a cloud-init bug. Cloud-init receives the config and writes it out correctly. At this point, netplan should set the name appropriately, but for some reason it does not.

Note that cloud-init doesn't attempt to rename anything from a V2 config unless a MAC is provided. The documentation should call that out, but it is describing the netplan behavior that for some reason is not happening.

[DocSepp]

I just tried matching against a macaddress and it does work because cloud-init is renaming it itself and then generates the netplan config:

2024-08-29 07:32:08,968 - net[DEBUG]: Detected interfaces {'lo': {'downable': False, 'device_id': None, 'driver': None, 'mac': '00:00:00:00:00:00', 'name': 'lo', 'up': True}, 'eth0': {'downable': True, 'device_id': None, 'driver': 'nvethernet', 'mac': '48:b0:2d:e5:da:ba', 'name': 'eth0', 'up': False}}
2024-08-29 07:32:08,968 - net[DEBUG]: achieving renaming of [['48:b0:2d:e5:da:ba', 'eno1', None, None]] with ops [('rename', '48:b0:2d:e5:da:ba', 'eno1', ('eth0', 'eno1'))]
2024-08-29 07:32:08,968 - subp.py[DEBUG]: Running command ['ip', 'link', 'set', 'eth0', 'name', 'eno1'] with allowed return codes [0] (shell=False, capture=True)
2024-08-29 07:32:08,987 - stages.py[INFO]: Applying network configuration from ds bringup=False: {'ethernets': {'eno1': {'dhcp4': True, 'dhcp6': True, 'match': {'macaddress': '48:b0:2d:e5:da:ba'}, 'set-name': 'eno1'}}, 'version': 2}

Does cloud-init only perform renaming of an interface when matching against a macaddress because it is unique whereas multiple interfaces could match against a driver?

I can't see it in the docs but is cloud-init (or netplan for that matter) able to match against a path like in systemd link files? When removing the netplan configuration and including a .link file in /etc/systemd/network/10-jetson-onboard-ethernet.link like this:

[Match]
Path=platform-6800000.ethernet
[Link]
Name=eno1

It does correctly name the interface as it (uniquely I assume) matches the interface against the position on the platform bus.

[DocSepp]

Also, does netplan get triggered again after the call to netplan generate and the several udevadm test-builtin ? Because afaik netplan generate will only generate the config files corresponding to the netplan config in /run. And after testing myself, udevadm test-builtin net_setup_link /sys/class/net/eth0 does not rename an interface, whereas udevadm test /sys/class/net/eth0 would for example.

[TheRealFalcon]

Does cloud-init only perform renaming of an interface when matching against a macaddress because it is unique whereas multiple interfaces could match against a driver?

Yes, netplan is more general, but cloud-init requires a mac address. I have a PR up to clarify this.

I can't see it in the docs but is cloud-init (or netplan for that matter) able to match against a path like in systemd link files?

For cloud-init, there is name, macaddress, and driver (same for netplan).

Also, does netplan get triggered again after the call to netplan generate and the several udevadm test-builtin ?

In your case no. There are scenarios where netplan apply may get called, but that would only be if a network connection is required to fetch datasource information, and then the datasource gives us a different network config that needs to be applied after network has already been up.

[randombyte-developer]

I am pretty sure this is the same issue I have. After booting up, the interface is not renamed yet and still down. Running netplan apply manually renames the interface and ups it. It seems like netplan apply was never run by cloud-init.

I solved it by running netplan apply as a bootcmd. This seems to be early enough for apt-get update and so on being run automatically.