You think this is irritating, what about when you're trying to replicate the network configuration to failover hardware... There is a way around this, I haven't tried it on CentOS but on Ubuntu there are kernel command line parameters:
net.ifnames=1 biosdevname=0
which will override this behavior. Again, on Ubuntu these are added in /etc/default/grub as parameters to GRUB_CMDLINE_LINUX_DEFAULT. Finally, there's /udev/rules.d/70-persistent-net.rules which allows you to associate a MAC address with an eth? label. However, without the command line parameters it is ignored (contrary to other statements on the web ). Given this is CentOS you mileage will almost certainly vary but hopefully this gives you enough to go on to get to the final solution. There is a freedesktop.org web page about why they did this - it has to do with mobile devices and plug-and-play networking. Take that page's statement about setting net.ifnames=0 cautiously, I found it was the exact opposite. biosdevname is a program written by someone at Dell which is supposed to report on hardware configurations and make some sense out of the cesspool. It appears the source of the whole thing is hardware vendors doing whatever they want and in some cases not playing by the rules.
----- Original Message ----- From: "John R Pierce" pierce@hogranch.com To: centos@centos.org Sent: Thursday, December 10, 2015 4:33:24 PM Subject: Re: [CentOS] wifi on servers and fedora [was Re: 7.2 kernel panic on boot]
On 12/10/2015 1:56 PM, m.roth@5-cent.us wrote:
As a lesser example, I just*adore* the new ethernet names - NOT. Breaks scripts, makes it all more difficult, not to mention*so* much easier to guess, when you've debugging a box and your organization has hardware from many OEMs. What was wrong with eth0, or even em1?
when you have multiple adapters, perhaps different types (maybe 2 10gigE and 2 1gigE?) which one is eth0 supposed to be? BSD has always used driver type in the network device names, and having dealt with device confusions before, I understand why.