If you are managing 1 or 10 that are not the same, then yes, but if one is managing 10,000+ physical linu servers with a very few models/layouts (spanning the 5-9 year life you are dealing with) and you up front determine the mappings by model then by pcid mapping is great. Prior to the pciids naming scheme, it depended on the order the drivers were loaded, and if you added the cards after the fact it showed up after the current cards (udev rule mapping by mac address and/or mac address mapping in ifcfg files). And if you involve the mac addresses anywhere replacing any failing hardware becomes a complicated process, as you have to find the udev rule/ifcfg-hwaddr and fix it, and if the node was dead when you do the replacement one has to often take it to single user mode and sort out the mac addresses. With the pciids, then replacement with a like identical replacement is easy, as the new machine just boots up and works, with mac addresses, it does boot up, but the network fails and has to be manually fixed. And when one is managing a bunch of systems this becomes a problem, the pciids also result in the configurations of a like model all having the exact same names for the same physical cards at the same locations which make things much simpler for the automation building systems and the people cabling the systems. On Sat, Apr 18, 2020 at 5:42 AM Ian Chapman <packages@xxxxxxxxxxxxxxxxxx> wrote: > > On 13/04/2020 07:47, Roger Heflin wrote: > > > The only negative part I have seen is that on one of my desktop > > systems at home removing/adding a pci card changes the PCI-busid of > > the built-in network card (guessing badly designed/coded bios). > > And that's exactly why the whole naming this is a PITA and doesn't solve > much anyway. It really is not that easier now playing guess the NIC than > it was when everything was eth*. Besides the supposed slot numbering > system often does match reality for the same reasons you say... the BIOS > being stupid. > > -- > Regards, > Ian Chapman > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx