Hola. 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: https://serverfault.com/questions/636621/why-is-my-eth0-called-eno16777736 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? https://communities.vmware.com/message/2378360 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: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/ Networking_Guide/ch-Consistent_Network_Device_Naming.html Just the subchapter of disabling the names is quite hilarious: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/ Networking_Guide/sec-Disabling_Consistent_Network_Device_Naming.html 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: https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#new-interface-names 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: https://www.freedesktop.org/wiki/Software/systemd/ PredictableNetworkInterfaceNames/ Which fails to mention how the feature can be configured and some mechanisms like relying on BIOS name, can be disabled, for example: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/ Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html 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. https://wiki.debian.org/ NetworkConfiguration#Predictable_Network_Interface_Names So in summary this change adds a *huge lot* of complexity with questionable gain. 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 https://bugs.debian.org/864074 screen: after sshing, some commands give error "Error opening terminal: screen.xterm-256color." https://bugs.debian.org/854414 (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. Adios, -- Martin
Attachment:
signature.asc
Description: This is a digitally signed message part.