Problem with udev and ethX naming in latest Fedora 19.

[Ben Greear]

On 08/15/2013 02:50 PM, Marko Vojinovic wrote:
> On Thu, 15 Aug 2013 10:42:03 -0700
> Ben Greear <greearb at candelatech.com> 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 at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com