# no ethernet adapters found (solved)

## <3

Hello All I have a Asus P7P55-d e PRO motherboard with a built-in REALTEK 8169 PCI-e Fast Ethernet card and an Intel Gigabit CT PCI-e Network card. According to the Debian Hardware Compatibility List I need to load the e1000e(intel) and  r8169(realtek) kernel modules. Yet for some reason I can not get either interfaced to come up in ifconfig after loading each as a module and even building both into the kernel. This is a fresh install and I have never had this problem before. Even on this same box.

Both network cards work properly if ran off the Gentoo 13.0 EOtW live-DVD. and using lsmod I can see that the Live DVD is indeed using the e1000 and r8169 modules for each card. I have also ensured that I am indeed running the correct kernel and have properly copied the kernel image to /boot.

lspci output

```
lspci | grep -ie ethernet

05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)

0b:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
```

Can someone please help me because I have a barebones Gentoo box right now and I can't even install a DE without a internet connection.Last edited by <3 on Fri Dec 19, 2014 7:37 pm; edited 4 times in total

----------

## zeek

If you run `lspci -v` and look for your Ethernet cards do you see the Kernel driver in use and Kernel modules entries?

 *Quote:*   

> 01:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01)
> 
>         Subsystem: Dell Ethernet 10G 4P X540/I350 rNDC
> 
>         Flags: bus master, fast devsel, latency 0, IRQ 34
> ...

 

If not look in `dmesg` for diagnostics, there may be a problem initializing the hardware ...

----------

## NeddySeagoon

<3,

udev will have trashed you device names.  When you boot your own Gentoo, what does 

```
ifconfig -a
```

 show for network device names?

Its not going to be eth0 and eth1.

----------

## <3

ifconfig only shows the loopback device "lo"

edit** corrected in the next post

----------

## <3

I'm sorry I didn't use the -a flag, when I issued ifconfig with the -a flag it shows that the 2 ethernet adapters were found but now how do I get that to work?

```
enp11s0: flags=4098<BROADCAST,MULTICAST>  mtu 1500

        ether 00:1b:21:82:9f:99  txqueuelen 1000  (Ethernet)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

        device interrupt 17  memory 0xf7ee0000-f7f00000

enp5s0: flags=4098<BROADCAST,MULTICAST>  mtu 1500

        ether e0:cb:4e:47:32:67  txqueuelen 1000  (Ethernet)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

        inet 127.0.0.1  netmask 255.0.0.0

        inet6 ::1  prefixlen 128  scopeid 0x10<host>

        loop  txqueuelen 0  (Local Loopback)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

sit0: flags=128<NOARP>  mtu 1480

        sit  txqueuelen 0  (IPv6-in-IPv4)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)
```

----------

## nemectic

ifconfig <interface> up

ie.

```
ifconfig enp11s0 up
```

----------

## <3

Thank you for your help so far I feel I am getting close to getting this to work. Now I have two more problems. First now that the interface is up how do I get it to use dhcp to get an ip address? and secondly is it possible to rename the two interfaces net.eth0 and net.eth1 so that the init scripts can automagically bring up the interfaces at boot?

----------

## Hu

<3: as NeddySeagoon hinted, your device names have been mangled by a bad udev default.  Read Gentoo news item Upgrading udev to version >=200 for details on how to fix this so that udev leaves the predictable kernel names in place.  The instructions nemetic gave you are useful for configuring the interface by hand, but for long term usage, you want to have the interfaces managed by your init scripts, as you mentioned.

----------

## <3

I don't have that news item

```
eselect news list

News items:

  [1]   N  2012-09-09  make.conf and make.profile move

  [2]   N  2012-11-06  PYTHON_TARGETS deployment
```

----------

## TomWij

Please note that the new names are the predictable ones as they clearly show to be in port 5 and port 11; whereas if you have the old names eth0 and eth1 and remove the eth0 network card it will move eth1 to eth0 which is not what you would want, the removal of one network card shouldn't change the behavior of the other. This doesn't happen with the new names, because their port didn't change.

Of course, if you are not changing hardware then the naming scheme doesn't matter; so, if people prefer the old naming for convenience then switching back is indeed handy. The new names have probably been intended for servers where multiple network cards where changing them is more common; for normal desktops / laptops, it really doesn't matter which one you use as it is just a name...

More details on how this predictability works as well as how to disable the new naming scheme can be found at http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Now that you are able to enable the interface and have chosen whether you want the new or old naming style, you can manually do `dhcpcd enp7s0` (or the equivalent dhclient command, replace by eth0 / eth1 if you went for old); although you will want to proceed with http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=4 to automatically set up your interfaces.

----------

## <3

Thanks guys I got the interfaces up by making new scripts named net.enp11s0 and net.enp5s0

----------

## Hu

<3: interesting.  I guess the filter for that news item excluded it since you never had the predictable kernel names.  Section 4 is a bit misleading in how it tries to scare people off kernel names, but it contains the information you need.  Advocates of the new naming scheme tend to play up that swapping out hardware will cause problems, but neglect the number of single user machines (often operated by people who are less adept at determining what happened) that are needlessly broken by the default of NIC name mangling.  Here is the full text of that news item:

```
2013-03-29-udev-upgrade

  Title                     Upgrading udev to version >=200

  Author                    Samuli Suominen <ssuominen@gentoo.org>

  Posted                    2013-03-29

  Revision                  2

This replaces the earlier news item about the udev 197 upgrade and

describes the predictable network interface names in more detail.

If you skip anything in this news item, your system will not be

bootable, or your networking will be down, or both.

Pay attention also to every message printed by emerge of sys-fs/udev

and sys-fs/udev-init-scripts as this news item may not be complete.

1. udev-postmount init script:

Remove the udev-postmount init script from your runlevels.

2. devtmpfs support:

You need at least version 2.6.32 of the kernel for devtmpfs

functionality. Once you have this, make sure CONFIG_DEVTMPFS=y is set

in the kernel configuration. See the gentoo udev guide for the option in

make menuconfig [1].

If you have a line for /dev in /etc/fstab, make sure it is configured

for file system type devtmpfs (not tmpfs or any other type). Also, you

can remove this line if you prefer, since devtmpfs is mounted

automatically.

3. Old interface naming rules:

If the system still has old network interface renaming rules in

/etc/udev/rules.d, like 70-persistent-net.rules, those will need

to be either modified or removed.

If you choose to modify them, you must use free namespace (like net*

or internet*) instead of kernel namespace (like eth* or wlan*)

because in-place renaming has been deprecated, see small

documentation of it if you like[2].

The file 70-persistent-net.rules, like the 70-persistent-cd.rules

should be removed, so if you modify, rename the file also to something

else like 70-my-network.rules to silence the deprecation warning coming

from the end of the sys-fs/udev emerge.

This is the old format with reserved namespace:

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

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="yy:yy:yy:yy:yy:yy", NAME="eth1"

This is the new format with free namespace:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="xx:xx:xx:xx:xx:xx", NAME="net0"

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="yy:yy:yy:yy:yy:yy", NAME="net1"

4. predictable network interface names:

If /etc/udev/rules.d/80-net-name-slot.rules is an empty file or a

symlink to /dev/null, the new names will be disabled and the kernel will

do all the interface naming, and the resulting names may vary by kernel

configuration, hardware configuration and kernel version.

Also, the forementioned old 70-persistent-net.rules might interfere with

the new predictable interface names.

You can get attributes of your network interfaces using a command like

the following (replace eth0 with the name of the appropriate interface):

# udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null

You can copy /lib/udev/rules.d/80-net-name-slot.rules to

/etc/udev/rules.d and specify the attributes and in which order

they will be used for naming. See upstream wiki[3] for detailed list

of options.

You can prepare the system for the new names before booting for example

by renaming /etc/init.d/net.* symlinks, editing /etc/conf.d/net, etc.

The feature can also be completely disabled using net.ifnames=0 on the

kernel command line.

If you only have one interface card, you don't necessarily have much

use for this feature as the name almost always stays at eth0, you can

easily disable it using forementioned methods.

This feature can also replace the functionality of sys-apps/biosdevname,

but you can still keep using it if you want.

In a normal new installation there are no files in /etc/udev/rules.d

and if you haven't edited any files you have in there, you should most

likely backup and delete them all if they don't belong to any packages.

The official wiki has a dedicated page for udev upgrade notes[4].

[1] http://www.gentoo.org/doc/en/udev-guide.xml

[2] http://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html

[3] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

[4] http://wiki.gentoo.org/wiki/Udev/upgrade
```

----------

## TomWij

 *Hu wrote:*   

> but neglect the number of single user machines (often operated by people who are less adept at determining what happened) that are needlessly broken by the default of NIC name mangling

 

Broken in which way?

----------

## Aiken

 *TomWij wrote:*   

>  *Hu wrote:*   but neglect the number of single user machines (often operated by people who are less adept at determining what happened) that are needlessly broken by the default of NIC name mangling 
> 
> Broken in which way?

 

I would have said the OP of this thread for starters. Without udev stuffing up the devices names there would have been no need for this thread. Tear down a computer for cleaning or trouble shooting then when putting it back together if any plug in network card is not placed in the slot it came out of networking has just been broken by udev. When usb wifi adaptors are used where of they are not placed in the same usb port bye bye networking. That also breaks the idea of plug in a usb device and have it just work.

----------

## TomWij

 *Aiken wrote:*   

>  *TomWij wrote:*    *Hu wrote:*   but neglect the number of single user machines (often operated by people who are less adept at determining what happened) that are needlessly broken by the default of NIC name mangling 
> 
> Broken in which way? 
> 
> I would have said the OP of this thread for starters. Without udev stuffing up the devices names there would have been no need for this thread.

 

The problem of this thread was that the interface did not appear (as it is disabled thus hidden from `ifconfig`), which is unrelated to the device names; this could have very well been posted with the old internet names.

 *Aiken wrote:*   

> Tear down a computer for cleaning or trouble shooting then when putting it back together if any plug in network card is not placed in the slot it came out of networking has just been broken by udev. When usb wifi adaptors are used where of they are not placed in the same usb port bye bye networking. That also breaks the idea of plug in a usb device and have it just work.

 

True, but for people whom not prefer to reuse the same slot the predictable names provide the ability to use the MAC address; to some extent, that would be a better default.

(Maybe we could propose a better default to the Gentoo Developers? Though on the other hand I have no idea if users would appreciate a second change. Once was enough, twice is just annoying...)

In my opinion it is not broken (as in buggy, perhaps it is in terms of expectations), it just depends on in which way you want it to be predictable as that is configurable;

I however agree that it is an unnecessary change for most people, because I would think that a statistics graph (*) would point out that quite some users (and sys admins) have one network card.

Thus for most people just eth0 and/or wlan0 would suffice; but yeah, in the server world the story is quite different and I think statistics graph (*) would show these users being a large enough share to support.

*: As we don't really collect information on that; it is hard to determine, but on Gentoo I'd think that due to the more low level approach to things the user / sysadmin ratio is lower than the average non-source distribution.

----------

## Aiken

 *TomWij wrote:*   

>  *Aiken wrote:*    *TomWij wrote:*    *Hu wrote:*   but neglect the number of single user machines (often operated by people who are less adept at determining what happened) that are needlessly broken by the default of NIC name mangling 
> 
> Broken in which way? 
> 
> I would have said the OP of this thread for starters. Without udev stuffing up the devices names there would have been no need for this thread. 
> ...

 

By the look of it I would say the OP had been expecting the normal eth0 and eth1. This includes the later reference to net.eth0 and net.eth1. If this guess is true then without udev renaming the interfaces they would have just worked.

Mapping of mac to name would work in some cases but not all. It is also an extra step to get the old behaviour of a consistent interface name. In my case of the wifi adaptors I would have to map all wifi adaptors to a single name just so it did not matter which adaptor and which usb slot was used. This also breaks wanting to plug in more than 1 adaptor at a time. With udev leaving the names alone I can pick any adaptor, any usb port and get the same name of wlan0 every time.

With multi nic machines I would be interested in how much of a problem this is. I have been using multi nic machines since 2000 or just before and the only time I can recall the network names being swapped around involved a mother board change so no surprise at all something changed. Still have the renaming disabled and the multi nic machines are coming up correctly every time.

I believe this would have been better if the udev renaming had been left disabled by default then the people who needed it could enable as needed. Instead of breaking working systems or causing confusion.

----------

## Jaglover

^^ ++

----------

## TomWij

Well, they have left that file in place which prevents the interface names from switching for existing users;

or maybe that was at least for me, I believe some people experienced a switch; perhaps this has only happened on ~.

Whereas for people that do new installs get the choice to configure as they see fit; so, they wouldn't experience it being broken

(at least during the install, it might however break due to hardware changes as you have said) or be confused as they would follow clear documentation.

Keeping the old for current users and introducing the new in a configurable manner is probably why this change went through;

but well, if everyone keeps suggesting to switch back, perhaps we should start a poll to hear if people want to switch the default to the old way. 

But really, I think most people don't change hardware often, so I don't consider that kind of hardware changing breakage to be a huge problem.

----------

## NeddySeagoon

TomWij,

 *Quote:*   

> But really, I think most people don't change hardware often, so I don't consider that kind of hardware changing breakage to be a huge problem.

 

Its a problem for people using USB network connections as they keep changing names depending on where they are connected.

It now requires extra configuration steps to stop that.

Looking back over udev design, the upstream maintainers have missed a few tricks.

In one version, interface renaming was dropped, so multi interface users had their interface names scrambled.

A few versions later, persistent interface names were introduced, which changed all the interface names again.

The reality is we have gone from one default, that was broken for a few corner cases, to another default that is broken for a different set of corner cases and upset most users at least once in the process.  

A little forethought by upstream udev would have dropped interface renaming and added the persistent interface names in the same release, so uses are only upset once.

Its difficult to believe that there is any feature planning in udev.

Personally, I'm glad that a static /dev still works, so I don't need udev and friends.

----------

## Hu

I am not aware of any quirks to the udev interface name mangling that I could classify as a bug, though I definitely consider the on-by-default name mangling to be a serious misfeature.  When I referred to "single user machines that are needlessly broken" I was thinking of the scenario in this thread, where the OP configured the machine in a way that would have worked if the names were not changed by udev.

As much as I dislike this default, I agree that changing it again would just cause problems since there is no good way to distinguish between users who expect kernel-style names and users who expect udev-style names.  Checking for a prior udev of the right version range would identify many, but not all, of the users who have a particular expectation.

People may not replace hardware that often, but some current laptops ship without a wired NIC.  Users who want to use a wired interface on those machines plug in a USB-to-Ethernet adapter to any free USB port on the device.  I believe Aiken's point was that, with one of the udev naming conventions, such a user must take care to plug the USB-to-Ethernet adapter to the same USB port every time, since the physical port selected influences the udev-chosen interface name.

----------

## <3

for some reason for the past few days the network interfaces have been named net.eth0 & net.eth1. I don't know why the names changed I have not done anything. I didn't remove the cards from the pcie slot etc.

----------

## <3

OK I don't know if someone is screwing with me or what because last week the interfaces were named eth0 and eth1 now for some reason they are back to being named enp11s0 and enp5s0. I really don't care what they are named anymore as long as it stays consistent. Why are the names constantly changing? I have not touched any config files or moved either from their physical PCI-e slots.

----------

## CoreLx

try this:

nano -w /etc/rc.conf

uncomment/add: rc_hotplug="net.eth0"

restart your pc

please say if it works

----------

## <3

Sorry for taking a while to respond. I am just seeing your response for the first time. Does this variable take a comma separated list?

I.E. do I do this?

```
rc_hotplug="net.eth0,net.eth1"
```

----------

## <3

OK, marking this thread as solved, I finally realized there is a kernel option to disable persistent naming.

----------

