You are not logged in.

#1 2013-03-26 05:29:22

Agnelo de la Crotche
Member
Registered: 2011-10-25
Posts: 19

[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!

Last edited by Agnelo de la Crotche (2013-03-27 07:14:05)

Offline

#2 2013-03-26 06:24:48

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

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

Ranting is not a constructive way to ask for help from a community of volunteers...
https://wiki.archlinux.org/index.php/Fo … cs.2FRants


You might also want to reread the original post on the ML announcing this change and note that
Dave 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.rules
2) 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.

Posting your rules is likely to get you some help at this point.


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#3 2013-03-26 06:29:22

jynnantonix
Member
Registered: 2012-09-07
Posts: 33

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 information
2) 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.

Offline

#4 2013-03-26 07:57:44

Agnelo de la Crotche
Member
Registered: 2011-10-25
Posts: 19

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

jasonwryan wrote:

Ranting is not a constructive way to ask for help from a community of volunteers...
https://wiki.archlinux.org/index.php/Fo … cs.2FRants

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 that
Dave 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.rules
2) 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.

jasonwryan wrote:

Posting your rules is likely to get you some help at this point.

# /etc/udev/rules.d/10-network.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:/sys/devices/pci0000:00/0000:00:1c.1/0000:04:00.0 (e1000e)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:00:00:00:00:00", NAME="eth0"

# PCI device 0x1969:/sys/devices/pci0000:00/0000:00:1c.5/0000:02:00.0 (ATL1E)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:00:00:00:00:00", NAME="eth1"

# PCI device 0x10ec:/sys/devices/pci0000:00/0000:00:1e.0/0000:06:01.0 (8139too)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:00:00:00:00:00", NAME="eth2"

# PCI device 0x10ec:/sys/devices/pci0000:00/0000:00:1e.0/0000:06:00.0 (8139too)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:00:00:00:00:00", NAME="eth3"

* I did replace the MAC addresses with "00" in this post.

Offline

#5 2013-03-26 08:13:31

Agnelo de la Crotche
Member
Registered: 2011-10-25
Posts: 19

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

jynnantonix wrote:
Agnelo de la Crotche wrote:

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

I'm not sure you do.

Don't worry! I do.


jynnantonix wrote:

why do you need the old naming scheme?
Why are you using Arch?


I surely could answer these two questions.  But would it help you?  Would it make your life or my life easier?  Thus, why answering by "why" when the question is "how"? 

It is really not relevant and would take too long to explain, and not even solve the problem, so please!

Offline

#6 2013-03-26 17:17:21

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,463

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

Agnelo de la Crotche wrote:

I surely could answer these two questions.  But would it help you?  Would it make your life or my life easier?  Thus, why answering by "why" when the question is "how"? 

It is really not relevant and would take too long to explain, and not even solve the problem, so please!

http://xkcd.com/1172/

Online

#7 2013-03-26 17:34:07

Inxsible
Forum Fellow
From: Chicago
Registered: 2008-06-09
Posts: 9,183

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

Agnelo de la Crotche wrote:
jynnantonix wrote:

why do you need the old naming scheme?
Why are you using Arch?


I surely could answer these two questions.  But would it help you?  Would it make your life or my life easier?  Thus, why answering by "why" when the question is "how"? 

It is really not relevant and would take too long to explain, and not even solve the problem, so please!

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. Don't go all high and mighty with us. When asking for help, a little politeness goes a long way. Give and take, baby! Give and take!

Agnelo de la Crotche wrote:

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

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.


Agnelo de la Crotche wrote:

I updated, rebooted and - I knew somehow - that I wouldn't have network after restart. :-(

Again, if you knew, you should have not updated or made the necessary adjustments.


Forum Rules

There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !

Offline

#8 2013-03-26 20:40:03

Agnelo de la Crotche
Member
Registered: 2011-10-25
Posts: 19

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

Inxsible wrote:

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.

Anyway ... wenn nicht, dann nicht.

Offline

#9 2013-03-26 21:56:05

Inxsible
Forum Fellow
From: Chicago
Registered: 2008-06-09
Posts: 9,183

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. roll

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.


Forum Rules

There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !

Offline

#10 2013-03-26 23:06:30

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

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.

Offline

#11 2013-03-26 23:46:46

tomegun
Developer
From: France
Registered: 2010-05-28
Posts: 661

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?

Cheers,

Tom

Offline

#12 2013-03-27 01:12:19

Agnelo de la Crotche
Member
Registered: 2011-10-25
Posts: 19

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.

Sorry.

Offline

#13 2013-03-27 01:27:04

Agnelo de la Crotche
Member
Registered: 2011-10-25
Posts: 19

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

tomegun wrote:

Hi Agnelo,

Salut Tom.


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,

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?


# Network profiles are found in /etc/network.d
#
# This requires the netcfg package
#
NETWORKS=(eth0 eth1 eth2 eth3)

I'm not so sure.

Offline

#14 2013-03-27 01:29:16

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

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

Arch doesn't have an /etc/rc.conf any more...
https://www.archlinux.org/news/final-sy … n-warning/


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#15 2013-03-27 01:41:44

Agnelo de la Crotche
Member
Registered: 2011-10-25
Posts: 19

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

jasonwryan wrote:

Arch doesn't have an /etc/rc.conf any more...
https://www.archlinux.org/news/final-sy … n-warning/

OK.

Offline

#16 2013-03-27 01:51:36

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

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.

This was copy/pasted from this page (which is the page that is linked to by seemingly every other that covers the new NIC persistent naming):
http://www.freedesktop.org/wiki/Softwar … rfaceNames


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?

Last edited by WonderWoofy (2013-03-27 01:54:55)

Offline

#17 2013-03-27 02:12:39

Agnelo de la Crotche
Member
Registered: 2011-10-25
Posts: 19

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.

This was copy/pasted from this page (which is the page that is linked to by seemingly every other that covers the new NIC persistent naming):
http://www.freedesktop.org/wiki/Softwar … rfaceNames

Yes, I read this today.

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?

"truly technical", certainly not. It's just - or used to be - truly convenient. But I see that it's starting to be more and more inconvenient.

Offline

#18 2013-03-27 02:50:21

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

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

Agnelo de la Crotche wrote:

<snip>
But I see that it's starting to be more and more inconvenient.

Not functioning is something I might consider beyond simply inconvenient....

Offline

#19 2013-03-27 05:49:49

Agnelo de la Crotche
Member
Registered: 2011-10-25
Posts: 19

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?

To answer this question more precisely.

* with  /etc/udev/rules.d/80-net-name-slot.rules => /dev/nul and /etc/udev/rules.d/10-network.rules posted earlier  (in #4)

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:0a:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:06:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:24:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:1b:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT 
    link/ether 66:64:b3:6a:26:61 brd ff:ff:ff:ff:ff:ff

The rules are ignored.

* after deleting   /etc/udev/rules.d/80-net-name-slot.rules

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp6s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:0a:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
3: enp6s1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:06:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
4: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:24:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
5: enp4s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:1b:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT 
    link/ether a2:ee:ec:d1:65:2d brd ff:ff:ff:ff:ff:ff

The rules don't apply.


* with  /etc/udev/rules.d/80-net-name-slot.rules => /dev/nul and after replacing eth0, eth1, eth2, eth3 with arbitrary names net0, net1, net2, net3 in  /etc/udev/rules.d/10-network.rules

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: net1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:24:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
3: net3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:0a:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
4: net2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:06:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
5: net0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:1b:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT 
    link/ether ea:63:09:b7:1b:1b brd ff:ff:ff:ff:ff:ff

But the rules were applied in this case!

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.

Those names don't work anymore, at least in my case.

Further I  created this file for static ips:

# cat /etc/systemd/system/network.service 
[Unit]
Description=Wired Static IP Connectivity
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-net0.device
After=sys-subsystem-net-devices-net0.device

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ip link set dev net0 up
ExecStart=/sbin/ip addr add 192.168.101.9/24 dev net0
ExecStart=/sbin/ip link set dev net1 up
ExecStart=/sbin/ip addr add 192.168.102.9/24 dev net1
ExecStart=/sbin/ip link set dev net2 up
ExecStart=/sbin/ip addr add 192.168.104.9/24 dev net2
ExecStart=/sbin/ip link set dev net3 up
ExecStart=/sbin/ip addr add 192.168.105.9/24 dev net3
ExecStart=/sbin/ip route add default via 192.168.101.1

ExecStop=/sbin/ip addr flush dev net0
ExecStop=/sbin/ip link set dev net0 down
ExecStop=/sbin/ip addr flush dev net1
ExecStop=/sbin/ip link set dev net1 down
ExecStop=/sbin/ip addr flush dev net2
ExecStop=/sbin/ip link set dev net2 down
ExecStop=/sbin/ip addr flush dev net3
ExecStop=/sbin/ip link set dev net3 down

[Install]
WantedBy=multi-user.target

I disabled netcfg and enabled network.service.
Problem is solved now.

Offline

#20 2013-03-27 12:20:24

tomegun
Developer
From: France
Registered: 2010-05-28
Posts: 661

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.

Cheers,

Tom

Offline

#21 2013-03-27 15:53:05

Agnelo de la Crotche
Member
Registered: 2011-10-25
Posts: 19

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.

I will.

Offline

#22 2013-03-27 15:59:54

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

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?

Offline

#23 2013-03-27 16:07:41

alphaniner
Member
From: Ancapistan
Registered: 2010-07-12
Posts: 2,810

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

Offline

#24 2013-03-27 16:14:42

Agnelo de la Crotche
Member
Registered: 2011-10-25
Posts: 19

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.

Offline

#25 2013-03-27 16:30:05

Agnelo de la Crotche
Member
Registered: 2011-10-25
Posts: 19

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.

Offline

Board footer

Powered by FluxBB