[systemd-devel] systemd.net-naming-scheme change after update

[Michal Sekletar]

On Wed, Aug 5, 2020 at 4:12 PM Thomas HUMMEL <thomas.hummel at pasteur.fr>
wrote:
>
>
> What I understand here in my case is that NAME is not empty (because of
> biosdevname step) so I don't understand why I don't end up with em1
> instead of the
>   onboard style name. This would mean ID_NET_NAME has been set in a
> previous step ? What was the use of the biosdevname stop then ?

On RHEL/CentOS 8 biosdevname naming is not used unless it is explicitly
enabled on the kernel command line using biosdevname=1. Since you didn't
have an interface named using biosdevname to begin with I'd assume that
this rule is always skipped (which is OK unless you have biosdevname=1 on
cmdline)

In the case of an updated system net_id failed to generate a name based on
an on board index provided by the firmware. Hence naming falls back to the
next naming scheme which is based on PCI topology. I can't explain the
difference in names between updated and newly provisioned system (provided
they are exactly identical in terms of HW, firmware, ...).  Maybe due to
some race we assign a PCI path based name because the sysfs attribute that
is used to construct an on board name (enoX) becomes available only later
on. If that is the case then it would be a driver bug. To prove this
hypothesis you need to modify net_id so that it would log about missing
attributes. Roughly here,

https://github.com/systemd-rhel/rhel-8/blob/master/src/udev/udev-builtin-net_id.c#L228

you need to call log_error() or something like that only then return
-ENOENT.

>
>
> finally, what does "If the kernel claims that the name it has set for a
> device is predictable" mean
> (https://www.freedesktop.org/software/systemd/man/systemd.link.html#) ?
>
> And what is the kernel name (%k) : is it always ethX ?

Kernel can indicate via value of name_assign_type sysfs attribute that the
already assigned name is predictable.

More details in commit message,

https://patchwork.kernel.org/patch/3733841/

Cheers,

Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200811/394909d7/attachment.htm>