workaround userspace-exposed ipmi linux devices that get auto-assigned 169 addr and fail boot
It's clear at this point that we need a workaround for these mgmt pseudo-devices that provide Linux userspace with access to the IPMI/BMC/whatever. We started seeing this on newer kernels (e.g. >= 4.15.x) within the past few months. There is no special attribute I've found that we can use to block them generally.
I don't fully understand what's going on; it seems that some state of this device flips dhclient out and it almost immediately returns. However, there have been cases where there is no obvious path to an auto-assigned 169. address (e.g. no dhclient hooks, no avahi daemon, etc), and it gets one anyway. I'm worried that distros are linking dhclient against libavahi or whatever. If that is true, we might not have a path to fixing this. Anyway, once the device has an auto-assigned 169. ipv4 address, of course systemd is "honor-bound" to continue boot as if the network is up.