[systemd-devel] when/where was support for assigning "ethX" names removed?

[Chris Friesen]

On 05/13/2016 08:54 AM, Chris Friesen wrote:
> On 05/13/2016 01:23 AM, Lennart Poettering wrote:
>> On Thu, 12.05.16 12:34, Chris Friesen (cbf123 at mail.usask.ca) wrote:
>>
>>> I booted the kernel with "net.ifnames=0", which worked to turn off the
>>> location-based naming.
>>>
>>> I then created a set of files, one per eth device that match based on MAC:
>>>
>>> [root at compute-0 root]# cat /etc/systemd/network/10-eth
>>> 10-eth0.link  10-eth1.link  10-eth2.link  10-eth3.link
>>>
>>>
>>> Here's an example of one of the files:
>>>
>>> [root at compute-0 wrsroot]# cat /etc/systemd/network/10-eth0.link
>>> [Match]
>>> MACAddress=08:00:27:f1:36:11
>>>
>>> [Link]
>>> Name=eth0
>>
>> "eth*" is the kernel's namespace for ethernet devices. Stepping into
>> that namespace, and racing against the kernel's name assignment logic
>> is something you can only lose at.
>>
>> Pick any other name, but assigning names in the kernel's own
>> namespace, that's not really supported.
>
> Okay, fair enough.
>
> Since I still need to do this for now, I changed the kernel to start naming at
> eth1000 so I could then rename it back down to the desired range.

(resending now that I'm on the list again, sorry for the dupe Lennart)

So I've been playing with this a bit, but I've run into another snag.  It seems 
that on initial boot even with "net.ifnames=0" the ethernet interface ordering 
isn't consistent.

This means that two systems with identical hardware can end up mapping "eth1000" 
to different physical slots.  This makes it very difficult to set up multiple 
machines.

I assume this is due to parallel network device initialization from udev?  Is 
there a way to serialize this at the cost of slower system initialization?  I 
don't really care what the ordering is, as long as it is consistent on identical 
hardware.

(Yes, I realize that the ideal would be to use the newer position-based naming, 
but that would mean a whole lot more work at this point.)

Thanks,
Chris