2

I am currently trying to configure two Raspberry Pi 3s. The first one works fine. However, the other one always renames eth0 to eth1 on boot.

dmesg | grep eth

[2.485760] smsc95xx 1-1-.1:1-0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:56:b6:06
[4.742863] smsc95xx 1-1.1:1.0 eth1: renamed from eth0
[4.794234] systemd-udevd[151]: renamed network interface eth0 to eth1

Both Raspberrys have the same image on their SD card with minimum non-OS modifications in custom scripts (datalogging from sensors). Both SD cards' OS instances get their correct IPs (assigned by MAC) from the DHCP server when using the first Pi. Neither get any address when installed in the other Pi. Both Pis are new and from the same seller.

Changing eth0 to eth1 in /etc/network/interfaces works around the problem, but it took me hours to find out because I didn't expect the LAN port to NOT work out of the box. Something hardware-related seems to cause unnormal behaviour even though both Pis are the same generation.

Why does the hardware have such an effect on the OS and how can I fix it?

Domme
  • 375
  • 2
  • 11
  • Have you used rpi-update? – Milliways Aug 08 '16 at 11:56
  • @Milliways Yes, everything is up to date. I found out how to use the interface again: I forgot to change auto eth0 to auto eth1, only changed the iface line before... now it works, still a highly confusing and massively time-consuming phenomen. One would have thought that all Pis are equal, but this one seems to have different hardware. – Domme Aug 08 '16 at 12:26
  • You did not answer my question, but I assume you have "In normal circumstances there is NEVER a need to run rpi-update as it always gets you to the leading edge firmware and kernel and because that may be a testing version it could leave your RPi unbootable". https://www.raspberrypi.org/forums/viewtopic.php?p=916911#p916911 – Milliways Aug 08 '16 at 12:33
  • @Milliways Thank you, I didn't know that before. I would have thought that it would always be good to have the latest version. Anyway, that was not the reason for mero use rpi-update, I did it while I was following tutorials to get the serial port working which is absolutely required for me.

    Oh, and on the other Pi everything is working after all! With the same configuration except for my custom scripts for datalogging.

     – Domme Aug 08 '16 at 12:50
  • If you want to get serial working see How-do-i-make-serial-work-on-the-raspberry-pi3 It is unfortunate that the Foundation makes undocumented changes to implementations, without adequate documentation, but installing bleeding edge testing software only makes it worse. I am sure Predictable (sic) Network Interface Names will be with us in future, but hopefully it will have appropriate changes in networking files to make it work. – Milliways Aug 08 '16 at 12:58

4 Answers4

2

You can create systemd.link file like /etc/systemd/network/25-eth0.link

Universal file for Raspbery Pi 3B (probably on other revisions it will be the same or similar) it can be like this:

[Match]
Driver=smsc95xx
Path=platform-3f980000.usb-usb-0:1.1:1.0
#MACAddress=b8:27:eb:??:??:??

[Link]
Description=Raspberry Pi embedded SMSC9512/9514 Fast Ethernet Adapter
Name=eth0

To check Driver and Path options for specific device (eth0 here) you can use udevadm info -q all /sys/class/net/eth0 (add -a to see all ancestors).

Instead of Driver and Path directives you can use MACAddress value, but it will be unique for all devices.

For other devices (like wlan0) you can create similar .link file. Wireless devices usually has Type=wlan (udev DEVTYPE entry):

[Match]
Type=wlan
Driver=brcmfmac
Path=platform-3f300000.mmc
#MACAddress=b8:27:eb:??:??:??

[Link]
Description=Raspberry Pi embedded Wireless Adapter
Name=wlan0

For more info see man systemd.link.

Mikhail
  • 21
  • 2
1

It sounds like the next version of Raspbian/Debian may be moving to "predictable network interface names" -- which will throw a lot of people for a loop, but should prevent problems like this. Maybe. Anyway, as mentioned there traditionally 'udev shipped support for assigning permanent "ethX" names to certain interfaces based on their MAC addresses' which you would think would be consistent on the Pi (the OEM prefix is the always the same as far as I've noticed), except obviously there is some glitch here, probably with it considering the slot as occupied already.

The way this currently seems to be achieved is via a script, /lib/udev/write_net_rules. While there's probably a better way (you could research this yourself), a hacky sort of solution would be to just disable the rule that invokes that; this is in /lib/udev/rules.d/75-persistent-net-generator.rules.

I notice there's a /lib/udev/rules.d/75-persistent-net-generator.rules.distrib; I believe adding that suffix disables that so perhaps this is something Raspbian has done. The only difference is the removal of excluding of eth*, wlan* and some other things (go figure). You might want to check if both those files are actually there.

As for the hacky solution, just move both files or add a suffix like .disabled. This may be prone to getting replaced by system updates, so the "better solution" would be to write your own rule to override this one and put it in /etc/udev/rules.d -- but I don't know how it should go in this case.

I can't promise the hacky solution won't cause you some form of grief but it is easy to undo (as long as you don't delete those files) and probably won't, as all this shouldn't matter on a Pi where there are likely only a couple of interfaces and they might as well keep the name the kernel gives them.

goldilocks
  • 58,859
  • 17
  • 112
  • 227
  • I suspect this is the cause, but I was waiting for the OP to respond before entering my own rant. On Ubuntu MATE 16.04 entering biosdevname=0 in cmdline.txt restores conventional behaviour. Of cause Ubuntu MATE 16.04 has abandoned traditional Debian network setup in favour of Network Manager, but Raspbian has also adopted an alternative dhcpcd. – Milliways Aug 08 '16 at 12:29
  • The biosdevname thing is definitely worth trying; it is presumably a flag handed on to init, which I think on Ubuntu 16 is now also systemd, and applied to udev. Apparently it is/was used on Redhat, and as per that you might want to try biosdevname=0 net.ifnames=0. – goldilocks Aug 08 '16 at 12:37
  • Yes should be biosdevname=0 net.ifnames=0 I worked from memory, and posted an incomplete "fix". – Milliways Aug 08 '16 at 12:40
  • Thanks to both of you, but I tried all of your suggestions and nothing stopped the OS from renaming eth0 to eth1. Anyway, I am now using eth1 instead (I initially forgot to enable auto eth1 and now it works as eth1... strange behaviour of the Pi though, because the LAN port didn't work out of the box and it confused me a lot. But I am happy that I could make it work somehow. – Domme Aug 08 '16 at 12:46
  • It seems biosdevname=0 net.ifnames=0 no longer works following an apt-get upgrade :( - more details here: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1593379 - still looking for a solution :( – Hackeron Sep 05 '16 at 18:58
0

Install one of the standard supported Foundation images and DO NOT run rpi-update.

Milliways
  • 59,890
  • 31
  • 101
  • 209
  • On the other Pi it's working even though I updated. And it was required for me to get the serial port running. – Domme Aug 08 '16 at 12:54
0

Did you duplicate the sd card from one to the other--after it had been booted and used in the first?

I found that you can edit: /etc/udev/rules.d/70-persistent-net.rules which is where PredictableNetworkInterfaceNames seem to be stored. It had eth0 and an eth1 in there after moving a micro sd card to a new system. I removed all the eth0/1 and wlan0/1 entries, and it then went back to 'normal' after rebooting.

user80834
  • 1