[solved] /etc/udev/rules.d/10-network.rules ignored

Hi.I have 4 nics (eth0, eth1, eth2, eth3) mapped to MAC addresses in /etc/udev/rules.d/10-network.rules.Some months ago, I had to symlink /etc/udev/rules.d/80-net-name-slot.rules to /dev/null in order to use these static names. Now it doesn't work anymore (again and again and again) after a full update (kernel and I assume systemd). The "nic-names" are completely wrong. You call this "predictable". I call this "unpredictable". The only thing which is predictable is that after a kernel update, the network will stop working. It has been that way for months and months ... fortunately I don't update other machines anymore.

Was this non sense really necessary?

Anyway, if you could tell me what to do now to get my network rules applied again, I would really appreciate.Right now all ethX/MAC are wrong and none of them gets an IP (had to set an IP manually to post here).

* I know what "predictable Network Interface Names" is about. I don't want this bullshit. It's much worse as it used to be. Keep it simple, folks!

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

You might also want to reread the original post on the ML announcing this change and note thatDave describes alternate approaches thus:

If you wish to opt out, you can do 1 of 2 things:1) mask the rule: ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules2) provide your own udev rule that applies a NAME to the interface. As long as this rule is ordered lexically before 80-net-name-slot.rules, then the upstream rule will have no effect. For example, providing a file called 70-net-naming.rules will trump 80-net-name-slot.rules.

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

Agnelo de la Crotche wrote:

* I know what "predictable Network Interface Names" is about.

I'm not sure you do. Unless you are seeing interface names like enp3s0 or wlp3s2, systemd is _not_ naming your interfaces with the persistent scheme. More likely, you are running into the unpredictability of the old network naming scheme. If I understand it correctly, the whole point was that just because an interface was called eth0 doesn't mean it will be called eth0 after you reboot. In most cases, there is only one ethernet and/or wireless card so it doesn't matter but it does matter when there are multple network cards. This seems to be your problem, especially since

Right now all ethX/MAC are wrong and none of them gets an IP (had to set an IP manually to post here).

So I suggest two things:1) Post your 10-network.rules files. No one here is familiar with your system and no one can help you without more information2) Try the persistent naming scheme - honestly I haven't noticed any difference. enp3s0 and eth0 are both ultimately just names, why do you need the old naming scheme?

Also, being aggressive while asking for help is not going to get you a lot of support on these forums. And

fortunately I don't update other machines anymore

Why are you using Arch? If you don't want to update often, want things to be stable, and want changes to slowly make their way to you, then there are plenty of other distros that will do that for you.

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

I am a volunteer and Linux contributor as well, helper and maintainer of several packages in other distros (i.e openSUSE) for many years.I just happen not to have time right now. Does it make sense? I updated, rebooted and - I knew somehow - that I wouldn't have network after restart. :-(

jasonwryan wrote:

You might also want to reread the original post on the ML announcing this change and note thatDave describes alternate approaches thus:

If you wish to opt out, you can do 1 of 2 things:1) mask the rule: ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules2) provide your own udev rule that applies a NAME to the interface. As long as this rule is ordered lexically before 80-net-name-slot.rules, then the upstream rule will have no effect. For example, providing a file called 70-net-naming.rules will trump 80-net-name-slot.rules.

I did already - of course before posting and asking for help. And I'm quite sure I found this post or a similar one couple months ago,as I first encountered this issue, which I solved by renaming (and editing a little bit) the probably deprecated /etc/udev/rules.d/70-persistent-net.rules that I had used for years into /etc/udev/rules.d/10-network.rules. I also symlinked /etc/udev/rules.d/80-net-name-slot.rules to /dev/null as advised, and I still have this symlink. It worked until today.

Just writing this, I realized that renaming 70-persistent-net.rules was probably not necessary. What helped was creating the symlink. .. But it has no effect any more, and my rules are just ignored now.

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

Just like you mention that these questions do not help in solving the problem, your statement

Agnelo de la Crotche wrote:

I am a volunteer and Linux contributor as well, helper and maintainer of several packages in other distros (i.e openSUSE) for many years.

also does not help anything

I agree. Sorry. Neither does your comment though.

Inxsible wrote:

Don't go all high and mighty with us.

I don't go anywhere with anyone. I just have to fix this problem.

Inxsible wrote:

When asking for help, a little politeness goes a long way. Give and take, baby! Give and take!

All right, "baby"! I sincerely apologize if I did hurt you guys because I'm not amused with the latest systemd development (which might suck after all, no matter if you complain or not). Let me know if you need more apologies!Now let's stick to the facts if you don't mind.

I already described the problem. Let me know if you need more details.

Agnelo de la Crotche wrote:

I just happen not to have time right now. Does it make sense?

Inxsible wrote:

If you didn't have time, you shouldn't have updated. Arch requires time for the constant changes it undergoes. So no it doesn't make sense that you updated when you didn't have time.

I know. But I would be nice to hear something I don't know, actually the answer to my question - if it's not too much asked and if it is, I will answer it myself when I do have more time.I still believe that it was worth asking though. One never knows. Sometimes one might also just provide the solution, instead of commenting the comment you made to another comment, explaining concepts which have been around for a while, asking why you are doing this or that or teaching you how to behave.

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

Agnelo de la Crotche wrote:

I agree. Sorry. Neither does your comment though.

Yes, but I wasn't the one who started being rude.

Agnelo de la Crotche wrote:

All right, "baby"! I sincerely apologize if I did hurt you guys because I'm not amused with the latest systemd development (which might suck after all, no matter if you complain or not). Let me know if you need more apologies!Now let's stick to the facts if you don't mind.

Doesn't matter what you think about systemd. Use it or lose it(as in use something else). No point complaining about it.

Agnelo de la Crotche wrote:

I know. But I would be nice to hear something I don't know, actually the answer to my question - if it's not too much asked and if it is, I will answer it myself when I do have more time.

Right. I will wait when you have more time.

Agnelo de la Crotche wrote:

I still believe that it was worth asking though. One never knows. Sometimes one might also just provide the solution, instead of commenting the comment you made to another comment, explaining concepts which have been around for a while, asking why you are doing this or that or teaching you how to behave.

Anyway ... wenn nicht, dann nicht.

Well, when you know that the "concepts" have been around for a while, you shouldn't have violated them. Then I wouldn't have to take the time in explaining them to you in the first place nor would I have to teach you to behave, if you had behaved.

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

So your attitude really sucks.

But I am pretty sure that naming your interfaces the same as what the kernel wants to name them is not supported in any way. It should have actually never really worked totally reliably, even if it did work on your machine for a while.

So the question about why you *need* to keep these eth* interface names is actually very relevant.

So stop being such a jerk, and please don't come posting around here until you can ask politely.

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

Hi Agnelo,

To narrow down the problem you are experiencing: What do you mean when you say that the names are "wrong"? Are they still eth0, eth1,... just in the wrong order, or are you actually seeing the "weird" new names given by udev?

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

WonderWoofy wrote:

So your attitude really sucks.

So is my english actually, because in the time it would take me to formulate more apologies, I would just get loged out - no kidding.

WonderWoofy wrote:

But I am pretty sure that naming your interfaces the same as what the kernel wants to name them is not supported in any way. It should have actually never really worked totally reliably, even if it did work on your machine for a while.

So the question about why you *need* to keep these eth* interface names is actually very relevant.

I'm afraid so. I'm using old names because it still has more advantages ( = less work ) than inconveniences in this lan. I can identify the nics (each machine has between 2 and 5 nics) according to their old eth* name, everywhere, in scripts, installation scripts, comments, in my DNS(s), etc. BTW I already switched the names under Fedora a long time ago, as it was Predictable Network Interface Names were introduced, I guess with Fedora 15 or 16.

WonderWoofy wrote:

So stop being such a jerk, and please don't come posting around here until you can ask politely.

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

To narrow down the problem you are experiencing: What do you mean when you say that the names are "wrong"? Are they still eth0, eth1,... just in the wrong order,

Yes, they are still eth0, eth1, etc but mapped to the "wrong" MAC address. By "wrong" I mean not the one I expected in my udev rule (since it is simply ignored).

tomegun wrote:

or are you actually seeing the "weird" new names given by udev?

No, but that's probably because I disabled the new naming scheme by symlinking 80-net-name-slot.rules to /dev/null. Isn't it?

But I guess something has changed (for the worse) The nics don't receive the wrong IP anymore - as they would if the ehtX were not what they are expected to be in my static configurations (/etc/network.d/eth0, etc). They dont' get an IP at all. Is this in /etc/rc.conf still relevant?

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

Have a look at this paragraph:

To fix this problem multiple solutions have been proposed and implemented. For a longer time udev shipped support for assigning permanent "ethX" names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems, among them: this required a writable root directory which is generally not available; the statelessness of the system is lost as booting an OS image on a system will result in changed configuration of the image; on many systems MAC addresses are not actually fixed, such as on a lot of embedded hardware and particularly on all kinds of virtualization solutions. The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same "ethX" namespace, a race condition with all kinds of weird effects, among them that assignment of names sometimes failed. As a result support for this has been removed from systemd/udev a while back.

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

WonderWoofy wrote:

Have a look at this paragraph:

To fix this problem multiple solutions have been proposed and implemented. For a longer time udev shipped support for assigning permanent "ethX" names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems, among them: this required a writable root directory which is generally not available; the statelessness of the system is lost as booting an OS image on a system will result in changed configuration of the image; on many systems MAC addresses are not actually fixed, such as on a lot of embedded hardware and particularly on all kinds of virtualization solutions. The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same "ethX" namespace, a race condition with all kinds of weird effects, among them that assignment of names sometimes failed. As a result support for this has been removed from systemd/udev a while back.

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

tomegun wrote:

To narrow down the problem you are experiencing: What do you mean when you say that the names are "wrong"? Are they still eth0, eth1,... just in the wrong order, or are you actually seeing the "weird" new names given by udev?

It solved the problem described originally. I think I was hit by the race condition after upgrating to kernel 3.8.4-1. This was actually my first 3.8 kernel. With kernel 3.7, the rules were working even if the devices were named eth0, eth1, etc.

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

@Agnelo:

So what you are experiencing is not caused by the new predictable interface names. On the contrary, you are experiencing one of the problems that predictable names are meant to solve. Namely that you cannot reliably rename interfaces within the same namespace. As you have experienced, sometimes it workes and other times it does not, depends on timing, which might be affected by the kernel version.

The solution you chose (netX rather than ethX) does not suffer from this problem, and should be fine in most cases. There are still cases where mac addresses are not reliable, and where using the predictable network names provided by udev would be better, but I'm assuming that does not apply to you.

If you still experience problems I suggest just using the predictable interface names. If there are reasons you cannot, please let us know so we can fix whatever problem you are experiencing.

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

tomegun wrote:

So what you are experiencing is not caused by the new predictable interface names. On the contrary, you are experiencing one of the problems that predictable names are meant to solve. Namely that you cannot reliably rename interfaces within the same namespace.

Yes, except that for years, I never had problems with udev rules before predictable interface names were introduced.For the record, on several Fedora machines were predictable names were introduced first, some interfaces got a predictable name and some others didn't (!). I used both kind of names in my ip static configuration. This is an older release though (Fedora 16).

tomegun wrote:

If you still experience problems I suggest just using the predictable interface names.

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

Agnelo de la Crotche wrote:

tomegun wrote:

So what you are experiencing is not caused by the new predictable interface names. On the contrary, you are experiencing one of the problems that predictable names are meant to solve. Namely that you cannot reliably rename interfaces within the same namespace.

Yes, except that for years, I never had problems with udev rules before predictable interface names were introduced.For the record, on several Fedora machines were predictable names were introduced first, some interfaces got a predictable name and some others didn't (!). I used both kind of names in my ip static configuration. This is an older release though (Fedora 16).

Did you read the quote I included above?! It explains exactly why this does not work anymore. Support has been removed for it. It may have worked for your machine while this was still allowed, but it was removed because it could not reliably be made to work across all machines in all instances due to race conditions.

So it is not surprising that you used it for years w/o an issue, and that it still works on your "older release through (Fedora 16)". But now the code that was in place for allowing the use of eth* is no longer there.

Maybe I am just reading your post wrong, but it really seems like you haven't gathered what is being told to you. Is this the case, or is it a linguistic barrier kind of thing?

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

The issue with ethX renaming has been around for years*. You just weren't hit by it. I wasn't either until a few months before 'predictable naming'.

*I remember the Ubuntu wiki recommending against renaming in the eth namespace back in '10, '11 at the latest.

But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.-Lysander Spooner

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

WonderWoofy wrote:

Edit: So other than "I don't want to do it that way", is there a truly technical reason why you want to do this?

There are actually several reasons why I want to do this. One of the reason is that in the scripts I use to install Arch as well as other distros, the number of network interface per machine is stored in an array. From this point of vue, ethX names are very predictable, because I know in advance which interface belongs to which network and so I can write my ip static configurations automatically. I could use dhcp for some of the interfaces but not for all of them, because the dhcp/dns servers cover some of the lans but not all.

With "predictable" names and many computers, it is impossible to predict the names the different interfaces will get. That's what I wrote in my first post: "You call this "predictable". I call this "unpredictable. In fact, these names are totally unpredictable for me. Of course, there are other scripting solutions I already applied, but I'm not happy when I have to do this at 3:00 AM and networks don't work.

Re: [solved] /etc/udev/rules.d/10-network.rules ignored

WonderWoofy wrote:

Did you read the quote I included above?! It explains exactly why this does not work anymore. Support has been removed for it. It may have worked for your machine while this was still allowed, but it was removed because it could not reliably be made to work across all machines in all instances due to race conditions.

Of course I did. That explains why it stopped working, but it just occured recently in my case, after the last update - meaning one or two weeks ago, it was still working. This time, it didn't work at all anymore - until I replaced eth* with net*

WonderWoofy wrote:

So it is not surprising that you used it for years w/o an issue, and that it still works on your "older release through (Fedora 16)". But now the code that was in place for allowing the use of eth* is no longer there.

Exactly. Notice that in one case though, while using eth* names in udev rules and explicitely disabling the use of predictable names, the devices are still named eth* but randomly - due to the race condition, I guess. Thus this could still need to be fixed somehow IMO.

WonderWoofy wrote:

Maybe I am just reading your post wrong, but it really seems like you haven't gathered what is being told to you.

No, no, I did. No worry. This info is what allowed me to solve the problem.Thank you.