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
