udev renaming the same hardware network i/f to different name, breaks networking and firewall

[Huygens]

My installation of Ubuntu Server 14.04 is bare metal (no virtualisation). The hardware box contains 3 network interfaces, one broadcom (not yet used) and two intel (actually one PCIe network card with 2 ports, one is currently used).

The MAC address of the intel network card is not changed, it is the "stock" MAC address. When installing Ubuntu, I choose the interface p1p2 from the Intel network card as default (and only) network interface. This is the only port at the moment with an Ethernet cable.

Last Friday I got my Btrfs filesystem corrupted, I had to do a hard reset. I thereafter upgraded to the latest kernel version (3.13.0-11, but was 3.13.0-8 before the crash). I do not know if this is something related but since then when rebooting I have no network. The reason being that udev decides to rename eth1 (the 2nd port of the intel card) to rename4 instead of p1p2. The problem is that my /etc/network/interfaces as only p1p2 configured, no rename4, this means that booting is slowed down because Ubuntu waits for p1p2 to "appear" but it won't happen as udev decide on a different naming. And once finally booted, ifconfig only reports the loopback interface, of course rename4 is not configured. Now after a power cycle or simply a reboot, sometimes udev switch back to the expected network naming so p1p2.

As a work around I had declared both p1p2 and rename4 in my interfaces configuration file, using the same settings for both. I had to duplicate the firewall rules so that they could be applied to either interfaces. The problem is that it is slowing the boot process (it is waiting 60 seconds to try to configure all network interfaces) and obviously I am ending up with either p1p2 or rename4 but not both, so each boot I have to wait.

I discarded the work around and only have p1p2 configured now and I am rebooting the machine when rename4 is "selected" by udev (rebooting until I get p1p2).

Note: it is possible that the problem was present since the beginning, but I almost did not reboot the system between the installation and the kernel update last Friday, so I cannot tell for sure if this was not existing already. Furthermore, I have tried also kernel 3.14-rc3 and I also have the problem. Finally, /var/log/dpkg.log does not report any udev update since initial installation.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: udev 204-5ubuntu11
ProcVersionSignature: Ubuntu 3.13.0-11.31-generic 3.13.3
Uname: Linux 3.13.0-11-generic x86_64
ApportVersion: 2.13.2-0ubuntu5
Architecture: amd64
Date: Mon Feb 24 09:58:57 2014
InstallationDate: Installed on 2014-02-09 (14 days ago)
InstallationMedia: Ubuntu-Server 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140208)
MachineType: HP ProLiant MicroServer
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=screen
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.13.0-11-generic root=UUID=d06b8dd1-fc10-45c9-a04b-3a303d8ccf58 ro rootflags=subvol=@ nomdmonddf nomdmonisw
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/29/2011
dmi.bios.vendor: HP
dmi.bios.version: O41
dmi.chassis.type: 7
dmi.chassis.vendor: HP
dmi.modalias: dmi:bvnHP:bvrO41:bd07/29/2011:svnHP:pnProLiantMicroServer:pvr:cvnHP:ct7:cvr:
dmi.product.name: ProLiant MicroServer
dmi.sys.vendor: HP

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Florian Engelmann (engelmann)]

even creating /etc/udev/rules.d/70-persistent-net.rules

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="2c:44:fd:81:34:84", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="em1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="2c:44:fd:81:34:85", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="em2"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="2c:44:fd:81:34:86", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="em3"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="2c:44:fd:81:34:87", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="em4"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="ac:16:2d:9b:07:4c", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="p3p1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="ac:16:2d:9b:07:4d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="p3p2"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="ac:16:2d:9b:07:4e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="p3p3"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="ac:16:2d:9b:07:4f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="p3p4"

does not fix the problem for every reboot. sometimes one of the p3p* interfaces gets renamed to rename{1..9} and another one gets it's p3p* name.

[Florian Engelmann (engelmann)]

adding also

net.ifnames=1 biosdevname=0

to the kernel cmdline fixed the problem

[Huygens (huygens-25)]

Hi Florian,

The kernel boot parameters are working but are also reverting to the "old" scheme for network naming. So my 3 network interfaces are now named eth0, eth1 and eth2 instead of em1, p1p1 and p1p2.
It is a work around which I can use for the time being. But I would like to switch to the new naming if possible.
So it would be good that this bug is resolved.

Note: the package name of the bug report refers to systemd. I am still using the default/stock upstart init system. But it comes together with udev. I am not sure if this bug is correctly categorised then.

[Florian Engelmann (engelmann)]

Hi Huygens,

sorry I am not maintaining this package. I just wanted to share my workaround. I hope someone is assigned soon to fix this thing.

You are able to rename your NICs by creating a etc/udev/rules.d/70-persistent-net.rules files like I described two posts above.

[Alberto Salvia Novella (es20490446e)]

It affects an essential hardware component (disk controller, built-in networking, video card, keyboard, mouse).

[Huygens (huygens-25)]

One more information that could hopefully help the investigation.

I have 3 network interfaces (em1, p1p1 and p1p2) but today I only use one (p1p2) the 2 others do not even have a cable plugged in.

So only p1p2 is configured to be up with a DHCP configuration and some firewall rules.

And guess what, only p1p2 is "renamed" the 2 other unused interfaces are *never* renamed!?!

Maybe that help tracking down the problem.

[Tom van Leeuwen (tom-vleeuwen)]

I don't feel this bug report is a duplicate of bug #1293633. I may very well fail to see the relation, but please enlight me then :-)

I've just installed 14.04 beta2 and setup a bond0 interface. After a reboot the server came online but the bond missed an interface because it was not existing.

I dumped the ifconfig information and rebooted. After a reboot ifconfig showed different devices.
Pre reboot:
bond0 Link encap:Ethernet HWaddr 68:b5:99:77:c5:8c
em1 Link encap:Ethernet HWaddr 68:b5:99:77:c5:8c
em3 Link encap:Ethernet HWaddr 68:b5:99:77:c5:92
lo Link encap:Local Loopback
p2p1 Link encap:Ethernet HWaddr 00:9c:02:3c:b0:40
p3p1 Link encap:Ethernet HWaddr 1c:c1:de:7b:b5:e0
p3p2 Link encap:Ethernet HWaddr 1c:c1:de:7b:b5:e2
rename3 Link encap:Ethernet HWaddr 68:b5:99:77:c5:8e
rename4 Link encap:Ethernet HWaddr 68:b5:99:77:c5:90
rename9 Link encap:Ethernet HWaddr 00:9c:02:3c:b0:44

Post reboot:
bond0 Link encap:Ethernet HWaddr 68:b5:99:77:c5:8c
em1 Link encap:Ethernet HWaddr 68:b5:99:77:c5:8c
em3 Link encap:Ethernet HWaddr 68:b5:99:77:c5:90
em4 Link encap:Ethernet HWaddr 68:b5:99:77:c5:92
lo Link encap:Local Loopback
p2p1 Link encap:Ethernet HWaddr 00:9c:02:3c:b0:40
p2p2 Link encap:Ethernet HWaddr 00:9c:02:3c:b0:44
p3p1 Link encap:Ethernet HWaddr 1c:c1:de:7b:b5:e0
rename3 Link encap:Ethernet HWaddr 68:b5:99:77:c5:8e
rename7 Link encap:Ethernet HWaddr 1c:c1:de:7b:b5:e2

The installation I did:
ubuntu-14.04-beta2-server-amd64.iso
choose openssh in the package selection

Afterwards I installed ifenslave-2.6 and did an apt-get dist-upgrade.
That's it.

Please note this is not an April's fool joke :-)

[Huygens (huygens-25)]

We are now 2nd of April, and I also think that this bug is not a duplicate of the other one.

I am totally fine not having eth0 and I personnally prefer the new naming convention with p1p2 and the sort.

And if the other bug is fixed, so that eth0 is used as a link to p1p1, then how this will help me if this is all renamed to rename1?

My problem is that on each boot the same network hardware does not end up with the same device name. I don't want (or need) to have a symbolic link from eth0 to p1p1 (or vice versa). I just want that the device named p1p1 is still called the same after the next reboot.

If we cannot have a deterministic device naming for network cards, then how can we configure DHCP or manual IP address for each network interface, or firewall?

[Huygens (huygens-25)]

Sorry, but as there was no counter argument why this could have been indeed a duplicate, I have taken the liberty to revert the change.
Please, if you still think it is a duplicate, first try to argument why. Once we agree, then we can find the right conclusion for this bug.
:-)
Sincerely yours.

[Martin Pitt (pitti)]

It's still the same bug *shrug*. The "em1", "p1p3" stuff etc. is from biosdevname which the server installs by default. So these names are quite intended.

[Dave (dlgawley)]

From the looks of it, biosdevname gets the name right when it's called. I'll admit I haven't taken the time to get the source let alone read it, however, it seems to be following this strategy:

1.) rename "ethXX" devices to a "renameYY" temporary name
2.) then rename "renameYY" temporary name to the `biosdevname` name.

The problem that I'm seeing is that step 2 doesn't always happen nor is the failure of it not happening consistant.

ie here's the results of "lshw-businfo -C network" from two identical pieces of hardware with fresh installs of "Ubuntu 14.04 beta2" with a full "apt-get update && apt-get dist-upgrade" applied this morning:

Host_A# lshw -businfo -C network
Bus info Device Class Description
===================================================
pci@0000:04:00.0 em1 network NX3031 Multifunction 1/10-Gigabit Server Adapter
pci@0000:04:00.1 em2 network NX3031 Multifunction 1/10-Gigabit Server Adapter
pci@0000:04:00.2 rename6 network NX3031 Multifunction 1/10-Gigabit Server Adapter
pci@0000:04:00.3 em3 network NX3031 Multifunction 1/10-Gigabit Server Adapter
pci@0000:44:00.0 p8p1 network OneConnect 10Gb NIC (be3)
pci@0000:44:00.1 p8p2 network OneConnect 10Gb NIC (be3)
pci@0000:47:00.0 p7p1 network MT27500 Family [ConnectX-3]
Bost_A#

Host_B# lshw -businfo -C network
Bus info Device Class Description
===================================================
pci@0000:04:00.0 em1 network NX3031 Multifunction 1/10-Gigabit Server
pci@0000:04:00.1 rename7 network NX3031 Multifunction 1/10-Gigabit Server
pci@0000:04:00.2 rename8 network NX3031 Multifunction 1/10-Gigabit Server
pci@0000:04:00.3 em2 network NX3031 Multifunction 1/10-Gigabit Server
pci@0000:44:00.0 p8p1 network OneConnect 10Gb NIC (be3)
pci@0000:44:00.1 p8p2 network OneConnect 10Gb NIC (be3)
pci@0000:47:00.0 p7p1 network MT27500 Family [ConnectX-3]
Host_B#

Note the resulting name differences in the embedded Nic device (NX3031 Multifunction 1/10-Gigabit Server)

There is a second problem that "lshw" is not seeing the second port of the MT27500 Family [ConnectX-3] dual port Mellanox CS314A card. (don't know if it's related or not).

[Dave (dlgawley)]

Should have also added that for these hosts, biosdevname returns the expected result (factoring in the pci slot location) :

Host_A# biosdevname -i rename6
em3
Host_A#

Host_B # biosdevname -i rename7
em2
Host_B# biosdevname -i rename8
em3
HostB#

[Jean-Daniel Bussy (silversurfer972)]

I confirm that set the following to /etc/default/grub fixed the problem:
GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=1 biosdevname=0"
followed by
sudo update-grub
and setup the naming in
/etc/udev/rules.d/70-persistent-net.rules

Before:
# lshw -businfo -C network
Bus info Device Class Description
===================================================
pci@0000:03:00.0 em1 network NetXtreme II BCM5709 Gigabit Ethernet
pci@0000:03:00.1 em2 network NetXtreme II BCM5709 Gigabit Ethernet
pci@0000:04:00.0 em3 network NetXtreme II BCM5709 Gigabit Ethernet
pci@0000:04:00.1 rename5 network NetXtreme II BCM5709 Gigabit Ethernet

After:
# lshw -businfo -C network
Bus info Device Class Description
================================================
pci@0000:03:00.0 em1 network NetXtreme II BCM5709 Gigabit Ethernet
pci@0000:03:00.1 em2 network NetXtreme II BCM5709 Gigabit Ethernet
pci@0000:04:00.0 em3 network NetXtreme II BCM5709 Gigabit Ethernet
pci@0000:04:00.1 em4 network NetXtreme II BCM5709 Gigabit Ethernet

For those wondering about the change in interface naming:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

[fedupwithjunk (fedupwithjunk)]

I am going nuts over this, I get the predictable name stuff but the change seems to be random.

On first reboot the names are different. eth0 renamed to p4p1 and eth1 renamed to p4p2

then on next reboot eth0 renamed to p4p1 and eth1 renamed to rename3

Whats predictable about that?

I was happy with eth0 and eth1, all my software was happy with eth0 and eth1, all my documentation refers to eth0 and eth1, so I thought lets uninstall biosdevname and stick with the original names. ....

That didn't work, I still get random names as above. Also in 14.04 ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules does not disable this behavior as indicated in the link above

I have just had to delete what I wrote here as I do not want to be rude to anyone and I live in hope that one day we will make the world a better place.

[Tom van Leeuwen (tom-vleeuwen)]

I did the suggestion:

$ grep GRUB_CMDLINE_LINUX_DEFAULT /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=1 biosdevname=0"

followed by update-grub.

Since then rebooting gives consequent eth* naming.
I have no udev rules:

$ ls /etc/udev/rules.d/
README

Not sure if this helps any.

[Vytenis Silgalis (vsilgalis)]

Currently running into the same issue on a HP DL360 G7, it is randomly renaming on one boot eth1 on another boot eth2, on another boot eth3, etc. Entirely unpredictable so far.

i did the grub fix and it we are working with legacy ethX names.

[Jean-Daniel Bussy (silversurfer972)]

It brings you the legacy ethX names.
It's up to you to write the naming you want in /etc/udev/rules.d/70-persistent-net.rules

I wrote the following:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e8:39:35:b2:04:d0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="em1"

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e8:39:35:b2:04:d2", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="em2"

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e8:39:35:b2:04:d8", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="em3"

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e8:39:35:b2:04:da", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="em4"

[yossarian_uk (morgancoxuk)]

Also effected me also on HP ProLiant DL160 G6

wrote udev file and enabled ' net.ifnames=1 biosdevname=0' as recommended - that fixed it.

Is this just effecting HP hardware?

[jtaguinerd (joannaliza)]

I am having the same issue with Dell R515

root@blacksea:~# lshw -businfo -C network
Bus info Device Class Description
====================================================
pci@0000:01:00.0 p3p1 network 82576 Gigabit Network Connection
pci@0000:01:00.1 rename7 network 82576 Gigabit Network Connection
pci@0000:03:00.0 em1 network NetXtreme II BCM5716 Gigabit Ethernet
pci@0000:03:00.1 em2 network NetXtreme II BCM5716 Gigabit Ethernet
pci@0000:04:00.0 p1p1 network 82599ES 10-Gigabit SFI/SFP+ Network Con
pci@0000:04:00.1 p1p2 network 82599ES 10-Gigabit SFI/SFP+ Network Con

[Eggsome (eggsome)]

This is happening for me on an HP/Compaq ProLiant DL180 G6

$ sudo lshw -businfo -C network
Bus info Device Class Description
===================================================
pci@0000:07:00.0 em1 network 82576 Gigabit Network Connection
pci@0000:07:00.1 em2 network 82576 Gigabit Network Connection
                  bond0 network Ethernet interface

em2 randomly sometimes appears as "rename3" at boot time.

[Jacek Nykis (jacekn)]

Could this be a race condition?

# biosdevname -i em1
em1
# biosdevname -i em2
em3
# biosdevname -i em3
em4
# biosdevname -i rename3
em2

# lshw -businfo -C network
Bus info Device Class Description
====================================================
pci@0000:03:00.0 em1 network NetXtreme II BCM5709 Gigabit Ethernet
pci@0000:03:00.1 rename3 network NetXtreme II BCM5709 Gigabit Ethernet
pci@0000:04:00.0 em2 network NetXtreme II BCM5709 Gigabit Ethernet
pci@0000:04:00.1 em3 network NetXtreme II BCM5709 Gigabit Ethernet

Not sure if relevant but the server in HP ProLiant DL380 G7

[Matt (l-matts)]

We are having this issue on multiple Dell PE 12g servers. It seems to specifically be an issue if there are two quad port NICs installed (the last NIC shows up as "rename8"). If the second NIC is disabled or it is a single NIC system, this problem doesn't manifest itself. We have Intel I350s as provisioned by Dell.

[Huygens (huygens-25)]

@Matt I only have 1 card with dual-ports, but it is also a i350.
The Broadcom embedded card (on the motherboard of my HP server) has never had the problem of being wrongly renamed.
Only the Intel one has issue.

[Jorge Niedbalski (niedbalski)]

Hello guys,

Does anybody is able to try this biosdevname package?

https://launchpad.net/~niedbalski/+archive/fix-biosdevname-testing-1323863/+files/biosdevname_0.4.1-0ubuntu7_amd64.deb

Or use the PPA: ppa:niedbalski/fix-biosdevname-testing-1323863

Please let me know if this fix your reported problem prior to introduce an official bug fix.

[Luke Watson (lukeaw)]

I am also affected by this bug. I have an HP ML110 G7 server with an Intel Gigabit ET Quad Port Server Adapter.

The on-board interfaces are always named correctly (em0 and em1), however the interfaces on the NIC aren't. There's normally three named p2p# (which are sometimes incorrect in that p2p1 may actually be p2p3) and one interface named rename#.

This feels very much like a race condition; once the system is booted up I am able to remove and re-add the kernel module as follows:

sudo modprobe -r igb
sudo modprobe igb

All of my interfaces are thereafter named correctly, until the next reboot.

[Jay Faulkner (jason-oldos)]

Jorge,

I was experiencing this exact bug as described by several others. I installed your biosdevname package from the ppa and then rebooted ten times without seeing the issue again.

I think it's safe to say it fixed my bug. Let me know when this is going to be released into 14.04. Thanks!

[Jacek Nykis (jacekn)]

Jorge,

Confirmed, your package fixed the bug for me as well.

[Mike Zupan (u6pb)]

Jorge,

This package also solved my issues with renaming interfaces on boot

[Luke Watson (lukeaw)]

Works for me too. Thanks Jorge!

[Shang Wu (shangwu)]

This patch has fixes the issue for us too! Thanks!

[Toby Corkindale (tjc-wintrmute)]

Are we definitely sure this is a duplicate?
I just mention because I'm seeing it on some servers currently, and biosdevname reports the correct bios name for each device, even though the kernel name has ended up at renameX.

For example:
# biosdevname -i rename3
p1p2

[Bryan Quigley (bryanquigley)]

@toby
Yes, pretty sure... what you describe in your comment is the other bug as well.. unless I'm missing something. Watch when it goes to -proposed to confirm.

[Rickard Armiento (ubuntu-armiento)]

I saw this bug for the first time today on a HP ProLiant DL140 G3. First interface correctly named 'em1', second one came up as 'rename3' instead of expected 'em2'.

Jorge's updated biosdevname package solved the issue. Thanks! This should

[Matt (l-matts)]

Another +1 for the biosdevname patch from Jorge. Worked great on our 12g Dell servers with Intel I350s.

[Marcantonio (marcantonio)]

+1 for Jorge's patch.

[Peter Maloney (peter-maloney)]

FYI: for working udev rules...

An example from above:

 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="ac:16:2d:9b:07:4f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="p3p4"

But I found that using it that way will not fix the case where a device is randomly named "renameX" on boot.. But if you remove all the optional bits from the line, it works reliably:

 SUBSYSTEM=="net", ATTR{address}=="ac:16:2d:9b:07:4f", NAME="p3p4"

My guess it that it doesn't think the "rename#" ones match the other criteria. So just use MAC, which is unique.

[Alex (oooo1)]

So strange, after ungrade to 3.13.0-30 version only set up GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=1 biosdevname=0" at /etc/default/grub helped.
Even fixed biosdevname had stopped to work.
Ubuntu is 32-bit.

[Philip Orleans (venefax)]

This is a huge bug and not a duplicate and yet it has no solution. I use ubuntu 14.04.
None of the solutions works all the time. In a virtual machine with 10 nics, the booting algorithm changes the PCI number all the time, it seems, so we need to match the name via the mac address.
I have not found a way to do this that works flawlessly
Can somebody from Canonical take this seriously?

[Robert Lockwood (rnlockwood)]

I'm having the same problem in that during boot eth0 is first renamed em1 for one NIC and then eth0 for my second NIC is renamed p3p. Sometimes one is first and sometimes the other but the names always correspond with the correct address. Only one of them works, though.

I'm about to try adding /etc/udev/rules.d/70-persistent-net.rules and then modifying grub. My grub has a line:
GRUB_CMDLINE_LINUX_DEFAULT="text"

Which do I do, replace that line or add the new line?

GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=1 biosdevname=0"

[Steve Buzonas (steve-buzonas)]

Adding information for individuals coming here because they get a `rename*` device as a bonding slave. You can't use 70-persistent-net.rules if you're matching on MAC address and are using a bonding mode that gives all slaves the same MAC.

[Locane (locane)]

How is this not fixed yet? We're having the same issue deploying Ubuntu 14.04 to 28x systems. The network adapters are getting random names under the new convention. It's been almost a year.

[nmgeek (oznelg)]

Reiterating comment from steve-buzonas:

You get `rename*` interface names if you have a 70-persistent-net.rules file which calls out the MAC address of any bonded ethernet port. The cascade of udev renaming that happens when those interfaces are bonded does not respect _any_ rules in the udev rules file (must be bug, right?).
This happens even if biosdevname is not installed. Adding `net.ifnames=1` to the kernel invocation command line will not fix the problem.

To fix the problem remove any rules from the 70-persistent-net.rules file that reference MAC addresses of slave interfaces which are part of a bonded interface configured in your `interfaces` configuration file. After I did this those interfaces were assigned consistent `eth*` interface names.

Perhaps there is a way to use udev rules that match some PCI device identifier instead of a MAC address. That would be an excellent solution but since I resolved my problem by removing the offending rules I have not investigated this approach.

[Allan MacLeod (aemacleod)]

I am experiencing this bug on a Raspberry Pi 3 Model B running 16.04. I am getting the image from https://wiki.ubuntu.com/ARM/RaspberryPi (direct link: http://www.finnie.org/software/raspberrypi/ubuntu-rpi3/ubuntu-16.04-preinstalled-server-armhf+raspi3.img.xz ) and it works out of the box, but this bug appears after doing sudo apt-get update and rebooting.

[Rich Wales (richw)]

The first answer (from Sebastian Marsching) on this page worked for me:
https://askubuntu.com/questions/767786/changing-network-interfaces-name-ubuntu-16-04

In brief, he recommended removing the KERNEL=="eth*" parameter from each line in the /etc/udev/rules.d/70-persistent-net.rules file.

I am running 16.04.1 on several x86_64 systems, and I want / need / insist upon custom names of my own choosing for the various network interfaces -- such as "grn" (green) for LAN interfaces, and "red" for WAN. This allows me, for example, to configure firewall rules (via Shorewall) in a consistent manner on all systems. I understand the motivation behind both of the old (eth0) and new (p1p2) naming styles, and I'm not objecting to people using either of these as long as the custom option (by tweaking 70-persistent-net.rules) is still available as well.

Here is a sample 70-persistent-net.rules file from one of my servers -- again, this box is running 16.04.1:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="40:16:7e:b4:45:f8", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="grn"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:18:f8:0e:7b:e1", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="red"

and the relevant line from this server's /etc/default/grub file is:

GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=1 biosdevname=0"

and the network interfaces are in fact named "grn" and "red" (as confirmed via "ifconfig").

[Poil (poil)]

Thanks Jorge Niedbalski (niedbalski) @wrote on 2014-05-28, with your patch all is working

[Spike (spike-4)]

just to add a data point:

Contrary to most ppl who posted so far I have Supermicro hardware, not HP and still see the same issue. This is happening on ubuntu xenial 16.04, both with a server install CD but also an installed system if I pull a disk from another server. In neither case I have biosdevname installed.

The interesting/funny/annoying this is that two very similar supermicro machines with the same intel i350 card work just fine. On the box where it breaks you can see from udev that the names selected where indeed conflicting:

P: /devices/pci0000:00/0000:00:1c.0/0000:06:00.0/net/rename2
E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:06:00.0/net/rename2
E: ID_BUS=pci
E: ID_MODEL_FROM_DATABASE=I350 Gigabit Network Connection
E: ID_MODEL_ID=0x1521
E: ID_NET_DRIVER=igb
E: ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
E: ID_NET_NAME_ONBOARD=eno1
E: ID_NET_NAME_PATH=enp6s0f0
--
P: /devices/pci0000:00/0000:00:1c.0/0000:06:00.1/net/rename3
E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:06:00.1/net/rename3
E: ID_BUS=pci
E: ID_MODEL_FROM_DATABASE=I350 Gigabit Network Connection
E: ID_MODEL_ID=0x1521
E: ID_NET_DRIVER=igb
E: ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
E: ID_NET_NAME_ONBOARD=eno1
E: ID_NET_NAME_PATH=enp6s0f1
--
P: /devices/pci0000:00/0000:00:1c.0/0000:06:00.2/net/eno1
E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:06:00.2/net/eno1
E: ID_BUS=pci
E: ID_MODEL_FROM_DATABASE=I350 Gigabit Network Connection
E: ID_MODEL_ID=0x1521
E: ID_NET_DRIVER=igb
E: ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
E: ID_NET_NAME_ONBOARD=eno1
E: ID_NET_NAME_PATH=enp6s0f2
--
P: /devices/pci0000:00/0000:00:1c.0/0000:06:00.3/net/rename5
E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:06:00.3/net/rename5
E: ID_BUS=pci
E: ID_MODEL_FROM_DATABASE=I350 Gigabit Network Connection
E: ID_MODEL_ID=0x1521
E: ID_NET_DRIVER=igb
E: ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
E: ID_NET_NAME_ONBOARD=eno1
E: ID_NET_NAME_PATH=enp6s0f3

Notice that for all of them ID_NET_NAME_ONBOARD=eno1 . This is correct from systemd perpsective since there is one card on this box and it's onboard. /lib/systemd/network/99-default.link does indeed specifty onboard before path which means all cards would end up being called eno1. Since this can't be true, the first one gets eno1, which is the case, and the remainder get renamed to "renameX".

On the boxes where this works it turns out that the ID_NET_NAME_ONBOARD is not set. Why that's the case I don't get it, it's almost the same mobo and definitely with the same onboard NIC... but that's why. I tried to change the order in /lib/systemd/network/99-default.link but for some reason that didn't help.

hope that helps someone,

Spike

[Toby Smithe (tsmithe)]

This bug also affects me, on an Intel I350 device (driver igb). Bizarre that the active interface is almost unstoppably being renamed "rename2", and very inelegant these hacks that are required to patch over the issue!

[max (ichiemo)]

I am also having the same problem in Ubuntu 18.04.1 with multiple network interfaces getting renamed consistently after reboots and complete shutdowns. All four network interfaces are from an Intel I350 device built into a Supermicro X9DRI-LN4F+ motherboard. Only 1 interface of the 4 is named eno1 the other 3 are a variation of renameX and all 4 interfaces are consistently switching names or getting new and higher numbered renameX which then screws up my network configuration for this machine.