Re: Ethernet trouble
On Thu 30 Jan 2020 at 11:58:47 (-0700), ghe wrote:
> On 1/29/20 7:06 PM, David Wright wrote:
>
> > These boards, do their PCI addresses have the save bus number but
> > different slot/device numbers? dmesg or kern.log will give you
> > those: they look like NN:DD.F optionally preceded by DDDD:, where
> > DDDD is the domain (typically 0000), NN is the bus, DD the device
> > of slot, F the function(s) provided by that card, eg
> > pci 0000:00:0e.0: [10ec:8139] type 00 class 0x020000
>
> Well, I don't in any way consider myself a hardware guy, but in Java,
> Pascal, C, PERL, Python, FORTRAN, BashScripts, etc, '+' usually does the
> same thing every time I type it.
?
> 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
And did you happen upon the boards' addresses?
> So something took the rational Ethernet interface names and,
> intentionally I assume, broke hundreds of lines of code.
>
> 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.
Yes, but the kernel's choice of eth0 and eth1 may not necessarily be
fixed. My experience with linux in the past was that, with two NICs,
there was no way of ensuring the order in which they were assigned.
With something like a firewall, you could end up with your WAN and LAN
interfaces reversed.
> Or if I put in a sound-card.
>
> 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. I
> especially don't need some broken piece of software to rename them.
And take disks. With the proliferation of buses in modern PCs, there's
no guarantee that the machine will boot up and have the system disk
on the usual /dev/sda. My PC in the attic appear to enumerate the legacy
PATA before the SATAs. This laptop enumerates USB sticks in an order
that appears stable, but I have no idea whether it's really a race.
I have read of a case analogous to yours, where booting up a laptop
with a USB stick inserted would demote the internal disk to /dev/sdb.
(I think the internal disk was an SSD.)
> I know I can put them back to the 'inconsistent' names in Grub, and I'll
> be doing that -- and editing the shell scripts.
>
> > 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 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.
Said attic PC is a Dell Optiplex.
> 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. If it does that, my Ethernet ports would
> have had the same labels, unless somebody renamed them. Would be the
> same too, if they'd just been left alone.
In your case, the sensible thing might be to use the MAC addresses,
assuming you don't change them. These Super Micro thingies could have
an IPMI built in, allowing you to change MACs to your heart's content.
> I'm not looking forward to systemd.emacs.
I got the impression there was an agenda polarising the debate. BTW,
you know who started all this renaming NICs business? Your friends at Dell.
Cheers,
David.
Reply to: