[systemd-devel] Rename NIC by using dynamic MAC

Andrei Borzenkov arvidjaar at gmail.com
Sat Dec 5 22:53:22 PST 2015


03.12.2015 19:57, Greg KH пишет:
> On Thu, Dec 03, 2015 at 08:35:24AM -0800, Aaron_Wright at selinc.com wrote:
>>> From: Kaesbauer Michael <Michael.Kaesbauer at krones.com>
>>> Hi,
>>>  
>>> up to now I found no way to write an udev rule which renames a
>>> specific NIC by using a MAC address that is returned by a bash
>>> script. The reason for getting the MAC address by the bash script is
>>> that the renaming NIC rule should be applied to different CPUs (with
>>> different MACs).
>>>  
>>>  ...snip...
>>
>> I have a similar problem, wanting to name NICs by location in the box. My udev
>> rules use KERNELS, which seems to be consistent for me, maybe it'll work for
>> you.
>>
>> KERNELS=="0000:02:00.0", NAME="front0"
>> KERNELS=="0000:06:03.0", NAME="rear0"
>> KERNELS=="0000:06:04.0", NAME="rear1"
> 
> That's just the PCI device id, which can, and will, randomly change when
> you plug a new device in, or update the bios, or update the firmware, or
> the next time you boot on a full moon (I had a machine that would change
> the pci order every 10th boot for some unknown reason), or some for some
> other random reason.
> 

Really? Why did not you say it when predictable interface names were
added? This is exactly what is used to "predictably" and "persistently"
name interfaces, is not it?

> Don't rely on these values, they will change in the future.
> 
> Use something that you know will not change, like the slot number (if
> your bios provides that), or the MAC address.
> 

Physical topology is not likely to change. It is just that kernel
exposes physical topology using names that are themselves unstable.

I.e. full path like in

/pci0000:00/0000:00:1c.4/0000:03:00.0

is not likely to change even though bus numbers can and it may become

/pci0000:00/0000:00:1c.4/0000:04:00.0

after reboot because new bus emerged.




More information about the systemd-devel mailing list