Linux – Why did the interface name of the wireless card change when I added a sound card

deviceslinuxnetwork-interface

Predictable network interface names are not supposed to change when hardware is added or removed. Isn't that the whole point of the naming scheme???

My wireless interface was named wlp3s0.

I installed an ASUS Xonar DX 7.1 Channels PCI Express x1 Interface Sound Card in a free PCI slot and my wireless interface name changed to wlp5s0.

The wireless card is in the same PCI slot that it was in before the sound card was installed, so why would the interface name change?!

The mobo is a GIGABYTE GA-970A-UD3, and the wireless card is an ASUS PCE-N15. The system is running Arch Linux with a stock kernel.

I'm looking for a reasonable explanation of why the interface name would change in this scenario. If there is not a good reason why the interface name would change, where do I file a bug report/who do I complain to?

It's not a big deal and the only config I needed to change was my network profile for netctl. I just think if a "predictable" network interface name isn't predictable then they completely failed at their job and this naming scheme is useless garbage!
/rant

Best Answer

Predictable network interface names are not supposed to change when hardware is added or removed. Isn't that the whole point of the naming scheme???

Long story short, this is nothing new; it's expected/intended. Therefore, you don't need to file a bug, unless you want to ask your PC-maker to support Linux better (BIOS) or the hardware manufacturer (drivers). Some options if you'd like to improve the situation for hot-plugging devices and/or go back to old naming scheme:

Disable new naming scheme for network devices with net.ifnames=0 kernel cmdline
Add biosdevname=1 kernel commandline to incorporate BIOS-provided index numbers to names
Create or edit udev rules for custom names or altered naming schemes
You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's .link file for the default policy: ln -s /dev/null /etc/systemd/network/99-default.link

If you're using systemd and/or udev, the "predictable naming scheme" argument might be different than before. Based on the naming scheme of the WiFi interface, though, I am assuming that you are using a system with systemd.

You can try appending the following boot parameter to the kernel commandline to use the "old" naming convention of network devices. However, I'm not entirely certain what, if any, additional effects this may have other than retaining the naming scheme for network devices.

net.ifnames=0

Adding it to /etc/default/grub can facilitate the persistence and reuse of this parameter; again, assuming you're using grub2:

GRUB_CMDLINE_LINUX="net.ifnames=0"

If udev uses device firmware, location and other options when determining device names, then perhaps the location or something else may have changed internally, depending on how the relevant devices interact with each other. This seems not as relevant here, as the devices are a WiFi adapter and a soundcard. Nevertheless, it may be related to the underlying bus structure; which does seem relevant, as the devices are both connected to PCI slots.

Additional info from FedoraDocs

8.1. Naming Schemes Hierarchy

By default, systemd will name interfaces using the following policy to apply the supported naming schemes:

Scheme 1: Names incorporating Firmware or BIOS provided index numbers for on-board devices (example: eno1), are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 2.
Scheme 2: Names incorporating Firmware or BIOS provided PCI Express hotplug slot index numbers (example: ens1) are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 3.
Scheme 3: Names incorporating physical location of the connector of the hardware (example: enp2s0), are applied if applicable, else falling directly back to scheme 5 in all other cases.
Scheme 4: Names incorporating interface's MAC address (example: enx78e7d1ea46da), is not used by default, but is available if the user chooses.
Scheme 5: The traditional unpredictable kernel naming scheme, is used if all other methods fail (example: eth0).

This policy, the procedure outlined above, is the default. If the system has biosdevname enabled, it will be used. Note that enabling biosdevname requires passing biosdevname=1 as a command-line parameter except in the case of a Dell system, where biosdevname will be used by default as long as it is installed. If the user has added udev rules which change the name of the kernel devices, those rules will take precedence.

Additional Resources

Related Solutions

Linux – How to Find Available Network Interfaces

The simplest method I know to list all of your interfaces is

ifconfig -a

EDIT

If you're on a system where that has been made obsolete, you can use

ip link show

Network Interface – Predictable Names Break VM Migration

Surely this is a problem that cloud providers (Azure, AWS, RackSpace, Openstack) have already solved when they import vms.

I think OpenStack uses cloud-init, ConfigDrive format, and provides a network configuration that matches the VM hardware. Sources:

If you rule out a first-boot script, there is one obvious answer.

Previously it was practically guaranteed that hosts equipped with a single ethernet card only had a single "eth0" interface. With this new scheme in place, an administrator now has to check first what the local interface name is before he can invoke commands on it where previously he had a good chance that "eth0" was the right name.

I don't like this, how do I disable this?

You basically have three options:

You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's .link file for the default policy: ln -s /dev/null /etc/systemd/network/99-default.link

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Switching back to the old persistent interface names is not one of the options documented.

The other alternative is a setup where network interfaces are enabled by default, regardless of their exact name. I think NetworkManager supports this by default. systemd-networkd can also be told to do this.

As soon as you have more than one network device for a VM, they probably need specific configuration anyway...

Outside of VM's, there is one obvious advantage of the NetworkManager-style approach: a PC might have multiple network interfaces, perhaps of different types, with only one of them being connected. For example this can be seen on some premium motherboards, or on a system where the first network interface did not work as desired and a second interface was installed at some point.