Not-so-predictable network names

[Michael Senizaiz]

Network naming has been troublesome for a bit.  If you want to keep the
classic names, your boot string needs to contain:

net.ifnames=0 biosdevname=0


On Thu, Aug 4, 2016 at 10:09 AM, Alexander Thomas <
alexander.thomas at esaturnus.com> wrote:

> There was a discussion titled “example network script will misname
> interface if installing stretch” just a few weeks ago. It ended with:
>
> Thomas Lange wrote:
> > > Using jessie as the base os to install stretch.
> > > 30-interface will setup /etc/network/interfaces with
> > > something like eth0, and if you upgrade to stretch,
> > > it will reboot and eth0 is now named something like
> > > enp3s0f1.
> > This is already fixed in FAI 5.1.
>
> I now have the same problem while installing xenial from a jessie
> NFSroot. It defines an interface eth0 in /etc/network/interfaces, but
> when the installed system boots, the interface is named ‘ens3’.
>
> I installed FAI 5.1.2 and ensured I have the latest config scripts
> from the FAI git repository, but it makes no difference. I tried the
> following workaround inspired by the same discussion thread, by
> renaming $NIC1 in scripts/DEBIAN/30-interface as follows:
>
> NIC1="$(udevadm test /sys/class/net/$NIC1 2>/dev/null | fgrep
> ID_NET_NAME_SLOT | cut -d= -f2)"
>
> Although it feels dirty and unreliable and I don't know why I need to
> use SLOT here instead of PATH, it worked fine, at first. When I try to
> install a VM with a virtio network interface, it breaks. In that case,
> ID_NET_NAME_SLOT is no longer in the udevadm output, only
> ID_NET_NAME_MAC is. Still, the interface eventually becomes ‘ens3’,
> but that name is nowhere to be found in the udevadm output.
>
> How do I ensure /etc/network/interfaces is always written with the
> correct names? Or how do I end up with a truly predictable network
> device?
>
>
> Regards,
> Alexander
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20160804/808c2248/attachment.html>