predictable network interface names

[curmudgeon]

I have read the news item (/usr/portage/metadata/news/2013-03-29-udev-upgrade/2013-03-29-udev-upgrade.en.txt), and freedesktop.org wiki page (http://www.freedesktop.org/wiki/Softwar ... rfaceNames) at least ten times, and it still makes absolutely no sense to me (other than the fact that it will likely break a bunch of stuff on my machines).

Code: Select all

# udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null
ID_NET_NAME_MAC=enx001372eb4498
ID_OUI_FROM_DATABASE=Dell ESG PCBA Test
ID_NET_NAME_PATH=enp3s0

First question - what happens (after I upgrade) if I remove ALL files from /etc/udev/rules.d/?

Next question - I see (in the ebuild) "You can use kernel command net.ifnames= to control this feature." Does net.ifnames have to go on the kernel command line, or can it go in /etc/sysctl.conf?

There is nothing in the documentation I have seen about updating /etc/init.d/net.eth0 (a link to /etc/init.d/net.lo) to /etc/init.d/net.enp3s0. Does that have to be done manually, or is there some automated way (like reinstalling openrc) to do it?

I haven't seen any of the documentation mention the need to update /etc/conf.d/net, which seems like a fairly important step in all of this (which I assume has to be done manually).

The bottom line is that I am quite happy with the eth0 name (I have been running linux for almost twenty years now, and gentoo for just about half of that).

What is the simplest way to keep the eth0 name (for a standard machine with one ethernet card)?

If you believe that is a really bad idea, I can probably get used to changing to net0 (again what is the simplest way to do that?).

I believe it would help to see exact rules files for the most common cases.

Thank you in advance.

[SamuliSuominen]

I have read the news item (/usr/portage/metadata/news/2013-03-29-udev-upgrade/2013-03-29-udev-upgrade.en.txt), and freedesktop.org wiki page (http://www.freedesktop.org/wiki/Softwar ... rfaceNames) at least ten times, and it still makes absolutely no sense to me (other than the fact that it will likely break a bunch of stuff on my machines).

Code: Select all

# udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null
ID_NET_NAME_MAC=enx001372eb4498
ID_OUI_FROM_DATABASE=Dell ESG PCBA Test
ID_NET_NAME_PATH=enp3s0

First question - what happens (after I upgrade) if I remove ALL files from /etc/udev/rules.d/?

Your interface gets name enp3s0, so you would have to eg. use /etc/init.d/net.enp3s0 instead of /etc/init.d/net.eth0

Next question - I see (in the ebuild) "You can use kernel command net.ifnames= to control this feature." Does net.ifnames have to go on the kernel command line, or can it go in /etc/sysctl.conf?

net.ifnames=1 is the default, as in, enabled, net.ifnames=0 you can set in kernel command line to disable the new names, so even with all files gone from /etc/udev/rules.d you can
disable it this way too.
good question about sysctl.conf, I'm not actually sure.

There is nothing in the documentation I have seen about updating /etc/init.d/net.eth0 (a link to /etc/init.d/net.lo) to /etc/init.d/net.enp3s0. Does that have to be done manually, or is there some automated way (like reinstalling openrc) to do it?
I haven't seen any of the documentation mention the need to update /etc/conf.d/net, which seems like a fairly important step in all of this (which I assume has to be done manually).

The news item briefly mentions the symlink, but it can't cover everything like eg. iptables rules, so it's not automated. That's the purpose of the news item in the first place,
since it can't be automated enough.

The bottom line is that I am quite happy with the eth0 name (I have been running linux for almost twenty years now, and gentoo for just about half of that).
What is the simplest way to keep the eth0 name (for a standard machine with one ethernet card)?

Use net.ifnames=0 kernel commandline OR create symlink from /etc/udev/rules.d/80-net-name-slot.rules to /dev/null, and eth0 as assigned by the kernel will stay used. Except that
if the driver code changes, kernel code changes, hardware changes, your device might end up accidentally as, for example, eth1
That's the point of predictable network names, it goes past that

If you believe that is a really bad idea, I can probably get used to changing to net0 (again what is the simplest way to do that?).

The news item has example of creating 70-my-network.rules or similar based on MAC address to rename into net0, net1, ... Just replace the yy:yy:yy:yy:yy... used in the news item with your MAC. If you do this, that would mean you only need /etc/udev/rules.d/70-my-network.rules, and the previously mentioned /etc/udev/rules.d/80-net-name-slot.rules symlink isn't required, but shouldn't really matter at all in this case either

I believe it would help to see exact rules files for the most common cases.
Thank you in advance.

Well, everything you asked above is already answered in the news item. I mean, this logic is revealed by the news item and by the link to the upstream wiki. It's not really that hard at all.

[curmudgeon]

Your interface gets name enp3s0, so you would have to eg. use /etc/init.d/net.enp3s0 instead of /etc/init.d/net.eth0

That is probably the last thing in the world I want.

net.ifnames=1 is the default, as in, enabled, net.ifnames=0 you can set in kernel command line to disable the new names, so even with all files gone from /etc/udev/rules.d you can
disable it this way too.
good question about sysctl.conf, I'm not actually sure.

I have now tested it in sysctl.conf (and it doesn't work). I don't really see any reason why it shouldn't.

Code: Select all

Mar 31 05:51:49 system [    6.460151] systemd-udevd[168]: starting version 200
Mar 31 05:51:49 system [    7.040179] systemd-udevd[185]: renamed network interface eth0 to enp3s0

Yeah, that is the most important thing in the world for udedv to do - rename the network interface as the first task.

Use net.ifnames=0 kernel commandline OR create symlink from /etc/udev/rules.d/80-net-name-slot.rules to /dev/null, and eth0 as assigned by the kernel will stay used. Except that
if the driver code changes, kernel code changes, hardware changes, your device might end up accidentally as, for example, eth1
That's the point of predictable network names, it goes past that

Just a side comment, but it seems strange to me that no file gets one behavior, and an empty file gets a completely different behavior. Maybe that treatment occurs somewhere else in the universe, but I can't think of any such instance off the top of my head.

The news item has example of creating 70-my-network.rules or similar based on MAC address to rename into net0, net1, ... Just replace the yy:yy:yy:yy:yy... used in the news item with your MAC. If you do this, that would mean you only need /etc/udev/rules.d/70-my-network.rules, and the previously mentioned /etc/udev/rules.d/80-net-name-slot.rules symlink isn't required, but shouldn't really matter at all in this case either

Well, everything you asked above is already answered in the news item. I mean, this logic is revealed by the news item and by the link to the upstream wiki. It's not really that hard at all.

Maybe I am becoming a dinosaur, but just about everything that has to do with udev seems like some combination of Greek and Swahili to me.

Let's suppose I have a lot of machines with identical hardware, and I want to change all of the interfaces to net0 based on the "physical/geographical location of the connector of the hardware" (NOT THE MAC ADDRESS). How do I map enp3s0 to net0 with a rule (which I could actually somewhat automate)?

[SamuliSuominen]

Just a side comment, but it seems strange to me that no file gets one behavior, and an empty file gets a completely different behavior. Maybe that treatment occurs somewhere else in the universe, but I can't think of any such instance off the top of my head.

Empty file, or symlink to /dev/null in /etc/udev/rules.d will override the one in /lib/udev/rules.d and prevent it from taking place. This way udev has always worked far as I remember, ie. /etc/udev/rules.d is for overriding rules in /lib/udev/rules.d to prevent editing them directly there as /lib should be only touched by the package manager and in theory should be able to be mounted RO.

Let's suppose I have a lot of machines with identical hardware, and I want to change all of the interfaces to net0 based on the "physical/geographical location of the connector of the hardware" (NOT THE MAC ADDRESS). How do I map enp3s0 to net0 with a rule (which I could actually somewhat automate)?

In this example, eth0 has PCI bus position 0000:00:0c.0 (domain 0000, bus 00, device 0c, function 0), and eth1 has PCI bus position 0000:00:0d.0 (domain 0000, bus 00, device 0d, function 0):

/etc/udev/rules.d/70-my-network.rules:

ACTION=="add", SUBSYSTEM=="net", BUS=="pci", KERNELS=="0000:00:0c.0", NAME="net0"
ACTION=="add", SUBSYSTEM=="net", BUS=="pci", KERNELS=="0000:00:0d.0", NAME="net1"

That should work. I didn't test it.

[curmudgeon]

In this example, eth0 has PCI bus position 0000:00:0c.0 (domain 0000, bus 00, device 0c, function 0), and eth1 has PCI bus position 0000:00:0d.0 (domain 0000, bus 00, device 0d, function 0):

/etc/udev/rules.d/70-my-network.rules:

ACTION=="add", SUBSYSTEM=="net", BUS=="pci", KERNELS=="0000:00:0c.0", NAME="net0"
ACTION=="add", SUBSYSTEM=="net", BUS=="pci", KERNELS=="0000:00:0d.0", NAME="net1"

That should work. I didn't test it.

It doesn't work, and I have no idea how to get it to work.

Code: Select all

$ /usr/sbin/lspci

[...]

03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express (rev 02)

So I created the file in /etc/udev/rules.d/:

Code: Select all

ACTION=="add", BUS=="pci", KERNELS=="0000:03:00.0", SUBSYSTEM=="net", NAME="net0"

And I still get "renamed network interface eth0 to enp3s0."

It's not really that hard at all.

I am ready to call BS on that.

[gerard27]

I had similar problems on a box with a simple wired internet connection.
After reading all that's written about it I simply moved the "80-net-name-slot.rules" to a directory in /root.
Net.eth0 starts w/o problems like before.

I've no idea what would be needed for wireless.
Gerard.

[SamuliSuominen]

In this example, eth0 has PCI bus position 0000:00:0c.0 (domain 0000, bus 00, device 0c, function 0), and eth1 has PCI bus position 0000:00:0d.0 (domain 0000, bus 00, device 0d, function 0):

/etc/udev/rules.d/70-my-network.rules:

ACTION=="add", SUBSYSTEM=="net", BUS=="pci", KERNELS=="0000:00:0c.0", NAME="net0"
ACTION=="add", SUBSYSTEM=="net", BUS=="pci", KERNELS=="0000:00:0d.0", NAME="net1"

That should work. I didn't test it.

It doesn't work, and I have no idea how to get it to work.

And I still get "renamed network interface eth0 to enp3s0."

nod, I expect syntax may have changed, i'll test later.
mainly the point is to just use epn3s0 but what you are requesting is surely possible too, syntax error from my part I bet.

[curmudgeon]

I tried to read this (which the gentoo documentation references):

http://www.reactivated.net/writing_udev_rules.html

But it is coming up on its fifth anniversary without an update this week, and refers to commands (udevinfo, udevtest) that don't exist on any of my machines.

[SamuliSuominen]

I had similar problems on a box with a simple wired internet connection.
After reading all that's written about it I simply moved the "80-net-name-slot.rules" to a directory in /root.
Net.eth0 starts w/o problems like before.
Gerard.

That's wrong way around. If eth0 is being used without empty 80-net-name-slot.rules in /etc/udev/rules.d, or if it's not a symlink to eg. /dev/null, then it should use the predictable names.
So basically I bet you have a file, perhaps 70-persistent-net.rules in /etc/udev/rules.d that's stale, and because the rule refers NAME, it supersedes the /lib/udev/rules.d/80-net-name-slot.rules,
thus udev stops renaming them entirely and kernel will assign
You got the eth0 from kernel directly then, which might jump to, for example, eth1 when kernel, hardware, or something else changes, no guarantees it will stay with the name it's now.

If this is what you wanted, you should instead create /dev/null symlink to /etc/udev/rules.d/80-net-name-slot.rules, and delete 70-persistent-*.rules files and possible other old network rules getting in the way. That way it wouldn't work "by accident" but be as configured.
The news item explains it this way too.

[SamuliSuominen]

I tried to read this (which the gentoo documentation references):

http://www.reactivated.net/writing_udev_rules.html

But it is coming up on its fifth anniversary without an update this week, and refers to commands (udevinfo, udevtest) that don't exist on any of my machines.

The gentoo udev guide doesn't reference that page anymore because it's outdated for a long time now:

http://www.gentoo.org/doc/en/udev-guide.xml

Most translated pages are behind unfortunately.

[tnt]

this is very uncomfortable situation.

with headless servers 700km away from me and a lot of custom scripts/rules for eth0/1/2/3... (custom routing tables, iptables, pre- and post- up scripts, traffic shaping, monitoring...), I feel very bad when I thing about next reboot.

even if I manage to access system remotely (which would mean that I've dealt correctly with poorly-documented bringing up of devices), I still have couple of days of work to change everything else to net0/1/2/3...

it would be definitely much more professional if there would be the way to stay with current configuration, skip udev update or similar...

[gerard27]

@ssuominen,
This is a desktop with a permanent wired connection to a router installed by my ISP.
/etc/udev/rules.d is empty.
I've upgraded udev and the kernel several times the past week or so.
Gerard.

[kurly]

it would be definitely much more professional if there would be the way to stay with current configuration, skip udev update or similar...

Change to eudev and avoid all this nonsense. That's another path forward, one that I've found success with.

[asturm]

There's not much activity going on though. I've changed back to udev-200. Also, there's no final/stable release yet - nothing you would put on a server.

@tnt: Is there anyone forcing you to upgrade udev? Any way, at some point in the future you will need to deal with it and figure out which parts need reconfiguring.

Here's one success story which perfectly sums up my upgrade, except I had even less to do on my desktop system (of course, no non-local access headaches there): http://gentoo-pr.org/node/42

[Ant P.]

Yep, I switched to eudev as soon as it hit ~arch, and haven't had a single problem with idiotic backward-incompatible upstream decisions since.

[user]

I can understand the reason of unpredictable when renaming to interface names within range of kernel namespace, e.g. ethX.

But, it makes no sense using "enp3s0" or "enx001372eb4498" in all configs, iptables rules and monitor scripts.
In first case "enp3s0" is not persistent when changing card slot, in second case "enx001372eb4498" is barbarous for us.

So renaming (based on MAC) to non-kernel namespace interface names, eg. netX, lanX, wanX, makes sense.

For headless remote servers, it will be hard to hit all configs and rules correctly before rebooting into networkless server.

[asturm]

This is probably worth a read: http://blog.flameeyes.eu/2013/03/predic ... onic-names

[Bircoph]

This is probably worth a read: http://blog.flameeyes.eu/2013/03/predic ... onic-names

Forbidden

You don't have permission to access /cache//2013/03/predictable-persistently-non-mnemonic-names.html on this server.

Apache Server at blog.flameeyes.eu Port 80

[Flameeyes]

If you're using a funky browser private msg me your IP address so I can see why you're being blacklisted. If you're using a custom user agent or masking to a different useragent, drop the mask for my site or you'll be listed as a likely spammer.

Sorry for the inconvenience but it's either that or I'd have to close commenting on older posts...

[g8ecj]

Has anyone any tips on using this new udev on a diskless netboot client - mine insists on continuing to use eth0 even though udevadm reports the interface as enp0s10 !!

Code: Select all

# udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null
ID_NET_NAME_MAC=enx00012e2649db
ID_OUI_FROM_DATABASE=PC Partner Ltd.
ID_NET_NAME_PATH=enp0s10

After changing files on the nfs mount point, I've had to change most of it back and I've no clear idea what may or may not be working.

[SamuliSuominen]

Has anyone any tips on using this new udev on a diskless netboot client - mine insists on continuing to use eth0 even though udevadm reports the interface as enp0s10 !!

Code: Select all

# udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null
ID_NET_NAME_MAC=enx00012e2649db
ID_OUI_FROM_DATABASE=PC Partner Ltd.
ID_NET_NAME_PATH=enp0s10

After changing files on the nfs mount point, I've had to change most of it back and I've no clear idea what may or may not be working.

Have you deleted conflicting /etc/udev/rules.d/70-persistent-*.rules and /etc/udev/rules.d/80-net-*.rules ? Delete them, and the new names will take over.

[elmar283]

Before I start changing the network names I would like to know witch config files uses these old eth0 and wlan0 names.
Is there a command to look into config files in /etc for eth0 and wlan0?

I have come up with this:

Code: Select all

cat -n /etc/* |grep "eth0"

This will show the line number, but it will not show what file it shows and it will also try to cat directory's.

[SamuliSuominen]

Before I start changing the network names I would like to know witch config files uses these old eth0 and wlan0 names.
Is there a command to look into config files in /etc for eth0 and wlan0?

I have come up with this:

Code: Select all

cat -n /etc/* |grep "eth0"

This will show the line number, but it will not show what file it shows and it will also try to cat directory's.

Code: Select all

$ grep -n -r eth0 /etc/*

[snake111]

Given that is good to use the new names, the whole point in my opinion is down to:

1- Stick with auto-chosen names: enp0s25 and wlp3s0 in my case
2- Map auto-chosen names to be user friendly like net0 and net1

Ideal solution will be the second for me.

Given his hw conf and convenience, one should be able to map ID_NET_NAME_MAC [enx4c240a1935a1] to net0, or even ID_NET_NAME_PATH [enp0s25] if he wants to rely on physical/geographical location of hw connector (laptop?), or again use another identifier from ones provided by udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null.

My question is, how can I write a rule to accomplish the above?

[SamuliSuominen]

Given that is good to use the new names, the whole point in my opinion is down to:

1- Stick with auto-chosen names: enp0s25 and wlp3s0 in my case
2- Map auto-chosen names to be user friendly like net0 and net1

Ideal solution will be the second for me.

Given his hw conf and convenience, one should be able to map ID_NET_NAME_MAC [enx4c240a1935a1] to net0, or even ID_NET_NAME_PATH [enp0s25] if he wants to rely on physical/geographical location of hw connector (laptop?), or again use another identifier from ones provided by udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null.

My question is, how can I write a rule to accomplish the above?

For using MAC based interface names, you can look at existing posts with examples like http://forums.gentoo.org/viewtopic-t-95 ... ight-.html (Second reply)