systemd, eth0 renamed as enxb827eb84edc9: why?

[DiTBho]

I am becoming crazy, a friend bought a RPI-3, which comes with a systemd-GNU/Linux image, and there is systemd, and I don't know why, the eth0 is renamed "enxb827eb84edc9"

annoying ...

any idea? 

[ataradov]

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

[golden_labels]

Also note that this is udev’s doing, not systemd’s. While udev has been incorporated into systemd, the latter as a whole is not responsible for the situation. And udev daemon may be provided by other software packages, like eudev.

The renaming is in full described in ataradov’s link, but shortly: it’s the network devices equivalent of UUIDs and “by-*” paths for storage media. A less annoying and reliable way to specify the device.

Out of curiosity: what was the friend using earlier? That change is like 2014 if not earlier.

[DiTBho]

Out of curiosity: what was the friend using earlier? That change is like 2014 if not earlier.

Gentoo-2011. Static dev-name, so there is no udev running.
I am studying systmed because I don't know it well.

Thanks guys, problem solved 

Code: [Select]

# ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.101  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::ba27:ebff:fe84:edc9  prefixlen 64  scopeid 0x20<link>
        inet6 2001:b07:5d37:d900:ba27:ebff:fe84:edc9  prefixlen 64  scopeid 0x0<global>
        ether b8:27:eb:84:ed:c9  txqueuelen 1000  (Ethernet)
        RX packets 7564  bytes 578980 (565.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4480  bytes 489060 (477.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 13  bytes 1823 (1.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 13  bytes 1823 (1.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:d1:b8:9c  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan1: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether 00:1d:0f:b1:b1:a6  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


[Monkeh]

A less annoying and reliable way to specify the device.

But despite the name, not readily predictable across varying hardware, which is incredibly annoying.

Also their default scheme can be easily proven broken, but they're entirely uninterested in feedback or improvement. Their way is perfect as implemented.

[madires]

Create /etc/systemd/network/10-eth0.link:

Code: [Select]

[Match]
MACAddress=11:22:33:44:55:66

[Link]
Name=eth0


[golden_labels]

I am studying systmed because I don't know it well.

Though in this case you will not learn much about systemd,⁽¹⁾ as that’s not related. Coincidently systemd, the project, adopted udev shortly before the introduction of predictable names. But the change is a part of a much wider movement to make Linux ecosystem more reliable and has nothing to do with udev being under the umbrella of a particular project.

But despite the name, not readily predictable across varying hardware, which is incredibly annoying.

Across varying hardware? How can a device name, that makes sense only on a single machine, be predictable across multiple of them? That’s not even specific to udev: old naming scheme was not having that property either.

Also their default scheme can be easily proven broken, but they're entirely uninterested in feedback or improvement. Their way is perfect as implemented.

Perhaps… anything concrete?

⁽¹⁾ Madires has proven above that something can still be learned.

[Monkeh]

But despite the name, not readily predictable across varying hardware, which is incredibly annoying.

Across varying hardware? How can a device name, that makes sense only on a single machine, be predictable across multiple of them? That’s not even specific to udev: old naming scheme was not having that property either.

Old scheme, single NIC: 'eth0'. New scheme, single NIC: 'fuck knows'.

Also their default scheme can be easily proven broken, but they're entirely uninterested in feedback or improvement. Their way is perfect as implemented.

Perhaps… anything concrete?

Any NIC with two or more ports on the same PCI function will break it.

[BrokenYugo]

But despite the name, not readily predictable across varying hardware, which is incredibly annoying.

Across varying hardware? How can a device name, that makes sense only on a single machine, be predictable across multiple of them? That’s not even specific to udev: old naming scheme was not having that property either.

Old scheme, single NIC: 'eth0'. New scheme, single NIC: 'fuck knows'.

This, it might make sense in a datacenter, but in my living room it's just another string of alphabet soup I have to deal with.

[ve7xen]

In your living room you don't need to know or care what the kernel's name for the device is... You click 'Wired Network Connection' and it comes up.

systemd-networkd at least allows configuring NICs either by type or by wildcarded names, or by MAC address if for some reason you need a machine-portable configuration or your hardware changes often.

[golden_labels]

Old scheme, single NIC: 'eth0'. New scheme, single NIC: 'fuck knows'.

Except… no? In the old scheme even on a single machine the name was random and could be eth1 on one boot and eth4 on another. Across multiple machines there was no predictability at all.

Any NIC with two or more ports on the same PCI function will break it.

No? They will get a different f-index. Which may still be unpredictable, if the adapter reports ports in random order, but that’s nothing that can be solved in a general manner and the old naming could not deal with that either.

This, it might make sense in a datacenter, but in my living room it's just another string of alphabet soup I have to deal with.

So… a bug should be introduced to “living-room implementations” that makes the names broken, because it’s not a datacenter? For… actually what, considering that to you it’s just “alphabet soup” anyway? Will you also oppose UUIDs or “by-*” hierarchy for mass storage, because your laptop only has a single device of that kind?

[Monkeh]

Old scheme, single NIC: 'eth0'. New scheme, single NIC: 'fuck knows'.

Except… no? In the old scheme even on a single machine the name was random and could be eth1 on one boot and eth4 on another. Across multiple machines there was no predictability at all.

Err? No, it wasn't random, they're allocated sequentially. If only one ethernet device is present, it will be eth0.

Any NIC with two or more ports on the same PCI function will break it.

No? They will get a different f-index. Which may still be unpredictable, if the adapter reports ports in random order, but that’s nothing that can be solved in a general manner and the old naming could not deal with that either.

There's no 'f' to index - f is function, if there is only one PCI function then both interfaces will get assigned the same name, which will break and leave the second interface with its original name. It's possible they've revised the scheme to resolve this in the years since I last wasted my time with it, of course..

[golden_labels]

Err? No, it wasn't random, they're allocated sequentially. If only one ethernet device is present, it will be eth0.

If there is only a single device present, then this is not even a subject of the discussion about naming interfaces. Why do you bring that up?

There's no 'f' to index - f is function, if there is only one PCI function then both interfaces will get assigned the same name, which will break and leave the second interface with its original name. It's possible they've revised the scheme to resolve this in the years since I last wasted my time with it, of course..

No indices, but functions? And “function” is expressed in the name as…

[Monkeh]

Err? No, it wasn't random, they're allocated sequentially. If only one ethernet device is present, it will be eth0.

If there is only a single device present, then this is not even a subject of the discussion about naming interfaces. Why do you bring that up?

.. how many ethernet interfaces does a Raspberry Pi have? Whether there is one interface or many, this naming scheme is used - and the outcome is not predictable even with only a single device.

There's no 'f' to index - f is function, if there is only one PCI function then both interfaces will get assigned the same name, which will break and leave the second interface with its original name. It's possible they've revised the scheme to resolve this in the years since I last wasted my time with it, of course..

No indices, but functions? And “function” is expressed in the name as…

When it's '0', it isn't.

Maybe I should fire up one of my example devices to demonstrate the flaw if it's still present.

[Ed.Kloonk]

Any NIC with two or more ports on the same PCI function will break it.

 

[magic]

Though in this case you will not learn much about systemd,⁽¹⁾ as that’s not related. Coincidently systemd, the project, adopted udev shortly before the introduction of predictable names. But the change is a part of a much wider movement to make Linux ecosystem more reliable and has nothing to do with udev being under the umbrella of a particular project.

coincidentally

This word is a well known far-right dog whistle and the whole paragraph sounds an awful lot like you are not a sincere supporter of LinuxⓇ on the Desktop™ but a troll mocking systemd's heroic effort and denying them credit for their work. I'm considering reporting this post for hate speech, just so you know that you can't get away with it here.

Create /etc/systemd/network/10-eth0.link:

Code: [Select]

lots of systemd nonsense which will stop working in the next release

Here's a much faster solution that has been working for me since forever:

Code: [Select]

ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules

[ve7xen]

Err? No, it wasn't random, they're allocated sequentially. If only one ethernet device is present, it will be eth0.

The kernel will allocate them sequentially by default during a single boot, but many *systems* will persistently save the 'eth0' name / MAC address binding and ensure it doesn't randomly change to a different interface if you e.g. plugged in a USB NIC since last boot or your multiple NICs come up in unpredictable order or whatever. This was pretty standard for many years until the udev scheme came along, and is pretty 'random' and 'unpredictable' if you don't know it's happening. It can easily lead to your only NIC being eth4 or something after you've done some upgrades.

There's no 'f' to index - f is function, if there is only one PCI function then both interfaces will get assigned the same name, which will break and leave the second interface with its original name. It's possible they've revised the scheme to resolve this in the years since I last wasted my time with it, of course..

Don't have such a device to test, but the code suggests it will get an enp0s0f0dN identifier based on a kernel-provided port-id.

Never mind that the OP question is about the MAC address format which doesn't suffer any of these complications...

[magic]

Never mind that the OP question is about the MAC address format which doesn't suffer any of these complications...

Everything suffers complications with systemd.

Names and MAC addresses are derived from various stable device metadata attributes. Newer versions of udev take more of these attributes into account, improving (and thus possibly changing) the names and addresses used for the same devices.

For a machine with one or two onboard NICs and maybe an occasional USB dongle connected for 5 minutes it's a nobrainer to disable all that crap. I do it on all my home systems.

[ve7xen]

Everything suffers complications with systemd.

You systemd haters really just can't leave the opportunity to troll un-trolled, can you?

The name of your network interface doesn't matter at all in 99.9% of systems, and if it does, the predictable naming is probably what you want, so whatever configuration you have that depends on the name is always guaranteed to apply to the same interface regardless of driver loading order or whatever.

If you want the naive and unpredictable ethN system for some reason, you would know this, because you'd have some specific reason, and know to disable it. Otherwise, who cares.

For a machine with one or two onboard NICs and maybe an occasional USB dongle connected for 5 minutes it's a nobrainer to disable all that crap. I do it on all my home systems.

For such a machine it doesn't matter at all what the name of the NICs is, as long as it/you can identify them consistently to apply the correct configuration. Which the persistent naming only helps with. I really don't get you people, the problems with ethN are so obvious; something as trivial as a driver change in the kernel that changes initialization order or even fiddling with /etc/modules can mess it up (without the previously-used persistence hack at least), and this can lead to the machine being totally unreachable over the network which can be a serious problem. Most Linux desktop setups apply your network configuration to any available interface of the correct type anyway, and that's usually exactly the behaviour you want.

[magic]

So far I have seen more name changes due to systemd updates than due to kernel updates, that's the point.

See the wiki somebody linked. They say that MAC addresses are not used by default. Now, apparently they are, perhaps as a fallback when all else fails. Next year, an update will come which fill find some "clever" name for RPi's built-in NICs and the name will change once again...

[madires]

Originally interface names were assigned when the kernel (or driver module) was looking for network interfaces. Based on the mainboard and BIOS the scan started at the top or bottom card slot. Later onboard ethernet added more naming fun. If you have just a single NIC/ethernet port this doesn't matter much. SInce there's only one ethernet port it always got eth0. But if you have more than one you'll have a naming problem when changing, adding or removing a NIC. Which NIC will get which name? Back then you would use driver modules with specific parameters to get some kind of persistent naming but It didn't work for all drivers.  When udev came along it allowed a more simple solution for persistent naming (/etc/udev/rules.d/70-persistent-net.rules). After changing any NIC simply update the udev rule and you're done. However, the old eth naming scheme still has some drawbacks when using multiple NICs or NICs with multiple ports. Which port was eth7? To find out which port is eth7 or vice versa you have to check several things - it's cumbersome. Therefore we have now a new scheme for predictable interface names which supports several variants. See https://systemd.io/PREDICTABLE_INTERFACE_NAMES/ for a brief intro. One variant uses the physical location (like professional network elements do), e.g. enp2s5. Another uses the MAC address, like RasPi's new distri.

[ve7xen]

So far I have seen more name changes due to systemd updates than due to kernel updates, that's the point.

Eh, I have definitely seen the opposite. Machines (routers) with multiple identical NICs have not had deterministic startup order in my experience. This was 'fixed' at some point with the previous persistence hacks, but it is definitely a problem. In addition to the unpredictability with adding/removing NICs and iding the ports.

The systemd policies have changed over time, generally to add granularity where collisions are possible, but I have not seen them actually have an impact on real systems. You have multiple options to address this, if you deem it to be a problem. There are no ways to address the issues with the kernel ordering.

• Use the MAC naming policy
• Fix the naming scheme based on whatever version of systemd you set the system up with
• Define custom links for your interfaces and name them whatever you want, predictably based on whatever match parameters you want (path, driver, whatever)

See the wiki somebody linked. They say that MAC addresses are not used by default. Now, apparently they are, perhaps as a fallback when all else fails. Next year, an update will come which fill find some "clever" name for RPi's built-in NICs and the name will change once again...

The defaults from systemd don't use the MAC at all. But the 'default' is just shipped as a default policy '99-default.link' and gets included in the link policy at runtime. The distribution may change this shipped policy or add rules (e.g. debian adds 73-usb-net-by-mac.link which always uses the MAC policy for USB devices only, since many RPi boards have USB NICs, I assume that's what's happening here).

If this policy changes frequently, you can take it up with your distribution. I'd expect enterprise-oriented distros might fix the default naming policy, at least within a major distro release, but I can't be bothered to check. If you really care, you can do this manually in your kernel command line, though.

Canonical: https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html (the other link above is deprecated).

[DiTBho]

bah, I have three routers here

• rb532, with two Korina 10/100Mbps Ethernet modules, plus the SoC built-in Lth* 10/100Mbps one
• rsp, with thee Koz 10/100/1000Mbps Ethernet modules, plus the SoC built-in Ath* 10/100Mbps one
• Helx+dual-QuadTulip, with eight Tulip 10/100/1000Mbps Ethernet modules, plus the SoC built-in Eth* 10/100Mbps one

So, a lot of Ethernet interfaces 

The Helx (also known as "Hell", there must be a good reason for this -> maybe too many ports?!?) has { eth0, eth1, eth2, eth3, eth4, eth5, eth6, eth7, eth9 }

The only assigned IP is the one assigned to the bridge, which is br0, to which all the Ethernet ports are attached.

This setup is for a lan-switch

[bson]

A bigger problem is with USB ethernet adapters, where you set up firewall and DHCP rules.  Then move it from one port to another, and now it's an entirely new interface...

[Monkeh]

Code: [Select]

2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:00:5a:74:2e:f2 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:00:5a:74:2e:f3 brd ff:ff:ff:ff:ff:ff
4: enp0s7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:e0:4d:a0:7d:48 brd ff:ff:ff:ff:ff:ff
Oh no, what happen?

Code: [Select]

[root@localhost-live ~]# udevadm test-builtin net_id /sys/class/net/enp2s0
...
Using default interface naming scheme 'v249'.
ID_NET_NAMING_SCHEME=v249
ID_NET_NAME_MAC=enx00005a742ef2
ID_OUI_FROM_DATABASE=SysKonnect GmbH
ID_NET_NAME_PATH=enp2s0
...
[root@localhost-live ~]# udevadm test-builtin net_id /sys/class/net/eth1
...
Using default interface naming scheme 'v249'.
ID_NET_NAMING_SCHEME=v249
ID_NET_NAME_MAC=enx00005a742ef3
ID_OUI_FROM_DATABASE=SysKonnect GmbH
ID_NET_NAME_PATH=enp2s0
...
Oh no, is broke. If only someone could have told them 9 years ago this wouldn't work in the real world. Wait, we did.

Legitimately a kernel bug today - but it wasn't then and it wouldn't be a bug if they didn't make it one.

A bigger problem is with USB ethernet adapters, where you set up firewall and DHCP rules.  Then move it from one port to another, and now it's an entirely new interface...

That would be why certain distros apparently use MAC-based names for USB devices.