On May 08, Martin Pitt <mpitt@debian.org> wrote: > I propose to retire [mac], i. e. drop > /lib/udev/rules.d/75-persistent-net-generator.rules and enable > [ifnames] by default. I see a large enough consensus about switching by default to ifnames, and I believe that the few people who want MAC-based names for USB interfaces can easily set NamePolicy=mac or write a custom rule. I am not sure that we really need to retire 75-persistent-net-generator right now: the annoying part to maintain is the kernel patch which we will need anyway for at least a couple of releases, and once we make it use em* or eno* instead of eth* then it should be robust. It is trivial to make it opt-in by setting something like net.ifnames=0 (or even a different and specific value), and we can revisit this decision when we will be closer to the release. > So we can only let time and replacing/reinstalling machines take care > of this. /etc/udev/rules.d/70-persistent-net.rules requires zero > maintenance from us (it's just like the admin had manually set their > own rules). Actually it requires us to keep maintaining the Revert-udev-network-device-renaming patch as long as there will be systems with a 70-persistent-net.rules file renaming eth* to eth*. I believe that firmware-based device names work well enough in practice since RHEL 7 uses them by default: I tend to trust a market-based approach to maintenability more than anecdote from a very selected population like the debian-devel@ subscribers. This is the relevant documentation, which I strongly recommend everybody interested in this issue to read: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Device_Renaming_Procedure.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Predictable_Network_Interface_Device_Names.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html Maybe biosdevname would be nice to have, but: - somebody needs to actually maintain it in Debian - by default it only works on Dell systems - it is not loved by the udev/systemd upstream maintainers - it does not seem to me to provide any benefit over the firmware-based names since in practice both would use by default an interface index in the common case So I do not think that we need to care about it. An obvious downside is longer names for devices which do not provide ID_NET_NAME_ONBOARD: e.g. the WiFi card in my Dell laptop does not (wlp2s0), but the Ethernet port does (eno1). It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on my Allwinner-based ARM computer), which means that interfaces will get a mac-based name like enx028909xxxxxx. But if somebody cares about the aesthetic value of network interface names then they can probably write a custom udev rule to rename them, or keep using 75-persistent-net-generator if we can keep it around. (I believe that it would be a good idea for the ARM porters to have a look at which values are exported by their network drivers, because probably nobody else is going to work on this any time soon.) FWIW, I did a quick survey of my hardware: - HP G8: OK - HP G8 + add-on Intel card: OK (but obviously no index) - HP G8 + FlexFabric: OK - HP Gen9 + FlexFabric: stupid but will work (the SMBIOS indexes start from 49 instead of 1!) - Cisco UCS: OK - IBM BladeCenter + Emulex CNA: very broken (only eth0 has an index! I only checked biosdevname but it should not matter) - IBM Flex + Emulex CNA: broken like the BladeCenter - Some Intel-based Supermicro: OK (If any of the HP people here can find out who is responsible to fix the Gen9 BIOS then I can have my HP account manager make a business case for it. Submitting a support case would be time consuming for me and unnecessarily cruel for the support people...) -- ciao, Marco
Attachment:
pgpXQPPPhH6FT.pgp
Description: PGP signature