| View previous topic :: View next topic |
| Author |
Message |
flysideways
Guru
Joined: 29 Jan 2005
Posts: 437
|
 Posted: Sun Jan 29, 2023 11:37 pm Post subject: eth0 Renamed end0 After Two Years |
 |
|
I have a Raspberry Pi that has had an ~arm64 install since 10-2020, and with today's update it renamed eth0 to end0. I fixed the ln and am using that Pi to write this.
I have some installs that are arm64, and they are still eth0. Some are headless, it'd be nice to preemptively fix them.
At the moment I am at a loss to remember where or why it would do this.
They are openrc, and running pi kernels copied over from RPiOS.
Thanks. |
|
| Back to top |
|
 |
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Mon Jan 30, 2023 12:27 am Post subject: |
|
|
My guess is that it is related to the Predictable Network Interface Name change. But that was quite a while ago, unless arm is only just now stabilizing it? If that is the cause, then I'd expect it to have been an updated udev that caused the change.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Mon Jan 30, 2023 12:30 am Post subject: |
|
|
You could add the parameter below to your kernel command line parameters:
EDIT: pjp was faster  |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21600
|
| Posted: Mon Jan 30, 2023 12:34 am Post subject: |
|
|
| I see you received the direct answer already. A quick search for linux eth0 rename has, as its fifth hit, a stackexchange post which provides the same information suggested here. |
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 437
|
| Posted: Mon Jan 30, 2023 2:59 am Post subject: |
|
|
Thanks all. I'm not fixated on it being eth0. I hadn't really given it much thought, but the Pi's had remained with eth0 for some reason, even one I created a few weeks ago.
Going down the path from pjp's link, I found this; | Code: | $ udevadm test-builtin net_id /sys/class/net/eth0
Using default interface naming scheme 'v252'.
Parsed configuration file "/lib/systemd/network/99-default.link"
Created link configuration context.
ID_NET_NAMING_SCHEME=v252
...
ID_OUI_FROM_DATABASE=Raspberry Pi Trading Ltd
ID_NET_NAME_ONBOARD=end0 |
on the Raspberry Pi 4 Model B Rev 1.4 running ~arm64.
On another Raspberry Pi 4 Model B Rev 1.4 running arm64; | Code: | Using default interface naming scheme 'v251'.
Parsed configuration file "/lib/systemd/network/99-default.link"
Created link configuration context.
ID_NET_NAMING_SCHEME=v251
...
ID_OUI_FROM_DATABASE=Raspberry Pi Trading Ltd |
It does not have the ID_NET_NAME_ONBOARD= response. It is also interface naming scheme v251, not v252.
I'm going to guess that, perhaps, the last update took the ~arm64 install to scheme v252. |
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 437
|
| Posted: Mon Jan 30, 2023 3:24 am Post subject: |
|
|
| To add, I did use mike155's hint and added to cmdline.txt while I was looking at this. The ~arm64 install is now back to default. I'll just deal with the arm64 installs when they change. |
|
| Back to top |
|
|
Goverp
Veteran
Joined: 07 Mar 2007
Posts: 1994
|
| Posted: Mon Jan 30, 2023 9:28 am Post subject: |
|
|
I love the way systemd calls this feechur "Predictable". It broke my machine when I inserted a new card (100% exactly the problem it's supposed to cure), and again more recently a different box hit this typo rename. I try to remember to disable it using the net.ifnames=0 override mentioned above.
_________________
Greybeard |
|
| Back to top |
|
|
flysideways
Guru
Joined: 29 Jan 2005
Posts: 437
|
| Posted: Mon Jan 30, 2023 11:23 am Post subject: |
|
|
| Code: | 2023-01-13T07:27:20 >>> sys-apps/systemd-utils-251.10-r1: 41s
2023-01-29T13:42:36 >>> sys-apps/systemd-utils-252.4: 42s |
I'm guessing this was the transition from v251 to v252. I got systemd-ed on my openrc install. |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Mon Jan 30, 2023 11:44 am Post subject: |
|
|
| Goverp wrote: | | I love the way systemd calls this feechur "Predictable" |
I call this feature "Lennart Poettering's Unpredictable Predictable Network Interface Names". |
|
| Back to top |
|
|
Banana
Veteran
Joined: 21 May 2004
Posts: 1383
Location: Germany
|
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Mon Jan 30, 2023 11:14 pm Post subject: |
|
|
| Goverp wrote: |
I love the way systemd calls this feechur "Predictable". It broke my machine when I inserted a new card (100% exactly the problem it's supposed to cure), and again more recently a different box hit this typo rename. I try to remember to disable it using the net.ifnames=0 override mentioned above. |
I'm not a fan of the change, but my main gripe with these types of changes is the "we break it, you fix it" approach. For the hobbyist / non-paid user, it seems like not breaking things would be the best starting point. "Do no harm" if you will. And for those who are paid to manage systems, it seems more than reasonable that a) they should learn why and how to do it; and b) they're already probably paying attention to the hardware ports and connections for other reasons. I decided I'd rather deal with the obtuse naming scheme rather than yet another "manage the damage" configuration file.
On one of my home systems, I have an internal NIC enp3s0 and for some reason, the external NIC at enp2s0. I'm sure there's a reason for why they are essentially the same name and only differing by the "p" number. Contrast that with my laptop which has the wonderfully easy to access enp0s31f6 and wlp4s0. Of course with the laptop, when it boots, neither of those are readable, so that's a joy if something disrupts normal booting and I have to work in the terminal (haven't deduced the magic incantation to make the default terminal / console a legible size). Oh well, but at least the NIC names are predictable for those paid to deal with it. If I were younger, I'd switch to a skilled trade.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Banana
Veteran
Joined: 21 May 2004
Posts: 1383
Location: Germany
|
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21600
|
| Posted: Tue Jan 31, 2023 1:49 pm Post subject: |
|
|
| There was a warning when udev first pushed this on users many years ago. I see from a few minutes of searching that there was another warning when eudev was retired: https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=eba63773624dd2dbdceefdf8ab2c88aab22dab40. Gentoo has a policy of following upstream where practical, so there is only so much Gentoo can do with this while upstream keeps pushing the default of renaming from kernel-assigned names to udev-policy-assigned names. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1525
Location: South America
|
| Posted: Tue Jan 31, 2023 10:41 pm Post subject: |
|
|
| flysideways wrote: | It does not have the ID_NET_NAME_ONBOARD= response. It is also interface naming scheme v251, not v252.
I'm going to guess that, perhaps, the last update took the ~arm64 install to scheme v252. |
Looks like it.
systemd.net-naming-scheme — Network device naming schemes
| Quote: | History
The following "naming schemes" have been defined (which may be chosen at system boot-up time via the net.naming-scheme= kernel command line switch, see above):
[...]
v252
Added naming scheme for platform devices with devicetree aliases. |
end0 does have format prefix d number indeed --> Devicetree alias index.
| flysideways wrote: | | I got systemd-ed on my openrc install. |
Yep...
| Goverp wrote: | | I love the way systemd calls this feechur "Predictable". |
It is... but they don't add the clarification "predictable by the machine, not by its human user"  I think that you can deduce it from information in the sysfs.
| pjp wrote: | | On one of my home systems, I have an internal NIC enp3s0 and for some reason, the external NIC at enp2s0. I'm sure there's a reason for why they are essentially the same name and only differing by the "p" number. |
Yes, different bus numbers. prefix [P domain ] p bus s slot [f function] [n phys_port_name | d dev_port ] --> PCI geographical location.
| pjp wrote: | | Contrast that with my laptop which has the wonderfully easy to access enp0s31f6 [...] |
Multi-function PCI device.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
hdcg
Tux's lil' helper
Joined: 07 Apr 2013
Posts: 120
|
| Posted: Wed Feb 01, 2023 4:38 am Post subject: |
|
|
Hi flysideways,
thanks for pointing this out and tracking it down. Just got my RPI4 back online, as this also hit me after rebooting it on the weekend.
Fun fact: Only after this issue I noticed, I do not yet have a micro HDMI adapter (RPI4 is running headless since it's 1st start in 2019) and I lost my SD card readers due to PC and Notebook updates in between. Adapter and reader will be delivered today, but now only needed for the next incident.
Best Regards,
Holger |
|
| Back to top |
|
|
|
Networking & Security
