Re: Ethernet trouble
On Thu, Jan 30, 2020 at 11:58:47AM -0700, ghe wrote:
I looked at dmesg a bit. I greped it for 'enp' and there was a funny
joke in the first 2 lines (of the grep output):
[ 2.181317] e1000e 0000:08:00.0 enp8s0: renamed from eth1
[ 2.422105] e1000e 0000:07:00.0 enp7s0: renamed from eth0
So something took the rational Ethernet interface names and,
intentionally I assume, broke hundreds of lines of code.
Because those "rational" ethernet names can be very unstable *in
practice* on modern systems. (Devices are initialized in parallel, so
when there are multiple interfaces present they may not always come up
in the same order.)
Once I was installing a computer that had a single Ethernet port
soldered to the mobo (a Dell). I had an eth0, but I needed an eth1, so I
put a card in the PCI bus. On reboot, I had eth0 and eth1. 0 was the
mobo, 1 was the card. And it was eth1 no matter which slot it was in.
See above. This worked reliably on old kernels, especially static
kernels (pre-modules) with ISA/PCI devices and works much less reliably
in a world of hotplug PCI, USB, and modular configurations with parallel
intialization. There was a series of hacks on top of the "rational
names" which mapped the name to a MAC address. In practice that *also*
renamed the ethernet devices, except in a less transparent fashion, and
caused its own headaches when NICs were replaced.
They were named by function, not by bus and slot. As a programmer, I'm
much more interested in *what* they are, not *where* they are.
As a programmer you should be concerned with making sure that the
packets go in and out of the correct physical hardware. If the name
doesn't relate to the physical harder that's a harder problem to solve.
You (and everyone else) could reimplement that in software at a higher
level, or accept that this is something the OS should help with.
AIUI it's nothing to do with the OS as these decisions are made by
the firmware on the mobo. Juggling cards in a mobo can even outwit
the BIOS so that the POST won't succeed: I've had mobos where I've
had to empty the box, power-up and save the settings, add one card
and repeat, add the next and so on, all to get a box with the cards
I wanted, located where I wanted them.
With all the 'puters
really?
I've dealt with, I've never seen anything like
that. If I got one that did that, I'd have sent it back to Amazon and
bought a Dell or a Raspberry Pi or a SuperMicro -- something with a
competently written and tested BIOS.
Again, many desktops have lousy firmware. Yours seems to be one of them. :-)
Besides, we've got UDEV. It allegedly looks at hardware and makes it
make sense. To do that, it must, I suspect, ignore what the BIOS says
and scan the bus(es) itself.
udev can't map a logical bus to a physical slot, only the firmware knows
how to do that (and only if it's been properly configured by the
vendor). udev can't even tell things like how many buses there are in
the system, because the firmware may turn them on and off or create
virtual buses and change those things between boots. As with most
things, the systemd folks didn't just implement a solution looking for a
problem, they tried to solve an actual problem that's a lot harder than
people throwing rocks from the sidelines tend to understand.
Reply to: