On Wed, Aug 5, 2020 at 4:12 PM Thomas HUMMEL <thomas.hummel@xxxxxxxxxx> 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
>
>
> 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
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
