1 |
On 11/28/21 9:50 AM, Jack wrote: |
2 |
> The network name switch ... is not directly due to eudev vs. udev, |
3 |
> but to the "new" ... switch to consistent naming ... so your network |
4 |
> is probably something like enp20s2, reflecting which slot your network |
5 |
> card is physically in. |
6 |
|
7 |
Except I've had multiple instances where the supposed to be consistent |
8 |
naming is anything but consistent. I don't know if it was a udev issue |
9 |
or something else. But I've seen the actual address of cards in the |
10 |
system change based on what other cards are added to / removed from the |
11 |
system. It seems as if the motherboard re-configured addressing with |
12 |
the hardware change. E.g. NIC1 in PCIe slot A and NIC2 in PCIe slot C. |
13 |
NIC2 changed from (hypothetical) enp20s2 to enp16s2 when NIC1 was |
14 |
removed from PCIe slot A. |
15 |
|
16 |
So ... if the new naming scheme isn't consistent, then I'm not going to |
17 |
give it the time of day. I'd rather have the older and simpler |
18 |
inconsistent naming scheme (eth#) vs the newer and more annoying scheme |
19 |
en{po}\d\d{,s}{,1,2,3}. |
20 |
|
21 |
The epiphany when is aw that the supposedly consistent names weren't was |
22 |
a real son of a REDACTED moment. |
23 |
|
24 |
> I'm pretty sure there is a kernel boot parameter which forces the old |
25 |
> way, but can't find it now, as I switched to the new naming with eudev, |
26 |
> so switching to udev didn't break anything for me. |
27 |
|
28 |
As Neil B. pointed out, "net.ifnames=0" is now on all my kernel boot |
29 |
lines (for the above reason). |
30 |
|
31 |
|
32 |
|
33 |
-- |
34 |
Grant. . . . |
35 |
unix || die |