All, Udev 197, which is in ~arch currently, has a feature they are calling predictable network interface names (see URL). Obviously, I am opting out of this on live systems. Once users understand it, they will be able to opt in very easily. In the section of the wiki page describing this, take note of the section called "Come again, what good does this do?". This is the udev author's justification for the new scheme. The big advantage of this scheme is that network interface names will be stable across reboots, kernel upgrades, etc, and the eth* and wlan* names are not stable as soon as you have multiple interfaces. The disadvantage is that in the documentation we will not know specifically what the name of the interface is that will appear on the users system. For example, my current network interface, which was eth0, is now enp1s5. This would be the path I prefer, I'm just not sure how we should document it. Jorge proposed that we keep the old scheme on the cds, but allow the new scheme in the stages. The disadvantage here is that it would require adding documentation to chapter 8 explaining to users how to either disable the scheme themselves before they reboot their system the first time, or explaining how to look up the new interface names and use those names when they configure their interfaces in this chapter. The third proposal would be to opt out of the new scheme, both in the CDs and in stages. I would be against this, because it means that we are not moving to the new names, which I do think have some advantages. What are your thoughts?
I feel that it would be bad to have the interface names be different between the livecd and a freshly installed system.
(In reply to comment #1) > I feel that it would be bad to have the interface names be different between > the livecd and a freshly installed system. I Agree with this. that is why I think adopting the new names for new installs is the best choice.
Does this mean that with the recent udev the interface names are automatically changed? Or will it continue to support the current ethX naming and only provide a second alias-alike name towards the interface?
If possible, I would rather consider using the current naming scheme (especially by default as to not confuse users who are used to the many-years-old naming for interfaces) and see where things are going with this. It would be even better if one can fix the interface name while keeping the current naming scheme?
Going to follow up on this through bug #466262 *** This bug has been marked as a duplicate of bug 466262 ***
