On Tue, Feb 19, 2013 at 4:33 PM, Tom Gundersen <teg@xxxxxxx> 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. > 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 > > 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 systemd-udev-settle.service lines in the service file for dhcpd as well? Thanks -- mike c