| View previous topic :: View next topic |
| Author |
Message |
Hobbes2100
n00b
Joined: 24 Apr 2002
Posts: 55
|
 Posted: Fri Jan 05, 2024 8:01 pm Post subject: Renaming Interfaces on OpenRC in 2023 [Solved] |
 |
|
Hi folks,
I fear I'm missing something simple, but I'm trying to give an explicit name to a hardline Ethernet interface and I'm having difficulty. I've copy and pasted some udev stuff in the past, but never really dug into it. I've tried to chase down as many rabbit holes as possible, but I'm currently at a brick wall. Any help is greatly appreciated.
First, here's the documentation I've found:
My software versions:
1. virtual/udev-217-r7
2. sys-apps/systemd-utils-254.7:0
3. sys-kernel/gentoo-kernel-6.1.60:6.1.60
Files of interest:
1. /etc/udev/rules.d and /etc/systemd/network are empty
2. /lib/udev/rules.d/*net*:
| Code: |
% ls /lib/udev/rules.d/*net*
/lib/udev/rules.d/75-net-description.rules /lib/udev/rules.d/81-net-dhcp.rules
/lib/udev/rules.d/77-mm-huawei-net-port-types.rules /lib/udev/rules.d/90-network.rules
/lib/udev/rules.d/80-net-setup-link.rules
|
3. /lib/systemd/network/99-default.link
Hints from /99-default.link:
| Code: |
% more /lib/systemd/network/99-default.link
# SPDX-License-Identifier: MIT-0
#
# This config file is installed as part of systemd.
# It may be freely copied and edited (following the MIT No Attribution license).
#
# To make local modifications, one of the following methods may be used:
# 1. add a drop-in file that extends this file by creating the
# /etc/systemd/network/99-default.link.d/ directory and creating a
# new .conf file there.
# 2. copy this file into /etc/systemd/network or one of the other paths checked
# by systemd-udevd and edit it there.
# This file should not be edited in place, because it'll be overwritten on upgrades.
[Match]
OriginalName=*
[Link]
NamePolicy=keep kernel database onboard slot path
AlternativeNamesPolicy=database onboard slot path
MACAddressPolicy=persistent
|
Comments from the Udev Guide Advanced ... Disable or override:
| Quote: |
This behavior may be disabled in several ways:
1. Symlink /etc/systemd/network/99-default.link to /dev/null: ln -s /dev/null /etc/systemd/network/99-default.link.
2. Create a lower-numbered .link file in /etc/systemd/network which assigns a different name to the interface.
3. Pass net.ifnames=0 on the kernel command line.
Reference: https://systemd.io/PREDICTABLE_INTERFACE_NAMES/
|
Comments from Udev Upgrade Guide ... udev 208 to 216
| Quote: |
* However, 80-net-setup-link.rules is only a trigger for the actual configuration file 99-default.link at /lib/systemd/network/ which can be overrided at /etc/systemd/network/
* The most reliable way of disabling the new network interface scheme is still the kernel bootline parameter: net.ifnames=0
|
So, with all that, I tried *many* permutations of a placing a file like the following in different places and names within /etc/udev/rules.d and /etc/systemd/network (things like /etc/udev/rules.d/81-somename.rules):
| Code: |
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="d4:3d:7e:57:61:ee", NAME="wire0"
|
I can confirm that ATTR{address} is correct (the default interface name is eno1):
| Code: |
# udevadm info -a -p /sys/class/net/eno1/ | grep address
ATTR{address}=="d4:3d:7e:57:61:ee"
|
And I think I can test new rules with:
| Code: |
# in terminal 1:
udevadm monitor
# in terminal 2:
udevadm control --reload-rules
udevadm trigger --attr-match=subsystem=net
# return to terminal 1 to see output
|
However, I can't figure out where to put the .rules file to get it to trigger and apply.
I'm wondering if I need to do a two step process of:
1. Disable or override the 99-default.link file. In this case, I'd need to either get luck and just disable with a /dev/null link or I'd have to dive in and learn about link files.
2. Put the .rules file in the right spot.
Any help would be greatly appreciated.
Best,
Mark
Last edited by Hobbes2100 on Thu Jan 11, 2024 5:10 pm; edited 1 time in total |
|
| Back to top |
|
 |
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1712
|
| Posted: Fri Jan 05, 2024 8:50 pm Post subject: |
|
|
What if you named it /etc/udev/rules.d/71-somename.rules?
It has to be less than 80 to start or the predictive names kick in before your rule. Since your rule has "add" action, then add was already processed by the 80-net-setup-link.rules |
|
| Back to top |
|
|
Hobbes2100
n00b
Joined: 24 Apr 2002
Posts: 55
|
| Posted: Fri Jan 05, 2024 9:26 pm Post subject: |
|
|
| grknight wrote: | What if you named it /etc/udev/rules.d/71-somename.rules?
It has to be less than 80 to start or the predictive names kick in before your rule. Since your rule has "add" action, then add was already processed by the 80-net-setup-link.rules |
grknight,
Thanks for responding.
Well, that's something I didn't consider at all: going *before* the other rules. I guess I assumed the interpretation of:
| Code: |
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="d4:3d:7e:57:61:ee", NAME="wire0"
|
was to add a name to a given (hardware/MAC address specified) interface. But it sounds like you are saying that the event is generated once and it triggers one (and only the first) matching rule when that MAC address has its first ADD action. (I'm guess ADD is capturing something that is sort of like the first time a USB device was plugged in, if this was a USB device.) Is there another action or pattern that could create a new device named wire0 that is an alias for the existing device (in my case, that interface is automatically & predicttively named eno1).
I'll give that filename a try a little later this evening. Thanks!
Best,
Mark |
|
| Back to top |
|
|
Hobbes2100
n00b
Joined: 24 Apr 2002
Posts: 55
|
| Posted: Thu Jan 11, 2024 5:09 pm Post subject: |
|
|
Using a lower numbered filename definitely solved my main issue. Thanks!
I'm also curious about how to add a symlink to an existing name. Using just the standard kernel-provided base name, didn't do it. Anyone have any thoughts?
Best,
Mark |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21836
|
| Posted: Thu Jan 11, 2024 6:29 pm Post subject: |
|
|
| Interfaces are not files, so you cannot create a symbolic link to an interface. Why are you trying to do this? |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3185
|
| Posted: Thu Jan 11, 2024 8:07 pm Post subject: |
|
|
ip does have aliases though. Like here:
| Code: | 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether xxxxxxxxxxxx brd ff:ff:ff:ff:ff:ff
--> altname enp0s31f6 <---
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether xxxxxxxxxxxx brd ff:ff:ff:ff:ff:ff permaddr xxxxxxxxxxxx
--> altname wlp0s20f3 <---
|
So I can refer to devices by using either kernel space name or unpredictable name, they are both recognized and interchangeable.
I'm just using net.ifnames=0 on kernel's boot line instead of renaming them, for simplicity. Never bothered to study udev rules. |
|
| Back to top |
|
|
Hobbes2100
n00b
Joined: 24 Apr 2002
Posts: 55
|
| Posted: Wed Jan 17, 2024 3:39 pm Post subject: |
|
|
| Hu wrote: | | Interfaces are not files, so you cannot create a symbolic link to an interface. Why are you trying to do this? |
99% it is just a matter of simple curiosity: can this be done? But I can think of a few applications. For example, on different (non-homogeneous distros) systems that have different default interface names, maintaining that default, but also allowing a common name (via a symlink, alias, or another mechanism) to provide a common shared environment for programs distributed across those non-homogeneous systems.
So, is it impossible to provide multiple names (via udev and not as an alternative for an unpredictable kernel-generated name which would slightly restrict the utility) for an interface?
Best,
Mark |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
