wildbillnj1975
Posts: 31
Joined: Mon Apr 17, 2017 12:39 pm

predictable interface names failing in Stretch

Thu Sep 07, 2017 9:01 pm

I have read a few things about the predictable interface naming in Raspbian Stretch, and a few of them mentioned that "predictable interface names are failing in Raspbian Stretch, a new image will be released soon". I realize Pi Towers isn't responsible for Raspbian, but can somebody address the issue here in the forums? Perhaps suggest a workaround?

BTW, considering that Stretch has been released, you may want to add a new Sticky topic for wifi issues specifically related to this new version. The old "wifi problems" thread has already been locked. You could maybe re-title that (e.g. "pre-Stretch"), so users like me don't waste our time looking for the Stretch issue there.

SurferTim
Posts: 1769
Joined: Sat Sep 14, 2013 9:27 am
Location: Miramar Beach, Florida

Re: predictable interface names failing in Stretch

Thu Sep 07, 2017 9:09 pm

If you want eth0 back, edit /boot/cmdline.txt. Add to the end of the one long line in that file
net.ifnames=0
Reboot.

Edit: There is a caveat with doing this. It makes using two ethernet or wifi devices difficult if not impossible.

User avatar
B.Goode
Posts: 8987
Joined: Mon Sep 01, 2014 4:03 pm
Location: UK

Re: predictable interface names failing in Stretch

Thu Sep 07, 2017 10:34 pm

I hadn't seen that this feature was failing. I thought that the most common feedback was that it was working too well?

There are already 2 published workarounds if predictable interface names are not what you want and seek to revert to the behaviour used by the Wheezy and Jessie releases of Raspbian.

SurferTim
Posts: 1769
Joined: Sat Sep 14, 2013 9:27 am
Location: Miramar Beach, Florida

Re: predictable interface names failing in Stretch

Thu Sep 07, 2017 10:39 pm

B.Goode wrote:
Thu Sep 07, 2017 10:34 pm
I hadn't seen that this feature was failing. I thought that the most common feedback was that it was working too well?

There are already 2 published workarounds if predictable interface names are not what you want and seek to revert to the behaviour used by the Wheezy and Jessie releases of Raspbian.
Do you have a link to those workarounds? I'd like to take a look at them.

Martin Frezman
Posts: 1020
Joined: Mon Oct 31, 2016 10:05 am

Re: predictable interface names failing in Stretch

Fri Sep 08, 2017 12:25 am

Edit: There is a caveat with doing this. It makes using two ethernet or wifi devices difficult if not impossible.
Can you say a little more about this? This is the first I've heard of it.
If this post appears in the wrong forums category, my apologies.

SurferTim
Posts: 1769
Joined: Sat Sep 14, 2013 9:27 am
Location: Miramar Beach, Florida

Re: predictable interface names failing in Stretch

Fri Sep 08, 2017 12:41 am

Martin Frezman wrote:
Edit: There is a caveat with doing this. It makes using two ethernet or wifi devices difficult if not impossible.
Can you say a little more about this? This is the first I've heard of it.
Sure. I was trying to use two wifi devices, one as an AP, the other as a client. Mucho trouble until I removed the net.ifnames=0 statement. Here is the thread. The part you will be interested in is on page 2.
viewtopic.php?f=36&t=191453

User avatar
B.Goode
Posts: 8987
Joined: Mon Sep 01, 2014 4:03 pm
Location: UK

Re: predictable interface names failing in Stretch

Fri Sep 08, 2017 7:14 am

SurferTim wrote:
Thu Sep 07, 2017 10:39 pm
B.Goode wrote:
Thu Sep 07, 2017 10:34 pm
I hadn't seen that this feature was failing. I thought that the most common feedback was that it was working too well?

There are already 2 published workarounds if predictable interface names are not what you want and seek to revert to the behaviour used by the Wheezy and Jessie releases of Raspbian.
Do you have a link to those workarounds? I'd like to take a look at them.
Passing a kernel parameter of net.ifnames=0 is one.

The other is to intervene in the systemd startup flow as described in this thread: viewtopic.php?f=66&t=192393

wildbillnj1975
Posts: 31
Joined: Mon Apr 17, 2017 12:39 pm

Re: predictable interface names failing in Stretch

Fri Sep 08, 2017 12:46 pm

I don't want to override the "predictable interface names" feature. It's not working on new installs of Stretch on 0W and 3B models.
For example, I have Stretch Lite installed in a 0W (I used Etcher to write the uSD card), and instead of e.g. wlxb827eb9ff7aa I have wlan0. And I do not have net.ifnames=0 in /boot/cmdline.txt.

Since I'm not installing any X, I am following the guide at https://www.raspberrypi.org/documentati ... ess-cli.md to set up wifi via the command line. I added the block to wpa_supplicant (exactly as generated by wpa_passphrase):

Code: Select all

country=US
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
        ssid="<my ssid>"
        #psk="<my passphrase>"
        psk=<generated hex hash from wpa_passphrase>
}
And I added the static block to /etc/dhcpcd.conf:

Code: Select all

interface wlan0
static ip_address=192.168.1.129
static routers=192.168.1.1
static domain_name_servers=71.250.0.12 68.237.161.12
Following the guide, I tried to force it to connect to the network with "sudo wpa_cli reconfigure", but that did not work. No connection at all.
I had to reboot to get an IP.

Curiously, this worked. I swear, yesterday, I was getting errors. Now, it's ok (other than the inconvenience of rebooting, which means I can't do my initial setups on multiple Pis via one nifty script).

In another thread, viewtopic.php?t=191061, I saw the comment from ShiftPlusOne (14th comment, August 14th 12:30pm), but I don't know if that means specifically for the "missing ctrl_interface line" issue. When he said
"the next image will disable them by default"
, I assumed it meant there's a more serious problem that couldn't be resolved by simply editing the config file. (My Stretch Lite image is dated 8/16, so maybe I have the fixed version?)

User avatar
B.Goode
Posts: 8987
Joined: Mon Sep 01, 2014 4:03 pm
Location: UK

Re: predictable interface names failing in Stretch

Fri Sep 08, 2017 12:58 pm

I have Stretch Lite installed in a 0W (I used Etcher to write the uSD card), and instead of e.g. wlxb827eb9ff7aa I have wlan0. And I do not have net.ifnames=0 in /boot/cmdline.txt.
Isn't that the expected behaviour?

As I understand it, the new predictable names feature applies to usb devices, and on an RPi ZeroW the built-in wlan adaptor is not a usb device.

SurferTim
Posts: 1769
Joined: Sat Sep 14, 2013 9:27 am
Location: Miramar Beach, Florida

Re: predictable interface names failing in Stretch

Fri Sep 08, 2017 1:00 pm

My onboard wifi interface show as wlan0. If I add a second usb wifi interface, the onboard interface shows as wlan1 and the usb wifi interface shows as wlan0. edit: if I have net.ifnames=0 in /boot/cmdline.txt.

You don't override the predictable interface names (eth0). You must add a parameter to /etc/cmdline.txt to use them.

If you are using only one of each type interface device, adding "net.ifnames=0" allows you to use eth0 instead of enx12345...

If I do not have the "net.ifnames=0", then the onboard wifi is always wlan0, and the usb wifi shows as wlx12345...

Martin Frezman
Posts: 1020
Joined: Mon Oct 31, 2016 10:05 am

Re: predictable interface names failing in Stretch

Fri Sep 08, 2017 1:54 pm

I assumed it meant there's a more serious problem that couldn't be resolved by simply editing the config file. (My Stretch Lite image is dated 8/16, so maybe I have the fixed version?)
Not necessarily. I think they just think it will be less confusing for the newb this way.

And I agree. Even if the "predictable" thingie is actually a good thing (and no less an authority than DL says it is is), it is still confusing and weird for a first time user. You're always free to undo whatever they do yourself if you prefer the feature to be on.
If this post appears in the wrong forums category, my apologies.

User avatar
B.Goode
Posts: 8987
Joined: Mon Sep 01, 2014 4:03 pm
Location: UK

Re: predictable interface names failing in Stretch

Fri Sep 08, 2017 2:04 pm

My Stretch Lite image is dated 8/16, so maybe I have the fixed version?
No. That is the original release of Raspbian Stretch which introduced the change of behaviour being discussed here.

A more recent release is now available, dated 7th or 8th September 2017, for which the Release Notes say:

Code: Select all

2017-09-07:
  * Disable predictable network interface names for Ethernet devices
  * Bug fix for keyboard settings dialog in Raspberry Pi Configuration
  * Bug fix for crash on some videos and animations in Chromium
  * Bug fix for taskbar crash when running RealVNC server
  * Bug fix for reloading projects with extensions in Scratch 2
  * Bug fix for MAC address problem in Bluetooth
  * Simple mode and new icons in Thonny
  * New Japanese translations in Raspberry Pi Configuration
  * Install fonts-droid-fallback for international fonts

User avatar
bensimmo
Posts: 4187
Joined: Sun Dec 28, 2014 3:02 pm
Location: East Yorkshire

Re: predictable interface names failing in Stretch

Fri Sep 08, 2017 2:24 pm

I wonder if they have thought of adding a raspi-config to turn them back on for anyone that may need them.

For me I'm happy they are not default, as I makes it consistent through the Pi's and chopping and changing wi-fi dongles in a school/jam/club etc.

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6084
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: predictable interface names failing in Stretch

Fri Sep 08, 2017 2:28 pm

bensimmo wrote:
Fri Sep 08, 2017 2:24 pm
I wonder if they have thought of adding a raspi-config to turn them back on for anyone that may need them.

For me I'm happy they are not default, as I makes it consistent through the Pi's and chopping and changing wi-fi dongles in a school/jam/club etc.
Of course. The reason that option isn't there is that predictable interface names and dhcpcd don't play nicely together. Sometimes dhcpcd grabs and interface and the rename fails.

wildbillnj1975
Posts: 31
Joined: Mon Apr 17, 2017 12:39 pm

Re: predictable interface names failing in Stretch

Fri Sep 08, 2017 4:48 pm

B.Goode wrote:
Fri Sep 08, 2017 12:58 pm
I have Stretch Lite installed in a 0W (I used Etcher to write the uSD card), and instead of e.g. wlxb827eb9ff7aa I have wlan0. And I do not have net.ifnames=0 in /boot/cmdline.txt.
Isn't that the expected behaviour?

As I understand it, the new predictable names feature applies to usb devices, and on an RPi ZeroW the built-in wlan adaptor is not a usb device.
AHA! Somewhere in all the words written about this feature, I missed that specific tidbit - that it only applies to USB devices (and specifically because of the vagaries of hotplugging).
That makes perfect sense.

User avatar
DougieLawson
Posts: 36570
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: predictable interface names failing in Stretch

Sat Sep 09, 2017 3:04 pm

ShiftPlusOne wrote:
Fri Sep 08, 2017 2:28 pm
bensimmo wrote:
Fri Sep 08, 2017 2:24 pm
I wonder if they have thought of adding a raspi-config to turn them back on for anyone that may need them.

For me I'm happy they are not default, as I makes it consistent through the Pi's and chopping and changing wi-fi dongles in a school/jam/club etc.
Of course. The reason that option isn't there is that predictable interface names and dhcpcd don't play nicely together. Sometimes dhcpcd grabs and interface and the rename fails.
I've been discussing this
https://github.com/RPi-Distro/pi-gen/co ... 79e546471a
but haven't had a chance to hack about with /usr/lib/dhcpcd5/dhcpcd to add a delay before it starts (to give predictable names to complete the rename). [Been too busy away from home doing my day job this week.]
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

SurferTim
Posts: 1769
Joined: Sat Sep 14, 2013 9:27 am
Location: Miramar Beach, Florida

Re: predictable interface names failing in Stretch

Sat Sep 09, 2017 3:41 pm

The new release 2017-09-07-stretch seems to work ok. It has the predictable interface names enabled as the default now. I'm still torture testing it.

DirkS
Posts: 10017
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

Re: predictable interface names failing in Stretch

Sat Sep 09, 2017 3:51 pm

SurferTim wrote:
Sat Sep 09, 2017 3:41 pm
The new release 2017-09-07-stretch seems to work ok. It has the predictable interface names enabled disabled as the default now. I'm still torture testing it.
FTFY

SurferTim
Posts: 1769
Joined: Sat Sep 14, 2013 9:27 am
Location: Miramar Beach, Florida

Re: predictable interface names failing in Stretch

Sat Sep 09, 2017 4:01 pm

DirkS wrote:
SurferTim wrote:
Sat Sep 09, 2017 3:41 pm
The new release 2017-09-07-stretch seems to work ok. It has the predictable interface names enabled disabled as the default now. I'm still torture testing it.
FTFY
Maybe I misunderstood. Is the predictable interface name eth0?

DirkS
Posts: 10017
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

Re: predictable interface names failing in Stretch

Sat Sep 09, 2017 4:04 pm

SurferTim wrote:
Sat Sep 09, 2017 4:01 pm
DirkS wrote:
SurferTim wrote:
Sat Sep 09, 2017 3:41 pm
The new release 2017-09-07-stretch seems to work ok. It has the predictable interface names enabled disabled as the default now. I'm still torture testing it.
FTFY
Maybe I misunderstood. Is the predictable interface name eth0?
No, the new naming (enxetcetera) is the predictable one, because it's linked to known parameters, like MAC address, etc
With ethx and multiple devices, IDs canchange after a reboot.

SurferTim
Posts: 1769
Joined: Sat Sep 14, 2013 9:27 am
Location: Miramar Beach, Florida

Re: predictable interface names failing in Stretch

Sat Sep 09, 2017 4:07 pm

Oh, I had it backwards. The older version of Stretch worked great with the predicable interface names.

Edit: Then it is the "unpredictable" interface names that seem to be more predictable now with the new version. The onboard interfaces appear to be starting first, and getting eth0 and wlan0.

If you like predictable interface names, you will not like the newest version of Stretch.

Martin Frezman
Posts: 1020
Joined: Mon Oct 31, 2016 10:05 am

Re: predictable interface names failing in Stretch

Sat Sep 09, 2017 4:35 pm

The term "predictable naming" is completely Orwellian.

Using this terminology will lead to nothing but confusion.

Better to just call it "the new, MAC-address-based, naming convention".
If this post appears in the wrong forums category, my apologies.

SurferTim
Posts: 1769
Joined: Sat Sep 14, 2013 9:27 am
Location: Miramar Beach, Florida

Re: predictable interface names failing in Stretch

Sat Sep 09, 2017 4:40 pm

Martin Frezman wrote:
Sat Sep 09, 2017 4:35 pm
The term "predictable naming" is completely Orwellian.

Using this terminology will lead to nothing but confusion.

Better to just call it "the new, MAC-address-based, naming convention".
I like that better. If you like "the new, MAC-address-based, naming convention", you will not like the default naming convention in the 2017-09-07 version. Does anybody know how to go back to the "the new, MAC-address-based, naming convention"?

Martin Frezman
Posts: 1020
Joined: Mon Oct 31, 2016 10:05 am

Re: predictable interface names failing in Stretch

Sat Sep 09, 2017 4:53 pm

I like that better. If you like "the new, MAC-address-based, naming convention", you will not like the default naming convention in the 2017-09-07 version. Does anybody know how to go back to the "the new, MAC-address-based, naming convention"?
1) I don't like it. The first thing I did after installing the August version of Stench was to put the "net.ifnames=0" thing in cmdline.txt

2) If you do install the September version and find that you want the Mac-address-based convention back, then you have to read whatever docs are out on the Internet, figure out which particular symlink they (the Raspbian maintainers) used, and remove that symlink.

Naturally, I think just adding or removing "net.ifnames=0" is a lot simpler than hunting around for some obscure symlink, but c'est la vie.
If this post appears in the wrong forums category, my apologies.

DirkS
Posts: 10017
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

Re: predictable interface names failing in Stretch

Sat Sep 09, 2017 4:55 pm

SurferTim wrote:
Sat Sep 09, 2017 4:40 pm
Martin Frezman wrote:
Sat Sep 09, 2017 4:35 pm
The term "predictable naming" is completely Orwellian.

Using this terminology will lead to nothing but confusion.

Better to just call it "the new, MAC-address-based, naming convention".
I like that better. If you like "the new, MAC-address-based, naming convention", you will not like the default naming convention in the 2017-09-07 version. Does anybody know how to go back to the "the new, MAC-address-based, naming convention"?
Well, if MAC address was the only parameter used that would work, but as usual it's a bit more complicated.
From https://www.freedesktop.org/wiki/Softwa ... quote]With systemd 197 we have added native support for a number of different naming policies into systemd/udevd proper and made a scheme similar to biosdevname's (but generally more powerful, and closer to kernel-internal device identification schemes) the default. The following different naming schemes for network interfaces are now supported by udev natively:

1 Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
2 Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
3 Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
4 Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
5 Classic, unpredictable kernel-native ethX naming (example: eth0)
By default, systemd v197 will now name interfaces following policy 1) if that information from the firmware is applicable and available, falling back to 2) if that information from the firmware is applicable and available, falling back to 3) if applicable, falling back to 5) in all other cases. Policy 4) is not used by default, but is available if the user chooses so.

This combined policy is only applied as last resort. That means, if the system has biosdevname installed, it will take precedence. If the user has added udev rules which change the name of the kernel devices these will take precedence too. Also, any distribution specific naming schemes generally take precedence.[/quote]

Return to “Troubleshooting”