37

My new RPi 3 device (yay) recently booted up with a deactivated ethernet.

So i watched /etc/networks/interfaces and saw the line:

auto eth0
iface eth0 inet dhcp

Calling ifup eth0 unfortunately gave the following message:

eth0 No such device
No hardware found

So i checked my ifconfig -a and saw a strange device:

enx*MACADDRESS* Link encap:Ethernet HWaddr **:**:**:**:**:**

Trying to change /etc/networks/interfaces to the name resulted in a working network. How can i change that device name back to eth0?

PS: i don't have any 70-persistent-net.rules file fyi. OS is Ubuntu MATE 15.10

Thanks.

1
  • Please check file > /etc/iftab Mine states: enxb827.... mac xx:xx:xx:xx:xx:xx arp 1 wlan0 mac xx:xx:xx:xx:xx:xx arp 1
    – user47854
    Commented Jun 10, 2016 at 17:38

15 Answers 15

18

I did have this issue when running Debian armhf on Raspberry Pi 2, you can change the interface name by create file /etc/udev/rules.d/70-persistent-net.rules and put this in

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="b8:ac:6f:65:31:e5", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

replace b8:ac:6f:65:31:e5 with your eth0 MAC address, reboot and it will become eth0, you may not have internet access after reboot because in /etc/network/interfaces is defining wrong interface, just change enx* to eth0

Edit: This is not an issue but a new interface naming scheme "Predictable Interface Names", you should adapt and using this instead of try to revert it to the old ones.

3
  • 4
    thanks to @UnSined i looked further and found, that i had to add: ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules. It's basically disabling the naming thingy. Works now.. thanks!
    – Tom Siwik
    Commented Mar 30, 2016 at 21:07
  • User is @Ficertyn now... clarity for happy readers of the red hat docs
    – Tom Siwik
    Commented Sep 1, 2017 at 11:47
  • 2
    I had to remove the KERNEL=="eth*" entry for this to work. Commented Jan 4, 2019 at 21:38
29

raspi-config is easiest method.

If you are on Raspbian then it's installed by default. But if you are on Ubuntu, Mint or Mate then you can install it with command below:

sudo apt-get install raspi-config

Then you can do configure it with raspi-config.

sudo raspi-config
  1. Select "2. Network options"
  2. Select "N3 Network interface names"
  3. Select "No". It's now disabled predictable network interface names.
  4. Click "OK" and "Finish". Then it will reboot your raspberry pi.

Done.

7
  • 1
    Does Ubuntu Mate (which is what the OP is using) have a raspi-config? Commented Mar 29, 2018 at 22:56
  • So your answer does not apply. Commented Mar 31, 2018 at 1:11
  • 1
    But if you googled same problem with Raspbian then this question found first. I did that and took time for research and found solution. I think that it helps some one. OK I edit answer now. Commented Mar 31, 2018 at 1:17
  • 2
    It confuses me to see people "researching" while the answer is clearly written in the approved answers. Ubuntu, debian, raspbian all the same. Installing the tool on Ubuntu Mate is no problem either (even installed by default) raspberrypi.stackexchange.com/a/67084/42528. However this is an answer without any explanation what is happening behind the curtain. While it solves the problem it discourages people to actually understand what is going on. I'll +1 this for all the lazies out there though.
    – Tom Siwik
    Commented Apr 5, 2018 at 8:11
  • 3
    Cool! This answer was definitely the easiest and solved my issue for establishing as working static IP address
    – vinyll
    Commented Jan 21, 2019 at 11:57
26

This solution only works if you're seeing an odd network interface device like env{hwdaddress} when running $ ifconfig -a instead of eth0. I tried all the common answers about adding rules but only this fix worked.

I'm running a Raspberry Pi 3 with Ubuntu 16.04 preinstalled server armhf. Long story short, running $ apt-get update added Predictable Network Interface Names

Edit the following file:

$ vim /lib/udev/rules.d/73-usb-net-by-mac.rules

You should see:

ACTION=="add", SUBSYSTEM=="net", SUBSYSTEMS=="usb", NAME=="", \
ATTR{address}=="?[014589cd]:*", \
TEST!="/etc/udev/rules.d/80-net-setup-link.rules", \
IMPORT{builtin}="net_id", NAME="$env{ID_NET_NAME_MAC}"

Change the NAME at the end as follows:

ACTION=="add", SUBSYSTEM=="net", SUBSYSTEMS=="usb", NAME=="", \
ATTR{address}=="?[014589cd]:*", \
TEST!="/etc/udev/rules.d/80-net-setup-link.rules", \
IMPORT{builtin}="net_id", NAME="eth0"

Save Changes

Reboot. Everything should be working now assuming everything is pointing to eth0.

Edit (10/26/2016) To prevent any future updates from overwriting this fix, do the following:

cp /lib/udev/rules.d/73-usb-net-by-mac.rules /etc/udev/rules.d/
3
  • 1
    I have spent far, far too long trying to get to the point of having a stable eth0 for my Pi with Ubuntu Server 16.04. Thank you. One small modification to your answer, which I would suggest that you try, implement and then add to your answer: Copy the 73-usb-net-by-mac.rules file to /etc/udev/rules.d/ directory and modify that one; if you change the one in /lib/udev/rules.d then it may be overwritten in a future OS update. Commented Oct 8, 2016 at 9:47
  • Thanks for the heads up. I also spent a solid 2 days troubleshooting the issue. I would have the pi all set to go with Python3 and OpenCV only to have the Ethernet stop working on reboot because of the update. Glad to see my answer was of some use. Commented Oct 9, 2016 at 16:06
  • 1
    It took me a while to figure out why it was happening, and then needing to figure out what to do and why (Ubuntu bug - the fix as committed doesn't seem to work, which is an edit to the same file). Here's the ongoing battle: bugs.launchpad.net/ubuntu/+source/systemd/+bug/1593379 - However, your fix doesn't appear to work on my Raspberry Pi 2. I'm really thinking to just get an x86 box at this point. Commented Oct 11, 2016 at 18:30
11

This is NOT a "bug" it is a "feature" "consistent network device naming". (I don't see anything consistent about it.)

There are probably many ways of "fixing" this, but they may not work if the hardware is changed.

To restore previous behaviour add net.ifnames=0 biosdevname=0 to the end of cmdline.txt.

4
  • Although the feature is, well, a feature, the way in which it behaves is a bug - specifically in how udev handles USB ethernet devices. It ignores net.ifnames=0. I don't believe that anyone should need to follow bug report discussions to make a popular OS work with a common hardware configuration, but that's life. bugs.launchpad.net/ubuntu/+source/systemd/+bug/1593379 Commented Oct 16, 2016 at 10:00
  • @KevinTeljeur and my comment was sarcasm - this is a common issue on computer systems.
    – Milliways
    Commented Oct 16, 2016 at 11:11
  • Ha ha, sorry - after so many wasted hours, and then finding that it was a quietly documented bug, I can't pick up on any consistent network device naming sarcasm. I did pick up on your quotation marks, but the adding of those magic incantations in config.txt genuinely doesn't work on on the Pi as a documented bug (maybe now with the release of the latest udev build it finally does). It's a surprisingly unknown bug which affects all systems with ethernet on USB. Commented Oct 16, 2016 at 21:44
  • This worked for me while other options didn't. I suspect the reason is that I'm booting using an initramfs, so the udev rules for bringing up the network are baked into that, rather than necessarily read out of my root volume. (I didn't confirm this by rebuilding the initramfs after updating udev rules, but that would've felt like a more fragile setup anyway)
    – Svet
    Commented Apr 10, 2023 at 11:53
4

I haven't encountered it specifically with the mac address as part of the name, however what you're experiencing is called consistent network device naming.

This was a change made because it's possible, and maybe even probable on some systems that have multiple network cards that the cards would come up out of order and using the eth0, eth1, etc. naming scheme you would end up applying routing rules and whatnot to the wrong interface.

Many Linux distributions have moved to some sort of consistent network device naming, typically it will look something like enp0s1, identifying the PCI bus and the attachment point to the bus (0 and 1 respectively).

You can get more information from https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html, as well as how to change your system to the old way of doing things if you still want to do so.

1
  • 1
    eventhough this is an informative comment it did not help solve the problem and neither did it answer the question (read the manual kind of answer). However, it helped find a small fix to the solution above. that's why upvote earned and a thank you :)
    – Tom Siwik
    Commented Mar 30, 2016 at 21:10
4

I had the same issue for Ubuntu Server 16.04 running in Raspberry Pi 2 and this (see link below) helped me solve the problem

https://bugs.launchpad.net/ubuntu-pi-flavour-maker/+bug/1585335

2

Simple:

sudo ln -s /dev/null /etc/systemd/network/99-default.link

and sudo reboot.

Source: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

1

With odroid creating this file fixed my problem

root@odroid:~# cat /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth0", NAME="eth0"
1

I had the same issue on Raspberry Pi 2 with Ubuntu 16.04 and what worked was following the link from #goutam and adding /etc/udev/rules.d/70-persistent-net.rules with the following:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth0", NAME="eth0"
1

I found this suggestion here:

Change one line in the 70-persistent-net.rules to

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="98:90:96:e0:3c:e9", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME:="eth0"

which is dropping the KERNEL attribute and changing the NAME from = to :=

It seems to force whatever MAC address is found to eth0. Works on Raspberry Pi and uboot booting systems.

1

I realize that this question is old but I have hit this problem and none of the proposed solutions thus far on this page solved my issue. For me the rules.d folder trick doesn't seem to do anything.

My solution was to simply write a script that goes in the init.d folder to assign DHCP to the wired ethernet port regardless of the name. This is important because I have several Raspberry Pi units and they all came down with this same issue. (very frustrating)

My issue is compounded because I have a network storage folder that needs to be mounted during the boot process. Because the interface didn't come up, this mount failed and things just went from bad to worse for me.

Here is my solution. I hope this will help anyone else that can't find join using the above answers.

Create the file /etc/init.d/raspi-init-network using your favorite text editor. I like to use vi.

cd /etc/init.d
sudo vi raspi-init-network

This is the code that belongs in the file

#!/bin/sh
### BEGIN INIT INFO
# Provides:          boot-identify-myself
# Required-Start:    $local_fs $network
# Required-Stop:     $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: identify-myself
# Description:       identify this computer to the main server upon
### END INIT INFO
#
# when using predictible network names for the interfaces,
# the pi doesn't seem to activate the interface correctly so
# this script will force the issue.
#
# it works by getting the interface name of the wired network
# device and using that to initialize dhcp

start() 
{
    interface=`ifconfig -a | grep "encap:Ethernet" | grep -oh -E "^[^ ]+"`
    dhclient $interface
    mount -a
}

stop() 
{
    : # do nothing
}

uninstall() 
{
    : # do nothing
}

case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  uninstall)
    uninstall
    ;;
  retart)
    stop
    start
    ;;
  *)
    echo "Usage: $0 {start|stop|restart|uninstall}"
esac

Make sure the script is executible

sudo chmod 755 raspi-init-network

Activate the code so it will execute during the boot process by executing the update-rc.d command.

sudo update-rc.d raspi-init-network defaults 90

After this, I have not had a single issue and I was able to copy the code to all of my Pi units with the same steady results.

NOTE: If you are not mounting drives, you can leave out the "mount -a" line.

TWEAKS: If you are using your wifi you can change the line that starts out "interface=" and edit the first "grep" segment. This first grep grabs the entire line of the interface you wish to use. The second grep takes that line and only returns the interface name.

1

For those now encountering this problem with the Raspberry Pi OS Bullseye, 73-usb-net-by-mac.rules no longer exists, at least for me, so I just edited /etc/udev/rules.d/80-net-setup-link.rules and much like the other comments, changed the final NAME listing from NAME="$env{ID_NET_NAME}" to NAME="eth0" and that did the trick.

1

Simply deactivate the udev rules responsible for the interface renaming process, i.e.

sudo ln -s /dev/null /etc/udev/rules.d/73-usb-net-by-mac.rules

or

sudo touch /etc/udev/rules.d/73-usb-net-by-mac.rules
0
0

For me, running Debian Unstable on the Raspberry Pi 2, the symlink mentioned in the comment to the first answer was the right idea, too, but its name had to be different: ln -vis /dev/null /etc/udev/rules.d/80-net-setup-link.rules

6
  • No, you did mention this file name but a different one in your comment which is why I referred to that comment and mentioned that it had to be a different file name for me. Commented Apr 20, 2016 at 10:40
  • 1
    I see. Please notice the difference between raspberry pi 3 and raspberry pi 2. Eventhough they are technically almost the same this naming difference could be one of those things to mislead people. Thanks for clarification though.
    – Tom Siwik
    Commented Apr 20, 2016 at 11:58
  • I assume this difference in file names comes from Debian 8 Jessie vs Debian Unstable with a newer systemd/udev version. The actual name of the interface without this symlink might indeed be more different than just the MAC address. But at least for the ethernet interface I think I remember having seen these enx interface names on both, Raspi 2 and 3. I though currently can't remember how the WLAN interface was named on the Raspi 3. Commented Apr 22, 2016 at 1:22
  • enx<MAC>, was using Ubuntu Mate, fixed problem like shown above. Switched to Debian and didn't have to do the renaming. It's weird though... you are right.
    – Tom Siwik
    Commented Apr 25, 2016 at 13:35
  • Doesn't work for me on Raspi 3B.
    – Akito
    Commented Jul 15, 2020 at 10:55
0

This is a simple fix

  1. Create a new file as follows
    sudo vim /etc/udev/rules.d/10-network-device.rules

  2. Place this text inside this file, using your device MAC address
    SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="eth0"

  3. reboot

  4. ifconfig should now show your network interface as eth0 not enxaabbccddeeff (enx+MAC address)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.