[Solved] Raspbian stretch - how do I restore original Ethernet names

[Yoramro]

Hi,

Just installed the new Raspbian stretch.
I was surprised to find out that the system is assigning new Ethernet interfaces names based on MAC address instead of eth0: eth1: etc.
what needs to be done to restore the names to the originals?

Thanks

Yoram

[beta-tester]

me too... i have the same issue...

is the naming style the new standard from now or is it by accident?

if i have multiple Ethernet adapters, how can i figure out, what is the built-in network adapter now?
i have a script, that was working with eth0. now it is broken because of the new naming style.
who can i find the internal Ethernet adapter (eth0), the second (eth1), ..., without knowing its MAC?

[fruitoftheloom]

https://www.debian.org/releases/stable/ ... face-names

https://www.freedesktop.org/wiki/Softwa ... faceNames/

[Martin Frezman]

You can turn this "feature" off. A few clicks of the google should get you to a page showing 3 different methods (take your pick) of disabling this.

[beta-tester]

You can turn this "feature" off. A few clicks of the google should get you to a page showing 3 different methods (take your pick) of disabling this.

but for me this is not a solution, because my script should run on several different RPis, without knowledge of their MAC addresses and without possibility to reconfigure and restart network adapters. the script needs to catch the RPi built-in ethernet adapter.

[Heater]

Not sure if this helps but one can add a virtual Ethernet interfaces on top of an existing hardware interface.

Code: Select all

$ ip link add link enb827eb351305 name eth0 type macvlan

After that any script using eth0 should (might) work.

[beta-tester]

Not sure if this helps but one can add a virtual Ethernet interfaces on top of an existing hardware interface.

Code: Select all

$ ip link add link enb827eb351305 name eth0 type macvlan

After that any script using eth0 should (might) work.

no, does not help, because that would need to prepare the RPi first, to be able to use the script.
but the script has to work out of the box under all conditions, without previous preparations.

ok, i think i open a new thread for my specific problem with a better title.
viewtopic.php?f=28&t=191052

[dliloch]

wlan0 is a short name how was it done for wlan0?

[epoch1970]

viewtopic.php?f=63&t=172250&p=1102336

So the storm is coming after all.

This "fooMACaddress" as fallback policy for predictable names is so weak it is laughable.
And among the many benefits of this very predictable but slightly intractable naming scheme, the bonus that names are actually difficult to guess

This feature is toxic on Pi.
I call for an rpi-netmods package that would install automatically one of the methods documented for disabling this.

[Yoramro]

All,
Thanks for the help

I can confirm that adding net.ifnames=0 at /boot/cmdline.txt restores behavior to the previous one.
This means that the Raspberry Pi Ethernet port is eth0: and any additional Ethernet over USB is eth1: eth2: etc.
wlan0: is not affected

BR

Yoram

[elkberry]

This feature is toxic on Pi.
I call for an rpi-netmods package that would install automatically one of the methods documented for disabling this.

"Those responsible for the sacking have been sacked"

But seriously, the MAC-based scheme is so far from operational reality, I can't understand how someone can seriously invent such broken and far-fetched schemes. For punishment, they shall maintain industrial automation systems configured with this naming scheme crap and constantly swap network interfaces. If the default would be path-based I could have understood that. But MAC-based? Did they ever have to use that scheme themselves?

[XueHai8]

This sucks.
It breaks hundreds of client installations.

Did ANYONE think about the millions of Bash Scripts with 'eth0' used in them?
Like for iptables?

[PeterO]

The issue here is that the new naming scheme is designed to solve an enterprise level problem i.e. big hosts with multiple ethernet interfaces, a problem that just does not exist on a PI.

It should be turned off by default as this "solution" it is clearly causing problems where none actually exists.

PeterO

[hippy]

But seriously, the MAC-based scheme is so far from operational reality, I can't understand how someone can seriously invent such broken and far-fetched schemes.

The idea itself is sound - I have run into the issues it is intended to overcome. The problem is that it's a change rather than addition, and quite a major change.

If they had provided well defined names alongside the traditional names there would have been no issue. Users with single same type interfaces would not have had a problem, would probably have just shrugged regarding the change. Users with multiple interfaces could choose to live with the old naming and risks involved or migrate to the new scheme. Everyone would have been happy.

Unfortunately they seem to have taken a one or the other approach rather than catering for both audiences, and seem to have not given much weight to the fact that most non-enterprise users likely only have one interface of each type.

Added: While it is a one or the other approach - well defined names can be enabled or disabled - it does seem they provided a mechanism to link 'easily rememberable names' to well define names. The problem may therefore more be that this does not appear to be automatically done; there will be no 'eth0' without manually creating it -

https://www.freedesktop.org/software/sy ... .link.html

[epoch1970]

Users with multiple interfaces could choose to live with the old naming and risks involved or migrate to the new scheme. Everyone would have been happy.

History is too fresh to be rewritten yet.
There was no "risk" using multiple interfaces because the way to set distinguishable names was to add udev rules to name your interfaces according to MAC address. Udev did that automatically for the first interfaces, in 70-persistent-net-rules.
People with dancing interfaces or extra needs would lookup the issue and find the solution in some wiki, and extend these rules using device serial no. or whatever.

It's been working like that for years.
There is no excuse to inventing a formula as stupid as prefixing foo to the MAC address and call that a predictable device name.
There is no excuse to being aware of the impending disaster months in advance and letting it roll out in the new release.

For my part, I'll be looking seriously at BSD on the Pi in 2018.

[hippy]

There was no "risk" using multiple interfaces because the way to set distinguishable names was to add udev rules to name your interfaces according to MAC address.

That I agree is a fair point.

There is no excuse to inventing a formula as stupid as prefixing foo to the MAC address and call that a predictable device name.

I don't think it is stupid as it does seem to me to do exactly what it is intended to do, but I'm not here to defend that decision.

There is no excuse to being aware of the impending disaster months in advance and letting it roll out in the new release.

I must admit that I have wondered why no one at the Foundation, any of those beta testing or already upgraded to Stretch, had reported any problems or concerns relating to this issue, when it does seem to be a major problem and inconvenience for many. It does seem to have taken every one by surprise.

For my part, I'll be looking seriously at BSD on the Pi in 2018.

I don't feel it's so much of a problem to take any decision now. The predictable naming can already be easily turned off and the Foundation indicates it will be in forthcoming installations. I will let them decide what the future holds before I consider whether I will change to something else.

[jojopi]

If they had provided well defined names alongside the traditional names there would have been no issue.

Except for every existing program that deals with network interfaces, which would suddenly see twice as many and have no reason to suspect that half of them are duplicates. Your proposal requires changing the kernel interface, and everything that uses it.

(Link allows you to rename an interface, or create side interfaces such as vlans and bridges. It does not give an interface two names.)

There was no "risk" using multiple interfaces because the way to set distinguishable names was to add udev rules to name your interfaces according to MAC address. Udev did that automatically for the first interfaces, in 70-persistent-net-rules.

Anything that requires manual udev rules is unusably broken. The auto-generated rules were okay, but there was no guarantee they would be the same across multiple installs. (If you had upgraded to stretch instead of reinstalling, you would still have your persistent eth0 rule from jessie.)

I was going to agree with everyone that it is crazy for Debian to add NamePolicy=mac, when the default in upstream systemd and other distros is never to use mac. However, it turns out that Debian have not added mac to NamePolicy. Instead they have a custom udev rule that applies only to USB NICs.

For all non-Pi platforms, this is actually quite a good default. If you have a USB NIC, you are probably using it intermittently, and you would not expect it to be firewalled differently, say, depending on which port you plug it in.

[Martin Frezman]

I think the real salient point here - as mentioned by someone on either this or one of the many related threads - is that it never got noticed during the (fairly long) development/testing phase. Yet it was noticed almost immediately upon "release".

Of course, these things do happen - nobody is saying otherwise - but this one seems kinda obvious - it seems weird that something like this escaped notice.

[drgeoff]

- it seems weird that something like this escaped notice.

Same kind of 'weird' as the USB issues when RPis were first released. Despite apparently 50 to 100 pre-production ones being in the hands of testers beforehand, that lots of paying customers* immediately on receipt found that their USB keyboards did not work properly came as a complete surprise to RPF.

(* myself included)

[hippy]

Thinking about it ... Most users beta-testing Stretch or installing early have probably gone through an upgrade rather than install process. From what I have read, that won't bring in any predictable name changes. That could explain why it wasn't spotted by those folk.

[Martin Frezman]

Thinking about it ...

Yes, but that underscores a problem: That what you get by "upgrading" from a previous version is not the same as what you get with a "fresh" install. This to me is a bad state of affairs - for a variety of what should be pretty obvious reasons.

But that in turn underscores a need for testing both modes - not just the "upgrade" path.

[DougieLawson]

Thinking about it ... Most users beta-testing Stretch or installing early have probably gone through an upgrade rather than install process. From what I have read, that won't bring in any predictable name changes. That could explain why it wasn't spotted by those folk.

That's absolutely correct. I have eight machines running Stretch with eth0/wlan0. I'm going to strip the /etc/network/interfaces file down to match the one shipped with Stretch to get the predictable names stuff running as that seems to be the direction that ALL distros (RedHat, SuSE, Ubuntu, Debian) are heading in and as far as I'm concerned is a good thing rather than anything retrograde.

That won't happen until next week when I'm home from America.

[hippy]

But that in turn underscores a need for testing both modes - not just the "upgrade" path.

Indeed. I would expect the issue got overlooked, or forgotten about, that 'it works okay for me, works for everyone here, works for everyone else, including people like Dougie who have multiple Pi's in various configurations' led to a belief that there was not and would not be such an issue upon release.

It happens and I'm sympathetic because I've been there myself. I am sure those involved in the release were more surprised than anyone, are already reflecting on how and why the issue came about, what lessons need to be learned.

[Mary2018]

I'm very disappointed with all this problem. Please can someone tell me which file I have to change so the wifi can work. I thank you VERY much, because I do not understand anything about networking.

[RedLyons]

I found this page trying to find out how to disable the predictable network names, but did not find an easy solution, so here is the easy solution I found.

In raspi-config under the Network Options, it will enable/disable predictable network names, and after searching that code, all it is doing is executing this command:

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