On Tue, Oct 29, 2024, 09:51 Henti Smith <henti@xxxxxxxxxxxxxxxxx> wrote:
On Mon, 28 Oct 2024 at 19:17, Mantas Mikulėnas <grawity@xxxxxxxxx> wrote:On Mon, Oct 28, 2024 at 8:54 PM Henti Smith <henti@xxxxxxxxxxxxxxxxx> wrote:Where can I find detailed information on where to find the names when systemd-udevd sees the interface for the first time ?At that point, they are just the original kernel names: "eth0", "eth1", etc.I'm going to look today with kernel parameter net.ifnames=0 to see what the names are. Maybe this will point at a way forward.In other words, at that point in time it is not "earlier renaming" but "future renaming", and the udev rule that processes your .link file is the very same rule that would've renamed the interface to "eno2" otherwise.Silvio in my previous mail thread commented that I can use udevadm info which is what I'm trying to do here. Is there another method to get the "pre systemd" interface names that I should be using ?I cannot use mac addresses to match on, nor the Path as both are not reliable in my use case, hence using the full DEVPATH from udevadm.Do you mean that .../0000:00:10.0/0000:05:00.0 is reliable, but .../0000:05:00.0 in itself is not? In that case, it might be possible to write a .network file or an udev rule that matches just these two parameters, but without comparing against "enoX" or "enpX".For example, maybe:Property=DEVPATH=/devices/pci0000:00/0000:00:11.0/0000:06:00.0/net/eth*I'll attempt today with wildcards and see what the result is, but based on the man page, all options implicitly mention glob support while property doesn't, but I'll try.If networkd doesn't accept wildcards, then an udev rule may work:DEVPATH==" /devices/pci0000:00/0000:00:11.0/0000:06:00.0/net/*", NAME="mvc-sw1"eno2 would also have ATTRS{index}=="2" from the firmware.I went the udev route initially, however Lennart advised that I should stick with link files. All the rest of our networking is being done in systemd-network, so this aligned with our current configuration methods.
It sounds like .link files aren't sufficiently flexible for your use case though. At least, if .link files need to be involved, then you might need to use udev rules to set a custom property via ENV{} and then match that from a .link file via Property=. (For example, match by devpath wildcard and set ENV{devboard_port}="1", or possibly copy the parent's ID_PATH into the child's PARENT_PATH...)
