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

[Nuno J. Silva (aka njsg)]

On 2013-03-30, Tanstaafl <tans...@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/

[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

[Nuno J. Silva (aka njsg)]

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 J. Silva (aka njsg)]

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.

[Pandu Poluan]

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

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

[Nuno J. Silva (aka njsg)]

On 2013-03-31, Dale <rdale...@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.

[Dale]

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.

[Nuno J. Silva (aka njsg)]

On 2013-03-31, Dale <rdale...@gmail.com> wrote:
> Nuno J. Silva (aka njsg) wrote:
>> On 2013-03-31, Dale <rdale...@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.

[Dale]

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.

[Alan McKinnon]

On 31/03/2013 20:26, Dale wrote:
> Nuno J. Silva (aka njsg) wrote:
>> On 2013-03-31, Dale <rdale...@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.m...@gmail.com

[Kevin Chadwick]

On Sun, 31 Mar 2013 11:48:19 +0000 (UTC)
"Nuno J. Silva (aka njsg)" <nunoj...@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.

[Neil Bothwick]

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

[Dale]

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.

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


--
Neil Bothwick

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

[Michael Mol]

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

[Tanstaafl]

On 2013-03-31 3:37 PM, Neil Bothwick <ne...@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 ?

[Kevin Chadwick]

On Sun, 31 Mar 2013 20:55:00 +0100
Neil Bothwick <ne...@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.

[Nuno J. Silva (aka njsg)]

On 2013-03-31, Neil Bothwick <ne...@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.

[Mick]

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

[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

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

[Pandu Poluan]

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

[Neil Bothwick]

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!

[Neil Bothwick]

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.

[Pandu Poluan]

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

[Neil Bothwick]

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.

[Neil Bothwick]

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!

[Neil Bothwick]

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

[Michael Mol]

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

[Kevin Chadwick]

On Mon, 1 Apr 2013 14:12:17 +0100
Neil Bothwick <ne...@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.

[Neil Bothwick]

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!

[Michael Mol]

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. :)

[»Q«]

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

[William Hubbs]

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

[Michael Mol]

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.

[Dale]

+1  Happy I am.  lol

[Peter Humphrey]

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

 

[Paul Hartman]

On Mon, Apr 1, 2013 at 7:00 PM, Peter Humphrey <pe...@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.

[Alan McKinnon]

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.m...@gmail.com

[Jarry]

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.

[Tanstaafl]

On 2013-04-02 3:21 PM, Jarry <mr.j...@gmail.com> wrote:
> On 02-Apr-13 21:13, Paul Hartman wrote:
>> On Mon, Apr 1, 2013 at 7:00 PM, Peter Humphrey
>> <pe...@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.

[Alan McKinnon]

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.m...@gmail.com

[Grant Edwards]

On 2013-04-02, Alan McKinnon <alan.m...@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 --

[Alan McKinnon]

On 02/04/2013 22:31, Grant Edwards wrote:
> On 2013-04-02, Alan McKinnon <alan.m...@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.m...@gmail.com

[Marc Joliet]

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

> On 2013-04-02, Alan McKinnon <alan.m...@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

[Marc Joliet]

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

> Am Tue, 2 Apr 2013 20:31:10 +0000 (UTC)
> schrieb Grant Edwards <grant.b...@gmail.com>:
>
> > On 2013-04-02, Alan McKinnon <alan.m...@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.

[Neil Bothwick]

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!

[Grant Edwards]

On 2013-04-02, Neil Bothwick <ne...@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

[Neil Bothwick]

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

> On 2013-04-02, Neil Bothwick <ne...@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.

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

[Grant Edwards]

On 2013-04-03, Neil Bothwick <ne...@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!

[Lee]

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.

[Jörg Schaible]

Hi,

Grant Edwards wrote:

> On 2013-04-03, Neil Bothwick <ne...@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

[Bruce Hill]

> - 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 ^^
sup...@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

[Mick]

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

[Nuno J. Silva (aka njsg)]

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

[Nuno J. Silva (aka njsg)]

On 2013-04-02, Alan McKinnon <alan.m...@gmail.com> 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...

[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.m...@gmail.com

[Tanstaafl]

On 2013-04-04 5:13 AM, Alan McKinnon <alan.m...@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?

[Grant Edwards]

On 2013-04-03, Mick <michael...@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 ...

[Michael Mol]

On 04/04/2013 10:59 AM, Grant Edwards wrote:
> On 2013-04-03, Mick <michael...@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.

[Neil Bothwick]

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!

[Neil Bothwick]

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.

[Bruce Hill]

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,

[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

[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 <walt...@waltdnes.org>
I don't run "desktop environments"; I run useful applications

[Tanstaafl]

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

[William Hubbs]

On Thu, Apr 04, 2013 at 09:07:00AM -0400, Tanstaafl wrote:
> On 2013-04-04 5:13 AM, Alan McKinnon <alan.m...@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

[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)...

[William Hubbs]

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

[Tanstaafl]

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

[William Hubbs]

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.

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

[William Hubbs]

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

[William Hubbs]

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

[Bruce Hill]

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

[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)?

[Neil Bothwick]

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?

[Mick]

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

[Pandu Poluan]

On Apr 6, 2013 3:44 PM, "Neil Bothwick" <ne...@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,
--

[kwk...@hkbn.net]

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

> On Apr 6, 2013 3:44 PM, "Neil Bothwick" <ne...@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.

[Tanstaafl]

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?

[Tanstaafl]

On 2013-04-06 8:31 AM, kwk...@hkbn.net <kwk...@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?

[Neil Bothwick]

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.

[Pandu Poluan]

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

[Tanstaafl]

On 2013-04-06 10:40 AM, Neil Bothwick <ne...@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...

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

[ny6...@gmail.com]

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

[Grant Edwards]

On 2013-04-06, Pandu Poluan <pa...@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!!

[Michael Mol]

On 04/06/2013 11:06 PM, Grant Edwards wrote:
> On 2013-04-06, Pandu Poluan <pa...@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'.

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

[Neil Bothwick]

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

[Neil Bothwick]

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.

[Pandu Poluan]

On Apr 7, 2013 5:59 PM, "Neil Bothwick" <ne...@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,
--

[Neil Bothwick]

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.

[Tanstaafl]

On 2013-04-07 4:09 PM, William Hubbs <will...@gentoo.org> 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.

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

Thanks for the validation!

[William Hubbs]

On Sat, Apr 06, 2013 at 10:25:50AM -0400, Tanstaafl 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

[Bruce Hill]

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