Hi Mike, On Tue, Feb 19, 2013 at 3:32 PM, Mike Cloaked <mike.cloaked@xxxxxxxxx> wrote: > I have a system with two ethernet sockets on the motherboard, and I have > until very recently been finding that my network at random failed to come > up during the boot process. 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? > I have the ethernet cable plugged into only one of the two sockets, and > assign the names to the interfaces as eno1 and eno2 - because left to its > own it assigned one of them as name "eno1" and the other to "eth0" or > "eth1" at random between boots! I was surprised that it chose ethX at all > for the second name, given this is running with the new naming scheme! 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. > However following the hints at: > > https://wiki.archlinux.org/index.php/Udev#Network_device > > 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. > What I then presumed was that although the same two names are always > assigned, the hardware mac address to which of the two physical network > ports was being assigned was being assigned differently to the two names - > i.e. sometimes being en01 and sometimes being eno2. Why this matters is > that I assign a static ip address to eno1 only and don't use eno2. This > would only be an issue if there was more than one NIC in the system. > > The system boots really fast as it has SSD drives, which possibly was not > allowing enough time for the name assignment, so I then found the advice at: > > https://wiki.archlinux.org/index.php/Rename_network_interfaces > > where it suggests editing the systemd unit file for in my case > NetworkManager service - which I then did and this finally seems to have > fixed the problem though I will still need to boot over a period of days to > check if the network comes up "every" time now. The wiki page refers to the > network service file, but I applied this to the NetworkManager service file. > > So the question that I hope someone can answer is whether in the case of > multiple NICs in a system the new network names, although the same "set" of > names is used for all the cards in the system, will still need this systemd > unit file amendment - i.e. adding the two lines: > > Requires=systemd-udev-settle.service > After=systemd-udev-settle.service > > to the [unit] section in order to get the correct 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). HTH, Tom
