[Solved] network interface predictable naming changed?

amish · 2018-03-13 02:57:12

[Edit: solved][Fixed upstream]

Upstream bug report:
Git issue: https://github.com/systemd/systemd/issues/8446
Git PR: https://github.com/systemd/systemd/pull/8458
Git commit: https://github.com/systemd/systemd/comm … 24559b94a4
Culprit commit: https://github.com/systemd/systemd/comm … 8d9e07L298

Today after update to systemd 238.0-3 my system had no network.

I realized that interface names had changed completely.

Earlier wlan0 was renamed to wls1 and eth0 was renamed to ens5

Mar 13 06:22:04 amish kernel: sky2 0000:85:00.0 ens5: renamed from eth0
Mar 13 06:22:04 amish kernel: iwlwifi 0000:02:00.0 wls1: renamed from wlan0

Now wlan0 is renamed to wlp2s0 and eth0 is renamed to enp133s0

Mar 13 08:00:54 amish kernel: sky2 0000:85:00.0 enp133s0: renamed from eth0
Mar 13 08:00:54 amish kernel: iwlwifi 0000:02:00.0 wlp2s0: renamed from wlan0

This broke my networking as well as iptables rules. (had to rewrite them all)

Did something change in JUST my system or this change was global and planned?

Lucky that this happened to my local system and I was able to update network configuration accordingly.

and lucky that I didnt update one remote system otherwise would have lost access to it completely.

I thought when systemd changed from eth convention to en* wl* convention that was meant to keep name persistent/predictable.

If this change was by systemd then its going to break many systems and interface name assumptions.

I suppose I better switch back to udev based FIXED (assigned by me) naming to avoid any such issues ever happening again.

Last edited by amish (2018-03-29 02:54:51)

seth · 2018-03-13 08:55:56

The following different naming schemes for network interfaces are now supported by udev natively:
Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
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.

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

amish · 2018-03-13 09:06:36

I know that.

What I meant to say is before systemd 238.0 the same cards were named as ens5 and wls0

Now with systemd 238.0 they are named even more weirdly. (enp133s0 and wlp2s0)

It appears that something has changed in algorithm to "create" name.

This should not have happened because such changes no more make them predictable.

Last edited by amish (2018-03-13 09:26:55)

seth · 2018-03-13 09:30:38

What changes is pretty much likely that "Firmware/BIOS provided PCI Express hotplug slot index numbers" is not (no longer?) given, ie. something in your Hardware; BIOS/UEFI; or the kernel.
There could indeed be a bug in systemd, but you need to isolate that, ie. downgrade *only* systemd in order to be sure.

amish · 2018-03-13 10:29:07

Umm.. no I chose easier way to fix, put the names in udev rules.

Unfortunately have no time to isolate.

pacman logs shows only following package upgrades done today:

[2018-03-13 06:34] [ALPM] upgraded libsystemd (237.64-1 -> 238.0-3)
[2018-03-13 06:34] [ALPM] upgraded device-mapper (2.02.177-4 -> 2.02.177-5)
[2018-03-13 06:34] [ALPM] upgraded cryptsetup (2.0.1-1 -> 2.0.2-1)
[2018-03-13 06:34] [ALPM] upgraded e2fsprogs (1.43.9-1 -> 1.44.0-1)
[2018-03-13 06:34] [ALPM] upgraded dhcp (4.4.1-2 -> 4.4.1-4)
[2018-03-13 06:34] [ALPM] upgraded git (2.16.2-1 -> 2.16.2-2)
[2018-03-13 06:34] [ALPM] upgraded lvm2 (2.02.177-4 -> 2.02.177-5)
[2018-03-13 06:34] [ALPM] upgraded systemd (237.64-1 -> 238.0-3)
[2018-03-13 06:34] [ALPM] upgraded systemd-sysvcompat (237.64-1 -> 238.0-3)

So highly likely to be systemd.

But I wonder if its only me... as noone else seems to have reported it.

But anyway ...

Trilby · 2018-03-13 10:41:07

It's ok to not care to track down an issue, but then why post here? You either care or you don't, you can't have it both ways. You want someone else to help pinpoint a problem that you are having when you will not even do a ridiculously trivial and simple test of downgrading and rebooting once?

Don't expect anyone here to be jumping at the chance to solve your problem for you.

amish · 2018-03-13 12:00:34

Buddy, why are you going offensive?

I reported for others... not for me. That such and such issue has happened for me and if it happens with you too then this is cud be the reason and this might be a solution. Also for those who have still not updated and may know that such an issue may popup.

In my first post itself its clear that I had resolved the problem. i.e. I was not looking for any help or solution for this case. (But yes Arch community is very helpful and I appreciate it)

And as I said unfortunately I have no time to isolate and debug (you dont even know the reason why I dont have time)

So please dont come to conclusion that I do not want to help and do trivial tasks.

Its not compulsory to post here only if there is problem and only to find solution.

Intention could be a precautionary post too.

Thank you. And peace

seth · 2018-03-13 12:29:53

I'd say that most people never used the hotplug slot idx numbers itfp (very rough estimation from vague forum post recalls) - notice that this is not necessarily a software thing. If It failed from one boot to another and the only thing updated is more or less systemd, it's indeed likely a change in systemd. However, if you eg. booted windows inbetween (or by any other chance got an UEFI update) the cause may be different.

There've been two possibly commits 18 days ago, https://github.com/systemd/systemd/comm … n-net_id.c
If you have the time, you should check this and file a bug.

amish · 2018-03-13 14:11:22

There was no change to hardware. Also I dont have windows installed.

All I did was:
pacman -Syu

Whenever I see systemd or linux kernel or glibc update, I reboot the system immediately after update.

And then network was gone.

I did ifconfig -a and realized that predictable names have changed.

So changed the .network and wpa_supplicant accordingly and I was back online.

systemd commits above dont seem to change interface names, so no idea whats going on.

Whats weird is ethernet (wired interface) has bus number 133!!

Thats kind of huge number. (google search shows its normal and nothing new)

If I find anything interesting then I will report back else thats all from me

Last edited by amish (2018-03-13 14:16:51)

katsuki · 2018-03-13 14:32:43

I noticed this as well in my VMWare based Arch install; I did my first update since 2018-03-05 and pulled in both a new version of systemd and the linux kernel. My network interface changed from ens33 to enp2s1. I've rolled back to my snapshot for now as I don't have time to do any deep debugging. However, given this is a VM, experimentation is easy as I can roll back to my snapshot if the system is bricked. I might have time this evening to play around if there is anything someone wants me to try.

Docbroke · 2018-03-13 14:42:32

I like to have this "net.ifnames=0 biosdevname=0" as kernel parameter on all my computers, to have old nice eth0 / wlan0.

wopfel · 2018-03-13 16:49:05

Same experience for me in a Proxmox environment. After updating with pacman -Syu in 2 virtual machines, the VMs don't have network access since the adapter names have changed: before it was ens18, and now it's enp0s18.

Previous working environment:
linux 4.15.5-1
systemd 237.64-1

Now "broken" environment:
linux 4.15.8-1
systemd 238.0-3

I was able to easily fix it changing the Name= attribute in the [Match] section of the 25-wired.network file.

aleskva · 2018-03-13 19:06:01

Today I wanted to start create_ap to create WiFi hotspot for my mobile phone: `$ sudo create_ap wls1 ens5 hotspot_name password`. Yesterday it worked, but today it outputted: `ERROR: 'wls1' is not a WiFi interface`

I tried `ip link show` and got:

```
$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp133s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 1c:c1:de:a2:e7:b0 brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
link/ether f6:11:c8:52:a0:71 brd ff:ff:ff:ff:ff:ff
```

It seems to me something somehow renamed my internet interfaces. How? And why? How could I return it back? Should I return it back or leave it on this?

jasonwryan · 2018-03-13 19:34:13

Merging with the existing thread...

amish · 2018-03-14 00:54:43

Upstream bugreport. (not by me)
https://github.com/systemd/systemd/issues/8446

Can someone test by downgrading systemd to 237? And report there.

If no, then I might do it today evening i.e. after about 14 hours from now.

amish · 2018-03-14 05:31:12

Downgraded to 237.64 and it is indeed systemd issue.

Reported to systemd git issue tracker (linked above)

with 237.64

> journalctl -b 0 | grep renamed
Mar 14 10:21:49 amish kernel: sky2 0000:85:00.0 ens5: renamed from eth0
Mar 14 10:21:49 amish kernel: iwlwifi 0000:02:00.0 wls1: renamed from wlan0

with 238.0

> journalctl -b 0 | grep renamed
Mar 14 10:43:14 amish kernel: sky2 0000:85:00.0 enp133s0: renamed from eth0
Mar 14 10:43:14 amish kernel: iwlwifi 0000:02:00.0 wlp2s0: renamed from wlan0

So there is definitely change in name prediction

Last edited by amish (2018-03-14 05:32:11)

ninian · 2018-03-14 08:50:09

Docbroke wrote:

I like to have this "net.ifnames=0 biosdevname=0" as kernel parameter on all my computers, to have old nice eth0 / wlan0.

Absolutely, and it makes it much easier for programs such as Conky to display interface info.
I use the same Conky config across many Arch systems and having predictable eth0, wlan0 and wlan1 saves a lot of bother.

amish · 2018-03-16 01:56:24

The issue has been fixed in upstream.

For references in case ever required:

Git issue: https://github.com/systemd/systemd/issues/8446
Git PR: https://github.com/systemd/systemd/pull/8458
Git commit: https://github.com/systemd/systemd/comm … 24559b94a4

katsuki · 2018-03-28 13:33:35

I updated my VM this morning and everything works as expected.

wopfel · 2018-03-28 15:03:37

katsuki wrote:

I updated my VM this morning and everything works as expected.

Thanks for the hint, katsuki. I can confirm that with systemd version 238.51-1. I updated my VM just a few minutes ago.

[ALPM] upgraded systemd (238.0-3 -> 238.51-1)

Arch Linux

#1 2018-03-13 02:57:12

[Solved] network interface predictable naming changed?

#2 2018-03-13 08:55:56

Re: [Solved] network interface predictable naming changed?

#3 2018-03-13 09:06:36

Re: [Solved] network interface predictable naming changed?

#4 2018-03-13 09:30:38

Re: [Solved] network interface predictable naming changed?

#5 2018-03-13 10:29:07

Re: [Solved] network interface predictable naming changed?

#6 2018-03-13 10:41:07

Re: [Solved] network interface predictable naming changed?

#7 2018-03-13 12:00:34

Re: [Solved] network interface predictable naming changed?

#8 2018-03-13 12:29:53

Re: [Solved] network interface predictable naming changed?

#9 2018-03-13 14:11:22

Re: [Solved] network interface predictable naming changed?

#10 2018-03-13 14:32:43

Re: [Solved] network interface predictable naming changed?

#11 2018-03-13 14:42:32

Re: [Solved] network interface predictable naming changed?

#12 2018-03-13 16:49:05

Re: [Solved] network interface predictable naming changed?

#13 2018-03-13 19:06:01

Re: [Solved] network interface predictable naming changed?

#14 2018-03-13 19:34:13

Re: [Solved] network interface predictable naming changed?

#15 2018-03-14 00:54:43

Re: [Solved] network interface predictable naming changed?

#16 2018-03-14 05:31:12

Re: [Solved] network interface predictable naming changed?

#17 2018-03-14 08:50:09

Re: [Solved] network interface predictable naming changed?

#18 2018-03-16 01:56:24

Re: [Solved] network interface predictable naming changed?

#19 2018-03-28 13:33:35

Re: [Solved] network interface predictable naming changed?

#20 2018-03-28 15:03:37

Re: [Solved] network interface predictable naming changed?

Board footer