I can understand it making sense in the context of a server with multiple interfaces. We used to have occasional problems with ethernet enumeration when we were using recycled PCs as gateway routers. I just don't see why that kind of corner case drove adoption for a problem that didn't exist for 99% of users. Seems to me like "predictable" names ought to be an opt-in rather than an opt-out.
-- Russell Senior [email protected] On Sun, Feb 14, 2021 at 9:37 PM Ben Koenig <[email protected]> wrote: > > Just some thoughts... If I'm reading the document on freedesktop.org > correctly then this new system does not actually solve the problem it > claims to be solving. Specifically this part here: > > > "...The following different naming schemes for network interfaces are > now supported by udev natively: > > 1. Names incorporating Firmware/BIOS provided index numbers for > on-board devices (example: eno1) > 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot > index numbers (example: ens1) > 3. Names incorporating physical/geographical location of the connector > of the hardware (example: enp2s0) > 4. Names incorporating the interfaces's MAC address (example: > enx78e7d1ea46da) > 5. Classic, unpredictable kernel-native ethX naming (example: eth0) > > By default, systemd v197 will now name interfaces following policy 1) if > that information from the firmware is applicable and available, falling > back to 2) if that information from the firmware is applicable and > available, falling back to 3) if applicable, falling back to 5) in all > other cases. Policy 4) is not used by default, but is available if the > user chooses so." > > > End quote. The whole problem is that the eth# is designated by the order > in which hardware is enumerated. This is unpredictable. However, relying > on the firmware/BIOS to define index numbers and falling back if not > properly defined is also unpredictable. Not only will this change from > one hardware configuration to the next but it is also subject to change > for a very large number of different reasons. > > > They are essentially removing an unpredictable system and replacing it > with another unpredictable system. I would argue that the old way is > actually better because of the simplicity of how it decides. Going with > the new process you now have to ask an additional question about the > nature of your hardware and such information may not be readily available. > > > Problem remains unsolved. Whoever funded the development of this feature > should probably ask for their money back. Unless of course their goal > was to destablize the Linux platform, in which case, Good Job! > > -Ben > > > > On 2/14/21 1:00 PM, Chuck Hast wrote: > > I too have never figured out what was gained by going to > > "predictable names" as far as I am concerned it is the > > definition of oxymoron. I always knew what eth0 or eth1 > > or whatever the original names were, these things though > > on a given machine will USUALLY come up the same but > > they change from machine to machine. I have 3 machines > > here and all 3 of them have different names for eth0.... > > > > As they say in Costa Rica "predictable names" turas... > > > > > > On Sat, Feb 13, 2021 at 8:33 PM Russell Senior <[email protected]> > > wrote: > > > >> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ > >> > >> Given the plenitude of schemes (!) that are supported, this system > >> deserves the word "predictable" about as much as USB deserves the word > >> "universal". > >> > >> On Sat, Feb 13, 2021 at 6:28 PM Russell Senior > >> <[email protected]> wrote: > >>>> There are ways to rename the interface back to eth0, but > >>>> I assume this breaks other things, > >>> It doesn't break anything. I routinely turn off the silly "predictable" > >> names. > >>> I use the technique of adding: > >>> > >>> GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0" > >>> > >>> to my /etc/default/grub file, and after running: > >>> > >>> sudo update-grub2 (or equivalent) you are good for the long haul. > >> _______________________________________________ > >> PLUG: https://pdxlinux.org > >> PLUG mailing list > >> [email protected] > >> http://lists.pdxlinux.org/mailman/listinfo/plug > >> > > > _______________________________________________ > PLUG: https://pdxlinux.org > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug _______________________________________________ PLUG: https://pdxlinux.org PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
