Re: F18: unpredictable 'Predictable Network Interface Names'?

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

 



Marko Vojinovic wrote:
> On Mon, 25 Feb 2013 22:51:15 +0100
> poma <pomidorabelisima@xxxxxxxxx> wrote:
>> On 02/25/13 21:01, Reindl Harald wrote:
>> […]
>>> so switch to anything else as ethX in your naming in
>>> /etc/udev/rules.d/70-persistent-net.rules
>>> like "lan0", "lan1", "wan0", "wan1" in ifcfg-lan1....
>>>
>>> so you would not have race-conditions in kernel/udev naming the
>>> interfaces
> 
> Just a small comment --- I believe everyone following this thread is
> aware that these race conditions are the very reason for the
> introduction of biosdevname in the first place.

"race conditions" on few static NICs?
"race conditions" which udev could serve well?
It sounds weird...

> In order to avoid race conditions, one can either use biosdevname and
> have eth* be replaced by different names like em* and p*p*, or one can
> disable biosdevname, configure udev manually, and have have eth* be
> replaced by names like lan* and wan*.
> 
> The actual difference between the two methods is about system
> maintenance --- when your network card burns out (these things happen,
> unfortunately), biosdevname allows you to plug a new card into the same
> pci slot and just turn the machine back on, with no extra
> configuration. If you are configuring udev manually, and tie nic names
> to MAC addresses, you are required to reconfigure udev for
> the new MAC address of the new card.
>
> The pain is greater in the latter case, while I see no gain at all,
> compared to the way of biosdevname.

During approx. last ten years I had only two bad network adapters
(as their single fault, I not consider situations when blow out whole
box). Then I have no problem with this.

> Maybe the OP can enlighten me *why* does he need MAC-oriented naming
> scheme so badly? Just curious... :-)

Why badly?
ethX are native kernel device, all Linux users ever know them, until
now was not problem with using them. Why should be it problem now?

And regards MAC-based naming: as before, until now has never been
problem with, why now?

And why is MAC based naming important for me? E.g:
- I often rebuild our Linux boxes and want right working with NICs in
other bus positions or even other mainboards.

- my boxes works not in vacuum but in normal or dusty environment
and must be periodically cleaned. And I want right function even
when I pull up NICs and then insert them in other order. I had
simply ethernet cable and relevant NIC marked (WAN2, DMZ, LAN3,..)
and want when I put cable to equally marked NIC right work.

> Best, :-)
> Marko

-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


[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