Web lists-archives.com

Naming of network devices (was: Re: Debian 9 in a VM with Proxmox 5 system)


Adam Borowski - 10.07.17, 18:22:
> On Mon, Jul 10, 2017 at 03:47:14PM +0200, Guus Sliepen wrote:
> > On Mon, Jul 10, 2017 at 01:57:08PM +0200, Rene Engelhard wrote:
> > > eth0 will be kept on upgrades, but new installs get new interface names
> > > (that is good, that removed unpredictability if you add a new network
> > > card.)> 
> > Interface names are, unfortunately, as unpredictable in stretch as they
> > were in jessie, just unpredictable in a different way. Now network names
> > are decided based on bus topology or MAC address. Bus topology however
> > is not something that is as predictable as you might think, and some
> > network cards just don't have a fixed MAC address. Bus topology might
> > change if you just move a card from one slot to the next, or as I've
> > experienced myself, when nothing in the hardware changes, but a BIOS
> > update causes enumeration to happen differently.
> > 
> > At least the interface names in jessie were shorter, and you had a good
> > chance that eth0 was exactly what you wanted :)
> I'd say the last part is the most important one: the vast majority of
> machines have exactly one Ethernet interface and at most one WiFi interface.
> Furthermore, the ones that got more either have an admin with some
> knowledge (bigger servers) or come preloaded (routers).
> Predictability is important, thus let's actually have _predictable_
> interface names.  The kernel default, eth0 and wlan0, is good enough for
> most users, why not keep that?  Even just ignoring the issue completely
> is much, much better than current state.
> FreeDesktop's interface naming promised stability, it did not deliver.  Even
> regular non-fancy x86 machines often switch names on jessie->stretch
> upgrades, not to mention arm SoCs with no MAC address at all (that EPROM
> would cost a few cents, you see...).

Actually I disabled the new naming scheme in CentOS VMs I use for training 
already, cause… for VMware VM´s it tends to create names followed by a number 
of about 16 million – sometimes. Yes, thats no joke. I don´t have a copy of 
that name any more, but here is an online reference to that marvellous 
eno16777736 name:


Yes, and it appears to be a negative overflow of acpi_index, so the actual 
issue below it may appear to be elsewhere, in the BIOS/UEFI firmware, but why 
rely on something that can have crazy values like that in the first place 
without checking it for sanity first?


I can imagine the likely response by upstream "wontfix – not a bug" – I have 
seen this pattern way too often regarding this particular upstream meanwhile.

Also, RHEL 7´s networking guide has a *complete* chapter with eleven sub 
chapters about naming network devices:


Just the subchapter of disabling the names is quite hilarious:


A *chapter* on the naming of network devices… sanity and simplicity look 
different to me and I am not happy about that being the new default in Stretch 
installs. I didn´t open a bug, cause my faith of it being handled in a way 
that actually creates a relief is pretty low. Thankfully it does´t change the 
naming scheme on upgrades:


But at least… RHEL has this documentation. In Debian it appears to be 
underdocumented, there is a snippet in README.Debian of udev package, the 
short mentioning in Release notes and a short snippet in Debian wiki which all 
refer to a quite short page on Freedesktop.org webpage which at least 
describes by what rules udev now tries to name network devices:


Which fails to mention how the feature can be configured and some mechanisms 
like relying on BIOS name, can be disabled, for example:


Funnily enough the Debian wiki page even mentions that some BIOS firmwares 
return crap as the onboard device number:

> Sadly, the system used is still somewhat arbitrary in that it relies on the
> BIOS enumeration which changes in with buggy BIOSs and under some
> situations.

without offering a solution:

> For people using more than one Network Interface - we will just have to deal
> with the new system.


So in summary this change adds a *huge lot* of complexity with questionable 

In addition to the new default VIM configuration and the new default screen 
configuration stuff Debian 9 is the Debian release where I currently adapt the 
most things in order to just regain some sanity:

vim: 'set mouse=' in /etc/vim/vimrc.local is ignored unless ~/.vimrc exists

screen: after sshing, some commands give error "Error opening terminal: 

(I can even understand the reasoning of the maintainer Axel not to change it, 
but it isn´t satisfying to leave it as it is either.)

I personally find this trend disturbing. Sure, I am experienced enough to make 
all these changes… but it certainly creates additional work and violates the 
principle of least surprise crossly.


Attachment: signature.asc
Description: This is a digitally signed message part.