i.e., it does not return the new name for eth0. I have now updated a machine to udev-199-r1 (adding USE=hwdb), but have not rebooted into it since it's headless and I don't want to hose my ssh access because udev might rename eth0. On my x86, x86_64 machines, I was up to udev-1999-r1 and could get the persistent network interface names in udev-199-r1 before updating to udev-200. Is it safe to boot into udev-199-r1 or will it start using some unknown network interface name? I'm using the latest kernel 3.8.5, btw. Anyone tried it?

Last edited by iMike on Thu Apr 04, 2013 10:10 am; edited 1 time in total

By default, systemd v197 will now name interfaces following policy 1) if that information from the firmware is applicable and available, falling back to 2) if that information from the firmware is applicable and available, falling back to 3) if applicable, falling back to 5) in all other cases. Policy 4) is not used by default, but is available if the user chooses so."

So your case is falling to the 5) from the document.

Out of curiosity, can you post the output of the following command:

Code:

$ udevadm info /sys/class/net/eth0

Since you see ID_NET_NAME_MAC there, you should be able to assume ID_NET_NAME_MAC is sane and safe to use as udev should check the sanity of it before making it available.

By default, systemd v197 will now name interfaces following policy 1) if that information from the firmware is applicable and available, falling back to 2) if that information from the firmware is applicable and available, falling back to 3) if applicable, falling back to 5) in all other cases. Policy 4) is not used by default, but is available if the user chooses so."

See part 4) which says MAC based names are disabled by default.

So about this point you are propably asking what a heck is he talking about, and what is the solution, right? You have 2 options. You can use the long MAC based enx* interface names, or you can use MAC to assign it a solid name:

Option 1, using short and sane MAC based name you can make up yourself)

Create file /etc/udev/rules.d/70-my-network.rules. The filename can be anything, but it's good idea to make it start like 70- and it must end with .rules.
Replace xx:xx:xx:xx:xx:xx with your own MAC address. And you can assign it any name you want, that is not already reserved by the kernel, so it can be other than net0 too.
The file would look like this:

I noticed that the PCI_CLASS_FROM_DATABASE in this case is "unassigned" and PCI_SUBCLASS_FROM_DATABASE is entirely missing; however, it didn't make any difference: your first soluton, creating a 70-my-network.rules, worked on both the G4 and G3. They both now report the same info above when I substitute net0 for eth0 running under udev-200 with kernel 3.8.5. I will probably try your solution 2 with a different G4 and see how that goes. If so, I'll report back here.

They both now report the same info above when I substitute net0 for eth0 running under udev-200 with kernel 3.8.5. I will probably try your solution 2 with a different G4 and see how that goes.

What do you mean by "when I substitute net0 for eth0"?

I hope you didn't mean you took the example Option 1) and replaced net0 with eth0 in your 70-my-network.rules from that, because that won't work.
That would be same as disabling the predictable interface feature entirely, because you can't rename into kernel reserved namespace like eth0, eth1, eth2, wlan0, wlan1, and a like.
That's why I said net0 but I could have said anything0, internet0, lan0, whatever123, freenamespace2, kernelhasnottakenthis6, ...

If the purpose was to use eth0 you could just delete 70-my-network.rules and create a empty file /etc/udev/rules.d/80-net-name-slot.rules to override /lib/udev/rules.d/80-net-name-slot.rules which is the correct way to disable the feature. Then possible random kernel names like eth0, eth1, eth2, wlan0, wlan1, ... are used.

Where I added the line with ID_NET_NAME_MAC. Then I would have long names like enx000393563422 I would use instead of something like net0. I don't see any advantage in this option, so I probably won't try it out for anything other than as a test.

If I have misunderstood, it was a good misunderstanding, because it all works (i.e., option 1, I have not tried option 2)

ok, so I've made today (with downloaded actual minimal iso, stage3 and snapshot) fresh install for new system and I was so suprised that nothing works fine - i went through like said in official handbook for amd64 as usual and I was very iritated.
First problem was the system cannot mount /run (eventually because it was not originally cleared before devtmpfs was mounted there), of course I resolved problem with kernel and devtmpfs and system went up and running with network eth0. But now I did update deep, so udev 200 apeared and eth0 vanished. I did "eselect read news all" to check what's going on and I came here to say that I don't understand how can I change eth's names with my own e.g. link0. I did what You write here in forum, but still I can only work with enp4s0 name so
cat /etc/udev/rules.d/70-my-network.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="my_mac", NAME="link0"
doesn't work

The eth0 or whatnot in handbook is an example. The device name has always been driver, kernel and hardware dependant, not much as it's now sure. So replace eth0 in the handbook with your actual device and go through the steps you did there, and you have everything working assuming they would have been working in the first place.

As for why the .rules file is not working, is there old /etc/udev/rules.d/70-persistent-net.rules in place? Or some other network .rules file with NAME in it that would take precedence?

Are you sure the MAC is typed correctly? Does it have lower or upper case letters? Trying to say, try the obvious first.
Are you using net.ifnames=0 kernel parameter or not? Should be visible in /proc/cmdline if changed.

ifconfig, ifconfig -a

The latest stage3 file is a bit old too, and still has 197-r8 as starting point, instead of 200, that should autoresolve itself with the autobuilds.