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

[Thomas HUMMEL]

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 at pasteur.fr 

> 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