On Tue, 29 Oct 2024 at 15:00, Mantas Mikulėnas <graw...@gmail.com> wrote:
> On Tue, Oct 29, 2024, 09:51 Henti Smith <he...@gaydonsmith.co.uk> wrote:
>
>> On Mon, 28 Oct 2024 at 19:17, Mantas Mikulėnas <graw...@gmail.com> wrote:
>>
>>> On Mon, Oct 28, 2024 at 8:54 PM Henti Smith <he...@gaydonsmith.co.uk>
>>> 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...)
>
It looks like glob does work with the Property field in link files.
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.
I'll continue testing and feedback, but if globbing is supported in
Property, making that clear in the documentation will be very helpful.
Kind regards
Henti
