Re: device names

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux