Steve Litt <slitt@???> wrote:

> As a wee lad, my mentors told me never to put two of the same model
> NICs in a computer, because which one became eth0 and which became eth1
> would be indeterminate from boot to boot. That's horrible, and that *is*
> solved by the systemd naming scheme.

Except when it isn't !
In fact, two card of the same type (or rather, using the same driver), is not a problem - they use the same driver, and enumeration of devices follows (or is supposed) to follow a set order.
When they use different drivers, then there is parallelism in initialisation which means it's not determinate which driver gets loaded first and hence which device is eth0 and which is eth1.



Adam Borowski <kilobyte@???> wrote:

>> Why not use a similar mechanism for interface names? remember which
>> names were recently used and use them again?
>>
>> This sounds a lot like the fstab-like proposal, except it
>> autoconfigures.
>
> You mean, /etc/udev/rules.d/70-persistent-net.rules which has been removed
> in favour of completely-un-"predictable" names, right?
>
> It has a very user unfriendly syntax, but it did just what you suggest.

Exactly, THAT problem was solved (in the server and probably desktop spaces) many many years ago. SOLVED, nothing to see here, move along please.
It has it's issues, but these are mostly down to hardware being changed and installations being cloned - ie situation that involve administrator involvement and so an opportunity to fix it at the same time.

I accept that there ARE issues in some cases - especially things like laptops with plug in (USB) NICs - but fixing that doesn't need to break everyone else. Put another way, yes I can see that there is a problem to be solved, but no, I don't think that imposing massive problems on the majority of users is the right way to do it.



Rick Moen <rick@???> wrote:

> I find myself in the position of being a little unconvinced about the
> extent and seriousness of the problem, even though I don't have
> exhaustive data, only a few decades of *ix experience to draw on.
> Let me try to draw a distinction with some nuance, here: To the best of
> my knowledge -- and my knowledge might be incomplete or unaware of some
> new developments -- 'spontaneous' network device renaming, just like
> spontaneous mass storage device renaming, happens _only_ following
> admin-initiated hardware reshuffles.

Not so.
I recall working on a system a while ago with two different SCSI interfaces - basically trying to make a working and usable system from scavenged parts, pretty well everything I did in the last 12 years (linux wise) has been using "hand me down" hardware that the Windoze server guys had discarded. This was around the time that similar discussions were being had about "what's wrong with sda, sdb, etc ?". Due to the parallel driver loading issue, it was random which interface got it's devices installed first, and so I did have devices that would be in random order at boot time - ie some boots would result in my "first" drive being sda, other boots it would be sdb.
This was easily fixed (for me) using filesystem labels instead of device names - others just accepted the opaque filesystem IDs with those very long and hard to type strings (great fun when trying to boot manually in Grub !)

I don't recall exactly that problem with network interfaces, as by the time I was working with systems susceptible to it, udev had already fixed it. What I do recall was the pain of a two-NIC system where the "active" NIC (only one cable plugged in) would be different when booted from an installer disk or live distro than when booted from the installed OS.
But that isn't the same thing really

I suppose that one REALLY good way to fix the problem (at least in the server & desktop areas) is actually to undo a lot of "progress" and make all driver and service initiation strictly linear. Ie, do away with all this parallelism and make all drivers be loaded strictly in sequence, one after the other, in a defined order. I strongly suspect that it wouldn't hugely impact boot times either.
Put another way, part of the "problem" being "solved" is actually a side effect of "improvements" made elsewhere.

marc <marcxdv@???> wrote:

> However, some time ago the authors of the reverse engineered
> nvidia ethernet driver (was it forcedeth?) noticed they had
> decoded the mac address incorrectly and fixed it in a point
> release. For me that meant a headless machine many thousands
> of kilometers away became unreachable as what was eth0 at the
> last reboot now was stuck at eth1_renamed or ens9faefas#*$? or
> whatever it was.
>
> Point is: In many cases eth0 means "the only network device
> on the system, the one we use to go online" and tieing it
> to a piece of hardware can be problematic too, as on occasion
> it gets replaced - or as per anecdode above, changes
> spontaneously, even though its function does not.

I can thing of a workaround for that.
As I've mentioned before, for non-trivial systems I tend to rename interfaces (with udev persistent rules) to meaningful names - eg ethlan, ethext, and so on). If you do that, then eth0 is always an available name (and eth1, and eth2, ... if more than one nic). So it would be quite possible to have our static network config include hotplug stanzas for eth0, eth1, etc so that if they appear, you'll get some form of networking that even if not correct for what the system should be doing, will at least allow remote access to fix it.

And that comes back to one of the arguments for NOT using eth0, eth1 etc - because that's what the system would like to name any "new" (as in, not matching descriptors for known & previously configured devices) NICs that appear.