Quoting Steve Litt ([email protected]): > 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.
It's funny you'll say that, and not just because we're both old enough that advice we got as 'wee lads' would probably have to involve sliderules. I'll get back to that, later. > That's horrible, and that *is* solved by the systemd naming scheme. 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. If you read the Freedesktop.org/systemd article on 'Predictable Network Interface Names' (https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/), you will get the impression that, without systemd's scheme, Linux systems are threatened by network interfaces suddenly coming up with new device node assignments in a totally unpredictable fashion, necessitating systemd/udev's baroque workaround to save us from chaos. And this brings to mind two immediate reservations I have: (1) If this were common, I'd expect to have encountered it fairly frequently, and I've not encountered it at all (except for reshuffles upon adding or removing relevant hardware). (2) The Freedesktop.org/systemd kiddies have a long track record of overselling the alleged problems their baroquely overengineered software supposedly fixes. I've worked with very large numbers of Linux servers over three decades. Most of those have each sported multiple ethernet NICs of the same manufacturer, model, and driver. e1000, tg3, e100, 3c905, 3c509, ne2000 {shudder}, etc. In all of those many hundreds of machines each with multiples of the same NIC/driver, over a long time, I cannot recall even a single case when, upon reboot, eth0 and eth1 suddenly swapped. Which is why I find your mentors' advice odd. I understood that, if you had a motherboard with dual e1000 NICs and suddenly added (or removed) a third ethernet port on a PCI-E card, whether it was also an e1000 NIC or not, you might expect to get a device assignment reshuffle. Therefore, if you were changing such hardware, you simply accepted that a one-time need to re-edit /etc/network/interfaces before redeployment was an implied part of the task. In exactly the same way, if you decided to throw in (or remove) a PCI-E (PCI-X, PCI, ISA, whatever) SATA/PATA/SCSI card into a system, or remove one, you would simply accept that a one-time need to re-edit /etc/fstab before redeployment was an implied part of the task. It's always been at least _possible_ that major kernel version jumps, such as 2.4.x to 2.6.x, might cause a one-time device reshuffle, and I've always been on-guard for it if conducting such an upgrade. I've not yet seen that happen (though it might). But, again, this is just a predictable part of the major-disro-upgrade task, and not an unpredictable catastrophe requiring layers of protective software to avert. When USB came along and people started using it (overusing it) as if it were reliable infrastructure, those of us who were paying attention saw immediately that it would add more of that kind of chaos, and indeed worsten it. _However_, even given that, in my experience any reshuffle USB would add to the _existing_ devices' node assignments would occur only at reboot time _if_ you left the USB device plugged in. The obvious takeaway lesson was Don't Do That, Then (to quote the old tech. support joke's punchline). Unplug the friggin' USB external hard or SSE or the USB network device before reboot, and the preexisting devices would come up exactly as planned and not render your /etc/network/interfaces and /etc/fstab contents inaccurate. I find it very telling that, when horror stories pop up about allegedly spontaneous Linux device node reshuffles, USB seems to be a recurring element: It suggests to me that the main problem isn't Linux device assignment instability at all; it's inattentive reliance on a known-problematic technology (USB) to do what it's not good for (long-term main infrastructure) instead of what it is good for (causal and light-duty device use). When I was designing my next-generation server to use a tiny, fanless Celeron box (CompuLab IntensePC) with only external RAID1-mirror storage, I went out of my way to ensure that the pair of external SSDs would be connected via eSATA rather than following the path of least resistance and using USB. Why? Because I don't trust USB for persistent infrastructure. Nor, IMO, should anyone. However, with all of the above having been said, I will be the first to admit that I might be missing something, and/or my information might be out of date. Since I'm disinclined to trust the Freedesktop.org/systemd kiddies' alleged documentation about network device naming, I looked around for something credible and relatively recent. What I found was this 2009 Dell Computer whitepaper: https://linux.dell.com/files/whitepapers/nic-enum-whitepaper.pdf Please do have a look. I'm not 100% confident of my reading of that whitepaper, but it _seems_ to support my recollection -- mostly. The bit near the end about where it says SLES 10/11 require udev rules to associate MAC addresses persistently with device node names is a bit troubling. Notice, however that the whitepaper says that RHEL even through RHEL5's accomplishment of that association via citation of MAC addresses ('HWADDR') within /etc/sysconfig/network- scripts/ifcfg-<network interface name> files suffices without udev tricks. (The whitepaper doesn't address RHEL revisions after RHEL5.) So, rather than arrogantly assert that my old-school rules of thumb still suffice in 2017, I'll ask: What new thing am I missing, that is not just a matter of expected reshuffles immediately following hardware addition/removal or (in theory) major kernel revision jumps? _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
