Comment 22 for bug 1902960

> coldplugging of the network device is happening before the driver is loaded,
> and so (unsurprisingly :) it doesn't find the driver.

so, 'coldplugging' (meaning systemd-udev-trigger service) just runs through all devices in the system and asks them to (re)issue 'add' uevents. if a device doesn't exist yet, it can't be asked to issue an 'add' uevent.

additionally, hotplugging the driver later would generate its own uevents, thus notifying udevd about it. That's the whole point of systemd-udev-trigger, it's only intended to provide uevent notification to udevd for devices that *already* have their drivers loaded (e.g. built-in drivers or ones loaded from the initramfs), and already sent out their 'add' uevents. Any drivers loaded later are hotplug events and send out their own uevents to notify udevd, which is why systemd-udev-trigger doesn't need to run other than once at boot.

additionally it doesn't explain how systemd-networkd *did* match the .network file, even though it doesn't know anything about the interface Driver.

> I suspect that adding an `After=systemd-modules-load.service` to
> systemd-udev-trigger-service addresses the issue,

that shouldn't be needed since systemd-udev-trigger only generates uevents for all pre-existing devices. any devices hotplugged later, including those whose drivers are loaded by systemd-modules-load, will generate their own uevents as their driver enumerates the devices.

I certainly may be wrong about cloud-init, however; that was just my guess on what code might be doing non-standard first-boot magic.

I'm fairly certain it isn't anything in systemd misbehaving, however.