Leonid.I wrote:Why less than 80? AFAIU rules are processed in lexical order, so 10-xxx.rules is processed before 20-yyy.rules. If you have a file 70-network.rules which touches interfaces, then won't 80-net-name-slot.rules change them? I'd say, user-defined interface names should come in effect after kernel/udev are done with the defaults...
The number is the priority.
Where is that coming from?
Even w/o looking at the udev manpage, if you read the above-mentioned freedesktop wiki which suggests using the name 70-xxx.rules, it says that this rule will be processed BEFORE 80-yyy.rules. The only reason why the latter will be ineffective is because it contains a check for non-empty NAME and quits if NAME has already been set. It seems to me that an error in this logic will destroy your naming convention...
]]>Why less than 80? AFAIU rules are processed in lexical order, so 10-xxx.rules is processed before 20-yyy.rules. If you have a file 70-network.rules which touches interfaces, then won't 80-net-name-slot.rules change them? I'd say, user-defined interface names should come in effect after kernel/udev are done with the defaults...
The number is the priority.
]]>twelveeighty wrote:Yes: 10-network-rules.conf works just fine. But OP renamed it to 70. If 70 is the new standard, we should update the Wiki on this. If not, let's not bother with any changes, since the old way works just fine.
I'm obviously missing something here: you can rename it to anything you like, as long as it is less than 80. What needs updating in the wiki?
Thats the part you are missing. He thinks it has to be 70 for being standard and therefore he wants to update the wiki saying that it has to be 70.
@twelveeighty: no, it has to be <80 only; 70 is fine, 10 is fine.
]]>twelveeighty wrote:Yes: 10-network-rules.conf works just fine. But OP renamed it to 70. If 70 is the new standard, we should update the Wiki on this. If not, let's not bother with any changes, since the old way works just fine.
I'm obviously missing something here: you can rename it to anything you like, as long as it is less than 80. What needs updating in the wiki?
Why less than 80? AFAIU rules are processed in lexical order, so 10-xxx.rules is processed before 20-yyy.rules. If you have a file 70-network.rules which touches interfaces, then won't 80-net-name-slot.rules change them? I'd say, user-defined interface names should come in effect after kernel/udev are done with the defaults...
]]>Yes: 10-network-rules.conf works just fine. But OP renamed it to 70. If 70 is the new standard, we should update the Wiki on this. If not, let's not bother with any changes, since the old way works just fine.
I'm obviously missing something here: you can rename it to anything you like, as long as it is less than 80. What needs updating in the wiki?
]]>Beelzebud wrote:Just curious about something. udev already had a network naming scheme. You would save your id's to a file called "/etc/udev/rules.d/10-network.rules". Will that file still work, or do I need to rename it to "70-my-net-names.rules"?
It just seems rather pointless to move configs around like this, when the function was already there to begin with. I guess I'm missing the point.
If by "id's" you mean mac addresses, then you're incorrect that a reliable and persistent naming scheme existed in udev before this. Plenty of machines exist where the MAC address for multiple interfaces is identical. There needed to be a better way of uniquely and reliably identifying an interface which is what systemd 197 introduced. The new rules generally end up naming interfaces by their location on the bus. This scheme is bounded by the laws of physics until you can figure out how to connect 2 network cards to the same PCI address.
All your answers are below, particularly in the first bullet point:
Yes I meant the MAC addresses. At any rate here is what is in my "70-my-net-names.rules" file:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:0e:a6:7a:9f:8c", NAME="net0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:0e:a6:68:1b:6a", NAME="net1"
I've booted a few times and it has worked correctly each time. I didn't realize some machines had cards with identical MAC addresses, so that goes a long way to understanding the rationale for the change. Thanks for the info.
]]>I don't think so because "Alias=" will be used when you enable dhcpcd@.service without anything after "@".
Strange, on my system running:
# systemctl enable dhcpcd@<ANYTHING>.service
Always creates a symlink to whatever the Alias value is. So by default it always does:
ln -s '/usr/lib/systemd/system/dhcpcd@.service' '/etc/systemd/system/multi-user.target.wants/dhcpcd@eth0.service'
If I change Alias to be something else, it will create the link to that. It's as if it's just ignoring what's after the @ on the command line.
Starting the service though, will work as expected:
# systemctl start dhcpcd@enp2s0.service
And run dhcpcd on the correct interface.
EDIT: Apparently because of https://bugs.freedesktop.org/show_bug.cgi?id=53954
]]>Ah; I hadn't thought to experiment and just let it boot like that: I changed it before rebooting.
Leonid.i wrote:Also, nothing got deprecated with udev 197. The naming convention has changed from one arbitrary scheme to another. But names based on ID_NET_NAME_PATH existed before.
My personal opinion is that this move is irrelevant for anything practical because people who want really persistent naming usually use MAC or ID_NET_NAME_MAC, and folks with single wifi/eth cards (e.g. laptop) do not need new names anyway.
Thank you for clarifying this. It's good to know we are swapping arbitrary for arbitrary
To give due credit, I'd say from arbitrary to less arbitrary. One advantage of the latter is persistence, so users who don't know about udev won't get their NICs confused. However, I find it more convenient to instruct udev to setup mnemonic names, like "external.nic".
Of course, there is always a question whether you want to identify a card based on its properties, like ID_NET_NAME_MAC, or based on its place on e.g. PCI bus (ID_NET_NAME_PATH). In the end it might be a matter of semantics...
]]>*** I don't like this, or, I've never needed persistent names
You'll never be forced to use the new schema. Masking the rule as
explained above will always work, and you're still able to write a rule
of your own to provide names you're comfortable with if that's what
you're into.
We enable it for new installs because that's what upstream does.
]]>