36

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.

Tom Siwik
  • 463
  • 1
  • 4
  • 5
  • 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 –  Jun 10 '16 at 17:38

15 Answers15

28

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.

Almas Dusal
  • 481
  • 5
  • 5
  • 1
    Does Ubuntu Mate (which is what the OP is using) have a raspi-config? – Steve Robillard Mar 29 '18 at 22:56
  • So your answer does not apply. – Steve Robillard Mar 31 '18 at 01: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. – Almas Dusal Mar 31 '18 at 01:17
  • That is all well and good, but you are answering a different question than the one above. So your theoretical user will come here and see that the question is for Ubuntu and leave without ever seeing your answer. I appreciate that you took time to research, but you missed a very pertinent detail namely that the user is using Ubuntu, not Raspbian. – Steve Robillard Mar 31 '18 at 01:25
  • 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) https://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 Apr 05 '18 at 08:11
  • 3
    Cool! This answer was definitely the easiest and solved my issue for establishing as working static IP address – vinyll Jan 21 '19 at 11:57
  • If you are on Raspbian, fine. If you are on another distribution, like DietPi, then you cannot install the package when you don't have internet due to OP's issue. – Akito Jul 15 '20 at 10:50
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/
Luis Godinez
  • 404
  • 1
  • 4
  • 4
  • 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.

    – Kevin Teljeur Oct 08 '16 at 09: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. – Luis Godinez Oct 09 '16 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: https://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. – Kevin Teljeur Oct 11 '16 at 18:30
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.

minhng99
  • 310
  • 1
  • 9
  • 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 Mar 30 '16 at 21:07
  • User is @Ficertyn now... clarity for happy readers of the red hat docs – Tom Siwik Sep 01 '17 at 11:47
  • 2
    I had to remove the KERNEL=="eth*" entry for this to work. – Roger Dueck Jan 04 '19 at 21:38
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.

Milliways
  • 59,890
  • 31
  • 101
  • 209
  • 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. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1593379 – Kevin Teljeur Oct 16 '16 at 10:00
  • @KevinTeljeur and my comment was sarcasm - this is a common issue on computer systems. – Milliways Oct 16 '16 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. – Kevin Teljeur Oct 16 '16 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 Apr 10 '23 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.

Ficertyn
  • 171
  • 6
  • 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 Mar 30 '16 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

goutam
  • 41
  • 1
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

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.

Greenonline
  • 2,740
  • 4
  • 23
  • 36
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"
Rodrigo
  • 11
  • 1
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.

user855443
  • 119
  • 1
  • 5
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
Greenonline
  • 2,740
  • 4
  • 23
  • 36
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.

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)

Kes
  • 101
  • 2
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

Axel Beckert
  • 1,182
  • 12
  • 26
  • 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. – Axel Beckert Apr 20 '16 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 Apr 20 '16 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. – Axel Beckert Apr 22 '16 at 01:22
  • enx, 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 Apr 25 '16 at 13:35
  • Doesn't work for me on Raspi 3B. – Akito Jul 15 '20 at 10:55
  • @Akito: Yes, given the date of my answer, this was valid for Raspbian 8 Jessie. We're now at Raspbian 10 Buster. More than four years and two new releases inbetween. A lot has changed since then. – Axel Beckert Jul 15 '20 at 18:01