[gentoo-user] Udev update and persistent net rules changes

[gentoo-user] Udev update and persistent net rules changes

[Tanstaafl]

Ok, just read the new news item and the linked udev-guide wiki page, and 
the only thing left that I'm unsure/concerned about now is the 
persistent net rules changes...

The very last line on the wiki page says:

> 4. Known problems
>
> Stale 70-persistent-net.rules (or other network rules) in
> /etc/udev/rules.d can prevent the predictable network naming from being
> enabled. Both 70-persistent-net.rules and 70-persistent-cd.rules are
> from the now deleted rule_generator

These 'stale' 70- rules are all I have right now (again I'm still on 
udev-171-r10), and while the wiki page doesn't say what to do with/about 
them, it seems to hint that I could leave these in place and... they 
would still work as they did previously (prevent the predictable network 
naming from being enabled)?

My system (8+ years old) has a Tyan motherboard (S2895) with dual Gb 
ethernet ports, with only one port currently used (but both are enabled 
in the BIOS so both are listed in my current rules file).

Contents of rules.d:

myhost : Sat Mar 30, 08:33:28 : ~
  # ls -al /etc/udev/rules.d
total 16
drwxr-xr-x 2 root root 4096 Feb 23 15:04 .
drwxr-xr-x 4 root root 4096 Feb 23 15:04 ..
-rw-r--r-- 1 root root 1187 Apr 11  2010 70-persistent-cd.rules
-rw-r--r-- 1 root root  492 Feb 23 15:04 70-persistent-net.rules
-rw-r--r-- 1 root root    0 Feb 23 15:04 .keep_sys-fs_udev-0
myhost : Sat Mar 30, 08:33:29 : ~

Contents of 70-persistent-net.rules:

> # This file was automatically generated by the /lib/udev/write_net_rules
> # program, probably run by the persistent-net-generator.rules rules file.
> #
> # You can modify it, as long as you keep each rule on a single line.
>
> # PCI device 0x10de:0x0057 (forcedeth)
> SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:e0:81:54:9c:8b", KERNEL=="eth*", NAME="eth1"
>
> # PCI device 0x10de:0x0057 (forcedeth)
> SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:e0:81:54:9c:8a", KERNEL=="eth*", NAME="eth0"

So... after reading the new news item, am I right that all I need to do 
to make sure that my network comes up properly is... edit the 80-* 
rule(s) that are created after udev is updated to make sure the same 
adapters that were named eth0/1 are now named net0/1, and the kernel 
will now take care of naming net0/1 eth0/1?

Also, is it critical to remove (or at least rename) the old 70- rules 
*before* the update, or just be sure to do so before I reboot after the 
update?

Thanks - I'm sure I'm just being paranoid, but it has helped me to avoid 
lots of pain in the past with other major updates on this system over 
these last 8+ years.

(I'm not concerned about the cd rule because obviously that won't affect 
the system booting, so I can come back and fix this one later if needed)

[gentoo-user] Re: Udev update and persistent net rules changes

[Nuno J. Silva (aka njsg)]

On 2013-03-30, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> Ok, just read the new news item and the linked udev-guide wiki page, and 
> the only thing left that I'm unsure/concerned about now is the 
> persistent net rules changes...
>
> The very last line on the wiki page says:
>
>> 4. Known problems
>>
>> Stale 70-persistent-net.rules (or other network rules) in
>> /etc/udev/rules.d can prevent the predictable network naming from being
>> enabled. Both 70-persistent-net.rules and 70-persistent-cd.rules are
>> from the now deleted rule_generator
>
> These 'stale' 70- rules are all I have right now (again I'm still on 
> udev-171-r10), and while the wiki page doesn't say what to do with/about 
> them, it seems to hint that I could leave these in place and... they 
> would still work as they did previously (prevent the predictable network 
> naming from being enabled)?
>
> My system (8+ years old) has a Tyan motherboard (S2895) with dual Gb 
> ethernet ports, with only one port currently used (but both are enabled 
> in the BIOS so both are listed in my current rules file).

(And, more importantly, they're seen and handled by the running kernel.)

[...]
> Contents of 70-persistent-net.rules:
>
>> # PCI device 0x10de:0x0057 (forcedeth)
>> SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:e0:81:54:9c:8b", KERNEL=="eth*", NAME="eth1"
>>
>> # PCI device 0x10de:0x0057 (forcedeth)
>> SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:e0:81:54:9c:8a", KERNEL=="eth*", NAME="eth0"
>
> So... after reading the new news item, am I right that all I need to do 
> to make sure that my network comes up properly is... edit the 80-* 
> rule(s) that are created after udev is updated to make sure the same 
> adapters that were named eth0/1 are now named net0/1, and the kernel 
> will now take care of naming net0/1 eth0/1?

You can either remove it and get what udev gives you (a bit more
cryptic, but it is supposed to be somewhat persistent unless the cards
are moved around, or there are major kernel changes), or you can give
them the names you want, as far as it's not ethX.

But you will always have to update other config files (firewall, init
scripts, etc.) to have the new names.

> Also, is it critical to remove (or at least rename) the old 70- rules 
> *before* the update, or just be sure to do so before I reboot after the 
> update?

No idea, I'd expect it to be only needed for the reboot, but I don't
know udev *that* well.

> Thanks - I'm sure I'm just being paranoid, but it has helped me to avoid 
> lots of pain in the past with other major updates on this system over 
> these last 8+ years.
>
> (I'm not concerned about the cd rule because obviously that won't affect 
> the system booting, so I can come back and fix this one later if needed)

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

[gentoo-user] Re: Udev update and persistent net rules changes

[Nikos Chantziaras]

On 30/03/13 17:15, Tanstaafl wrote:
> Ok, just read the new news item and the linked udev-guide wiki page

You should probably also read:

   http://blog.flameeyes.eu/2013/03/predictably-non-persistent-names

and:

 
http://blog.flameeyes.eu/2013/03/predictable-persistently-non-mnemonic-names

[gentoo-user] Re: Udev update and persistent net rules changes

[Nuno J. Silva (aka njsg)]

On 2013-03-31, Nikos Chantziaras <realnc@gmail.com> wrote:
> On 30/03/13 17:15, Tanstaafl wrote:
>> Ok, just read the new news item and the linked udev-guide wiki page
>
> You should probably also read:
>
>    http://blog.flameeyes.eu/2013/03/predictably-non-persistent-names
>
> and:
>
>  
> http://blog.flameeyes.eu/2013/03/predictable-persistently-non-mnemonic-names

The feeling that I got while reading the first was exactly what the
second talks about.

We - from what I understand - had scripts automatically generating the
name rules from MAC addresses, it's just that they generated stuff like
ethX.

Can't we just keep these scripts around (even if this was something
provided by upstream and we would have to forge a new incarnation)?

I mean, IMHO, net0, wl0, ... are much easier to deal with and understand
than something physically-based. They also avoid problems caused by
moving these cards around, or changes in the kernel drivers or BIOS, or
BIOS settings that eventually end up exposing cards in a different way.

The problem with the old approach was *just* the name clash that
rendered the hacky approach unreliable. Maybe we could just fix the
issue by using non-clashing namespaces, instead of pushing a completely
different (and possibly less reliable) naming scheme by default.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

[gentoo-user] Re: Udev update and persistent net rules changes

[Nuno J. Silva (aka njsg)]

On 2013-03-31, Nuno J. Silva (aka njsg) <nunojsilva@ist.utl.pt> wrote:
> On 2013-03-31, Nikos Chantziaras <realnc@gmail.com> wrote:
>> On 30/03/13 17:15, Tanstaafl wrote:
>>> Ok, just read the new news item and the linked udev-guide wiki page
>>
>> You should probably also read:
>>
>>    http://blog.flameeyes.eu/2013/03/predictably-non-persistent-names
>>
>> and:
>>
>>  
>> http://blog.flameeyes.eu/2013/03/predictable-persistently-non-mnemonic-names
>
> The feeling that I got while reading the first was exactly what the
> second talks about.
>
> We - from what I understand - had scripts automatically generating the
> name rules from MAC addresses, it's just that they generated stuff like
> ethX.
>
> Can't we just keep these scripts around (even if this was something
> provided by upstream and we would have to forge a new incarnation)?
>
> I mean, IMHO, net0, wl0, ... are much easier to deal with and understand
> than something physically-based. They also avoid problems caused by
> moving these cards around, or changes in the kernel drivers or BIOS, or
> BIOS settings that eventually end up exposing cards in a different way.
>
> The problem with the old approach was *just* the name clash that
> rendered the hacky approach unreliable. Maybe we could just fix the
> issue by using non-clashing namespaces, instead of pushing a completely
> different (and possibly less reliable) naming scheme by default.

Ok, after some chat on IRC, it seems that upstream made it rather
non-trivial to have something like the old rule-generator, and that's
why we can't simply move that from, e.g., ethX to, say, netX.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Kevin Chadwick]

On Sun, 31 Mar 2013 11:48:19 +0000 (UTC)
"Nuno J. Silva (aka njsg)" <nunojsilva@ist.utl.pt> wrote:

> instead of pushing a completely
> different (and possibly less reliable) naming scheme by default.

Whilst I wouldn't want them changing on me (though if your physically
changing the pci slot then you should be able to handle the number
change). I find the OpenBSD method of different names like fxp0 useful
because it means you can look up the manpage for that card type which
as long as the documentation is good is very useful.

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]

On Mar 31, 2013 7:13 PM, "Nuno J. Silva (aka njsg)" <nunojsilva@ist.utl.pt>
wrote:
>
> On 2013-03-31, Nuno J. Silva (aka njsg) <nunojsilva@ist.utl.pt> wrote:
> > On 2013-03-31, Nikos Chantziaras <realnc@gmail.com> wrote:
> >> On 30/03/13 17:15, Tanstaafl wrote:
> >>> Ok, just read the new news item and the linked udev-guide wiki page
> >>
> >> You should probably also read:
> >>
> >>    http://blog.flameeyes.eu/2013/03/predictably-non-persistent-names
> >>
> >> and:
> >>
> >>
> >>
http://blog.flameeyes.eu/2013/03/predictable-persistently-non-mnemonic-names
> >
> > The feeling that I got while reading the first was exactly what the
> > second talks about.
> >
> > We - from what I understand - had scripts automatically generating the
> > name rules from MAC addresses, it's just that they generated stuff like
> > ethX.
> >
> > Can't we just keep these scripts around (even if this was something
> > provided by upstream and we would have to forge a new incarnation)?
> >
> > I mean, IMHO, net0, wl0, ... are much easier to deal with and understand
> > than something physically-based. They also avoid problems caused by
> > moving these cards around, or changes in the kernel drivers or BIOS, or
> > BIOS settings that eventually end up exposing cards in a different way.
> >
> > The problem with the old approach was *just* the name clash that
> > rendered the hacky approach unreliable. Maybe we could just fix the
> > issue by using non-clashing namespaces, instead of pushing a completely
> > different (and possibly less reliable) naming scheme by default.
>
> Ok, after some chat on IRC, it seems that upstream made it rather
> non-trivial to have something like the old rule-generator, and that's
> why we can't simply move that from, e.g., ethX to, say, netX.
>
> --
> Nuno Silva (aka njsg)
> http://njsg.sdf-eu.org/
>
>

Since it's obvious that upsteam has this "my way or the highway" mentality,
I'm curious about whether eudev (and mdev) exhibits the same behavior...

Rgds,
--

[-- Attachment #2: Type: text/html, Size: 2919 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Dale]

Pandu Poluan wrote:
>
>
>
> Since it's obvious that upsteam has this "my way or the highway"
> mentality, I'm curious about whether eudev (and mdev) exhibits the
> same behavior...
>
> Rgds,
> --
>

I synced yesterday and I didn't see the news alert.   Last eudev update
was in Feb. so I *guess* not.  It seems to be a "udev" thing.  That is
why I mentioned eudev to someone else that was having this issue with a
server setup. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

[gentoo-user] Re: Udev update and persistent net rules changes

[Nuno J. Silva (aka njsg)]

On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
> Pandu Poluan wrote:
>>
>>
>>
>> Since it's obvious that upsteam has this "my way or the highway"
>> mentality, I'm curious about whether eudev (and mdev) exhibits the
>> same behavior...
>>
>
> I synced yesterday and I didn't see the news alert.   Last eudev update
> was in Feb. so I *guess* not.  It seems to be a "udev" thing.  That is
> why I mentioned eudev to someone else that was having this issue with a
> server setup. 

I'd guess eudev will eventually do the same, although I hope that, it
being a separate codebase, makes it easier to adopt some solution like
the old rule generator, instead of using udev's approach.

The udev upstream may have its issues, but there's actually a point in
removing this, the approach there was so far was just a dirty hack.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Dale]

Nuno J. Silva (aka njsg) wrote:
> On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
>> Pandu Poluan wrote:
>>>
>>>
>>> Since it's obvious that upsteam has this "my way or the highway"
>>> mentality, I'm curious about whether eudev (and mdev) exhibits the
>>> same behavior...
>>>
>> I synced yesterday and I didn't see the news alert.   Last eudev update
>> was in Feb. so I *guess* not.  It seems to be a "udev" thing.  That is
>> why I mentioned eudev to someone else that was having this issue with a
>> server setup. 
> I'd guess eudev will eventually do the same, although I hope that, it
> being a separate codebase, makes it easier to adopt some solution like
> the old rule generator, instead of using udev's approach.
>
> The udev upstream may have its issues, but there's actually a point in
> removing this, the approach there was so far was just a dirty hack.
>


Thing is, it works for me.  The old udev worked, eudev works but I'm not
sure what hoops I would have to go through to get the new udev working,
most likely the same ones others here are going through now.  For once,
I'm not having to deal with some broken issue.  < knock on wood > 

My current uptime is about 190 days.  May hit it still but I'm certainly
hoping I don't. 

Dale 

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

[gentoo-user] Re: Udev update and persistent net rules changes

[Nuno J. Silva (aka njsg)]

On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
> Nuno J. Silva (aka njsg) wrote:
>> On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
>>> Pandu Poluan wrote:
>>>>
>>>>
>>>> Since it's obvious that upsteam has this "my way or the highway"
>>>> mentality, I'm curious about whether eudev (and mdev) exhibits the
>>>> same behavior...
>>>>
>>> I synced yesterday and I didn't see the news alert.   Last eudev update
>>> was in Feb. so I *guess* not.  It seems to be a "udev" thing.  That is
>>> why I mentioned eudev to someone else that was having this issue with a
>>> server setup. 
>> I'd guess eudev will eventually do the same, although I hope that, it
>> being a separate codebase, makes it easier to adopt some solution like
>> the old rule generator, instead of using udev's approach.
>>
>> The udev upstream may have its issues, but there's actually a point in
>> removing this, the approach there was so far was just a dirty hack.
>>
>
>
> Thing is, it works for me.  The old udev worked, eudev works but I'm not
> sure what hoops I would have to go through to get the new udev working,
> most likely the same ones others here are going through now.  For once,
> I'm not having to deal with some broken issue.  < knock on wood > 
>
> My current uptime is about 190 days.  May hit it still but I'm certainly
> hoping I don't. 

And, at least now, I have got enough knowledge to know whether it
affects me or not. But the sad thing is that I got most of that
knowledge *after* the first of these versions without the old script was
stabilized.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Dale]

Nuno J. Silva (aka njsg) wrote:
> On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
>> Nuno J. Silva (aka njsg) wrote:
>>> On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
>>>> Pandu Poluan wrote:
>>>>>
>>>>> Since it's obvious that upsteam has this "my way or the highway"
>>>>> mentality, I'm curious about whether eudev (and mdev) exhibits the
>>>>> same behavior...
>>>>>
>>>> I synced yesterday and I didn't see the news alert.   Last eudev update
>>>> was in Feb. so I *guess* not.  It seems to be a "udev" thing.  That is
>>>> why I mentioned eudev to someone else that was having this issue with a
>>>> server setup. 
>>> I'd guess eudev will eventually do the same, although I hope that, it
>>> being a separate codebase, makes it easier to adopt some solution like
>>> the old rule generator, instead of using udev's approach.
>>>
>>> The udev upstream may have its issues, but there's actually a point in
>>> removing this, the approach there was so far was just a dirty hack.
>>>
>>
>> Thing is, it works for me.  The old udev worked, eudev works but I'm not
>> sure what hoops I would have to go through to get the new udev working,
>> most likely the same ones others here are going through now.  For once,
>> I'm not having to deal with some broken issue.  < knock on wood > 
>>
>> My current uptime is about 190 days.  May hit it still but I'm certainly
>> hoping I don't. 
> And, at least now, I have got enough knowledge to know whether it
> affects me or not. But the sad thing is that I got most of that
> knowledge *after* the first of these versions without the old script was
> stabilized.
>


I switched to eudev when the separate /usr thing popped up.  While I am
watching this thread and sort of taking mental notes, I'm hoping this is
not a eudev thing, even in the future. 

I'm just hoping people will be able to find a solution to this that
works well for them.  I especially wish that for those managing a remote
system with little or no physical access. 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Alan McKinnon]

On 31/03/2013 20:26, Dale wrote:
> Nuno J. Silva (aka njsg) wrote:
>> On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
>>> Pandu Poluan wrote:
>>>>
>>>>
>>>> Since it's obvious that upsteam has this "my way or the highway"
>>>> mentality, I'm curious about whether eudev (and mdev) exhibits the
>>>> same behavior...
>>>>
>>> I synced yesterday and I didn't see the news alert.   Last eudev update
>>> was in Feb. so I *guess* not.  It seems to be a "udev" thing.  That is
>>> why I mentioned eudev to someone else that was having this issue with a
>>> server setup. 
>> I'd guess eudev will eventually do the same, although I hope that, it
>> being a separate codebase, makes it easier to adopt some solution like
>> the old rule generator, instead of using udev's approach.
>>
>> The udev upstream may have its issues, but there's actually a point in
>> removing this, the approach there was so far was just a dirty hack.
>>
> 
> 
> Thing is, it works for me.  The old udev worked,

It's more accurate to say it worked by accident rather than by design.
(Sort of like how the power utility gets power to your house - if yours
is anything like mine I get power despite their best efforts to not give
me any ...)

Anyway, the old method sucked and it sort of works for you and I because
we don't add anything ourselves that trip it up. But this new method...
geez lads, I just dunno.

How do Windows, Mac and Android deal with this stuff? They don't seem to
have any device naming problems, so what is the magic solution in use on
those platforms?


 eudev works but I'm not
> sure what hoops I would have to go through to get the new udev working,
> most likely the same ones others here are going through now.  For once,
> I'm not having to deal with some broken issue.  < knock on wood > 
> 
> My current uptime is about 190 days.  May hit it still but I'm certainly
> hoping I don't. 
> 
> Dale 
> 
> :-)  :-) 
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

On Sun, 31 Mar 2013 13:44:18 -0500, Dale wrote:

> I'm just hoping people will be able to find a solution to this that
> works well for them.  I especially wish that for those managing a remote
> system with little or no physical access. 

Well I just updated a headless box, followed the instructions in the news
article and it just worked. I now have net0 instead of eth0. What the
article didn't mention was that if you change your interface names, you
have to create a new symlink in /etc/init.d and add it to the default
runlevel. I'm glad I spotted that one before rebooting :)


-- 
Neil Bothwick

When told the reason for Daylight Saving time the old Indian said...
"Only a white man would believe that you could cut a foot off the top of a
blanket And sew it to the bottom of a blanket and have a longer blanket."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Dale]

Alan McKinnon wrote:
> On 31/03/2013 20:26, Dale wrote:
>> Nuno J. Silva (aka njsg) wrote:
>>> On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
>>>> Pandu Poluan wrote:
>>>>>
>>>>> Since it's obvious that upsteam has this "my way or the highway"
>>>>> mentality, I'm curious about whether eudev (and mdev) exhibits the
>>>>> same behavior...
>>>>>
>>>> I synced yesterday and I didn't see the news alert.   Last eudev update
>>>> was in Feb. so I *guess* not.  It seems to be a "udev" thing.  That is
>>>> why I mentioned eudev to someone else that was having this issue with a
>>>> server setup. 
>>> I'd guess eudev will eventually do the same, although I hope that, it
>>> being a separate codebase, makes it easier to adopt some solution like
>>> the old rule generator, instead of using udev's approach.
>>>
>>> The udev upstream may have its issues, but there's actually a point in
>>> removing this, the approach there was so far was just a dirty hack.
>>>
>>
>> Thing is, it works for me.  The old udev worked,
> It's more accurate to say it worked by accident rather than by design.
> (Sort of like how the power utility gets power to your house - if yours
> is anything like mine I get power despite their best efforts to not give
> me any ...)
>
> Anyway, the old method sucked and it sort of works for you and I because
> we don't add anything ourselves that trip it up. But this new method...
> geez lads, I just dunno.
>
> How do Windows, Mac and Android deal with this stuff? They don't seem to
> have any device naming problems, so what is the magic solution in use on
> those platforms?
>
>

Well, it still works regardless of by accident or by design.  On the
rare occasion that I have to reboot/shutdown, when my system comes up, I
still have the same network connection(s) I had before.  I still have
net.eth0 like I have had since I built this rig.  On my old rig, same
thing and I added networks cards to it, more than once I might add. 
Everything was consistent until I disabled the on board nic since it
went bad then it got interesting because I had to configure things to
let the first network card be the internet connection instead of the on
board old one.  I'm pretty sure that regardless of what was managing
devices that I would still have had to tell it which interface to use
tho.  I mean, it can't exactly read my mind.  lol 

Point is, just like the /usr mess, it's working just fine.  Odd thing
is, udev folks said it couldn't be fixed but the eudev folks seemed to
have fixed it just fine.  It seems Walter found his own fix too.  Sort
of like a plumber telling me I have to put with the drip when another
plumber can replace the o-ring and stop the drip.  So much for the first
plumber.  I'll loose his number for sure.  Only with this, two plumbers
had a better plan.  One replaced the o-ring, one replaced the whole
faucet.  Still got rid of the drip tho. 

I generally look more at the results than the how.  I'm not a
programmer, just a user.  End result is what I look for. 

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

On Sun, 31 Mar 2013 15:40:09 +0100, Kevin Chadwick wrote:

> > instead of pushing a completely
> > different (and possibly less reliable) naming scheme by default.  
> 
> Whilst I wouldn't want them changing on me (though if your physically
> changing the pci slot then you should be able to handle the number
> change).

What about USB network adaptors? A user may not even realise they plugged
it into a different USB slot from last time, yet the device name changes.


-- 
Neil Bothwick

"B?#$^f," said Pooh, as line noise garbled his transmission.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

On 03/31/2013 03:55 PM, Neil Bothwick wrote:
> On Sun, 31 Mar 2013 15:40:09 +0100, Kevin Chadwick wrote:
> 
>>> instead of pushing a completely
>>> different (and possibly less reliable) naming scheme by default.  
>>
>> Whilst I wouldn't want them changing on me (though if your physically
>> changing the pci slot then you should be able to handle the number
>> change).
> 
> What about USB network adaptors? A user may not even realise they plugged
> it into a different USB slot from last time, yet the device name changes.

Social media is infectious. I was looking for a '+1' button for this...



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Tanstaafl]

On 2013-03-31 3:37 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> What the article didn't mention was that if you change your interface
> names, you have to create a new symlink in /etc/init.d and add it to
> the default runlevel. I'm glad I spotted that one before rebooting:)

So, just

ln -s net.net0 -> net.lo

Then after reboot, you can rm net.eth0 -> net.lo ?

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Kevin Chadwick]

On Sun, 31 Mar 2013 20:55:00 +0100
Neil Bothwick <neil@digimed.co.uk> wrote:

> What about USB network adaptors? A user may not even realise they
> plugged it into a different USB slot from last time, yet the device
> name changes.

Fair point but wouldn't that be only if you plug in two of the same
type that the names may switch? In which case there are various ways of
solving the problem and name assignment may be handy in some cases,
though I still think it would be good to have a man page linked to
that name.

[gentoo-user] Re: Udev update and persistent net rules changes

[Nuno J. Silva (aka njsg)]

On 2013-03-31, Neil Bothwick <neil@digimed.co.uk> wrote:
>
> On Sun, 31 Mar 2013 13:44:18 -0500, Dale wrote:
>
>> I'm just hoping people will be able to find a solution to this that
>> works well for them.  I especially wish that for those managing a remote
>> system with little or no physical access.=20
>
> Well I just updated a headless box, followed the instructions in the news
> article and it just worked. I now have net0 instead of eth0. What the
> article didn't mention was that if you change your interface names, you
> have to create a new symlink in /etc/init.d and add it to the default
> runlevel. I'm glad I spotted that one before rebooting :)

This one was mentioned and discussed in gentoo-dev. It's sad if this
information didn't make it to the news item, but perhaps it was
mentioned a bit too late.

-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 856 bytes --]

On Sunday 31 Mar 2013 21:19:18 Tanstaafl wrote:
> On 2013-03-31 3:37 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> > What the article didn't mention was that if you change your interface
> > names, you have to create a new symlink in /etc/init.d and add it to
> > the default runlevel. I'm glad I spotted that one before rebooting:)
> 
> So, just
> 
> ln -s net.net0 -> net.lo
> 
> Then after reboot, you can rm net.eth0 -> net.lo ?

Worth noting that I did not remove /etc/init.d/net.eth0 and upon rebooting a 
box I couldn't connect to it via ssh!  This was despite having changed the 
firewall interface in the iptables rules to the new NIC name.

Thankfully I had physical access.  sshd complained that net.eth0 was not 
available.  I deleted the /etc/init.d/net.eth0 symlink and rebooted.  No more 
problems.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[William Kenworthy]

On 01/04/13 01:01, Dale wrote:
> Pandu Poluan wrote:
>>
>>
>>
>> Since it's obvious that upsteam has this "my way or the highway"
>> mentality, I'm curious about whether eudev (and mdev) exhibits the
>> same behavior...
>>
>> Rgds,
>> --
>>
> 
> I synced yesterday and I didn't see the news alert.   Last eudev update
> was in Feb. so I *guess* not.  It seems to be a "udev" thing.  That is
> why I mentioned eudev to someone else that was having this issue with a
> server setup. 
> 
> Dale
> 
> :-)  :-) 
> 

Have not seen it yet (eudev), but something interesting is I am moving
to a small cloud of libvirt managed vm instances for my services and
instead of having to delete the net rules file in each instance (because
the mac address is changing) it creates a new eth0 for the new mac
address, and moved the old to eth1 - handy as I am using a base image
and spawning off a child from a snap for each instance - one less
annoyance to worry about!  Seemed to happen about the time of the last
eudev update, need to look into it more.

BillK

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Volker Armin Hemmann]

Am 31.03.2013 21:55, schrieb Neil Bothwick:
> On Sun, 31 Mar 2013 15:40:09 +0100, Kevin Chadwick wrote:
>
>>> instead of pushing a completely
>>> different (and possibly less reliable) naming scheme by default.  
>> Whilst I wouldn't want them changing on me (though if your physically
>> changing the pci slot then you should be able to handle the number
>> change).
> What about USB network adaptors? A user may not even realise they plugged
> it into a different USB slot from last time, yet the device name changes.
>
>
congratulation, you just found another reason why today's udev sucks.

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 2225 bytes --]

On Apr 1, 2013 2:10 AM, "Alan McKinnon" <alan.mckinnon@gmail.com> wrote:
>
> On 31/03/2013 20:26, Dale wrote:
> > Nuno J. Silva (aka njsg) wrote:
> >> On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
> >>> Pandu Poluan wrote:
> >>>>
> >>>>
> >>>> Since it's obvious that upsteam has this "my way or the highway"
> >>>> mentality, I'm curious about whether eudev (and mdev) exhibits the
> >>>> same behavior...
> >>>>
> >>> I synced yesterday and I didn't see the news alert.   Last eudev
update
> >>> was in Feb. so I *guess* not.  It seems to be a "udev" thing.  That is
> >>> why I mentioned eudev to someone else that was having this issue with
a
> >>> server setup.
> >> I'd guess eudev will eventually do the same, although I hope that, it
> >> being a separate codebase, makes it easier to adopt some solution like
> >> the old rule generator, instead of using udev's approach.
> >>
> >> The udev upstream may have its issues, but there's actually a point in
> >> removing this, the approach there was so far was just a dirty hack.
> >>
> >
> >
> > Thing is, it works for me.  The old udev worked,
>
> It's more accurate to say it worked by accident rather than by design.
> (Sort of like how the power utility gets power to your house - if yours
> is anything like mine I get power despite their best efforts to not give
> me any ...)
>
> Anyway, the old method sucked and it sort of works for you and I because
> we don't add anything ourselves that trip it up. But this new method...
> geez lads, I just dunno.
>
> How do Windows, Mac and Android deal with this stuff? They don't seem to
> have any device naming problems, so what is the magic solution in use on
> those platforms?
>

I'm not sure about Macs and Android, but with Windows it all happens based
on MAC address.

I found about it quite accidentally; I had exported a VM from XenServer and
imported it to a different host. By default, XenServer assigns a new,
random MAC for imported VMs. Windows saw this and proceeded to initialize a
new NIC. When I tried setting the IP settings, it complained that the
settings are currently being used by an invisible NIC. So, I shut down the
VM, restored the old MAC, and the prior settings reappeared.

Rgds,
--

[-- Attachment #2: Type: text/html, Size: 2942 bytes --]

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

On Sun, 31 Mar 2013 21:34:51 +0100, Kevin Chadwick wrote:

> > What about USB network adaptors? A user may not even realise they
> > plugged it into a different USB slot from last time, yet the device
> > name changes.  
> 
> Fair point but wouldn't that be only if you plug in two of the same
> type that the names may switch?

According to Flameyes' blog, if you have only one adaptor, its name will
change according to the port used, which is a rather different definition
of "persistent" than I have been used to.


-- 
Neil Bothwick

All mail what i send is thoughly proof-red, definately!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

On Mon, 01 Apr 2013 03:02:51 +0200, Volker Armin Hemmann wrote:

> > What about USB network adaptors? A user may not even realise they
> > plugged it into a different USB slot from last time, yet the device
> > name changes.

> congratulation, you just found another reason why today's udev sucks.

I take no credit for it, Flameyes pointed that one out.


-- 
Neil Bothwick

Not one shred of evidence supports the notion that life is serious.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 273 bytes --]

On Sun, 31 Mar 2013 15:40:09 +0100, Kevin Chadwick wrote:

> I find the OpenBSD method of different names like fxp0 usefuk

You can emulate that with suitable (e)udev rules.


-- 
Neil Bothwick

Computers are like Old Testament gods; lots of rules and no mercy.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Apr 1, 2013 1:54 PM, "Neil Bothwick" <neil@digimed.co.uk> wrote:
>
> On Sun, 31 Mar 2013 21:34:51 +0100, Kevin Chadwick wrote:
>
> > > What about USB network adaptors? A user may not even realise they
> > > plugged it into a different USB slot from last time, yet the device
> > > name changes.
> >
> > Fair point but wouldn't that be only if you plug in two of the same
> > type that the names may switch?
>
> According to Flameyes' blog, if you have only one adaptor, its name will
> change according to the port used, which is a rather different definition
> of "persistent" than I have been used to.
>
>
> --
> Neil Bothwick
>
> All mail what i send is thoughly proof-red, definately!

True, that.

I still don't understand what's so bad with MAC-based identification? I
mean, uniqueness defined through MAC Address identity, the system name is
just a label...

Rgds,
--

[-- Attachment #2: Type: text/html, Size: 1159 bytes --]

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

On Mon, 1 Apr 2013 13:57:42 +0700, Pandu Poluan wrote:

> I still don't understand what's so bad with MAC-based identification? I
> mean, uniqueness defined through MAC Address identity, the system name
> is just a label...

MAC addresses are not human-friendly. It would be OK if you could set up
aliases, so your firewall rules could use enaabbccddeeff while you could
still type eth0.


-- 
Neil Bothwick

Don't just read the Tagline; read the MESSAGE!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

On Sun, 31 Mar 2013 16:19:18 -0400, Tanstaafl wrote:

> > What the article didn't mention was that if you change your interface
> > names, you have to create a new symlink in /etc/init.d and add it to
> > the default runlevel. I'm glad I spotted that one before rebooting:)  
> 
> So, just
> 
> ln -s net.net0 -> net.lo
> 
> Then after reboot, you can rm net.eth0 -> net.lo ?

You also need to "rc-update add net.net0 default"


-- 
Neil Bothwick

WinErr 003: Dynamic linking error - Your mistake is now in every file

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On 04/01/2013 09:12 AM, Neil Bothwick wrote:
> On Mon, 1 Apr 2013 13:57:42 +0700, Pandu Poluan wrote:
> 
>> I still don't understand what's so bad with MAC-based identification? I
>> mean, uniqueness defined through MAC Address identity, the system name
>> is just a label...
> 
> MAC addresses are not human-friendly. It would be OK if you could set up
> aliases, so your firewall rules could use enaabbccddeeff while you could
> still type eth0.
> 
> 

Frankly, I never found 'eth0' to be particularly friendly, either. Hence
why I like naming my interfaces things like 'wan', 'wifilan' and 'wiredlan'.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Kevin Chadwick]

On Mon, 1 Apr 2013 14:12:17 +0100
Neil Bothwick <neil@digimed.co.uk> wrote:

> > I still don't understand what's so bad with MAC-based
> > identification? I mean, uniqueness defined through MAC Address
> > identity, the system name is just a label...  
> 
> MAC addresses are not human-friendly. It would be OK if you could set
> up aliases, so your firewall rules could use enaabbccddeeff while you
> could still type eth0.

It used to be dead easy to link the MAC to the device type and number
from dmesg without looking up the MAC to Manufacturer codes. A lot of
useful information seems to have been removed from the linux dmesg?
atleast on 3.2 kernels.

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On Mon, 01 Apr 2013 09:29:08 -0400, Michael Mol wrote:

> > MAC addresses are not human-friendly. It would be OK if you could set
> > up aliases, so your firewall rules could use enaabbccddeeff while you
> > could still type eth0.

> Frankly, I never found 'eth0' to be particularly friendly, either. Hence
> why I like naming my interfaces things like 'wan', 'wifilan' and
> 'wiredlan'.

Relative to 'lan' or 'wan', no, but relative to an embedded MAC address?


-- 
Neil Bothwick

I don't know if I can assimilate one more Borg Tagline!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

On 04/01/2013 09:54 AM, Neil Bothwick wrote:
> On Mon, 01 Apr 2013 09:29:08 -0400, Michael Mol wrote:
> 
>>> MAC addresses are not human-friendly. It would be OK if you could set
>>> up aliases, so your firewall rules could use enaabbccddeeff while you
>>> could still type eth0.
> 
>> Frankly, I never found 'eth0' to be particularly friendly, either. Hence
>> why I like naming my interfaces things like 'wan', 'wifilan' and
>> 'wiredlan'.
> 
> Relative to 'lan' or 'wan', no, but relative to an embedded MAC address?

Honestly, with IPv6, I get so accustomed to recognizing the last three
or four octets of MAC addresses, that idea is starting to grow on me,
too! It's like recognizing phone numbers, really. You eventually just
start remembering enough of the thing to be useful.

If the system isn't smart enough to apply a solid semantic name (like my
'wan', 'wifilan' or 'wiredlan'), I'd rather it not try to apply a
semantic name (eth0 or net0) at all. But you're hearing this come from a
C++ programmer turned network admin, so take that with a grain of salt. :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

[gentoo-user] Re: Udev update and persistent net rules changes

[»Q«]

On Sun, 31 Mar 2013 18:37:07 +0000 (UTC)
"Nuno J. Silva (aka njsg)" <nunojsilva@ist.utl.pt> wrote:

> On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
> > Nuno J. Silva (aka njsg) wrote:
> >> On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
> >>> Pandu Poluan wrote:
> >>>>
> >>>>
> >>>> Since it's obvious that upsteam has this "my way or the highway"
> >>>> mentality, I'm curious about whether eudev (and mdev) exhibits
> >>>> the same behavior...
> >>>>
> >>> I synced yesterday and I didn't see the news alert.   Last eudev
> >>> update was in Feb. so I *guess* not.  It seems to be a "udev"
> >>> thing.  That is why I mentioned eudev to someone else that was
> >>> having this issue with a server setup. 
> >> I'd guess eudev will eventually do the same, although I hope that,
> >> it being a separate codebase, makes it easier to adopt some
> >> solution like the old rule generator, instead of using udev's
> >> approach.
> >>
> >> The udev upstream may have its issues, but there's actually a
> >> point in removing this, the approach there was so far was just a
> >> dirty hack.
> >>
> >
> >
> > Thing is, it works for me.  The old udev worked, eudev works but
> > I'm not sure what hoops I would have to go through to get the new
> > udev working, most likely the same ones others here are going
> > through now.  For once, I'm not having to deal with some broken
> > issue.  < knock on wood > 
> >
> > My current uptime is about 190 days.  May hit it still but I'm
> > certainly hoping I don't. 
> 
> And, at least now, I have got enough knowledge to know whether it
> affects me or not. But the sad thing is that I got most of that
> knowledge *after* the first of these versions without the old script
> was stabilized.

Another sad thing is that if you want to find out about the option to
keep the old-style naming rules, Udev/upgrade page
<https://wiki.gentoo.org/wiki/Udev/upgrade> just links to bug 453494,
so instead of a guide, users get to read a bug entry with 94 comments
(and counting).

I went with the new persistent names because it seemed simpler and
because there was relatively clearer information about how it should be
done.

Once upon a time, for an upgrade like this, Gentoo would have produced
a guide summarizing the pros and cons of the two courses of actions
along with a recipe for each one.  (Or if not a recipe, at least a list
of all the considerations needed for each path.)

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2204 bytes --]

On Sun, Mar 31, 2013 at 01:44:18PM -0500, Dale wrote:
> Nuno J. Silva (aka njsg) wrote:
> > On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
> >> Nuno J. Silva (aka njsg) wrote:
> >>> On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
> >>>> Pandu Poluan wrote:
> >>>>>
> >>>>> Since it's obvious that upsteam has this "my way or the highway"
> >>>>> mentality, I'm curious about whether eudev (and mdev) exhibits the
> >>>>> same behavior...
> >>>>>
> >>>> I synced yesterday and I didn't see the news alert.   Last eudev update
> >>>> was in Feb. so I *guess* not.  It seems to be a "udev" thing.  That is
> >>>> why I mentioned eudev to someone else that was having this issue with a
> >>>> server setup. 
> >>> I'd guess eudev will eventually do the same, although I hope that, it
> >>> being a separate codebase, makes it easier to adopt some solution like
> >>> the old rule generator, instead of using udev's approach.
> >>>
> >>> The udev upstream may have its issues, but there's actually a point in
> >>> removing this, the approach there was so far was just a dirty hack.
> >>>
> >>
> >> Thing is, it works for me.  The old udev worked, eudev works but I'm not
> >> sure what hoops I would have to go through to get the new udev working,
> >> most likely the same ones others here are going through now.  For once,
> >> I'm not having to deal with some broken issue.  < knock on wood > 
> >>
> >> My current uptime is about 190 days.  May hit it still but I'm certainly
> >> hoping I don't. 
> > And, at least now, I have got enough knowledge to know whether it
> > affects me or not. But the sad thing is that I got most of that
> > knowledge *after* the first of these versions without the old script was
> > stabilized.
> >
> 
> 
> I switched to eudev when the separate /usr thing popped up.  While I am
> watching this thread and sort of taking mental notes, I'm hoping this is
> not a eudev thing, even in the future. 

You know that both udev and eudev have exactly the same issue with
separate /usr right?

The problem there isn't in the udev code, but it has to do with what is
happening in rules that other packages install.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 3595 bytes --]

On 04/01/2013 03:26 PM, William Hubbs wrote:
> On Sun, Mar 31, 2013 at 01:44:18PM -0500, Dale wrote:
>> Nuno J. Silva (aka njsg) wrote:
>>> On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
>>>> Nuno J. Silva (aka njsg) wrote:
>>>>> On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
>>>>>> Pandu Poluan wrote:
>>>>>>>
>>>>>>> Since it's obvious that upsteam has this "my way or the highway"
>>>>>>> mentality, I'm curious about whether eudev (and mdev) exhibits the
>>>>>>> same behavior...
>>>>>>>
>>>>>> I synced yesterday and I didn't see the news alert.   Last eudev update
>>>>>> was in Feb. so I *guess* not.  It seems to be a "udev" thing.  That is
>>>>>> why I mentioned eudev to someone else that was having this issue with a
>>>>>> server setup. 
>>>>> I'd guess eudev will eventually do the same, although I hope that, it
>>>>> being a separate codebase, makes it easier to adopt some solution like
>>>>> the old rule generator, instead of using udev's approach.
>>>>>
>>>>> The udev upstream may have its issues, but there's actually a point in
>>>>> removing this, the approach there was so far was just a dirty hack.
>>>>>
>>>>
>>>> Thing is, it works for me.  The old udev worked, eudev works but I'm not
>>>> sure what hoops I would have to go through to get the new udev working,
>>>> most likely the same ones others here are going through now.  For once,
>>>> I'm not having to deal with some broken issue.  < knock on wood > 
>>>>
>>>> My current uptime is about 190 days.  May hit it still but I'm certainly
>>>> hoping I don't. 
>>> And, at least now, I have got enough knowledge to know whether it
>>> affects me or not. But the sad thing is that I got most of that
>>> knowledge *after* the first of these versions without the old script was
>>> stabilized.
>>>
>>
>>
>> I switched to eudev when the separate /usr thing popped up.  While I am
>> watching this thread and sort of taking mental notes, I'm hoping this is
>> not a eudev thing, even in the future. 
> 
> You know that both udev and eudev have exactly the same issue with
> separate /usr right?
> 
> The problem there isn't in the udev code, but it has to do with what is
> happening in rules that other packages install.

As I recall, the problem is where the ebuild choses to install the code.
Putting the udev code under /usr forces the issue on systems where it
would otherwise not be an issue.

Putting the udev code under / avoids that issue, but opens up the system
to the "silently fail" thing upstream liked to use as the basis of
"separate /usr is broken"

So, there are three conceivable configurations (initramfs notwithstanding):

1. With systems which don't require /usr binaries before /usr would be
mounted, separate /usr is not a problem.

2. With systems which require /usr binaries for some features before
/usr would be mounted, those features will silently fail.

3. With systems which require /usr binaries to mount /usr, all hell
breaks loose.

Putting the udev code under /usr moves all udev systems from group 2
into group 3. In a sense, this fixes those systems because the admin is
forced to address the silent failures he was previously unaware of. It
also means pissing off a bunch of people who had features silently
failing...but they probably didn't know or care about those features in
the first place.

It also moves all systems from group 1 into group 3...which is simply wrong.

So long as eudev keeps its install path at / instead of /usr, admins in
group 1 will probably be perfectly happy.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Dale]

[-- Attachment #1: Type: text/plain, Size: 3779 bytes --]

Michael Mol wrote:
> On 04/01/2013 03:26 PM, William Hubbs wrote:
>> On Sun, Mar 31, 2013 at 01:44:18PM -0500, Dale wrote:
>>> Nuno J. Silva (aka njsg) wrote:
>>>> On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
>>>>> Nuno J. Silva (aka njsg) wrote:
>>>>>> On 2013-03-31, Dale <rdalek1967@gmail.com> wrote:
>>>>>>> Pandu Poluan wrote:
>>>>>>>>
>>>>>>>> Since it's obvious that upsteam has this "my way or the highway"
>>>>>>>> mentality, I'm curious about whether eudev (and mdev) exhibits the
>>>>>>>> same behavior...
>>>>>>>>
>>>>>>> I synced yesterday and I didn't see the news alert.   Last eudev
update
>>>>>>> was in Feb. so I *guess* not.  It seems to be a "udev" thing. 
That is
>>>>>>> why I mentioned eudev to someone else that was having this issue
with a
>>>>>>> server setup.
>>>>>> I'd guess eudev will eventually do the same, although I hope that, it
>>>>>> being a separate codebase, makes it easier to adopt some solution
like
>>>>>> the old rule generator, instead of using udev's approach.
>>>>>>
>>>>>> The udev upstream may have its issues, but there's actually a
point in
>>>>>> removing this, the approach there was so far was just a dirty hack.
>>>>>>
>>>>>
>>>>> Thing is, it works for me.  The old udev worked, eudev works but
I'm not
>>>>> sure what hoops I would have to go through to get the new udev
working,
>>>>> most likely the same ones others here are going through now.  For
once,
>>>>> I'm not having to deal with some broken issue.  < knock on wood >
>>>>>
>>>>> My current uptime is about 190 days.  May hit it still but I'm
certainly
>>>>> hoping I don't.
>>>> And, at least now, I have got enough knowledge to know whether it
>>>> affects me or not. But the sad thing is that I got most of that
>>>> knowledge *after* the first of these versions without the old
script was
>>>> stabilized.
>>>>
>>>
>>>
>>> I switched to eudev when the separate /usr thing popped up.  While I am
>>> watching this thread and sort of taking mental notes, I'm hoping this is
>>> not a eudev thing, even in the future.
>>
>> You know that both udev and eudev have exactly the same issue with
>> separate /usr right?
>>
>> The problem there isn't in the udev code, but it has to do with what is
>> happening in rules that other packages install.
>
> As I recall, the problem is where the ebuild choses to install the code.
> Putting the udev code under /usr forces the issue on systems where it
> would otherwise not be an issue.
>
> Putting the udev code under / avoids that issue, but opens up the system
> to the "silently fail" thing upstream liked to use as the basis of
> "separate /usr is broken"
>
> So, there are three conceivable configurations (initramfs
notwithstanding):
>
> 1. With systems which don't require /usr binaries before /usr would be
> mounted, separate /usr is not a problem.
>
> 2. With systems which require /usr binaries for some features before
> /usr would be mounted, those features will silently fail.
>
> 3. With systems which require /usr binaries to mount /usr, all hell
> breaks loose.
>
> Putting the udev code under /usr moves all udev systems from group 2
> into group 3. In a sense, this fixes those systems because the admin is
> forced to address the silent failures he was previously unaware of. It
> also means pissing off a bunch of people who had features silently
> failing...but they probably didn't know or care about those features in
> the first place.
>
> It also moves all systems from group 1 into group 3...which is simply
wrong.
>
> So long as eudev keeps its install path at / instead of /usr, admins in
> group 1 will probably be perfectly happy.
>


+1  Happy I am.  lol

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 6113 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Peter Humphrey]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On Monday 01 April 2013 20:51:45 Michael Mol wrote:

--->8

> So, there are three conceivable configurations (initramfs
> notwithstanding):

What a fine word! It's a while since I saw it last.

> 1. With systems which don't require /usr binaries before /usr would be
> mounted, separate /usr is not a problem.

I'm in that group, I'm glad to be able to say. The most important para to me 
in the news item was: "The feature can also be completely disabled using 
net.ifnames=0 on the kernel command line." I just added that to my grub.conf 
entries and I sail blissfully on with eth0. Of course this is a simple 
desktop box with a static network topology; on a less simple setup things 
would differ. Maybe I've left a hostage to fortune, but it'll do for now.

--->8

-- 
Peter

[-- Attachment #2: Type: text/html, Size: 3918 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Paul Hartman]

On Mon, Apr 1, 2013 at 7:00 PM, Peter Humphrey <peter@humphrey.ukfsn.org> wrote:
> The most important para to me in the news item was: "The feature can also be
> completely disabled using net.ifnames=0 on the kernel command line." I just
> added that to my grub.conf entries and I sail blissfully on with eth0.


I updated remote virtual server (xen guest) and added this same
option, crossed my fingers and rebooted, eth0 was still there and I
was happy.

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Jarry]

On 02-Apr-13 21:13, Paul Hartman wrote:
> On Mon, Apr 1, 2013 at 7:00 PM, Peter Humphrey <peter@humphrey.ukfsn.org> wrote:
>> The most important para to me in the news item was: "The feature can also be
>> completely disabled using net.ifnames=0 on the kernel command line." I just
>> added that to my grub.conf entries and I sail blissfully on with eth0.
>
> I updated remote virtual server (xen guest) and added this same
> option, crossed my fingers and rebooted, eth0 was still there and I
> was happy.

I think it is not necessary to add any options. If after upgrading
to udev200 you do not do anything, after reboot you still have eth0.
"Empty" 80-net-name-slot.rules takes care of it...

Jarry

-- 
_______________________________________________________________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Alan McKinnon]

On 02/04/2013 21:13, Paul Hartman wrote:
> On Mon, Apr 1, 2013 at 7:00 PM, Peter Humphrey <peter@humphrey.ukfsn.org> wrote:
>> The most important para to me in the news item was: "The feature can also be
>> completely disabled using net.ifnames=0 on the kernel command line." I just
>> added that to my grub.conf entries and I sail blissfully on with eth0.
> 
> 
> I updated remote virtual server (xen guest) and added this same
> option, crossed my fingers and rebooted, eth0 was still there and I
> was happy.
> 


I did this to get exactly the same result:

$ ls -al /etc/udev/rules.d/
total 8
drwxr-xr-x 2 root root 4096 Apr  1 15:10 .
drwxr-xr-x 4 root root 4096 Mar 30 20:34 ..
lrwxrwxrwx 1 root root    9 Apr  1 15:10 80-net-name-slot.rules -> /dev/null

Like you, I happen to *like* eth0 and wlan0 on a laptop workstation :-)
-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Tanstaafl]

On 2013-04-02 3:21 PM, Jarry <mr.jarry@gmail.com> wrote:
> On 02-Apr-13 21:13, Paul Hartman wrote:
>> On Mon, Apr 1, 2013 at 7:00 PM, Peter Humphrey
>> <peter@humphrey.ukfsn.org> wrote:
>>> The most important para to me in the news item was: "The feature can
>>> also be
>>> completely disabled using net.ifnames=0 on the kernel command line."
>>> I just
>>> added that to my grub.conf entries and I sail blissfully on with eth0.
>>
>> I updated remote virtual server (xen guest) and added this same
>> option, crossed my fingers and rebooted, eth0 was still there and I
>> was happy.
>
> I think it is not necessary to add any options. If after upgrading
> to udev200 you do not do anything, after reboot you still have eth0.
> "Empty" 80-net-name-slot.rules takes care of it...

?

Are you saying that now, with udev-200, the default is the OLD way, and 
you have to intentionally enable the NEW way??

This is mind-boggling.

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Alan McKinnon]

On 02/04/2013 21:41, Tanstaafl wrote:
> On 2013-04-02 3:21 PM, Jarry <mr.jarry@gmail.com> wrote:
>> On 02-Apr-13 21:13, Paul Hartman wrote:
>>> On Mon, Apr 1, 2013 at 7:00 PM, Peter Humphrey
>>> <peter@humphrey.ukfsn.org> wrote:
>>>> The most important para to me in the news item was: "The feature can
>>>> also be
>>>> completely disabled using net.ifnames=0 on the kernel command line."
>>>> I just
>>>> added that to my grub.conf entries and I sail blissfully on with eth0.
>>>
>>> I updated remote virtual server (xen guest) and added this same
>>> option, crossed my fingers and rebooted, eth0 was still there and I
>>> was happy.
>>
>> I think it is not necessary to add any options. If after upgrading
>> to udev200 you do not do anything, after reboot you still have eth0.
>> "Empty" 80-net-name-slot.rules takes care of it...
> 
> ?
> 
> Are you saying that now, with udev-200, the default is the OLD way, and
> you have to intentionally enable the NEW way??
> 
> This is mind-boggling.


No, you are stilling misunderstanding. The news item goes to great
lengths to explain that there is a new way and it is different from the
old way.

Jarry mentioned an EMPTY file, not an absent file. The ebuild does not
install an empty file, so it is not the default.

All the questions you have raised are clearly explained in the news
item. Please read it and study it, it really is complete. You appear to
be confusing yourself by adding things that are not there.





-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: Udev update and persistent net rules changes

[Grant Edwards]

On 2013-04-02, Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> No, you are stilling misunderstanding.

He's not the only one.

> The news item goes to great lengths to explain that there is a new
> way and it is different from the old way.

I did grok that much.  I had a 70-persistent-net.rules file that named
my three interfaces "eth0" "eth1" and "eth2" based on their MAC
addresses. After reading the news item and flameeyes blog, I was still
pretty much at a loss regarding what I was actually supposed to _do_.

In Flameyes blog, he showed an example of using udev rules pretty much
identical to the ones I already had, so I couldn't figure out what was
different (other than the default interface names, which still aren't
really predictable).

In the end, I just did the upgrade and rebooted.  My existing rules
seemed to work fine: the interfaces came up with the same names as
before.  So I gave up trying to figure it out...

-- 
Grant Edwards               grant.b.edwards        Yow! Of course, you
                                  at               UNDERSTAND about the PLAIDS
                              gmail.com            in the SPIN CYCLE --

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Alan McKinnon]

On 02/04/2013 22:31, Grant Edwards wrote:
> On 2013-04-02, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>> No, you are stilling misunderstanding.
> 
> He's not the only one.
> 
>> The news item goes to great lengths to explain that there is a new
>> way and it is different from the old way.
> 
> I did grok that much.  I had a 70-persistent-net.rules file that named
> my three interfaces "eth0" "eth1" and "eth2" based on their MAC
> addresses. After reading the news item and flameeyes blog, I was still
> pretty much at a loss regarding what I was actually supposed to _do_.
> 
> In Flameyes blog, he showed an example of using udev rules pretty much
> identical to the ones I already had, so I couldn't figure out what was
> different (other than the default interface names, which still aren't
> really predictable).
> 
> In the end, I just did the upgrade and rebooted.  My existing rules
> seemed to work fine: the interfaces came up with the same names as
> before.  So I gave up trying to figure it out...
> 

That is the expected result - you have explicit udev rules that lay out
how you want every interface to be named, and udev did what you told it
to do.

The issue at hand, for the most part, is what udev will do if you
*don't* have explicit unambiguous rules, i.e. you leave it up to the
software to make a decision. The new version is most likely going to do
something different to what earlier versions did. That's not hard to
understand.

The trick with all this new udev stuff is to read what is coming out of
the horse's mouth and ignore all the frenetic noise that the internet is
spewing out.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

Am Tue, 2 Apr 2013 20:31:10 +0000 (UTC)
schrieb Grant Edwards <grant.b.edwards@gmail.com>:

> On 2013-04-02, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
> > No, you are stilling misunderstanding.
> 
> He's not the only one.
> 
> > The news item goes to great lengths to explain that there is a new
> > way and it is different from the old way.
> 
> I did grok that much.  I had a 70-persistent-net.rules file that named
> my three interfaces "eth0" "eth1" and "eth2" based on their MAC
> addresses. After reading the news item and flameeyes blog, I was still
> pretty much at a loss regarding what I was actually supposed to _do_.

AFAIU, as soon as the names in your rules file differ from the in-kernel names
(e.g., if the kernel switches eth0 and eth1), bad things can happen during
renaming, due to deadlocks or something like that (others will have understood
it better and should explain it rather than I).

So, again AFAIU, it's enough to change the network device names from eth* to
net*, or whatever you desire (I went with Flameeyes naming scheme).  The
important thing is that your device names *don't* use the in-kernel namespace
"eth*". See section 3 "Old interface naming rules" in the news item and the
references therein.

The new default naming scheme is AFAICT orthogonal to that.

HTH
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]

Am Tue, 2 Apr 2013 23:15:40 +0200
schrieb Marc Joliet <marcec@gmx.de>:

> Am Tue, 2 Apr 2013 20:31:10 +0000 (UTC)
> schrieb Grant Edwards <grant.b.edwards@gmail.com>:
> 
> > On 2013-04-02, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> > 
> > > No, you are stilling misunderstanding.
> > 
> > He's not the only one.
> > 
> > > The news item goes to great lengths to explain that there is a new
> > > way and it is different from the old way.
> > 
> > I did grok that much.  I had a 70-persistent-net.rules file that named
> > my three interfaces "eth0" "eth1" and "eth2" based on their MAC
> > addresses. After reading the news item and flameeyes blog, I was still
> > pretty much at a loss regarding what I was actually supposed to _do_.
> 
> AFAIU, as soon as the names in your rules file differ from the in-kernel names
> (e.g., if the kernel switches eth0 and eth1), bad things can happen during
> renaming, due to deadlocks or something like that (others will have understood
> it better and should explain it rather than I).

OK, I should have looked first. Here's a technical explanation from
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
(referenced in the news item, BTW):

  For a longer time udev shipped support for assigning permanent "ethX" names to
  certain interfaces based on their MAC addresses. This turned out to have a
  multitude of problems, among them: [snipped various other reasons]. The
  biggest of all however is that the userspace components trying to assign the
  interface name raced against the kernel assigning new names from the same
  "ethX" namespace, a race condition with all kinds of weird effects, among
  them that assignment of names sometimes failed. As a result support for this
  has been removed from systemd/udev a while back.

So not a deadlock, but a race condition.

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

On Tue, 2 Apr 2013 20:31:10 +0000 (UTC), Grant Edwards wrote:

> In Flameyes blog, he showed an example of using udev rules pretty much
> identical to the ones I already had, so I couldn't figure out what was
> different (other than the default interface names, which still aren't
> really predictable).

They are totally predictable, since the names are specified in the rules,
so you can predict what the interface will be called, it's what the rules
file says it will be called. However, the important issue is persistence,
whatever name an interface has is the name it will always have. The rules
renaming within the kernel namespace, eth, wlan etc, could not guarantee
that because of race conditions, and the so-called persistent names from
the new udev still cannot do the same for devices that can be physically
moved (mainly USB).

The simplest solution is to do what the news item suggests, rename the
persistent-net rules file and rename the interfaces within it to not
clash with the kernel. That's all you need to worry about when going from
197 to 200, upgrading from earlier versions means you should act on the
parts about DEVTMPFS and runlevel files.


-- 
Neil Bothwick

Am I ignorant or apathetic? I don't know and don't care!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: Udev update and persistent net rules changes

[Grant Edwards]

On 2013-04-02, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Tue, 2 Apr 2013 20:31:10 +0000 (UTC), Grant Edwards wrote:
>
>> In Flameyes blog, he showed an example of using udev rules pretty much
>> identical to the ones I already had, so I couldn't figure out what was
>> different (other than the default interface names, which still aren't
>> really predictable).
>
> They are totally predictable,

As long as you know the PCI bus IDs of the slots, which board is
plugged into which slot, the PCI bus IDs of the USB controllers, and
which USB ports are connected to which controllers, and so on.  For
most of us that equates to "not predictable".  :)

The one thing (AFAICT) that does sort of make them what I would call
"predictable" is the support for BIOS labels for ports.  I've never
actually seen a machine that supported that.

> since the names are specified in the rules, so you can predict what
> the interface will be called,

In _theory_ you can, but you need to gather a lot of very low-level
information first.  In practice, I bet nobody does that -- they just
boot up the kernel and see what they get.

> it's what the rules file says it will be called. However, the
> important issue is persistence, whatever name an interface has is the
> name it will always have.

Until you move it to a different USB port or PCI slot.  Names still
aren't persistent (or, in practical terms, predictable), they're just
based on a different parameter than they used to be.  For some people
the new 'prameter' is apparently more useful -- so I guess it's an
improvement.

> The rules renaming within the kernel namespace, eth, wlan etc, could
> not guarantee that because of race conditions, and the so-called
> persistent names from the new udev still cannot do the same for
> devices that can be physically moved (mainly USB).
>
> The simplest solution is to do what the news item suggests, rename
> the persistent-net rules file

Why does the file need to be renamed?

> and rename the interfaces within it to not clash with the kernel.

So the kernel is still using the names eth[0-n]?  And there's a race
condition if I use the names eth[0-n] in my rules?  Same as before?

> That's all you need to worry about when going from 197 to 200,
> upgrading from earlier versions means you should act on the parts
> about DEVTMPFS and runlevel files.

-- 
Grant Edwards               grant.b.edwards        Yow! My life is a patio
                                  at               of fun!
                              gmail.com            

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

On Wed, 3 Apr 2013 15:13:12 +0000 (UTC), Grant Edwards wrote:

> On 2013-04-02, Neil Bothwick <neil@digimed.co.uk> wrote:
> > On Tue, 2 Apr 2013 20:31:10 +0000 (UTC), Grant Edwards wrote:
> >
> >> In Flameyes blog, he showed an example of using udev rules pretty
> >> much identical to the ones I already had, so I couldn't figure out
> >> what was different (other than the default interface names, which
> >> still aren't really predictable).
> >
> > They are totally predictable,
> 
> As long as you know the PCI bus IDs of the slots, which board is
> plugged into which slot, the PCI bus IDs of the USB controllers, and
> which USB ports are connected to which controllers, and so on.  For
> most of us that equates to "not predictable".  :)

We're at cross-purposes here. You mentioned udev rules, which I took to
mean user-installed rules in /etc/udev. The names udev comes up with in
the absence of any rules are not completely predictable, nor persistent.

[snip more cross-purpose confusion]

> > The simplest solution is to do what the news item suggests, rename
> > the persistent-net rules file
> 
> Why does the file need to be renamed?

> > and rename the interfaces within it to not clash with the kernel.
> 
> So the kernel is still using the names eth[0-n]?  And there's a race
> condition if I use the names eth[0-n] in my rules?  Same as before?

Have you read the news item? It explains why the file should be renamed
and also why you should change the names in the rules to not use ethN.


-- 
Neil Bothwick

My Go this  amn keyboar  oesn't have any  's.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Jarry]

On 02-Apr-13 21:58, Alan McKinnon wrote:
> On 02/04/2013 21:41, Tanstaafl wrote:
>>
>> Are you saying that now, with udev-200, the default is the OLD way, and
>> you have to intentionally enable the NEW way??
>
> No, you are stilling misunderstanding. The news item goes to great
> lengths to explain that there is a new way and it is different from the
> old way.
>
> Jarry mentioned an EMPTY file, not an absent file. The ebuild does not
> install an empty file, so it is not the default.

Well, believe me or not, but I had "empty" (only comments) file
/etc/udev/rules.d/80-net-name-slot.rules :

------
# Udev 197 and above has implemented predictable network interface names
...
# To activate this function, move this file to a name that doesn't end
# in .rules, or remove it then reboot your system
------

And I am pretty sure I did not create it manually, so it must have
come previously with some stable package, maybe udev197 (it has
25-Jan-2013 time-stamp).

So yes, I had to "activate" new interface names manually by
renaming the above mentioned file...

Jarry
-- 
_______________________________________________________________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.

[gentoo-user] Re: Udev update and persistent net rules changes

[Grant Edwards]

On 2013-04-03, Neil Bothwick <neil@digimed.co.uk> wrote:

> Have you read the news item?

Yes.  I found it rather confusing.

It refers to a "new format" for rules, but the examples use the exact
same format as the old rules.

It talks about how 80-net-name-slot.rules needs to be either an empty
file or a synmlink to /dev/null if you want to disable the new naming
scheme -- but that doesn't seem to be right.  After the upgrade my
80-net-name-slot.rules file was neither an empty file nor a symlink to
/dev/null, but I'm still getting the same old names.

> It explains why the file should be renamed and also why you should
> change the names in the rules to not use ethN.

The only explanation I found was "the old way is now deprecated".

-- 
Grant Edwards               grant.b.edwards        Yow! Kids, don't gross me
                                  at               off ... "Adventures with
                              gmail.com            MENTAL HYGIENE" can be
                                                   carried too FAR!

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Lee]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

And if it's confusing for the 'bit jockeys' on this mailing list what do
you think will be the effect on the casual user?

This could have been handled better, imho. What happened to that
documentation mojo Gentoo is known for? The post-install notes
are a real head scratcher.
On Apr 3, 2013 9:40 AM, "Grant Edwards" <grant.b.edwards@gmail.com> wrote:

> On 2013-04-03, Neil Bothwick <neil@digimed.co.uk> wrote:
>
> > Have you read the news item?
>
> Yes.  I found it rather confusing.
>
> It refers to a "new format" for rules, but the examples use the exact
> same format as the old rules.
>
> It talks about how 80-net-name-slot.rules needs to be either an empty
> file or a synmlink to /dev/null if you want to disable the new naming
> scheme -- but that doesn't seem to be right.  After the upgrade my
> 80-net-name-slot.rules file was neither an empty file nor a symlink to
> /dev/null, but I'm still getting the same old names.
>
> > It explains why the file should be renamed and also why you should
> > change the names in the rules to not use ethN.
>
> The only explanation I found was "the old way is now deprecated".
>
> --
> Grant Edwards               grant.b.edwards        Yow! Kids, don't gross
> me
>                                   at               off ... "Adventures with
>                               gmail.com            MENTAL HYGIENE" can be
>                                                    carried too FAR!
>
>
>

[-- Attachment #2: Type: text/html, Size: 1945 bytes --]

[gentoo-user] Re: Udev update and persistent net rules changes

[Jörg Schaible]

Hi,

Grant Edwards wrote:

> On 2013-04-03, Neil Bothwick <neil@digimed.co.uk> wrote:
> 
>> Have you read the news item?
> 
> Yes.  I found it rather confusing.
> 
> It refers to a "new format" for rules, but the examples use the exact
> same format as the old rules.
> 
> It talks about how 80-net-name-slot.rules needs to be either an empty
> file or a synmlink to /dev/null if you want to disable the new naming
> scheme -- but that doesn't seem to be right.  After the upgrade my
> 80-net-name-slot.rules file was neither an empty file nor a symlink to
> /dev/null, but I'm still getting the same old names.

same for me. I followed the upgrade guide and removed any 70-* files, 
renamed the net.eth0 link to the new scheme net.enp0s1 just to to find out 
that the kernel could not bring up a network with the such a device. The 
machine booted fine after using eth0 instead again. One a second machine I 
kept eth0 immediately and it booted without problems afterwards.
 
>> It explains why the file should be renamed and also why you should
>> change the names in the rules to not use ethN.
> 
> The only explanation I found was "the old way is now deprecated".

And the new name simply did not work.

- Jörg

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Bruce Hill]

On Wed, Apr 03, 2013 at 08:06:20PM +0200, Jörg Schaible wrote:
> Hi,
> 
> Grant Edwards wrote:
> 
> > On 2013-04-03, Neil Bothwick <neil@digimed.co.uk> wrote:
> > 
> >> Have you read the news item?
> > 
> > Yes.  I found it rather confusing.
> > 
> > It refers to a "new format" for rules, but the examples use the exact
> > same format as the old rules.
> > 
> > It talks about how 80-net-name-slot.rules needs to be either an empty
> > file or a synmlink to /dev/null if you want to disable the new naming
> > scheme -- but that doesn't seem to be right.  After the upgrade my
> > 80-net-name-slot.rules file was neither an empty file nor a symlink to
> > /dev/null, but I'm still getting the same old names.
> 
> same for me. I followed the upgrade guide and removed any 70-* files, 
> renamed the net.eth0 link to the new scheme net.enp0s1 just to to find out 
> that the kernel could not bring up a network with the such a device. The 
> machine booted fine after using eth0 instead again. One a second machine I 
> kept eth0 immediately and it booted without problems afterwards.
>  
> >> It explains why the file should be renamed and also why you should
> >> change the names in the rules to not use ethN.
> > 
> > The only explanation I found was "the old way is now deprecated".
> 
> And the new name simply did not work.
> 
> - Jörg
 
When the news item is too convoluted to understand without writing it on
paper, and doing a diagram of my LAN, I just get out the USB SystemRescueCD
and have it ready on first reboot. So far I've just sailed along as it's been
since before last March or so when WilliamH first put out the news item about
udev about to fubar the universe. I'd not wanted to go to or past udev-181,
but kerframil told me to stop being scared and upgrade to stable, so I did.
And here are the results, just upgrading, not changing ANY file:

mingdao@router ~ $ less /etc/udev/rules.d/80-net-name-slot.rules
/etc/udev/rules.d/80-net-name-slot.rules: No such file or directory
mingdao@router ~ $ eix sys-fs/udev
[I] sys-fs/udev
     Available versions:  [M]171-r10 197-r8^t ~198-r6^t ~199-r1^t 200^t **9999^t {{acl action_modeswitch build debug doc edd extras +firmware-loader floppy gudev hwdb introspection keymap +kmod +openrc +rule_generator selinux static-libs test}}
     Installed versions:  200^t(05:01:58 PM 04/02/2013)(acl firmware-loader kmod openrc -doc -gudev -hwdb -introspection -keymap -selinux -static-libs)
     Homepage:            http://www.freedesktop.org/wiki/Software/systemd
     Description:         Linux dynamic and persistent device naming support (aka userspace devfs)

[I] sys-fs/udev-init-scripts
     Available versions:  23^t ~24^t 25^t **9999^t
     Installed versions:  25^t(05:02:08 PM 04/02/2013)
     Homepage:            http://www.gentoo.org
     Description:         udev startup scripts for openrc

Found 2 matches.
mingdao@router ~ $ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="68:05:ca:03:05:5d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="68:05:ca:03:05:50", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10de:0x03ef (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f4:6d:04:e8:1d:d9", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"



mingdao@server ~ $ less /etc/udev/rules.d/80-net-name-slot.rules
/etc/udev/rules.d/80-net-name-slot.rules: No such file or directory
mingdao@server ~ $ eix sys-fs/udev
[I] sys-fs/udev
     Available versions:  [M]171-r10 197-r8^t ~198-r6^t ~199-r1^t 200^t **9999^t {{acl action_modeswitch build debug doc edd extras +firmware-loader floppy gudev hwdb introspection keymap +kmod +openrc +rule_generator selinux static-libs test}}
     Installed versions:  200^t(06:01:45 PM 04/02/2013)(acl firmware-loader kmod openrc -doc -gudev -hwdb -introspection -keymap -selinux -static-libs)
     Homepage:            http://www.freedesktop.org/wiki/Software/systemd
     Description:         Linux dynamic and persistent device naming support (aka userspace devfs)

[I] sys-fs/udev-init-scripts
     Available versions:  23^t ~24^t 25^t **9999^t
     Installed versions:  25^t(06:01:58 PM 04/02/2013)
     Homepage:            http://www.gentoo.org
     Description:         udev startup scripts for openrc

Found 2 matches.
mingdao@server ~ $ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:d0:68:0b:87:66", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:d0:68:0b:87:67", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"



mingdao@workstation ~ $ less /etc/udev/rules.d/80-net-name-slot.rules
/etc/udev/rules.d/80-net-name-slot.rules: No such file or directory
mingdao@workstation ~ $ eix sys-fs/udev
[I] sys-fs/udev
     Available versions:  [M]171-r10 197-r8^t ~198-r6^t ~199-r1^t 200^t **9999^t {{acl action_modeswitch build debug doc edd extras +firmware-loader floppy gudev hwdb introspection keymap +kmod +openrc +rule_generator selinux static-libs test}}
     Installed versions:  200^t(05:35:34 PM 04/02/2013)(firmware-loader gudev kmod openrc -acl -doc -hwdb -introspection -keymap -selinux -static-libs)
     Homepage:            http://www.freedesktop.org/wiki/Software/systemd
     Description:         Linux dynamic and persistent device naming support (aka userspace devfs)

[I] sys-fs/udev-init-scripts
     Available versions:  23^t ~24^t 25^t **9999^t
     Installed versions:  25^t(05:35:12 PM 04/02/2013)
     Homepage:            http://www.gentoo.org
     Description:         udev startup scripts for openrc

Found 2 matches.
mingdao@workstation ~ $ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:b8:e2:f8", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f4:6d:04:d2:6b:be", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"



mingdao@router ~ $ less /etc/udev/rules.d/80-net-name-slot.rules
/etc/udev/rules.d/80-net-name-slot.rules: No such file or directory
mingdao@router ~ $ eix sys-fs/udev
[I] sys-fs/udev
     Available versions:  [M]171-r10 197-r8^t ~198-r6^t ~199-r1^t 200^t **9999^t {{acl action_modeswitch build debug doc edd extras +firmware-loader floppy gudev hwdb introspection keymap +kmod +openrc +rule_generator selinux static-libs test}}
     Installed versions:  200^t(05:01:58 PM 04/02/2013)(acl firmware-loader kmod openrc -doc -gudev -hwdb -introspection -keymap -selinux -static-libs)
     Homepage:            http://www.freedesktop.org/wiki/Software/systemd
     Description:         Linux dynamic and persistent device naming support (aka userspace devfs)

[I] sys-fs/udev-init-scripts
     Available versions:  23^t ~24^t 25^t **9999^t
     Installed versions:  25^t(05:02:08 PM 04/02/2013)
     Homepage:            http://www.gentoo.org
     Description:         udev startup scripts for openrc

Found 2 matches.
mingdao@router ~ $ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="68:05:ca:03:05:5d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="68:05:ca:03:05:50", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10de:0x03ef (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f4:6d:04:e8:1d:d9", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"



mingdao@peter ~ $ less /etc/udev/rules.d/80-net-name-slot.rules
/etc/udev/rules.d/80-net-name-slot.rules: No such file or directory
mingdao@peter ~ $ eix sys-fs/udev
[I] sys-fs/udev
     Available versions:  [M]171-r10 197-r8^t ~198-r6^t ~199-r1^t 200^t **9999^t {{acl action_modeswitch build debug doc edd extras +firmware-loader floppy gudev hwdb introspection keymap +kmod +openrc +rule_generator selinux static-libs test}}
     Installed versions:  200^t(11:35:07 AM 04/01/2013)(firmware-loader kmod openrc -acl -doc -gudev -hwdb -introspection -keymap -selinux -static-libs)
     Homepage:            http://www.freedesktop.org/wiki/Software/systemd
     Description:         Linux dynamic and persistent device naming support (aka userspace devfs)

[I] sys-fs/udev-init-scripts
     Available versions:  23^t ~24^t 25^t **9999^t
     Installed versions:  25^t(11:34:23 AM 04/01/2013)
     Homepage:            http://www.gentoo.org
     Description:         udev startup scripts for openrc

Found 2 matches.
mingdao@peter ~ $ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="bc:ae:c5:6c:3c:97", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"


Therefore, all's well that's still working! And AFAIR, on at least 2 of those
machines, the 70-persistent-net.rules was never something I did manually.

I've grown weary of the poor Linux desktop(s), so these are the only 5
computers left on the LAN running Gentoo. Two laptops and two PCs that were
for desktop type computers only have been migrated to Windows 7. I really hate
it, but at least now everything desktop environment wise just works, and does
not either (a) get messed up by updates, or (b) require a lot of work to get
it to work properly to start with, or keep it working.

Cheers,
Bruce
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.                                                                                                                                                          
Q: Why is top-posting such a bad thing?                                                                                                                                                                                        
A: Top-posting.                                                                                                                                                                                                                
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 501 bytes --]

On Wednesday 03 Apr 2013 20:46:37 Bruce Hill wrote:

> Therefore, all's well that's still working! And AFAIR, on at least 2 of
> those machines, the 70-persistent-net.rules was never something I did
> manually.

Right, it used to be auto-generated by udev scripts.  With udev-200 you are 
meant to remove it along with any other files from your /etc/udev/rules.d/

If you left them there and their syntax is still valid, then udev will parse 
them and do as is told.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: Udev update and persistent net rules changes

[Nuno J. Silva (aka njsg)]

On 2013-04-01, Michael Mol <mikemol@gmail.com> wrote:
>
> On 04/01/2013 03:26 PM, William Hubbs wrote:
>
>> You know that both udev and eudev have exactly the same issue with
>> separate /usr right?
>> The problem there isn't in the udev code, but it has to do with what is
>> happening in rules that other packages install.
>
> As I recall, the problem is where the ebuild choses to install the code.
> Putting the udev code under /usr forces the issue on systems where it
> would otherwise not be an issue.
>
> Putting the udev code under / avoids that issue, but opens up the system
> to the "silently fail" thing upstream liked to use as the basis of
> "separate /usr is broken"
>
> So, there are three conceivable configurations (initramfs notwithstanding):
>
> 1. With systems which don't require /usr binaries before /usr would be
> mounted, separate /usr is not a problem.
>
> 2. With systems which require /usr binaries for some features before
> /usr would be mounted, those features will silently fail.
>
> 3. With systems which require /usr binaries to mount /usr, all hell
> breaks loose.
>
> Putting the udev code under /usr moves all udev systems from group 2
> into group 3. In a sense, this fixes those systems because the admin is
> forced to address the silent failures he was previously unaware of. It
> also means pissing off a bunch of people who had features silently
> failing...but they probably didn't know or care about those features in
> the first place.
>
> It also moves all systems from group 1 into group 3...which is simply wro=
> ng.
>
> So long as eudev keeps its install path at / instead of /usr, admins in
> group 1 will probably be perfectly happy.

I'd guess nothing prevents the udev ebuild from doing so, too.


-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

[gentoo-user] Re: Udev update and persistent net rules changes

[Nuno J. Silva (aka njsg)]

On 2013-04-02, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 02/04/2013 21:13, Paul Hartman wrote:
>> On Mon, Apr 1, 2013 at 7:00 PM, Peter Humphrey <peter@humphrey.ukfsn.org> wrote:
>>> The most important para to me in the news item was: "The feature can also be
>>> completely disabled using net.ifnames=0 on the kernel command line." I just
>>> added that to my grub.conf entries and I sail blissfully on with eth0.
>> 
>> 
>> I updated remote virtual server (xen guest) and added this same
>> option, crossed my fingers and rebooted, eth0 was still there and I
>> was happy.
>> 
>
>
> I did this to get exactly the same result:
>
> $ ls -al /etc/udev/rules.d/
> total 8
> drwxr-xr-x 2 root root 4096 Apr  1 15:10 .
> drwxr-xr-x 4 root root 4096 Mar 30 20:34 ..
> lrwxrwxrwx 1 root root    9 Apr  1 15:10 80-net-name-slot.rules -> /dev/null
>
> Like you, I happen to *like* eth0 and wlan0 on a laptop workstation
> :-)

Sort of the same here, except that I use lan0 instead of eth0, because
once in a while I use broadcom's wireless drivers instead of the kernel
drivers, and the former assign an ethX name.

Sadly, I still get some problems after resuming from hibernation:
*sometimes*, the ethernet NIC won't be renamed lan0 (and remains eth0),
and I have to rmmod and modprobe.

Also sadly, the fact that several people go "oh noes you can't use
wlan0" when I try to get comments on how to fix the issue does not
help a lot...


-- 
Nuno Silva (aka njsg)
http://njsg.sdf-eu.org/

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Alan McKinnon]

On 04/04/2013 10:10, Nuno J. Silva (aka njsg) wrote:
> Sort of the same here, except that I use lan0 instead of eth0, because
> once in a while I use broadcom's wireless drivers instead of the kernel
> drivers, and the former assign an ethX name.
> 
> Sadly, I still get some problems after resuming from hibernation:
> *sometimes*, the ethernet NIC won't be renamed lan0 (and remains eth0),
> and I have to rmmod and modprobe.
> 
> Also sadly, the fact that several people go "oh noes you can't use
> wlan0" when I try to get comments on how to fix the issue does not
> help a lot...


I hear you :-)

The amount of FUD and misinformation surrounding the entire udev
"ecosystem" over the past 6 months defies all belief. I don't think I've
ever seen quite this much hysteria and mob-think in anything
computing-related until now. And that includes SCO, which is saying
something...

I gets so bad that people are starting to make shit up to be worried
about, instead of just reading the simple document that is right in
front of their eyes that already fully and completely answers the
question at hand....





-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Tanstaafl]

On 2013-04-04 5:13 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> I gets so bad that people are starting to make shit up to be worried
> about, instead of just reading the simple document that is right in
> front of their eyes that already fully and completely answers the
> question at hand....

But Alan, haven't you read the recent (past couple of DAYS) emails in 
this very thread from people who followed the current 'simple document' 
you refer to and it did not work as advertised? I don't think these 
people are making this stuff up - are you saying you do?

Not to mention the fact that this final/current seemingly complete 
document was way, way too late for the many people who ended up with 
totally broken systems, and *that* is what caused all of the 'hysteria 
and mob-think' you so condescendingly speak of.

It is these reports that is causing me all kinds of fear/trepidation at 
this seemingly simple/benign update (as you seem to believe it is).

So, again, I would really, really like a very simple answer as to the 
*best* way to retain the old way that is least likely to cause problems 
down the road (ie, if/when udev is subsumed by systemd). Currently I 
count 3 different ways.

Or, as an alternative, *how* to switch to eudev (their web page does 
*not* have simple/precise instructions on how to switch, only a 
description of what it is) - ie, do I just emerge -C udev && emerge -C 
virtual/udev && emerge eudev? Or is there more to it?

[gentoo-user] Re: Udev update and persistent net rules changes

[Grant Edwards]

On 2013-04-03, Mick <michaelkintzios@gmail.com> wrote:
> On Wednesday 03 Apr 2013 20:46:37 Bruce Hill wrote:
>
>> Therefore, all's well that's still working! And AFAIR, on at least 2 of
>> those machines, the 70-persistent-net.rules was never something I did
>> manually.
>
> Right, it used to be auto-generated by udev scripts.  With udev-200 you are 
> meant to remove it along with any other files from your /etc/udev/rules.d/

Huh?  I'm supposed to remove all the other rules files as well?

If we're not supposed to have user-defined rules, how do I do things
like get various USB/firewire devices named/symlinked properly so that
my backup drive gets mounted in the right spot, my oscilloscope SW can
find the right USB "serial" port, and so on...

-- 
Grant Edwards               grant.b.edwards        Yow! I'll show you MY
                                  at               telex number if you show me
                              gmail.com            YOURS ...

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

On 04/04/2013 10:59 AM, Grant Edwards wrote:
> On 2013-04-03, Mick <michaelkintzios@gmail.com> wrote:
>> On Wednesday 03 Apr 2013 20:46:37 Bruce Hill wrote:
>>
>>> Therefore, all's well that's still working! And AFAIR, on at least 2 of
>>> those machines, the 70-persistent-net.rules was never something I did
>>> manually.
>>
>> Right, it used to be auto-generated by udev scripts.  With udev-200 you are 
>> meant to remove it along with any other files from your /etc/udev/rules.d/
> 
> Huh?  I'm supposed to remove all the other rules files as well?
> 
> If we're not supposed to have user-defined rules, how do I do things
> like get various USB/firewire devices named/symlinked properly so that
> my backup drive gets mounted in the right spot, my oscilloscope SW can
> find the right USB "serial" port, and so on...
> 

You're supposed to remove all the files in there that you did not
yourself create.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

On Wed, 3 Apr 2013 16:38:28 +0000 (UTC), Grant Edwards wrote:

> > Have you read the news item?  
> 
> Yes.  I found it rather confusing.
> 
> It refers to a "new format" for rules, but the examples use the exact
> same format as the old rules.

Poor choice of terminology there, the format is the same only the chosen
namespace is different.

> It talks about how 80-net-name-slot.rules needs to be either an empty
> file or a synmlink to /dev/null if you want to disable the new naming
> scheme -- but that doesn't seem to be right.  After the upgrade my
> 80-net-name-slot.rules file was neither an empty file nor a symlink to
> /dev/null, but I'm still getting the same old names.

Do you have a 70-persistent-net.rules file? That would override to give
the old names, which is why the news item tells you to change it

"If the system still has old network interface renaming rules in
/etc/udev/rules.d, like 70-persistent-net.rules, those will need
to be either modified or removed."

> > It explains why the file should be renamed and also why you should
> > change the names in the rules to not use ethN.  
> 
> The only explanation I found was "the old way is now deprecated".

My bad, I thought that was covered in the news item, but it is left to
one of the linked pages to explain it.


-- 
Neil Bothwick

The voices in my head may not be real, but they have some good ideas!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

On Thu, 04 Apr 2013 09:07:00 -0400, Tanstaafl wrote:

> Not to mention the fact that this final/current seemingly complete 
> document was way, way too late for the many people who ended up with 
> totally broken systems, and *that* is what caused all of the 'hysteria 
> and mob-think' you so condescendingly speak of.

This time the news was released before the update became available,
although for something as potentially system-breaking as this, the gap
should have been several days larger IMO.

> So, again, I would really, really like a very simple answer as to the 
> *best* way to retain the old way that is least likely to cause problems 
> down the road (ie, if/when udev is subsumed by systemd). Currently I 
> count 3 different ways

The no.ifrename kernel option mentioned in the news item.
 
> Or, as an alternative, *how* to switch to eudev (their web page does 
> *not* have simple/precise instructions on how to switch, only a 
> description of what it is) - ie, do I just emerge -C udev && emerge -C 
> virtual/udev && emerge eudev? Or is there more to it?

quickpkg udev && emerge -Ca udev && emerge -1a eudev

Don't try removing virtual/udev, that is depended on by several packages
(and probably system) but is satisfied by eudev. The only gotcha I found
is that the USE flags for eudev must match those for eudev, so if you have
anything udev-related in /etc/portage/package.use, make sure it applies
to eudev too.


-- 
Neil Bothwick

Did you hear about the blind prostitute? You have to hand it to her.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Bruce Hill]

On Wed, Apr 03, 2013 at 11:28:10PM +0100, Mick wrote:
> On Wednesday 03 Apr 2013 20:46:37 Bruce Hill wrote:
> 
> > Therefore, all's well that's still working! And AFAIR, on at least 2 of
> > those machines, the 70-persistent-net.rules was never something I did
> > manually.
> 
> Right, it used to be auto-generated by udev scripts.  With udev-200 you are 
> meant to remove it along with any other files from your /etc/udev/rules.d/
> 
> If you left them there and their syntax is still valid, then udev will parse 
> them and do as is told.
> 
> -- 
> Regards,
> Mick

Why are we "meant to remove it"?

Why would we remove them, since they're working?

My kernel(s) all have eth* and none of that weirdness others reported.

Thanks,
Bruce
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.                                                                                                                                                          
Q: Why is top-posting such a bad thing?                                                                                                                                                                                        
A: Top-posting.                                                                                                                                                                                                                
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

[gentoo-user] Re: Re: Udev update and persistent net rules changes

[Jörg Schaible]

Neil Bothwick wrote:

> On Wed, 3 Apr 2013 16:38:28 +0000 (UTC), Grant Edwards wrote:
> 
>> > Have you read the news item?
>> 
>> Yes.  I found it rather confusing.
>> 
>> It refers to a "new format" for rules, but the examples use the exact
>> same format as the old rules.
> 
> Poor choice of terminology there, the format is the same only the chosen
> namespace is different.
> 
>> It talks about how 80-net-name-slot.rules needs to be either an empty
>> file or a synmlink to /dev/null if you want to disable the new naming
>> scheme -- but that doesn't seem to be right.  After the upgrade my
>> 80-net-name-slot.rules file was neither an empty file nor a symlink to
>> /dev/null, but I'm still getting the same old names.
> 
> Do you have a 70-persistent-net.rules file? That would override to give
> the old names, which is why the news item tells you to change it
>
> "If the system still has old network interface renaming rules in
> /etc/udev/rules.d, like 70-persistent-net.rules, those will need
> to be either modified or removed."

I don't have any rules except the 80-* one installed by new udev and I still 
have the old names - and this has been the case now for 3 machines and I 
upgrade a 4th right now.

>> > It explains why the file should be renamed and also why you should
>> > change the names in the rules to not use ethN.
>> 
>> The only explanation I found was "the old way is now deprecated".
> 
> My bad, I thought that was covered in the news item, but it is left to
> one of the linked pages to explain it.

- Jörg

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Walter Dnes]

On Thu, Apr 04, 2013 at 05:05:06PM +0100, Neil Bothwick wrote
> On Thu, 04 Apr 2013 09:07:00 -0400, Tanstaafl wrote:
>  
> > Or, as an alternative, *how* to switch to eudev (their web page does 
> > *not* have simple/precise instructions on how to switch, only a 
> > description of what it is) - ie, do I just emerge -C udev && emerge -C 
> > virtual/udev && emerge eudev? Or is there more to it?
> 
> quickpkg udev && emerge -Ca udev && emerge -1a eudev

  A bit more detail... *WARNING* do the following in sequence, quickly,
and do *NOT* reboot until after step 7)

1) Optional fallback... quickpkg udev
2) Keyword sys-fs/eudev/eudev-1_beta2-r2 (~x86 or ~amd64 or whatever is
correct for your machine)
3) Remove udev... emerge -Ca udev
4) Install eudev... emerge -1a eudev

NOTE; eudev is a drop-in replacement for udev, and generates the same
file names.  With that in mind, the next 2 items make sense...

5) Stop the old udev demon and start the new one with the command...
   /etc/init.d/udev --nodeps restart
6) Do *NOT* remove virtual/udev and do *NOT* remove the udev service
with rc-update

7) Follow any additional instructions you may get as ewarn messages or
in /var/log/portage/elog

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Tanstaafl]

On 2013-04-03 6:28 PM, Mick <michaelkintzios@gmail.com> wrote:
> On Wednesday 03 Apr 2013 20:46:37 Bruce Hill wrote:
>
>> Therefore, all's well that's still working! And AFAIR, on at least 2 of
>> those machines, the 70-persistent-net.rules was never something I did
>> manually.

> Right, it used to be auto-generated by udev scripts.  With udev-200 you are
> meant to remove it along with any other files from your /etc/udev/rules.d/
>
> If you left them there and their syntax is still valid, then udev will parse
> them and do as is told.

Ok, so...

I just realized that my current/existing 70-persistent-net.rules syntax 
is different from the 'old format' referenced in the udev upgrade news 
item. I have:

> # This file was automatically generated by the /lib/udev/write_net_rules
> # program, probably run by the persistent-net-generator.rules rules file.
> #
> # You can modify it, as long as you keep each rule on a single line.
>
> # PCI device 0x10de:0x0057 (forcedeth)
> SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:e0:81:54:9c:8b", KERNEL=="eth*", NAME="eth1"
>
> # PCI device 0x10de:0x0057 (forcedeth)
> SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:e0:81:54:9c:8a", KERNEL=="eth*", NAME="eth0"

Note the 'DRIVERS==' and 'KERNEL==' items that are not showing in the 
news item example for the old format, as well as the LACK of the 
'ACTION==' item... is this dependent on the interface type? Or is mine 
'wrong' (and just has been working by accident all these years)?

So, now I'm even more confused.

If I just want to totally disable the new behavior and keep the old, I 
know I just add 'net.ifnames=0' on the kernel command-line, but...

Do I just rename the above file to something like 
'70-my-net-names.rules', keeping the content the same?

Or do I need to edit the lines? And if so, to what? Do I remove the 
'DRIVERS==' and 'KERNEL==' items and add the 'ACTION==' item?

Do I change the eth0 to net0 (and create the symlink and update 
rc-update as discussed earlier)?

crap-crud...

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]

On Thu, Apr 04, 2013 at 09:07:00AM -0400, Tanstaafl wrote:
> On 2013-04-04 5:13 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> > I gets so bad that people are starting to make shit up to be worried
> > about, instead of just reading the simple document that is right in
> > front of their eyes that already fully and completely answers the
> > question at hand....
> 
> But Alan, haven't you read the recent (past couple of DAYS) emails in 
> this very thread from people who followed the current 'simple document' 
> you refer to and it did not work as advertised? I don't think these 
> people are making this stuff up - are you saying you do?
> 
> Not to mention the fact that this final/current seemingly complete 
> document was way, way too late for the many people who ended up with 
> totally broken systems, and *that* is what caused all of the 'hysteria 
> and mob-think' you so condescendingly speak of.
> 
> It is these reports that is causing me all kinds of fear/trepidation at 
> this seemingly simple/benign update (as you seem to believe it is).
> 
> So, again, I would really, really like a very simple answer as to the 
> *best* way to retain the old way that is least likely to cause problems 
> down the road (ie, if/when udev is subsumed by systemd). Currently I 
> count 3 different ways.
 
You are right, there are several different ways to disable udev's
predictable network interface names:

1) add net.ifnames=0 to the kernel command line in your boot loader
configuration.

2) use any of the methods listed on the upstream wiki [1] under "I don't
like this, how do I disable this?"

None of those should cause problems later.

William

[1]
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Tanstaafl]

But what confuses me about that linked page is that from what I've heard 
from others here, option 1 - which is the option I think I'd prefer - 
requires more than just symlinking 80-net-name-slot.rules to 
/dev/null...? Apparently you should also create your own 
70-my-net-names.rules - but I've heard many people claim they used ethX 
names instead of netX names, so... again... should I just rename my file 
to 70-my-net-names.rules and leave the contents alone?

Still confused/concerned about the differences in my current rules 
(items in mine that aren't in the examples)...



On 2013-04-05 12:17 PM, William Hubbs <williamh@gentoo.org> wrote:
> You are right, there are several different ways to disable udev's
> predictable network interface names:
>
> 1) add net.ifnames=0 to the kernel command line in your boot loader
> configuration.
>
> 2) use any of the methods listed on the upstream wiki [1] under "I don't
> like this, how do I disable this?"
>
> None of those should cause problems later.
>
> William
>
> [1]
> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
>

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

On Fri, Apr 05, 2013 at 01:32:23PM -0400, Tanstaafl wrote:
> But what confuses me about that linked page is that from what I've heard 
> from others here, option 1 - which is the option I think I'd prefer - 
> requires more than just symlinking 80-net-name-slot.rules to 
> /dev/null...? Apparently you should also create your own 
> 70-my-net-names.rules - but I've heard many people claim they used ethX 
> names instead of netX names, so... again... should I just rename my file 
> to 70-my-net-names.rules and leave the contents alone?

symlinking /etc/udev/rules.d/80-net-name-slot.rules to /dev/null does
the same thing as adding net.ifnames=0 to your kernel command line, so
choose one or the other of these.

Neither of these is needed if you want to have your own names,
because naming the interfaces yourself in /etc/uev/70-net-names.rules or
whatever you call the file overrides udev's predictable names.

If people are using ethx names and getting away with it it is probably
because they are loading the drivers as modules, or by chance the kernel
is initializing the cards in the order they expect. There is no
guarantee that will stay consistent.

I recommend using netx names.

Does that clear it up?

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Tanstaafl]

On 2013-04-05 2:41 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Fri, Apr 05, 2013 at 01:32:23PM -0400, Tanstaafl wrote:
>> But what confuses me about that linked page is that from what I've heard
>> from others here, option 1 - which is the option I think I'd prefer -
>> requires more than just symlinking 80-net-name-slot.rules to
>> /dev/null...? Apparently you should also create your own
>> 70-my-net-names.rules - but I've heard many people claim they used ethX
>> names instead of netX names, so... again... should I just rename my file
>> to 70-my-net-names.rules and leave the contents alone?
>
> symlinking /etc/udev/rules.d/80-net-name-slot.rules to /dev/null does
> the same thing as adding net.ifnames=0 to your kernel command line, so
> choose one or the other of these.
>
> Neither of these is needed if you want to have your own names,
> because naming the interfaces yourself in /etc/uev/70-net-names.rules or
> whatever you call the file overrides udev's predictable names.
>
> If people are using ethx names and getting away with it it is probably
> because they are loading the drivers as modules, or by chance the kernel
> is initializing the cards in the order they expect. There is no
> guarantee that will stay consistent.
>
> I recommend using netx names.
>
> Does that clear it up?

Well, to a point (as to whether I use netX or ethX)...

I'd still like to know why the contents of my current rules file differs 
so much from the examples I've seen... ie, the two extra items that are 
in mine ('DRIVERS==' and 'KERNEL=='), and the missing one 
('ACTION==')... and whether or not I should include these if I decide to 
go with my own rules file...

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

On Fri, Apr 05, 2013 at 01:41:28PM -0500, William Hubbs wrote:
> On Fri, Apr 05, 2013 at 01:32:23PM -0400, Tanstaafl wrote:
> > But what confuses me about that linked page is that from what I've heard 
> > from others here, option 1 - which is the option I think I'd prefer - 
> > requires more than just symlinking 80-net-name-slot.rules to 
> > /dev/null...? Apparently you should also create your own 
> > 70-my-net-names.rules - but I've heard many people claim they used ethX 
> > names instead of netX names, so... again... should I just rename my file 
> > to 70-my-net-names.rules and leave the contents alone?
> 
> symlinking /etc/udev/rules.d/80-net-name-slot.rules to /dev/null does
> the same thing as adding net.ifnames=0 to your kernel command line, so
> choose one or the other of these.
> 
> Neither of these is needed if you want to have your own names,
> because naming the interfaces yourself in /etc/uev/70-net-names.rules or
> whatever you call the file overrides udev's predictable names.
> 
> If people are using ethx names and getting away with it it is probably
> because they are loading the drivers as modules, or by chance the kernel
> is initializing the cards in the order they expect. There is no
> guarantee that will stay consistent.
 
 There is one more situation where you would get away with eth0, and
 that is if you just have one network card.

But, as soon as you add another card, there is no guarantee that eth0
will refer to the card you expect it to refer to.

> I recommend using netx names.
> 
> Does that clear it up?
> 
> William
> 



[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Bruce Hill]

On Fri, Apr 05, 2013 at 01:41:28PM -0500, William Hubbs wrote:
> 
> Neither of these is needed if you want to have your own names,
> because naming the interfaces yourself in /etc/uev/70-net-names.rules or
> whatever you call the file overrides udev's predictable names.
> 
> If people are using ethx names and getting away with it it is probably
> because they are loading the drivers as modules, or by chance the kernel
> is initializing the cards in the order they expect. There is no
> guarantee that will stay consistent.
> 
> I recommend using netx names.
> 
> Does that clear it up?
> 
> William

Just dealing with one server and my Linux router, they've been updated to
sys-fs/udev-200 and are both still using the same
/etc/udev/rules.d/70-persistent-net.rules file they've had for over a year,
which was working with udev-171.

mingdao@server ~ $ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:d0:68:0b:87:66", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:d0:68:0b:87:67", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"


mingdao@router ~ $ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="68:05:ca:03:05:5d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="68:05:ca:03:05:50", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10de:0x03ef (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f4:6d:04:e8:1d:d9", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

There is no log file or any indication of other than eth* for those NICs. And
neither those 2 or the other 3 Gentoo boxen on this LAN have ever had a
/etc/udev/rules.d/80-net-name-slot.rules file.

As stated before, I didn't want to upgrade past udev-171, but kerframil told
me it would work fine, don't worry, upgrade to stable. Though I did upgrade, I
didn't intend to reboot any of those boxen until I looked carefully. And then
March 29 we had a power outage for over an hour, none of the UPSes stood up
that long, but everything was the same when I started the machines again.

Amazed, as usual...
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.                                                                                                                                                          
Q: Why is top-posting such a bad thing?                                                                                                                                                                                        
A: Top-posting.                                                                                                                                                                                                                
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote:
> Just dealing with one server and my Linux router, they've been updated to
> sys-fs/udev-200 and are both still using the same
> /etc/udev/rules.d/70-persistent-net.rules file they've had for over a year,
> which was working with udev-171.

Do you have your network interface drivers built into the kernel or are
they modules?

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

On Fri, Apr 05, 2013 at 02:58:02PM -0400, Tanstaafl wrote:
> I'd still like to know why the contents of my current rules file differs 
> so much from the examples I've seen... ie, the two extra items that are 
> in mine ('DRIVERS==' and 'KERNEL=='), and the missing one 
> ('ACTION==')... and whether or not I should include these if I decide to 
> go with my own rules file...
 
 The first thing I would do if I were you is to test with one of the
 examples (keeping my rules file somewhere as a backup), and if that
 test works, I would go with it.

ACTION== is needed, but you may be able to get away without DRIVERS==
and KERNEL==.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Bruce Hill]

On Fri, Apr 05, 2013 at 03:11:39PM -0500, William Hubbs wrote:
> On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote:
> > Just dealing with one server and my Linux router, they've been updated to
> > sys-fs/udev-200 and are both still using the same
> > /etc/udev/rules.d/70-persistent-net.rules file they've had for over a year,
> > which was working with udev-171.
> 
> Do you have your network interface drivers built into the kernel or are
> they modules?
> 
> William

All built in:

mingdao@server ~ $ zgrep -i tigon /proc/config.gz 
CONFIG_TIGON3=y

mingdao@router ~ $ zgrep -i e1000e /proc/config.gz 
CONFIG_E1000E=y
mingdao@router ~ $ zgrep -i forcedeth /proc/config.gz 
CONFIG_FORCEDETH=y
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.                                                                                                                                                          
Q: Why is top-posting such a bad thing?                                                                                                                                                                                        
A: Top-posting.                                                                                                                                                                                                                
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Walter Dnes]

On Fri, Apr 05, 2013 at 01:41:28PM -0500, William Hubbs wrote

> If people are using ethx names and getting away with it it is probably
> because they are loading the drivers as modules, or by chance the kernel
> is initializing the cards in the order they expect. There is no
> guarantee that will stay consistent.

  Question; will the following work reliably?  IANAD (I Am Not A
Developer) which is why I'm asking.

* on a machine with multiple network cards *ALL USING DIFFERENT DRIVERS*
* drivers are built as modules, not built-in into the kernel
* is it possible to set things up so that the network driver modules do
  not load automatically at bootup?
* have a script in /etc/local.d/ (or wherever) modprobe the drivers in
  the desired order

  I can see complications involving services that depend on net (e.g.
sshd), but in general, would it work reliably?  I.e. would the order of
initial modprobe'ing determine the device names (eth/0/1/2/etc)?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

On Fri, 5 Apr 2013 21:14:39 -0400, Walter Dnes wrote:

> * on a machine with multiple network cards *ALL USING DIFFERENT DRIVERS*
> * drivers are built as modules, not built-in into the kernel
> * is it possible to set things up so that the network driver modules do
>   not load automatically at bootup?
> * have a script in /etc/local.d/ (or wherever) modprobe the drivers in
>   the desired order
> 
>   I can see complications involving services that depend on net (e.g.
> sshd), but in general, would it work reliably? 

What happens if one of the modules fails to load for any reason?

If you need persistent device names, set up rules to give them, but use
names outside of the kernel namespace to avoid the problems that udev is
trying to avoid with its new naming rules.
 

-- 
Neil Bothwick

Where do you think you're going today?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1593 bytes --]

On Saturday 06 Apr 2013 09:43:28 Neil Bothwick wrote:
> On Fri, 5 Apr 2013 21:14:39 -0400, Walter Dnes wrote:
> > * on a machine with multiple network cards *ALL USING DIFFERENT DRIVERS*
> > * drivers are built as modules, not built-in into the kernel
> > * is it possible to set things up so that the network driver modules do
> > 
> >   not load automatically at bootup?
> > 
> > * have a script in /etc/local.d/ (or wherever) modprobe the drivers in
> > 
> >   the desired order
> >   
> >   I can see complications involving services that depend on net (e.g.
> > 
> > sshd), but in general, would it work reliably?
> 
> What happens if one of the modules fails to load for any reason?
> 
> If you need persistent device names, set up rules to give them, but use
> names outside of the kernel namespace to avoid the problems that udev is
> trying to avoid with its new naming rules.

Answering Walter's question - from my experience on at least two boxen that 
I've rebooted since udev 200:

My ethernet cards which had their driver built in the kernel were renamed by 
udev to the enp_something predictable name.

The wireless cards that I had them built as modules remained the same as 
before; e.g. wlan0.  I only have one wireless card in each machine so I don't 
know if the naming will get mixed up, if I had more than one and the kernel 
decided to modprobe them in a different order.  I expect that it would rename 
them as it would do before udev-200, in which case a 70-net-names.rules would 
bring things back to even keel.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

On Apr 6, 2013 3:44 PM, "Neil Bothwick" <neil@digimed.co.uk> wrote:
>
> On Fri, 5 Apr 2013 21:14:39 -0400, Walter Dnes wrote:
>
> > * on a machine with multiple network cards *ALL USING DIFFERENT DRIVERS*
> > * drivers are built as modules, not built-in into the kernel
> > * is it possible to set things up so that the network driver modules do
> >   not load automatically at bootup?
> > * have a script in /etc/local.d/ (or wherever) modprobe the drivers in
> >   the desired order
> >
> >   I can see complications involving services that depend on net (e.g.
> > sshd), but in general, would it work reliably?
>
> What happens if one of the modules fails to load for any reason?
>
> If you need persistent device names, set up rules to give them, but use
> names outside of the kernel namespace to avoid kk problems that udev is
> trying to avoid with its new naming rules.ooh
>

Ahhh... I think now I understand...

So. Here's my summarization of the situation:

* The ethX naming can change, i.e., the interfaces can get out of order
* So, to fix this, udev decided to use the physical attachment points of
the NIC in driving a persistent name, a name that will be identical across
boots as long as there is no hardware change
* In doing so, it also frees the 'traditional' ethX names to be used
* If one wants, one can still 'rename' the NICs to the 'traditional' names
using the 70-*.rules script
* Doing so (specifying the NICs' names using the 70-*r.rules script) will
also disable the new 'persistent naming' system -- for the NICs specified
in the 70-*r.rules file
* Therefore, users that will be impacted are those that upgraded udev but
doesn't have the 70-*r.rules, for udev will then assign new names for the
NICs
* For these users, specifying the net....something switch for the kernel
(sorry, forgot the complete switch) will disable the new naming system

So, have I gotten everything correctly?

CMIIW, please.

Rgds,
--

[-- Attachment #2: Type: text/html, Size: 2314 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[kwkhui]

[-- Attachment #1: Type: text/plain, Size: 2678 bytes --]

On Sat, 6 Apr 2013 19:11:46 +0700
Pandu Poluan <pandu@poluan.info> wrote:

> On Apr 6, 2013 3:44 PM, "Neil Bothwick" <neil@digimed.co.uk> wrote:
> >
> > On Fri, 5 Apr 2013 21:14:39 -0400, Walter Dnes wrote:
> >
> > > * on a machine with multiple network cards *ALL USING DIFFERENT
> > > DRIVERS*
> > > * drivers are built as modules, not built-in into the kernel
> > > * is it possible to set things up so that the network driver
> > > modules do not load automatically at bootup?
> > > * have a script in /etc/local.d/ (or wherever) modprobe the
> > > drivers in the desired order
> > >
> > >   I can see complications involving services that depend on net
> > > (e.g. sshd), but in general, would it work reliably?
> >
> > What happens if one of the modules fails to load for any reason?
> >
> > If you need persistent device names, set up rules to give them, but
> > use names outside of the kernel namespace to avoid kk problems that
> > udev is trying to avoid with its new naming rules.ooh
> >
> 
> Ahhh... I think now I understand...
> 
> So. Here's my summarization of the situation:
> 
> * The ethX naming can change, i.e., the interfaces can get out of
> order
> * So, to fix this, udev decided to use the physical attachment points
> of the NIC in driving a persistent name, a name that will be
> identical across boots as long as there is no hardware change

There are also other ways such as using the mac address (disabled by
default).

> * In doing so, it also frees the 'traditional' ethX names to be used

No.  The eth[0-9]+ namespace is not free, it has always been used by
the linux kernel, and will stay so.

> * If one wants, one can still 'rename' the NICs to the 'traditional'
> names using the 70-*.rules script
> * Doing so (specifying the NICs' names using the 70-*r.rules script)
> will also disable the new 'persistent naming' system -- for the NICs
> specified in the 70-*r.rules file
> * Therefore, users that will be impacted are those that upgraded udev
> but doesn't have the 70-*r.rules, for udev will then assign new names
> for the NICs
> * For these users, specifying the net....something switch for the
> kernel (sorry, forgot the complete switch) will disable the new
> naming system
> 
> So, have I gotten everything correctly?

Almost, except you should not specify a name that is also eth[0-9]+
(what you called 'traditional' name), since it can cause a race
condition where the kernel and udev fight for the name.  While it used
to be the case (i.e. <udev-197) that udev tries to handle the race
condition, the devs has decided to remove those code.

Regards,

Kerwin.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Tanstaafl]

On 2013-04-06 8:31 AM, kwkhui@hkbn.net <kwkhui@hkbn.net> wrote:
> Almost, except you should not specify a name that is also eth[0-9]+
> (what you called 'traditional' name), since it can cause a race
> condition where the kernel and udev fight for the name.  While it used
> to be the case (i.e. <udev-197) that udev tries to handle the race
> condition, the devs has decided to remove those code.

Ok, thanks, I *think* I've got a handle on this now (sorry for being so 
dense)...

So, other than userland scripts that I created myself and know where 
they live, where do I search for any files/scripts 
created/generated/maintained by the system, for references to eth0/1 to 
change to net0/1? Is it just /etc/conf.d?

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Tanstaafl]

On 2013-04-05 4:11 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote:
>> Just dealing with one server and my Linux router, they've been updated to
>> sys-fs/udev-200 and are both still using the same
>> /etc/udev/rules.d/70-persistent-net.rules file they've had for over a year,
>> which was working with udev-171.
>
> Do you have your network interface drivers built into the kernel or are
> they modules?

I'm very interested in the significance of this question...

My server is module free, so all drivers are built into the kernel.

Does this provide for another option and/or make things easier?

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

On Sat, 06 Apr 2013 10:22:49 -0400, Tanstaafl wrote:

> So, other than userland scripts that I created myself and know where 
> they live, where do I search for any files/scripts 
> created/generated/maintained by the system, for references to eth0/1 to 
> change to net0/1? Is it just /etc/conf.d?

/etc/udev/rules.d

Or grep -r 'eth[0-9]' /etc.


-- 
Neil Bothwick

Sure, we just route the main sensor through Data's cat.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 3103 bytes --]

On Apr 6, 2013 7:32 PM, <kwkhui@hkbn.net> wrote:
>
> On Sat, 6 Apr 2013 19:11:46 +0700
> Pandu Poluan <pandu@poluan.info> wrote:
>
> > On Apr 6, 2013 3:44 PM, "Neil Bothwick" <neil@digimed.co.uk> wrote:
> > >
> > > On Fri, 5 Apr 2013 21:14:39 -0400, Walter Dnes wrote:
> > >
> > > > * on a machine with multiple network cards *ALL USING DIFFERENT
> > > > DRIVERS*
> > > > * drivers are built as modules, not built-in into the kernel
> > > > * is it possible to set things up so that the network driver
> > > > modules do not load automatically at bootup?
> > > > * have a script in /etc/local.d/ (or wherever) modprobe the
> > > > drivers in the desired order
> > > >
> > > >   I can see complications involving services that depend on net
> > > > (e.g. sshd), but in general, would it work reliably?
> > >
> > > What happens if one of the modules fails to load for any reason?
> > >
> > > If you need persistent device names, set up rules to give them, but
> > > use names outside of the kernel namespace to avoid kk problems that
> > > udev is trying to avoid with its new naming rules.ooh
> > >
> >
> > Ahhh... I think now I understand...
> >
> > So. Here's my summarization of the situation:
> >
> > * The ethX naming can change, i.e., the interfaces can get out of
> > order
> > * So, to fix this, udev decided to use the physical attachment points
> > of the NIC in driving a persistent name, a name that will be
> > identical across boots as long as there is no hardware change
>
> There are also other ways such as using the mac address (disabled by
> default).
>
> > * In doing so, it also frees the 'traditional' ethX names to be used
>
> No.  The eth[0-9]+ namespace is not free, it has always been used by
> the linux kernel, and will stay so.
>
> > * If one wants, one can still 'rename' the NICs to the 'traditional'
> > names using the 70-*.rules script
> > * Doing so (specifying the NICs' names using the 70-*r.rules script)
> > will also disable the new 'persistent naming' system -- for the NICs
> > specified in the 70-*r.rules file
> > * Therefore, users that will be impacted are those that upgraded udev
> > but doesn't have the 70-*r.rules, for udev will then assign new names
> > for the NICs
> > * For these users, specifying the net....something switch for the
> > kernel (sorry, forgot the complete switch) will disable the new
> > naming system
> >
> > So, have I gotten everything correctly?
>
> Almost, except you should not specify a name that is also eth[0-9]+
> (what you called 'traditional' name), since it can cause a race
> condition where the kernel and udev fight for the name.  While it used
> to be the case (i.e. <udev-197) that udev tries to handle the race
> condition, the devs has decided to remove those code.
>
> Regards,
>
> Kerwin.

Ah, thanks for the clarification! :-)

So, from now on, for safety I'm going to use a custom naming scheme, like
lan[0-9]+ or wan[0-9]+ or wifi[0-9]+, anything that won't collide with
kernel names of eth[0-9]+

Now I only had to figure out how to rename eth[0-9]+ to the custom naming
scheme when using mdev.

Rgds,
--

[-- Attachment #2: Type: text/html, Size: 4131 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Tanstaafl]

On 2013-04-06 10:40 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Sat, 06 Apr 2013 10:22:49 -0400, Tanstaafl wrote:
>
>> So, other than userland scripts that I created myself and know where
>> they live, where do I search for any files/scripts
>> created/generated/maintained by the system, for references to eth0/1 to
>> change to net0/1? Is it just /etc/conf.d?
>
> /etc/udev/rules.d
>
> Or grep -r 'eth[0-9]' /etc.

Perfect, thanks Neil...

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Bruce Hill]

On Sat, Apr 06, 2013 at 07:11:46PM +0700, Pandu Poluan wrote:
> 
> Ahhh... I think now I understand...
> 
> So. Here's my summarization of the situation:
> 
> * The ethX naming can change, i.e., the interfaces can get out of order
> * So, to fix this, udev decided to use the physical attachment points of
> the NIC in driving a persistent name, a name that will be identical across
> boots as long as there is no hardware change
> * In doing so, it also frees the 'traditional' ethX names to be used
> * If one wants, one can still 'rename' the NICs to the 'traditional' names
> using the 70-*.rules script
> * Doing so (specifying the NICs' names using the 70-*r.rules script) will
> also disable the new 'persistent naming' system -- for the NICs specified
> in the 70-*r.rules file
> * Therefore, users that will be impacted are those that upgraded udev but
> doesn't have the 70-*r.rules, for udev will then assign new names for the
> NICs
> * For these users, specifying the net....something switch for the kernel
> (sorry, forgot the complete switch) will disable the new naming system
> 
> So, have I gotten everything correctly?

Works for me...

mingdao@router ~ $ cat /etc/udev/rules.d/70-persistent-net.rules 
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="68:05:ca:03:05:5d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="68:05:ca:03:05:50", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10de:0x03ef (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f4:6d:04:e8:1d:d9", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"


mingdao@router ~ $ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN 
    link/ether f2:58:cb:48:72:b3 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 68:05:ca:03:05:50 brd ff:ff:ff:ff:ff:ff
    inet 192.168.54.1/24 brd 192.168.54.255 scope global eth0
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 68:05:ca:03:05:5d brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 brd 192.168.100.255 scope global eth1
5: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether f4:6d:04:e8:1d:d9 brd ff:ff:ff:ff:ff:ff
    inet <public IP> brd <munged> scope global eth2

If these NICs don't get assigned correctly, this whole LAN fails.

-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.                                                                                                                                                          
Q: Why is top-posting such a bad thing?                                                                                                                                                                                        
A: Top-posting.                                                                                                                                                                                                                
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Re: Udev update and persistent net rules changes

[ny6p01]

[-- Attachment #1: Type: text/plain, Size: 1848 bytes --]

On Thu, Apr 04, 2013 at 06:37:22PM +0200, J??rg Schaible wrote:
> Neil Bothwick wrote:
> 
> > On Wed, 3 Apr 2013 16:38:28 +0000 (UTC), Grant Edwards wrote:
> > 
> >> > Have you read the news item?
> >> 
> >> Yes.  I found it rather confusing.
> >> 
> >> It refers to a "new format" for rules, but the examples use the exact
> >> same format as the old rules.
> > 
> > Poor choice of terminology there, the format is the same only the chosen
> > namespace is different.
> > 
> >> It talks about how 80-net-name-slot.rules needs to be either an empty
> >> file or a synmlink to /dev/null if you want to disable the new naming
> >> scheme -- but that doesn't seem to be right.  After the upgrade my
> >> 80-net-name-slot.rules file was neither an empty file nor a symlink to
> >> /dev/null, but I'm still getting the same old names.
> > 
> > Do you have a 70-persistent-net.rules file? That would override to give
> > the old names, which is why the news item tells you to change it
> >
> > "If the system still has old network interface renaming rules in
> > /etc/udev/rules.d, like 70-persistent-net.rules, those will need
> > to be either modified or removed."
> 
> I don't have any rules except the 80-* one installed by new udev and I still 
> have the old names - and this has been the case now for 3 machines and I 
> upgrade a 4th right now.

Same behavior here. Rm'd the 70- rules files from udev dir, and it's still
using old device names. 


> 
> >> > It explains why the file should be renamed and also why you should
> >> > change the names in the rules to not use ethN.
> >> 
> >> The only explanation I found was "the old way is now deprecated".
> > 
> > My bad, I thought that was covered in the news item, but it is left to
> > one of the linked pages to explain it.
> 
> - J??rg
> 
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: Udev update and persistent net rules changes

[Grant Edwards]

On 2013-04-06, Pandu Poluan <pandu@poluan.info> wrote:

> Ahhh... I think now I understand...
>
> So. Here's my summarization of the situation:
>
> * The ethX naming can change, i.e., the interfaces can get out of order
> * So, to fix this, udev decided to use the physical attachment points of
> the NIC in driving a persistent name, a name that will be identical across
> boots as long as there is no hardware change
> * In doing so, it also frees the 'traditional' ethX names to be used
> * If one wants, one can still 'rename' the NICs to the 'traditional' names
> using the 70-*.rules script

Wha?  I swear I was told that you could not reliably name the
iterfaces eth[0-n] using udev rules (which is what I've always done
without problems) because of "race conditions".  So I changed over to
net[0-n] on one machine, and was planning on doing so on the others
soon.

Can we still use udev rules to name interfaces eth[0-n] or not?

-- 
Grant Edwards               grant.b.edwards        Yow! I've got an IDEA!!
                                  at               Why don't I STARE at you
                              gmail.com            so HARD, you forget your
                                                   SOCIAL SECURITY NUMBER!!

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

On 04/06/2013 11:06 PM, Grant Edwards wrote:
> On 2013-04-06, Pandu Poluan <pandu@poluan.info> wrote:
> 
>> Ahhh... I think now I understand...
>>
>> So. Here's my summarization of the situation:
>>
>> * The ethX naming can change, i.e., the interfaces can get out of order
>> * So, to fix this, udev decided to use the physical attachment points of
>> the NIC in driving a persistent name, a name that will be identical across
>> boots as long as there is no hardware change
>> * In doing so, it also frees the 'traditional' ethX names to be used
>> * If one wants, one can still 'rename' the NICs to the 'traditional' names
>> using the 70-*.rules script
> 
> Wha?  I swear I was told that you could not reliably name the
> iterfaces eth[0-n] using udev rules (which is what I've always done
> without problems) because of "race conditions".  So I changed over to
> net[0-n] on one machine, and was planning on doing so on the others
> soon.
> 
> Can we still use udev rules to name interfaces eth[0-n] or not?
> 

If and only if there is no device named ethN when you go to name a
device ethN. That's what's meant by 'reliably'.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Walter Dnes]

On Sat, Apr 06, 2013 at 09:46:13PM +0700, Pandu Poluan wrote

> Ah, thanks for the clarification! :-)
> 
> So, from now on, for safety I'm going to use a custom naming scheme,
> like lan[0-9]+ or wan[0-9]+ or wifi[0-9]+, anything that won't
> collide with kernel names of eth[0-9]+
> 
> Now I only had to figure out how to rename eth[0-9]+ to the custom
> naming scheme when using mdev.

  ***UDEV*** has broken using "eth[0-9]".  mdev works just fine, thank
you.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

On Sun, 7 Apr 2013 03:06:30 +0000 (UTC), Grant Edwards wrote:

> Wha?  I swear I was told that you could not reliably name the
> iterfaces eth[0-n] using udev rules (which is what I've always done
> without problems) because of "race conditions".  So I changed over to
> net[0-n] on one machine, and was planning on doing so on the others
> soon.
> 
> Can we still use udev rules to name interfaces eth[0-n] or not?

Yes, just as before. And just as before, you cannot rely on it working
every time.


-- 
Neil Bothwick

<Linuxgeek> How do i find the model of my card?
<Serena[T]> your nick is misleading, seriously

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

On Sun, 7 Apr 2013 00:34:03 -0400, Walter Dnes wrote:

> > Now I only had to figure out how to rename eth[0-9]+ to the custom
> > naming scheme when using mdev.  
> 
>   ***UDEV*** has broken using "eth[0-9]".  mdev works just fine, thank
> you.

udev has broken nothing, it is avoiding the breakage caused by a
fundamentally flawed renaming procedure. Or does mdev have some magic for
for renaming eth0 to eth1 while eth1 already exists?


-- 
Neil Bothwick

Having children will turn you into your parents.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

On Apr 7, 2013 5:59 PM, "Neil Bothwick" <neil@digimed.co.uk> wrote:
>
> On Sun, 7 Apr 2013 00:34:03 -0400, Walter Dnes wrote:
>
> > > Now I only had to figure out how to rename eth[0-9]+ to the custom
> > > naming scheme when using mdev.
> >
> >   ***UDEV*** has broken using "eth[0-9]".  mdev works just fine, thank
> > you.
>
> udev has broken nothing, it is avoiding the breakage caused by a
> fundamentally flawed renaming procedure. Or does mdev have some magic for
> for renaming eth0 to eth1 while eth1 already exists?
>

"Broken" or not is totally depending on the eye of the beholder.

Server SysAdmins *sometimes* need to reboot, and if the name suddenly
changes, that's hell on earth for us.

AFAICT, prior to udev-200, once an interface got assigned an ethX moniker,
it just won't change name unless there's a hardware change. At least,
that's my experience so far.

Rgds,
--

[-- Attachment #2: Type: text/html, Size: 1160 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

On Sun, 7 Apr 2013 22:26:52 +0700, Pandu Poluan wrote:

> > udev has broken nothing, it is avoiding the breakage caused by a
> > fundamentally flawed renaming procedure. Or does mdev have some magic
> > for for renaming eth0 to eth1 while eth1 already exists?
> >  
> 
> "Broken" or not is totally depending on the eye of the beholder.
> 
> Server SysAdmins *sometimes* need to reboot, and if the name suddenly
> changes, that's hell on earth for us.
> 
> AFAICT, prior to udev-200, once an interface got assigned an ethX
> moniker, it just won't change name unless there's a hardware change. At
> least, that's my experience so far.

But that isn't guaranteed. Basically, renaming within the eth namespace
has always had the potential for breakage, whether it worked for you or
not. The fact that for 99% of the time it didn't break doesn't remove
that potential, and a server with multiple NICs is more likely to be
affected than a laptop.

Also, if you believe the breakage won't apply to you, there is nothing to
stop you continuing with your old rules, in fact that is exactly what
udev does if you don't remove them yourself.


-- 
Neil Bothwick

Many husbands go broke on the money their wives save on sales.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

On Sat, Apr 06, 2013 at 10:25:50AM -0400, Tanstaafl wrote:
> On 2013-04-05 4:11 PM, William Hubbs <williamh@gentoo.org> wrote:
> > On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote:
> >> Just dealing with one server and my Linux router, they've been updated to
> >> sys-fs/udev-200 and are both still using the same
> >> /etc/udev/rules.d/70-persistent-net.rules file they've had for over a year,
> >> which was working with udev-171.
> >
> > Do you have your network interface drivers built into the kernel or are
> > they modules?
> 
> I'm very interested in the significance of this question...
> 
> My server is module free, so all drivers are built into the kernel.

The significance is that the kernel determines the eth* name order.
Right now, you are lucky in that the order is what you think it should
be, but if something changes in the kernel causing your cards to be
initialized in a different order, you will not be allowed to swap them
around in the eth* name space, e.g. eth1 can't become eth0 or visa
versa.

That is why it is recommended that you use something like net0, net1,
etc for your interface names.

William

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Tanstaafl]

On 2013-04-07 4:09 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Sat, Apr 06, 2013 at 10:25:50AM -0400, Tanstaafl wrote:
>> On 2013-04-05 4:11 PM, William Hubbs <williamh@gentoo.org> wrote:
>>> Do you have your network interface drivers built into the kernel or are
>>> they modules?
>>
>> I'm very interested in the significance of this question...
>>
>> My server is module free, so all drivers are built into the kernel.
>
> The significance is that the kernel determines the eth* name order.
> Right now, you are lucky in that the order is what you think it should
> be, but if something changes in the kernel causing your cards to be
> initialized in a different order, you will not be allowed to swap them
> around in the eth* name space, e.g. eth1 can't become eth0 or visa
> versa.
>
> That is why it is recommended that you use something like net0, net1,
> etc for your interface names.

Wow... that is actually what I was thinking it meant, but wasn't sure...

Thanks for the validation!

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Bruce Hill]

On Sun, Apr 07, 2013 at 03:09:43PM -0500, William Hubbs wrote:
> On Sat, Apr 06, 2013 at 10:25:50AM -0400, Tanstaafl wrote:
> > On 2013-04-05 4:11 PM, William Hubbs <williamh@gentoo.org> wrote:
> > > On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote:
> > >> Just dealing with one server and my Linux router, they've been updated to
> > >> sys-fs/udev-200 and are both still using the same
> > >> /etc/udev/rules.d/70-persistent-net.rules file they've had for over a year,
> > >> which was working with udev-171.
> > >
> > > Do you have your network interface drivers built into the kernel or are
> > > they modules?
> > 
> > I'm very interested in the significance of this question...
> > 
> > My server is module free, so all drivers are built into the kernel.
> 
> The significance is that the kernel determines the eth* name order.
> Right now, you are lucky in that the order is what you think it should
> be, but if something changes in the kernel causing your cards to be
> initialized in a different order, you will not be allowed to swap them
> around in the eth* name space, e.g. eth1 can't become eth0 or visa
> versa.
> 
> That is why it is recommended that you use something like net0, net1,
> etc for your interface names.

Thanks for your reply. After 10 years of eth* it's going to be hard to make a
change until the kernel does this, also.

Bruce
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.                                                                                                                                                          
Q: Why is top-posting such a bad thing?                                                                                                                                                                                        
A: Top-posting.                                                                                                                                                                                                                
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Michael Mol]

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

On 04/08/2013 11:04 AM, Bruce Hill wrote:
> On Sun, Apr 07, 2013 at 03:09:43PM -0500, William Hubbs wrote:
>> On Sat, Apr 06, 2013 at 10:25:50AM -0400, Tanstaafl wrote:
>>> On 2013-04-05 4:11 PM, William Hubbs <williamh@gentoo.org> wrote:
>>>> On Fri, Apr 05, 2013 at 02:38:21PM -0500, Bruce Hill wrote:
>>>>> Just dealing with one server and my Linux router, they've been updated to
>>>>> sys-fs/udev-200 and are both still using the same
>>>>> /etc/udev/rules.d/70-persistent-net.rules file they've had for over a year,
>>>>> which was working with udev-171.
>>>>
>>>> Do you have your network interface drivers built into the kernel or are
>>>> they modules?
>>>
>>> I'm very interested in the significance of this question...
>>>
>>> My server is module free, so all drivers are built into the kernel.
>>
>> The significance is that the kernel determines the eth* name order.
>> Right now, you are lucky in that the order is what you think it should
>> be, but if something changes in the kernel causing your cards to be
>> initialized in a different order, you will not be allowed to swap them
>> around in the eth* name space, e.g. eth1 can't become eth0 or visa
>> versa.
>>
>> That is why it is recommended that you use something like net0, net1,
>> etc for your interface names.
> 
> Thanks for your reply. After 10 years of eth* it's going to be hard to make a
> change until the kernel does this, also.

No kidding. There's almost 30 years' documentation out there that
assumes 'eth0' is the interface you care about, except in cases where
you care about 'eth0' and 'eth1'.

As far as the kernel namespace issue...there needs to be a different
namespace between what the kernel defines and what udev can control; at
the moment, if you define your own NIC names (say, wan1, wan2), there's
a chance that a kernel driver will stomp on it if you start using a card
that has a driver that likes that numbering scheme.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-user] Re: Udev update and persistent net rules changes

[Bruce Hill]

On Sun, Apr 07, 2013 at 03:09:43PM -0500, William Hubbs wrote:
> 
> The significance is that the kernel determines the eth* name order.
> Right now, you are lucky in that the order is what you think it should
> be, but if something changes in the kernel causing your cards to be
> initialized in a different order, you will not be allowed to swap them
> around in the eth* name space, e.g. eth1 can't become eth0 or visa
> versa.
> 
> That is why it is recommended that you use something like net0, net1,
> etc for your interface names.
> 
> William

This doesn't seem consistent with my experience. The reason that I edited the
70-persistent-net.rules file to begin with is to make the NICs whatever eth* I
wanted, regardless of the order the kernel loaded them. Since the modules are
built-in, and both NICs use the same module, I think this won't change.

The server has two built-in NICs. One is being used to connect it to the
switch, and the other is not in use (backup). One has ID 1 and the other ID 2.
The kernel was loading the one with the higher MAC address first, and the
lower MAC address second. The lower MAC number is the one with the stamp ID 1
on the back of the server, so I edited the rules file to load it always as
eth1 so my /etc/conf.d/net can use static IPs (like everything wired on the
LAN); because the ethernet cable is connected from ID 1 to the switch. Thus:

server ~ # dmesg | grep -i eth
[   11.691830] tg3 0000:03:00.0: eth0: Tigon3 [partno(BCM95721) rev 4101] (PCI Express) MAC address 00:d0:68:0b:87:67
[   11.691985] tg3 0000:03:00.0: eth0: attached PHY is 5750 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[   11.692192] tg3 0000:03:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1]
[   11.692340] tg3 0000:03:00.0: eth0: dma_rwctrl[76180000] dma_mask[64-bit]
[   11.699283] tg3 0000:02:00.0: eth1: Tigon3 [partno(BCM95721) rev 4101] (PCI Express) MAC address 00:d0:68:0b:87:66
[   11.699439] tg3 0000:02:00.0: eth1: attached PHY is 5750 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[   11.699591] tg3 0000:02:00.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[   11.699738] tg3 0000:02:00.0: eth1: dma_rwctrl[76180000] dma_mask[64-bit]
[   82.703869] tg3 0000:02:00.0: eth1: Link is up at 1000 Mbps, full duplex
[   82.703875] tg3 0000:02:00.0: eth1: Flow control is off for TX and off for RX
server ~ # cat /etc/udev/rules.d/70-persistent-net.rules 
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:d0:68:0b:87:66", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x14e4:0x1659 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:d0:68:0b:87:67", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

server ~ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:d0:68:0b:87:67 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:d0:68:0b:87:66 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.3/24 brd 192.168.100.255 scope global eth1


The Linux router has 3 NICs in use. Two of them are identical Intel cards. It
controls 3 networks, and there's a backup NIC of the same brand. So it's
important for me to know the assignment of them, and again,
70-persistent-net.rules allows me to keep the ordered according to MAC
address:

router log # zgrep -i eth* kern.log-20130326.gz
Mar 25 18:31:47 router kernel: [    1.434939] pata_amd 0000:00:06.0: setting latency timer to 64
Mar 25 18:31:47 router kernel: [    1.436360] e1000e: Intel(R) PRO/1000 Network Driver - 1.9.5-k
Mar 25 18:31:47 router kernel: [    1.437229] e1000e 0000:02:00.0: (unregistered net_device): Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
Mar 25 18:31:47 router kernel: [    1.540889] e1000e 0000:02:00.0: eth0: (PCI Express:2.5GT/s:Width x1) 68:05:ca:03:05:50
Mar 25 18:31:47 router kernel: [    1.541039] e1000e 0000:02:00.0: eth0: Intel(R) PRO/1000 Network Connection
Mar 25 18:31:47 router kernel: [    1.541185] e1000e 0000:02:00.0: eth0: MAC: 3, PHY: 8, PBA No: E46981-007
Mar 25 18:31:47 router kernel: [    1.542263] e1000e 0000:03:00.0: (unregistered net_device): Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
Mar 25 18:31:47 router kernel: [    1.644050] e1000e 0000:03:00.0: eth1: (PCI Express:2.5GT/s:Width x1) 68:05:ca:03:05:5d
Mar 25 18:31:47 router kernel: [    1.644196] e1000e 0000:03:00.0: eth1: Intel(R) PRO/1000 Network Connection
Mar 25 18:31:47 router kernel: [    1.644345] e1000e 0000:03:00.0: eth1: MAC: 3, PHY: 8, PBA No: E46981-007
Mar 25 18:31:47 router kernel: [    1.644806] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.64.
Mar 25 18:31:47 router kernel: [    1.645462] forcedeth 0000:00:07.0: setting latency timer to 64
Mar 25 18:31:47 router kernel: [    1.705185] forcedeth 0000:00:07.0: ifname eth2, PHY OUI 0x732 @ 1, addr f4:6d:04:e8:1d:d9
Mar 25 18:31:47 router kernel: [    1.705326] forcedeth 0000:00:07.0: highdma pwrctl mgmt gbit lnktim msi desc-v3
Mar 25 18:31:47 router kernel: [    1.705851] ehci_hcd 0000:00:02.1: setting latency timer to 64
Mar 25 18:31:47 router kernel: [    1.714810] hub 1-0:1.0: 10 ports detected
Mar 25 18:31:47 router kernel: [    1.715266] ohci_hcd 0000:00:02.0: setting latency timer to 64
Mar 25 18:31:47 router kernel: [    1.769859] hub 2-0:1.0: 10 ports detected
Mar 25 18:31:47 router kernel: [    1.773762] rtc0: alarms up to one year, y3k, 114 bytes nvram, hpet irqs
Mar 25 18:31:47 router kernel: [    1.777459] Netfilter messages via NETLINK v0.30.
Mar 25 18:31:47 router kernel: [    1.777746] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
Mar 25 18:31:47 router kernel: [    1.778444] ctnetlink v0.93: registering with nfnetlink.
Mar 25 18:31:47 router kernel: [    1.778660] ip_tables: (C) 2000-2006 Netfilter Core Team
Mar 25 18:31:47 router kernel: [    1.779172] NET: Registered protocol family 17
Mar 25 18:31:47 router kernel: [   16.553800] forcedeth 0000:00:07.0: irq 49 for MSI/MSI-X
Mar 25 18:31:47 router kernel: [   16.553824] forcedeth 0000:00:07.0: eth2: MSI enabled
Mar 25 18:31:50 router kernel: [   19.165275] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Mar 25 18:31:50 router kernel: [   19.441463] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

router log # cat /etc/udev/rules.d/70-persistent-net.rules 
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="68:05:ca:03:05:5d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x10d3 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="68:05:ca:03:05:50", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10de:0x03ef (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f4:6d:04:e8:1d:d9", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
router log # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN 
    link/ether f2:58:cb:48:72:b3 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 68:05:ca:03:05:50 brd ff:ff:ff:ff:ff:ff
    inet 192.168.54.1/24 brd 192.168.54.255 scope global eth0
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 68:05:ca:03:05:5d brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 brd 192.168.100.255 scope global eth1
5: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether f4:6d:04:e8:1d:d9 brd ff:ff:ff:ff:ff:ff
    inet <public IP> brd <munged> scope global eth2

If you can show me where my reasoning is technically wrong, and why/what
should be changed, I'm open to learn. At this point I don't see the kernel
messing up my setup(s).

Thanks,
Bruce
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.                                                                                                                                                          
Q: Why is top-posting such a bad thing?                                                                                                                                                                                        
A: Top-posting.                                                                                                                                                                                                                
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting