<flokli>
check networkctl status $iface what .link matches?
<rnhmjoj>
the generated .link file is identical to that example, the only difference is the 10- prefix: i'm trying this now
<rnhmjoj>
ok, it works on master
<hexa->
flokli: but this still seems to break udev renaming, any idea?
<hexa->
I mean, this drops udev-settle, so networkd starts earlier
<hexa->
just too early
<rnhmjoj>
...and it breaks with my change, so using a .link or udev makes no difference here
<hexa->
yeah, both should work honestly
<hexa->
both are handled by udev
<flokli>
I'm lacking some context I think
<flokli>
but yes, the .link files are matched by udev, pretty early in boot
<flokli>
however, you can use networkctl (or poke at the logs) to see which one was picked up
<rnhmjoj>
i don't understand why networkd would enter this kind of race condition. it certainly does not require udev-settle on other distro, does nixos patches it somehow?
<flokli>
rnhmjoj: wait wait
<rnhmjoj>
(i'll try running the test interactively)
<flokli>
so I think the problem here is that something brings the network interface up
<flokli>
the udev rules are not copied in the initrd
<flokli>
but something brings up the network interfaces too early
<flokli>
we'd need to copy udev.extraRules into the initrd too
<flokli>
but that could cause too much stuff to be pulled in
<flokli>
so udev in initrd renames it, and we bring them up later
<rnhmjoj>
flokli: yeah, the "device or resource busy" error
<flokli>
yes
<flokli>
rnhmjoj: so I'd propose trying to see if it works if we copy udev rules into the initrd
<rnhmjoj>
this is interesting: i tried as you suggested to see what is the final ifname with networkctl
<rnhmjoj>
it's left intact: eth0, because in nixos vms usePredictableInterfaceNames is false
<flokli>
ugh
<rnhmjoj>
if i force it on (needs lib.mkOverride 0), then the interface is actually renamed
<flokli>
yeah, the whole test driver networking stuff is another tire fire
<flokli>
-> #nixos-python-test-driver
<rnhmjoj>
i'll have to try on a real machine, but it looks like `usePredictableInterfaceNames = false` interferes with the custom renaming, somehow
<rnhmjoj>
uhm, all the option does is setting net.ifnames=0, i think i'll take a look at the udev source
<rnhmjoj>
(btw, i figued net.ifnames is not a real kernel parameter but a systemd-udev thing)
<flokli>
yes, it's read there
Shados has quit [Quit: Shados]
Shados has joined #nixos-on-your-router
chrisaw has joined #nixos-on-your-router
<rnhmjoj>
it looks like it's not a networkd issue, or an issue if net.ifnames=0: i managed to reproduce it with dhcpcd and net.ifnames=1
rb2k has joined #nixos-on-your-router
<rnhmjoj>
it's just that udev takes too long to rename the interfaces
<rnhmjoj>
i see no other way than to move all .link/rules to stage 1
<flokli>
rnhmjoj: sounds like a plan to me
<flokli>
I hope we can somehow distinguish "extraRules renaming interfaces" from other stuff
<flokli>
I'm afraid some modules might interpolate some nix paths in there, and blow up initramfs size
<rnhmjoj>
uhm, we could advise to use netword.links to change interface settings, given they work even outside networkd
<rnhmjoj>
or maybe create service.udev.initrdRules
<flokli>
yeah, providing some more examples on how to use .link for renaming, and providing udev.initrdRules as an escape hatch might be better than just adding all udev rules
<flokli>
if we have more release notes assisting people to update their configs
<rnhmjoj>
links are probably a better idea because they are interfaces-specific and structured, unlike extraRules
<flokli>
I agree
<flokli>
but then people come and say like "these rules worked all the time, why do I need to systemd-ify them?"
<flokli>
problem is, udev.extraRules currently contains such a "rename network interfaces" example
<rnhmjoj>
well, we could do both: it's not much more code. an initrdRules option could also be used for other purposes, besides networking
<flokli>
ack
rb2k has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rb2k has joined #nixos-on-your-router
aleph- has joined #nixos-on-your-router
teozkr_ has quit [Remote host closed the connection]