<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 29 Oct 2024 at 15:00, Mantas Mikulėnas <<a href="mailto:grawity@gmail.com">grawity@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 29, 2024, 09:51 Henti Smith <<a href="mailto:henti@gaydonsmith.co.uk" target="_blank">henti@gaydonsmith.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 28 Oct 2024 at 19:17, Mantas Mikulėnas <<a href="mailto:grawity@gmail.com" rel="noreferrer" target="_blank">grawity@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 28, 2024 at 8:54 PM Henti Smith <<a href="mailto:henti@gaydonsmith.co.uk" rel="noreferrer" target="_blank">henti@gaydonsmith.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Where can I find detailed information on where to find the names when systemd-udevd sees the interface for the first time ? <br></div></div></div></blockquote><div><br></div><div>At that point, they are just the original kernel names: "eth0", "eth1", etc.</div></div></div></blockquote><div><br></div><div>I'm going to look today with kernel parameter 
<tt>net.ifnames=0</tt> to see what the names are. Maybe this will point at a way forward. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>
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 <i>would've</i> renamed 
the interface to "eno2" otherwise.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div><br></div><div>Silvio in my previous mail thread commented that I can use 
<span>udevadm</span> 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 ? <br></div><div><br></div><div>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. <br></div></div></div></blockquote><div><br></div><div>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".</div><div><br></div><div>For example, maybe:</div><div>  
Property=DEVPATH=/devices/pci0000:00/0000:00:11.0/0000:06:00.0/net/eth*</div></div></div></blockquote><div><br></div><div>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. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>If networkd doesn't accept wildcards, then an udev rule may work:</div><div>  DEVPATH=="
/devices/pci0000:00/0000:00:11.0/0000:06:00.0/net/*", NAME="mvc-sw1"</div><div>eno2 would also have ATTRS{index}=="2" from the firmware.</div></div></div></blockquote><div><br></div>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.</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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...)</div></div></blockquote><div><br></div><div>It looks like glob does work with the Property field in  link files. <br></div><div><br></div><div>I've updated the link files to match on "Property=DEVPATH=/devices/pci0000:00/0000:00:10.0/0000:05:00.0/net/*" and that is working. <br></div><div><br></div><div>I'll continue testing and feedback, but if globbing is supported in Property, making that clear in the documentation will be very helpful. <br></div><div><br></div><div>Kind regards</div><div>Henti<br></div></div></div>