Failed to start Raise network interfaces after upgrading to 16.04

Question

I just upgraded a virtual 14.04 server machine to 16.04. After rebooting the VM I see the following error:

[FAILED] Failed to start Raise network interfaces.
 See 'systemctl status networking.service' for details

After login I can run the mentioned command and get the following output (image as I'm not able to connect):

The configuration in /etc/network/interfaces looks fine - featuring the manually configured eth0 (not using dhcp here)

What makes me wondering is that ifconfig -a lists

• ens160
• lo

Where I would expect

• eth0
• lo

Trying to up the eth0 device via

sudo ifup -v eth0 

outputs:

...
Cannot find device "eth0"
Failed to bring up eth0.

The virtual wired network device itself is still configured in the VM itself as it was before.

ip link shows as well lo and ens160 - where ens160 has the mac address configured in vmware for the single configured virtual network device.

UPDATE

I am able to solve the issue if i change all references of eth0 in /etc/network/interfaces to ens160.

BUT - this feels wrong for me for several reasons:

1. I would like to understand this problem
2. I would like to stick to eth0 instead of ens160

So please can someone explain this change, which didn't happen to several other 14.04 machines on the same server which I also upgraded to 16.04.

Solution 1

Reason

The problem was caused by Predictable-Network-Interface-Names from systemd/udev.

Possible solution

According to this source you can either:

• You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules
• You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own .link files in /etc/systemd/network/, that choose an explicit name or a better naming scheme for one, some, or all of your interfaces. See systemd.link(5) for more information.
• You pass the net.ifnames=0 on the kernel command line

Applied solutions

I did create a new file 10-rename-network.rules in /etc/udev/rules.d/ and added the following content to it:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="ff:ff:ff:ff:ff:ff", NAME="eth0"

where

• eth0 = desired network interface name, used in /etc/network/interfaces
• ff:ff:ff:ff:ff:ff = hardware mac address of the network device

I'd recommend rebooting after completing this to make sure the change is sticky.

Solution 2

Solved by changing file /etc/network/interfaces.d/setup from:

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp

to:

auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet dhcp

Solution 3

In my case this problem was related to trying to bring up my bridge br0. I had forgotten to do this:

sudo apt-get install bridge-utils

before and so my adapter couldn't get started.

Comments

[dufte]

Might be duplicate to: askubuntu.com/questions/704361/…

[theINtoy]

A similar description of the fix is here: askubuntu.com/a/830163/543586

[Zanna]

This is different from OP's problem. I'm not sure this answer belongs to this question!

[Aneel]

I discovered I had to run update-initramfs -u to get my changes to take effect

[jeremiah]

On my Debian system the file is '/etc/udev/rules.d/70-persistent-net.rules'

[styks]

I missed the /etc/network/interfaces.d/setup and assumed interfaces

[Timo]

Why not enter this data with allow-hotplug directly in /etc/network/interfaces?

[Timo]

@Aneel does your update code work for the upredictable kernel names in solution 1? Seems not.

[Timo]

My impression is that you can stick with your "old" device name such as wlan0 in 10-rename-network.rules and do not have to "invent" one.

[talsibony]

worked like a magic thanks!