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

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

 



On 08/15/2013 02:50 PM, Marko Vojinovic wrote:
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.

Quite close actually.  They closed the bug within about 10 minutes :)

But, I still think it all can be made to work..if nothing else, by allowing
the kernel to use a different default name space.

https://bugzilla.redhat.com/show_bug.cgi?id=997573

I'm not actually complaining about their default naming..just the inability
of udev to over-ride names based on a MAC address *with the new name being ethX*
instead of fooX.

Thanks,
Ben


Best, :-)
Marko



--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc  http://www.candelatech.com

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