1 |
Hi Alarig, |
2 |
|
3 |
On 11/13/19 5:54 PM, Alarig Le Lay wrote: |
4 |
> |
5 |
> PS: Old interface names were way more guessable than the new ones (eth0 |
6 |
> used to work 99% of time). I really don’t understand why someone woke a |
7 |
> morning a though “we should randomise this, it’s too much stable”. |
8 |
|
9 |
While I've no idea about why your dev manager seems to not pick up the |
10 |
task to rename the network devices, the reason behind the rename is: |
11 |
|
12 |
Especially server machines may have multiple network devices, maybe |
13 |
even built with different hardware requiring different kernel drivers. |
14 |
Now the device initialization is performed in parallel, but the ethX |
15 |
naming scheme does require serialization to get unique device names, |
16 |
causing the device being initialized fastest to receive the name eth0. |
17 |
|
18 |
But on another reboot, another device may be faster, and you end up with |
19 |
eth0 and eth1 being toggled this time. For example, I have discovered |
20 |
this to be fatal for virtualization hosts, when virtual guest's network |
21 |
devices need to be bound to a specific host device. |
22 |
|
23 |
What usually does not change across reboots is the physical location of |
24 |
network devices, and the firmware. So the new naming scheme is based on |
25 |
their physical location in the machine's hardware layout. For example, |
26 |
unless configured otherwise, on board devices that are enumerated by the |
27 |
firmware receive the enoX name, and PCI devices receive some enpXsY name |
28 |
with some physical PCI connector numbers as reported by the PCI firmware. |
29 |
|
30 |
But agreed, eth0 name is "stable" if there is one single network device. |
31 |
|
32 |
HTH, |
33 |
/haubi/ |