On Tue, Feb 19, 2013 at 4:33 PM, Tom Gundersen <teg@jklm.no> wrote: Just to be clear: the problem is still occurring (I am confused by
"until recently")? Was it brought on by the recent udev naming change, or is it a long-standing problem?
This is a new system that was installed very recently using the February archiso. So I have no past history of the problem - only current experience. What you are seeing is that udev is able to reliably name one of your
devices (eno1), which (unless you add any custom rules) will always refer to the same network port between reboots (in particular, it refers to the first on-board network device). However, the other device udev is not able to reliably name, so it leaves it alone. This explains why it still has a name in the kernel namespace (ethX), and why it alternates between eth0 and eth1.
Thank you for that explanation - it certainly helps to understand what is going on.
I specify that udev fix the two interface names as eno1 and eno2
It is probably better to use different names than the enoX ones (though not strictly speaking necessary) if you specify them using your custom scheme (as outlined in the wiki article you link to). The reason is that the enoX names have a specific meaning (they are the on-board devices in the order given by the hardware).
Currently, udev will not give out stable interface names based on mac addresses even though it can. To overcome this, you could put this into /etc/udev/rules/80-net-name-slot.rules:
ACTION=="remove", GOTO="net_name_slot_end" SUBSYSTEM!="net", GOTO="net_name_slot_end" NAME!="", GOTO="net_name_slot_end"
NAME=="", ENV{ID_NET_NAME_ONBOARD}!="", NAME="$env{ID_NET_NAME_ONBOARD}" NAME=="", ENV{ID_NET_NAME_SLOT}!="", NAME="$env{ID_NET_NAME_SLOT}" NAME=="", ENV{ID_NET_NAME_PATH}!="", NAME="$env{ID_NET_NAME_PATH}" NAME=="", ENV{ID_NET_NAME_MAC}!="", NAME="$env{ID_NET_NAME_MAC}"
LABEL="net_name_slot_end"
That should, if the MAC address is reliable, name your ethX device as something like "enx98fe023fa538". Note, however, that udev will try to first ascertain if the MAC address can be trusted (for instance, some machines will randomly assign the MAC at every boot), so if this does not work for you it (probably) means that udev decided not to trust the MAC address so did not export the name.
same hardware mac address every boot?
If someone who understands these things in detail could confirm if my understanding is correct I would appreciate it?
There has been some bugs where network software grab the device before udev can rename it, which could be solved with the workaround you reference above. However, I doubt this to be the case with NetworkManager, as far as I know it is only a problem with dhcpcd.service (but dhcpcd@<your network device>.service works correctly).
I will check which of the two is enabled - but I have since my last post now switched on dhcpd (server) and named services - after boot the dhcpd service had entered a failed state and I am now wondering if I need to add
The MAC addresses seem to be consistent - and the udev rule does seem to make it boot consistently once I had done that in combination with the systemd-udev-settle.service lines in the service file. ct name associated with the the systemd-udev-settle.service lines in the service file for dhcpd as well? Thanks -- mike c