Re: [...] "How does the new naming scheme look like, precisely?"

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

 



The current naming scheme works for the case of motherboard
replacements were the names and pci buses stay the same but the mac
addresses change.

I was previously using a static udev rule using bus-ids to force the
eth* devices to be consistent across motherboard replacements and
chassis swaps.    We had separate similar udev rules for each "model"
we used.    A static naming schem based on bus-id does eliminate the
need for the udev rule based on busid.

Note that all previous default udev schemes used in all versions I had
experience with were *CRAP* as on a motherboard replacement (exact
same model of motherboard) the new devices ended up being
ethn+1....were n was the number of original cards several of which are
no longer in there.

I did have one home motherboard were adding a PCI card resulted in the
bus-id changing but I more count that as a bad bios as outside of that
motherboard I have never seen the bus-id chaned.

Using mac address fails on card replacement without fighting with the
default generated rules and system, were as the static naming just
works on card and motherboard replacements.    And in the enterprise
card and motherboard replacements happen often.


On Tue, Mar 14, 2017 at 12:25 PM, Tom Horsley <horsley1953@xxxxxxxxx> wrote:
> On Tue, 14 Mar 2017 09:43:45 -0700
> Rick Stevens wrote:
>
>> Like I said, it's damned difficult to come up with something. If you
>> have a better idea, then submit it to the various kernel groups.
>
> I do have a better idea: Go back to the way it was when you could
> use udev to permanently assign names to interfaces :-).
>
> As you have just shown it is impossible to get it "right" but
> before they "fixed" it, you could at least get it to remain
> consistent with the udev rules.
>
> Stop trying to solve impossible problems.
> _______________________________________________
> users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@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