Thanks for your answer
On 8/11/20 5:43 PM, Michal Sekletar wrote:
On Wed, Aug 5, 2020 at 4:12 PM Thomas HUMMEL <thomas.hummel@xxxxxxxxxx
On RHEL/CentOS 8 biosdevname naming is not used unless it is explicitly
enabled on the kernel command line using biosdevname=1.
Indeed I've read the udev rule too fast. No biosdevname involved.
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,
...).
Yes this is the exact same host.
But as you said, it seems it could only be some kind of race condition
as in one case firmware correctly provided the index, doesn't it ?
To prove this hypothesis you need to modify net_id
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.
Unfortunately this host is not this often available to play with so I'm
not sure I can test this.
More details in commit message,
https://patchwork.kernel.org/patch/3733841/
Thanks. So basically with this attribute the kernel can say that the
name has been set by itself and thus may need to be renamed if one wants
predictable names ?
However I'm note sure to understand which way it works. Here's how I see
a simple case like an onboard ethernet nic :
a) kernel is the first to see the device
b) it sends the corresponding event to userspace udev
c) udev via its rules may rename the device
d) kernel sets the name_assign_type attribute accordingly
am I correct ?
If so,
- in a) : does it name the device or not ? with just an enumerated
suffix (ethX) ?
- in c) could %k be something already diffrent than ethX ?
- in a case where udev applies either onboard or physical path policy,
would d) be _USER or _RENAMED ?
Thanks for your help
--
TH
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
