# Unable to get Onboard Intel NiC working [Solved]

## tabanus

I built a Ryzen system using 2400G

Many problems with the onboard graphics, so I've installed a Radeon R5 230 graphics card.

This caused a kernel panic on boot, which I've worked around by disabling IOMMU in BIOS.

Now the onboard ethernet adapter won't work. It's an intel I211AT Gigabit LAN, and was working fine without the external graphics card, and other than the kernel options and firmware for the graphics, I hadn't changed any kernel configs.

The network does work when booting System rescue CD or Ubuntu from a USB.

I tried just including all the intel ethernet drivers, but that's not helped either.

My kernel config

----------

## Jaglover

Boot from Sysrescue and do lspci -k, it will show what driver is in use.

----------

## Naib

whats the output of lspci -vvv  && ifconfig -a

----------

## tabanus

 *Naib wrote:*   

> whats the output of lspci -vvv  && ifconfig -a

 

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

        inet 192.168.0.4  netmask 255.255.255.0  broadcast 192.168.0.255

        ether 2c:fd:a1:59:67:09  txqueuelen 1000  (Ethernet)

        RX packets 1230  bytes 1196825 (1.1 MiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 1063  bytes 114846 (112.1 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

        device memory 0xfe400000-fe41ffff  

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

        inet 127.0.0.1  netmask 255.0.0.0

        loop  txqueuelen 1000  (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 1000  (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)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

```

When I saw this I realised the interface name has changed from enp7s0 to enp8s0. Changing the network config to reflect this has solved to problem.

So much for predictable device names   :Confused: 

Thanks guys.

----------

## Hu

As I understand the "predictable" names feature, this indicates that your seemingly unrelated hardware change (adding the discrete graphics card) moved the network card to a new PCI slot, hence a new name.  You describe the NIC as onboard, so presumably you cannot actually move it to a new slot.  If so, this represents an interesting failure mode for the predictable names feature.

----------

## Jaglover

Plug'n'play, everything is floating around. There were times one had to use jumpers to configure hardware.

----------

## Naib

 *tabanus wrote:*   

>  *Naib wrote:*   whats the output of lspci -vvv  && ifconfig -a 
> 
> ```
> enp8s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> 
> ...

 

Expect it to change again... Mine changed to eno1 (onboard1) when I updated bios with agesa 1.1.0.1 and disabled the PSP snooping device.

It took me 30seconds to figure it had changed but DAMN predictable names are meant to mitigate the crap

----------

## mike155

If you want 'predictable' network interface names: start your kernel with option 'net.ifnames=0'. Your network interface will be called 'eth0' and everything will be fine.

----------

## Naib

 *mike155 wrote:*   

> If you want 'predictable' network interface names: start your kernel with option 'net.ifnames=0'. Your network interface will be called 'eth0' and everything will be fine.

 no, that just means "1st come 1st serve". if for some reason a piece of hardware is slow than normal IT will be bumped down hte list if you have multiple adaptors

THAT was why the predictable name scheme was introduced... rather than being based upon when the device is available its based upon WHERE the device is detected. 

 *Quote:*   

> Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
> 
> Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
> 
> Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
> ...

 

So now there is a secondary side of this... how to ensure the mechanism used to classify it: onboard, pci id, mac, is PREDICTABLE... if udev messes around with which scheme to use then its a pointless waste of time such a scheme being forced onto people because it doesn't solve what it meant to

----------

## mike155

 *Quote:*   

> no, that just means "1st come 1st serve". 

 

... and that's perfectly fine for most users, because most computers just have one or two network interfaces. The new network interface naming system just doesn't make much sense on those computers. That's why I start all of my servers with 'net.ifnames=0'.  :Wink: 

----------

## Tony0945

 *Naib wrote:*   

> no, that just means "1st come 1st serve". 

 

ONLY if you have more than one NIC. Most people only have one. If you have more than one, the best way is to define a udev/eudev rule assigning a name that YOU determine, based on MAC address. That's predictable. The other is a crap shoot. It's interesting to note that this ill-thought predictable name garbage is unpredictable even if only one NIC exists.

I use the net.ifnames=0. I can predict the name. It's eth0, ALWAYS eth0, no matter if I move the video card,  add or remove a multimedia card or anything else. I do have one machine used as a router, It has an onbard NIC and a PCI slot NIC. eudev names the onboard (100MB) as wan0 and the PCI card (gigabit) as lan0 based on MAC addresss. I use a blue cat5e cable to the cable modem and a yellow cat 6 cable to the eight port switch. Never any confusion.

EDIT: Just wanted to add that if you have a mult-lan box, you can always name them, lan0, lan1... or mynet0, mynet1 ... or whatever. I'm not even sure if a number afterward is needed i.e firsteth, othereth, but NeddySeagoon warned me (and I always heed his advice) to not use the kernel name eth0, eth1... So use the net.inames=0 or the scheme I described in the main post. NEVER a non-euphonious name like epanada. Just would make me hungry anyway.

----------

## Naib

 *Tony0945 wrote:*   

>  *Naib wrote:*   no, that just means "1st come 1st serve".  
> 
> ONLY if you have more than one NIC. Most people only have one. If you have more than one, the best way is to define a udev/eudev rule assigning a name that YOU determine, based on MAC address. That's predictable. The other is a crap shoot. It's interesting to note that this ill-thought predictable name garbage is unpredictable even if only one NIC exists.
> 
> I use the net.ifnames=0. I can predict the name. It's eth0, ALWAYS eth0, no matter if I move the video card,  add or remove a multimedia card or anything else. I do have one machine used as a router, It has an onbard NIC and a PCI slot NIC. eudev names the onboard (100MB) as wan0 and the PCI card (gigabit) as lan0 based on MAC addresss. I use a blue cat5e cable to the cable modem and a yellow cat 6 cable to the eight port switch. Never any confusion.
> ...

 

Well apparently even this new "predictable names" is flawed... 

eth* en....  makes no difference to me as they are mnemonics for hardware devices... PREDICTABILITY however is more important... 

I use to have two ethernet (:onboard and pci...) and to mitigate which one went up 1st I had net.eth0, net.eth1 both in the default runlevel.  This new naming was ment to mitigate this but now there is no way to predict what they will be called.

This is total BS if you ask me

----------

## NeddySeagoon

Naib,

The 'Predicable Interface Names' has just swapped one set of corner cases for another.

I like the old corner cases, probably because I'm used to them :)

----------

## Tony0945

 *Naib wrote:*   

> I use to have two ethernet (:onboard and pci...) and to mitigate which one went up 1st I had net.eth0, net.eth1 both in the default runlevel. 

  I would think that would exacerbate the problem. I had a similar situation once but the drivers were different, r8169 and e1000e. I would blacklist e100e and then modprobe it and execute /etc/init.d/net.eth1 later. That was when I was running pure mdev. Now I run an old version of eudev from local overlay and when I still had two cards, just made the rules I described above, naming them by mac address.

----------

## Naib

 *Tony0945 wrote:*   

>  *Naib wrote:*   I use to have two ethernet (:onboard and pci...) and to mitigate which one went up 1st I had net.eth0, net.eth1 both in the default runlevel.   I would think that would exacerbate the problem. I had a similar situation once but the drivers were different, r8169 and e1000e. I would blacklist e100e and then modprobe it and execute /etc/init.d/net.eth1 later. That was when I was running pure mdev. Now I run an old version of eudev from local overlay and when I still had two cards, just made the rules I described above, naming them by mac address.

 I agree MAC is the more unique but you know free desktop .... lets provide 5 means to determine the interface but then not really provide a consistent means to priorities the naming convention

----------

## Tony0945

 *Naib wrote:*   

> I agree MAC is the more unique but you know free desktop .... lets provide 5 means to determine the interface but then not really provide a consistent means to priorities the naming convention

 

For sure!

----------

