| 1 |
Grant Taylor wrote: |
| 2 |
> On 11/28/21 9:50 AM, Jack wrote: |
| 3 |
>> The network name switch ... is not directly due to eudev vs. udev, |
| 4 |
>> but to the "new" ... switch to consistent naming ... so your network |
| 5 |
>> is probably something like enp20s2, reflecting which slot your |
| 6 |
>> network card is physically in. |
| 7 |
> |
| 8 |
> Except I've had multiple instances where the supposed to be consistent |
| 9 |
> naming is anything but consistent. I don't know if it was a udev |
| 10 |
> issue or something else. But I've seen the actual address of cards in |
| 11 |
> the system change based on what other cards are added to / removed |
| 12 |
> from the system. It seems as if the motherboard re-configured |
| 13 |
> addressing with the hardware change. E.g. NIC1 in PCIe slot A and |
| 14 |
> NIC2 in PCIe slot C. NIC2 changed from (hypothetical) enp20s2 to |
| 15 |
> enp16s2 when NIC1 was removed from PCIe slot A. |
| 16 |
> |
| 17 |
> So ... if the new naming scheme isn't consistent, then I'm not going |
| 18 |
> to give it the time of day. I'd rather have the older and simpler |
| 19 |
> inconsistent naming scheme (eth#) vs the newer and more annoying |
| 20 |
> scheme en{po}\d\d{,s}{,1,2,3}. |
| 21 |
> |
| 22 |
> The epiphany when is aw that the supposedly consistent names weren't |
| 23 |
> was a real son of a REDACTED moment. |
| 24 |
> |
| 25 |
>> I'm pretty sure there is a kernel boot parameter which forces the old |
| 26 |
>> way, but can't find it now, as I switched to the new naming with |
| 27 |
>> eudev, so switching to udev didn't break anything for me. |
| 28 |
> |
| 29 |
> As Neil B. pointed out, "net.ifnames=0" is now on all my kernel boot |
| 30 |
> lines (for the above reason). |
| 31 |
> |
| 32 |
> |
| 33 |
> |
| 34 |
|
| 35 |
|
| 36 |
What I noticed in dmesg is that it takes the old name, eth0 for example, |
| 37 |
and then renames it to the new name. Well, if one moves things around |
| 38 |
and eth0 becomes eth3 then doesn't that mess up the new name as well? |
| 39 |
That could be why you see the results you have. It's hard to base a |
| 40 |
name on something that is changing itself. It would seem to me that if |
| 41 |
they were going to change things for real, they would change what the |
| 42 |
kernel names it in the beginning and it uses the name it was first given |
| 43 |
based on slot or something else unique. In other words, have the kernel |
| 44 |
assign it enp2s3 or whatever when booting and that is the only name it |
| 45 |
gets. |
| 46 |
|
| 47 |
I don't change much hardware often so it doesn't affect me but I'm sure |
| 48 |
there are people, maybe even large companies/orgs that it does and it |
| 49 |
could be a issue for them. It could even be a security issue if two |
| 50 |
nics gets switched and one has a lot of security and the other doesn't. |
| 51 |
|
| 52 |
Either way, I'm up and running again. Even rebuilt my backup kernels to |
| 53 |
include the drivers this morning. I just hope nothing comes back and |
| 54 |
bites me later. :/ I was a bit lost there for a while. |
| 55 |
|
| 56 |
Dale |
| 57 |
|
| 58 |
:-) :-) |
Archives