In some situations, nmstate persist-nic-names saves NIC name and mac address mapping to the kernel command line. In the case of Azure VMs with Accelerated Networking this leads to two entries with the same MAC address:

$ rpm-ostree kargs
rhcos.root=crypt_rootfs random.trust_cpu=on console=tty0 console=ttyS0,115200n8 rd.luks.options=discard $ignition_firstboot ostree=/ostree/boot.1/rhcos/13e68aee0be9cb47c1fc1b23fc64255b87736ffb522a1eab5c1659bbfc4a301d/0 ignition.platform.id=azure ifname=enP21906s1:60:45:BD:3B:70:FB ifname=eth0:60:45:BD:3B:70:FB systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller=1

This leads to the same failure mode as seen in OCPBUGS-30256. The observed behavior is the node never becomes Ready. SSHing to the node shows

[systemd]
Failed Units: 1
  NetworkManager-wait-online.service

For a customer case, see https://portal.microsofticm.com/imp/v5/incidents/details/557511587/summary. That particular cluster was born on 4.5.16 so that might have something to do with why persist-nic-names is using kargs in addition to link files here.

Since the kernel does not support a "driver" mapping, we may need to skip persist-nic-names on upgrade for all ARO (or all Azure) nodes.