[systemd-devel] system is not match systemd.link configs

[Mantas Mikulėnas]

On Tue, Oct 29, 2024, 09:51 Henti Smith <henti at gaydonsmith.co.uk> wrote:

> On Mon, 28 Oct 2024 at 19:17, Mantas Mikulėnas <grawity at gmail.com> wrote:
>
>> On Mon, Oct 28, 2024 at 8:54 PM Henti Smith <henti at 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...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20241029/b8cb5276/attachment.htm>