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

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

 



Marko Vojinovic writes:

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.

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.

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

This is how the network devices were configured originally, by whatever component was used to install whatever Fedora release was initially installed on this machine. I don't remember which one it was, but that must've been how ifcfg-* was set up some time ago, by whatever version of Anaconda was in effect at that time.

I don't see the big hassle with binding network interfaces by MAC addresses. It's not like I replace NIC cards every week.

Plus, the MAC binding came in handy when the kernel switcherooed them on me. It's a much more spectacular failure mode. It's better to have not anything come up at all, then have all the firewall rules wrong.

P.S. There's something magical about ethX. Even after I moved eth1 to wan0, there was one boot where eth0 came up as eth1, even though nothing came up at eth0, and the other NIC came up normally as wan0, so I ended up with wan0 and eth1.

But after moving both of them to lan0 and wan0 things seemed to be settled down…

Attachment: pgpbgp2PhsZY_.pgp
Description: PGP signature

-- 
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