[18:33] <sbraz> ok so i fixed my issue with "rename2: renamed from eth0", it was caused by eth0 being in 70-persistent-net.rules, causing udev to rename eth0 to eth1 (via rename2), eth1 to eth2, etc.
[18:34] <sbraz> what i mean by "eth0 in persistent rules" was that another mac address was there, and i guess udev decided that there was a conflict with the current eth0 so it renamed all interfaces
[18:37] <sbraz> anyway, i still don't understand how, when predictable names are used (e.g. debian 11/12), i don't have an issue, because there is less than 100 ms between the last rename (kernel: ixgbe 0000:03:00.1 eno4: renamed from eth1) and the start of cloud-init-local.service
[18:38] <sbraz> am i just lucky that it doesn't fail? and the issue only occurs when there is a double rename (eth0 becomes rename2 and then becomes eth1)?
[18:40] <sbraz> and debian doesn't use systemd-udev-settle.service from what i see so it can't be because of it