Re: Problem with udev and ethX naming in latest Fedora 19.

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

 



On Thu, 15 Aug 2013 10:42:03 -0700
Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote:
> On 08/15/2013 08:14 AM, Reindl Harald wrote:
> > Am 15.08.2013 16:53, schrieb Ben Greear:
> >> On 08/15/2013 07:18 AM, Reindl Harald wrote:
> >>> Am 15.08.2013 16:05, schrieb Ben Greear:
> >>>>
> >>>> Yes, and I considered it, but I do not want my networks named
> >>>> like that.  I've been using ethX in my application and products
> >>>> for more than a decade, and do not want to change the naming
> >>>> scheme if at all possible.
[snip]
> >>>> I understand why the names come up jumbled on bootup, but there
> >>>> is no excuse for udev not being able to properly rename them as
> >>>> requested
> >>>
> >>> the kernel may also rename the devices as they come up
> >>> if kernel want make one nic to eth1 and udev at the same time
> >>> another one -> collision
> >>
> >> That's fine.  Udev can just detect the collision and try again,
> >> potentially moving the other one to a new name.  That is what it
> >> has done for years, in between bugs that caused eth0.rename
> >> devices to be left lying around.
> >
> > well complain at the udev/systemd-guys and the ones before who came
> > up with "biosdevname" you know that, i know that, you asked, i gave
> > you an answer more can hardly do a *user* in this case
> 
> I opened a bug against udev..will see if it gets any response.

Bugzilla link please?

Btw, I doubt that you'll be taken seriously enough. I can bet that the
devs are going to argue like this: if your software makes explicit
use of the "eth#" NIC naming, it is broken to begin with. Fix your
software, and that will remove the need for your complaint.

I remember seeing this argument before --- this was one of the reasons
why the biosdevname NIC names were designed as "p#p#" and "em#", while
ignoring the traditional "eth" naming. I cannot find any of the links
now, but all discussions were basically like this:

User: Why this stupid "p#p#" numbering scheme? Couldn't you use "eth#"
instead?
Dev: There is no way to name the NIC's in a linear way, so "eth#"
names are unsuitable.
User: But can't you at least make aliases from "p#p#" to "eth#" in udev?
Dev: There is no way to do that uniquely either, so we won't do it.
User: But my firewall rules are all written up using "eth#" names, and
now they are broken!
Dev: If your firewall rules made explicit usage of "eth#", they were
broken to begin with. You should fix the rules, rather than insist on
using "eth#".
User: How come my firewall rules were broken to begin with? They worked!
Dev: They worked by accident, because you didn't happen to experience
any race conditions in naming the NIC's. But they were broken
nevertheless.

So I basically expect that you'll be told to fix your software, so
that it doesn't use "eth#" names. If it is important for your software
to know which NIC is which, use biosdevname and "p#p#" naming. And bug
will be closed WONTFIX. Sorry.

Best, :-)
Marko

-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
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