# [SOLVED] interface eth0 does not exist (udev issue)

## dead_parrot

Hi,

I have installed Gentoo (3.7.10) with the following problem:

```
* Bringing up interface eth0

 *   ERROR: interface eth0 does not exist

 *   Ensure that you have loaded the correct kernel module for your hardware

 * ERROR: net.eth0 failed to start

 * ERROR: cannot start netmount as net.eth0 would not start 
```

I compared the network configuration with the manual http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=8 -was OK

Kernel module forcedeth was loaded.

I tried to run dhcpcd manually and it created following interface 

```
enp0s5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
```

What's going on? Kernel configuration or udev?Last edited by dead_parrot on Mon May 06, 2013 8:30 pm; edited 1 time in total

----------

## NeddySeagoon

dead_parrot,

udev has renamed your eth0 to enp0s5 at no extra cost.

You can fix its rules to leave eth0 alone or you can change eth0 to enp0s5 everywhere.

----------

## miket

 *dead_parrot wrote:*   

> Hi,

 

You've got the perfect username for this.  Cue Monty Python: Bloody parrot, bloody bird, ... bloody udev!

 *dead_parrot wrote:*   

> I have installed Gentoo (3.7.10) with the following problem:
> 
> ```
> * Bringing up interface eth0
> 
> ...

 

Let me guess--you're doing your first Gentoo installation.  My apologies to you on behalf of the Gentoo community.  You landed in the middle of a big controversy.  Whereas users had long been told to look for the eth0 interface, and whereas documentation you find in all kinds of places talks about eth0, the upstream responsible for udev thinks it's important to overturn the world, and Gentoo maintainers have taken it on to propagate these changes into Gentoo without even allowing for enough time to adjust the installation documentation.

 *dead_parrot wrote:*   

> I tried to run dhcpcd manually and it created following interface enp0s5

 

That's the incredibly stupid default that you get.  It reflects the fact that your interface is plugged into PCI bus 0, slot 5.  If you move it somewhere else, the name changes.  Hooray!

A lot of us are up in arms about this!  If you've got a single interface, there is a fairly simple solution:  put an empty file at /etc/lib/udev/rules.d/80-net-name-slot.rules and reboot you'll get the sane eth0 interface name.

EDIT:  I had written the incorrect path for /etc/lib/udev/rules.d/80-net-name-slot.rules

There are definite reasons to have made a change in device naming which I won't get into here, but their default renaming rule is sold as being "predictable".  That is the precise word they use even though it is the epitome of unpredictablity unless you promise never to move your NIC to another slot.  There are other rules you can use--it is a bit harder to set up--but better down the road.

Good luck on the rest of your installation.Last edited by miket on Sat Apr 27, 2013 10:00 pm; edited 1 time in total

----------

## sitquietly

 *miket wrote:*   

> .....
> 
>  *dead_parrot wrote:*   I tried to run dhcpcd manually and it created following interface enp0s5 
> 
> That's the incredibly stupid default that you get.  It reflects the fact that your interface is plugged into PCI bus 0, slot 5.  If you move it somewhere else, the name changes.....

 

F**k!  I just caught on.   :Sad: 

I guess that's weird enough to laugh at  :Very Happy: 

Thanks for making it clear for me.

----------

## Hu

 *miket wrote:*   

> If you've got a single interface, there is a fairly simple solution:  put an empty file at /usr/lib/udev/rules.d/80-net-name-slot.rules

 Are you sure about that path?  The news says to use /etc/udev/rules.d/80-net-name-slot.rules.  All my machines use the /etc name and enjoy their predictable name of eth0 instead of bizarre slot-based naming.

----------

## miket

 *Hu wrote:*   

>  *miket wrote:*   If you've got a single interface, there is a fairly simple solution:  put an empty file at /usr/lib/udev/rules.d/80-net-name-slot.rules Are you sure about that path?  The news says to use /etc/udev/rules.d/80-net-name-slot.rules.  All my machines use the /etc name and enjoy their predictable name of eth0 instead of bizarre slot-based naming.

 

Egg on my face!  You're right.  I'll edit my response lest anyone get led astray.  Thank you.

----------

## dead_parrot

Thanks to all of you for the answer and especially to miket for his exhaustive explanation. I have created 80-net-name-slot.rules and it works. 

Before I flag this threat as solved, I would like to ask one more thing. In general, there are two types of solutions: one with the  80-net-name-slot.rules file and the second, mentioned by NeddySeagoon, to replace eth0 with enp0s5. What are advantages/disadvantages of any of them? 

Is a change of the naming convention a bigger plan or just a side effect?

----------

## Fitzcarraldo

Actually, there's also a third solution: rename all interfaces to e.g. netX (https://forums.gentoo.org/viewtopic-p-7244030.html#7244030).

----------

## NeddySeagoon

dead_parrot,

If you only have a single network card its a case of being aware of the naming convention in use.

If you add network cards, replace network cards, or move your network card from slot to slot, you need to conside the pros and cons.

The kernel names eth0, eth1 ... are allocated in PCI bus scan order. So if you add a card, before your present card, eth0 can become eth1.

Old udev had code/rules to fix the names based on the MAC address, so that this didn't happen but it meant that it had to be able to swap kernel names around.  Swapping kernel names has been dropped.  As names were tied to MAC addesses, whem your NIC died and you fitted a new one, the new one became eth1 until you fixed the rules file.

The new default naming scheme names interfaces for the PCI bus and slot they are in, so you can swap NICs without the names changing.  If you fit an extra NIC, the old name won't change either. If you move the NIC to another slot say because you have a new shiny video card that is two slots wide, it changes names.

Its a case of two different default naming conventions, neither of which are perfect for 100% of use cases.  Both work for single NICs, which is over 99% of installs.

Its a PITA when defaults are changed like this and its alienating many udev users to the point where udev has been forked and other options are being looked too.

----------

## miket

 *NeddySeagoon wrote:*   

> The new default naming scheme names interfaces for the PCI bus and slot they are in, so you can swap NICs without the names changing.  If you fit an extra NIC, the old name won't change either. If you move the NIC to another slot say because you have a new shiny video card that is two slots wide, it changes names.

 

Now here is a thing I don't see adequately addressed, and unfortunately I've not gone tweaking through to find out:  since obviously udev has knowledge of the physical address of the NIC to be able to generate the "predictable" name, isn't it possible to write a udev rule that tests for bus type, bus number, and slot number and assign a netX, lanX, wanX, or whateverX?  The renaming should not come down to a choice between either mac-address-to-nice-name or bus-address-to-ugly-name; you should be able to use a bus-address-to-nice-name pattern.

Of course, I would like to be able to end up in a situation where "nice name" in new udev could include ethX without risking a race condition, that that's a whole other issue.  The question now:  isn't there a way you can get a name like net0 based on bus and slot rather than MAC address?

----------

## Anon-E-moose

 *miket wrote:*   

> Of course, I would like to be able to end up in a situation where "nice name" in new udev could include ethX without risking a race condition, that that's a whole other issue.

 

Udev itself caused the "race condition" by trying to start itself before the kernel truly finished loading 

all in the name of trying to save a second or two booting.

----------

## miket

 *Anon-E-moose wrote:*   

>  *miket wrote:*   Of course, I would like to be able to end up in a situation where "nice name" in new udev could include ethX without risking a race condition, that that's a whole other issue. 
> 
> Udev itself caused the "race condition" by trying to start itself before the kernel truly finished loading 
> 
> all in the name of trying to save a second or two booting.

 

EDIT:  No, I didn't know that.  When did they start that?  What follows below is another way I thought of going around the situation, but maybe the best thing is going back to making udev wait a bit!

A couple of weeks ago I thought of making a kernel patch to allow the user to configure the kernel to use a different base name so that udev could safely rename to names in the eth series.  As I looked to the kernel sources, I see Ethernet drivers generally have this in them:

```
sprintf(dev->name, "eth%d", unit)
```

That told me two things: 1) that makes for way too many places to patch, and 2) that base integer is a better target.  Unfortunately, I haven't had a lot of time to trace back in the driver-initialization flow to see how feasible it is to make the devices have a different initial count, but maybe you can see where I'm going.  With an offset like 10, the kernel could freely assign names like eth10, eth11, and so on.  This would leave the lower numbers like eth0 free for udev.  Someone setting up a kernel might go with knowledge like "I certainly won't have more more than X interfaces" and leave those lower-numbered names free.

In any case, this is not the question I was posing just now in this thread.

----------

## eurabilis

This drove me nuts for a day. Thanks to all that responded, touching 80-net-name-slot.rules in /etc/udev/rules.d/ fixed it for me.

----------

