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

[Henti Smith]

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.

I'll try udev as well.

Kind regards
Henti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20241029/cacf0037/attachment-0001.htm>