[arch-general] A question about handling a system with two wired network interfaces?

Mike Cloaked mike.cloaked at gmail.com
Tue Feb 19 16:03:48 EST 2013

On Tue, Feb 19, 2013 at 4:33 PM, Tom Gundersen <teg at 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"
>   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


mike c

More information about the arch-general mailing list