Comment 15 for bug 1902960

This isn't a problem with 3.2 to 3.3 upgrade, this is a problem where on first boot of the azure instance any restart of networkd fails to associate the .network file with the interface, e.g.:

root@lp1902960-3:~# networkctl status eth0
● 2: eth0
             Link File: n/a
          Network File: /run/systemd/network/10-netplan-eth0.network
                  Type: ether
                 State: routable (configured)
                  Path: acpi-VMBUS:01
            HW Address: 00:0d:3a:4e:ec:8c (Microsoft Corp.)
                   MTU: 1500 (min: 68, max: 65521)
  Queue Length (Tx/Rx): 64/64
      Auto negotiation: no
                 Speed: 40Gbps
                Duplex: full
               Address: 10.0.1.4 (DHCP4)
                        fe80::20d:3aff:fe4e:ec8c
               Gateway: 10.0.1.1
                   DNS: 168.63.129.16
        Search Domains: wh32vgcjtxsend1z44t3vj4ibg.bx.internal.cloudapp.net

root@lp1902960-3:~# systemctl restart systemd-networkd
root@lp1902960-3:~# networkctl status eth0
● 2: eth0
             Link File: n/a
          Network File: n/a
                  Type: ether
                 State: routable (unmanaged)
                  Path: acpi-VMBUS:01
            HW Address: 00:0d:3a:4e:ec:8c (Microsoft Corp.)
                   MTU: 1500 (min: 68, max: 65521)
  Queue Length (Tx/Rx): 64/64
      Auto negotiation: no
                 Speed: 40Gbps
                Duplex: full
               Address: 10.0.1.4
                        fe80::20d:3aff:fe4e:ec8c
               Gateway: 10.0.1.1

This is because udev doesn't know about the eth0 'Driver', because the systemd-udev-trigger service didn't correctly run at the proper time to generate uevents for existing devices.

Simply re-running systemd-udev-trigger will update udevd with the correct info (including the Driver value), and then restarting systemd-networkd will again work correctly.