On 07/10/2017 07:31 PM, Martin Steigerwald wrote: > 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
I was under the impression that Debian does not even use biosdevname. (I'm not sure anyone else still does.) But I can be wrong, of course. I think now that we released this the most straightforward way to go about this is to cope and document for others. Personally I dislike the idea of a state file that you need to know about to remove during imaging, but to everyone their own. If you use things like systemd-networkd[1], you'll also notice that the configuration scheme does not even require you to specify the interface to operate on. Instead you get a bunch of match expressions. Which leaves things like daemons, which more often hardcode IP addresses than interfaces, though. Kind regards Philipp Kern [1] Which indeed has flaws, most notably with IPv6.
signature.asc
Description: OpenPGP digital signature