Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
predictable network interface names
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
dbishop
n00b
n00b


Joined: 08 Dec 2007
Posts: 56

PostPosted: Tue Apr 16, 2013 2:09 pm    Post subject: Reply with quote

@py-ro:

I beg to differ. Replacing a NIC involves more than just plugging it in. There's the obvious issue of breaking down the hardware to install or replace the NIC. And with the new naming scheme you have to put the new card in the same slot. And if you've availed yourself of the MAC naming which seems to be in the new scheme very prominently, well, then, oops.

This is not xenophobia. There are real fundamental logic flaws in all this:

Logic Flaw #1. If you add a NIC, all bets are off since the new card may be earlier in the PCI slot numbering scheme than desirable. This is what has happened to me. You may find that default behaviour is seriously altered and things don't work -- exactly the disaster scenario you said this prevents.

Logic Flaw #2: If you add a new card, you have to add the new driver (unless you've built them ALL preemptively into the kernel, just in case, like Windows does...). So it's never just plug-and-play.

Logic Flaw #3: Writing one line to a list of two or three other udev-rules is inferior to rewriting iptables rules, routing tables, and whatnot to override default behaviour and preserve the ideal that interface numbers derived from the hardware bus (somewhat random itself) is better than a fixed algorithm that numbers them.

Logic Flaw #4: That if the interface name remains the same, nothing can happen that will make a working configuration fail if new hardware is added or old hardware is changed. Anyone who thinks that should immediately one giant step back from their keyboards. They are not qualified.

I have three or four more, but I am tired now. Absent a sane way to order the interface-up sequence in net.whatever, I am going back to my aptly-named sysinit-level runscript called fixudevnightmare and go back to calling everything eth*. This is udev megalomania just ridiculous.
Back to top
View user's profile Send private message
dbishop
n00b
n00b


Joined: 08 Dec 2007
Posts: 56

PostPosted: Tue Apr 16, 2013 2:11 pm    Post subject: Reply with quote

@py-ro:

Quote:
Sorry, but can't you just define the order/dependencies in /etc/rc.conf?


Ah perfect! If this is so, please advise how! That's all I was asking!
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2083
Location: Dallas area

PostPosted: Tue Apr 16, 2013 2:18 pm    Post subject: Reply with quote

One can copy udev-171-* to the local portage tree (include virtual/udev-171) and
mask anything beyond it.
*Needs to be put in the local portage tree as it is slated for removal by the gentoo devs *

A/o right now, I have udev-171-r6 installed and it is working fine with kernel 3.8.5

Note: Yes, I'm aware that udev-171* might stop working in the future,
but I have no guarantees that udev-19*/udev-20* won't do the same.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.9.1-zen, eudev
glibc-2.17, gcc-4.7.3-r1, xorg-server-1.15, lxde, nouveau, oss4
Back to top
View user's profile Send private message
miket
Apprentice
Apprentice


Joined: 28 Apr 2007
Posts: 173
Location: Gainesville, FL, USA

PostPosted: Tue Apr 16, 2013 2:40 pm    Post subject: Reply with quote

Anon-E-moose wrote:
One can copy udev-171-* to the local portage tree (include virtual/udev-171) and
mask anything beyond it.
*Needs to be put in the local portage tree as it is slated for removal by the gentoo devs *

A/o right now, I have udev-171-r6 installed and it is working fine with kernel 3.8.5

Note: Yes, I'm aware that udev-171* might stop working in the future,
but I have no guarantees that udev-19*/udev-20* won't do the same.


That's the place to be until/unless someone "helpfully" pulls it from the tree.

Then we'd be up a tree.
Back to top
View user's profile Send private message
py-ro
Veteran
Veteran


Joined: 24 Sep 2002
Posts: 1368
Location: St. Wendel

PostPosted: Tue Apr 16, 2013 2:47 pm    Post subject: Reply with quote

Quote:
@py-ro:

Logic Flaw #1. If you add a NIC, all bets are off since the new card may be earlier in the PCI slot numbering scheme than desirable. This is what has happened to me. You may find that default behaviour is seriously altered and things don't work -- exactly the disaster scenario you said this prevents.


K, give you that.

Quote:

Logic Flaw #2: If you add a new card, you have to add the new driver (unless you've built them ALL preemptively into the kernel, just in case, like Windows does...). So it's never just plug-and-play.


In most cases you will use a specific set of cards and won't mix too much chips up, atleast we don't do this. We keep a stock of two kinds of cards.

Quote:

Logic Flaw #3: Writing one line to a list of two or three other udev-rules is inferior to rewriting iptables rules, routing tables, and whatnot to override default behaviour and preserve the ideal that interface numbers derived from the hardware bus (somewhat random itself) is better than a fixed algorithm that numbers them.


There was no fixed algorithm to number them, the new mechanism is not perfect, but less random then the oldone IMHO.

Quote:

Logic Flaw #4: That if the interface name remains the same, nothing can happen that will make a working configuration fail if new hardware is added or old hardware is changed. Anyone who thinks that should immediately one giant step back from their keyboards. They are not qualified.


Sure you can break any system by changes, intended or not, but in most cases you won't do too much changes on a production system, atleast you should not, same reason as mentionend.

Quote:

I have three or four more, but I am tired now. Absent a sane way to order the interface-up sequence in net.whatever, I am going back to my aptly-named sysinit-level runscript called fixudevnightmare and go back to calling everything eth*. This is udev megalomania just ridiculous.


We were naming our Interfaces by function with our own naming scheme way before and nobody prevents anybody to ommit the change or do his own thinggy.

EDIT: Fixed quoting
Back to top
View user's profile Send private message
miket
Apprentice
Apprentice


Joined: 28 Apr 2007
Posts: 173
Location: Gainesville, FL, USA

PostPosted: Tue Apr 16, 2013 2:57 pm    Post subject: Reply with quote

py-ro wrote:
We were naming our Interfaces by function with our own naming scheme way before and nobody prevents anybody to ommit the change or do his own thinggy.

Ah, that's the sane way to use names other than eth0; the new "predictable" pattern is in fact unpredictable. Your organization has gone with a predictable pattern. Good for you. You didn't need new udev to do it.
Back to top
View user's profile Send private message
dbishop
n00b
n00b


Joined: 08 Dec 2007
Posts: 56

PostPosted: Tue Apr 16, 2013 3:02 pm    Post subject: Reply with quote

@py-ro:

My original post here included this:
Quote:
I was thinking the answer would be in something like RC_NEED=... (or some such) put some where that provoked the Gentoo start scripts to call the new names in a specific order.


Clearly, I have been asking this all along. Many, many innocent database bytes could have been spared if we didn't get mired in udev-mania. *sigh*

@Anon-E-moose
I also wrote this a little later on:

Quote:
As I have read all these threads several times (and had even masked >udev171 until just recently in silent protest) it is clear to me that something like 70-persistent-net.rules is really the only way.


It's bizarre how simple the question I asked really was, and that all this is because I have been trying to "go along to get along" with all the new udev naming nonsense. It is clear that the new 'persistent names' idea was ill-conceived, poorly designed, even more poorly pushed out, and then in the end achieves none of its original design goals. Rather, it's wreaked havoc.

Here's a clue: Changing hardware necessitates changing software, since software is the final customization of the hardware. It is definitional. Writing tons of complicated preemption code that expects to anticipate every imaginable permutation and change so that the "idiot end user" is relieved of the burden of thinking is both foolishness and recklessness. Anyone software engineer who believes otherwise should change careers. It is hubris and elitist at its most off-putting level.

Maybe we should just call it "Obamacare for Linux".
Back to top
View user's profile Send private message
dbishop
n00b
n00b


Joined: 08 Dec 2007
Posts: 56

PostPosted: Tue Apr 16, 2013 3:34 pm    Post subject: Reply with quote

@py-ro:

I have no desire to keep bickering. I really would prefer if you know what I should put in rc.conf, please just tell me. Or tell me where to go look to figure it out myself.

But, because I can't resist the fun:


First, my machine that this happened to was/is a production machine. I didn't change a thing nor did I want to. The new udev and the kooky persistent naming thing broke it, not any change I made. I have simply been cleaning up the mess it made.

Second, you are a little off-center when you write that everyone should use two NIC types. Which two? Your two? Are you kidding? I guess we'd better tell the hardware guys we only need two from now on, thanks.

Third, while it is true, I could never predict what would be eth0, eth1, etc until each machine started for the first time, they never ever changed. therefore it was not difficult using udev rules to make them whatever I wanted them to be, and they never changed either. So saying that there was no one fixed algorithm, you are wrong. Every combination of hardware gave consistent and repeatable numbering. And then it never changed unless I changed the hardware, and in that case making it back into exactly what I wanted was equally simple and straightforward. I don't know what all the persistent-name zealots are drinking, but this was clearly much more predictable and much more controllable that this new mess.

Fourth, what could be more ironic than a system that calls itself "persistent naming" than one that presents you three, or four, or five to choose from? And as I wrote earlier, one of the choices is based on mac addresses! Do you have only two mac addresses to choose from too? You are killin' me...

Fifth -- I could not care less what interfaces are named (in theory). My issue is that the cards are not being named in an order that brings them up in a way allows me to use default routing algorithms. With things this "new better way" is forcing me to write a ton of routing rules in post-up patches. It has nothing to do with calling them by names that tickle me. Subverting this issue is allowing everyone to trot out all these strawman arguments and misdirect for whatever reason. I am really just trying to control which interface comes up first, second and third in the boot process. It used to be easy, now it's a nightmare.

I don't know how to be more clear or more logical.


I could go on, but I have a machine to fix...
Back to top
View user's profile Send private message
miket
Apprentice
Apprentice


Joined: 28 Apr 2007
Posts: 173
Location: Gainesville, FL, USA

PostPosted: Tue Apr 16, 2013 3:49 pm    Post subject: Folsom Udev Blues Reply with quote

With apologies to Johnny Cash.

Code:
I see the train a-coming
It's coming round the bend
Hey! It's on the same track I'm on
Don't tell me it's the end!

I'm cruising to disaster
On this udev-using line.
I'm gonna get myself of this track
While I still have the time.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2083
Location: Dallas area

PostPosted: Tue Apr 16, 2013 4:26 pm    Post subject: Reply with quote

Calling the new way predictable is somewhat true, calling it persistent isn't.

If I change slots or in the case of usb adapters, a port, then the name changes, maybe predictable, but certainly not persistent.

The old way ala 171 was to use the mac addr, not necessarily predictable but persistent,
if I changed slot or usb port it would still see the mac addr.

Under 171 I could have named my device don0, don1, etc.
The same as I can now. So no real benefit in the new way over the old.

Under the old way, if I only had one card, then I got eth0 and it worked without the need to ask why or try and change my firewall rules,
and other scripts that depend (by default) on eth0.

Yes under the old way, if I changed cards because the one I had died, then I had to modify the rules, as the mac addr changed
the same thing holds true under the new one (supposedly putting a new/different card) in the same slot yields the same name,
but AFAIK that's anecdotal, not tested.

So the end result is tons of brouhaha, many threads started, and much angst over something that should never have been an issue.
End result lots of pain, hardly any gain.

JMHO
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.9.1-zen, eudev
glibc-2.17, gcc-4.7.3-r1, xorg-server-1.15, lxde, nouveau, oss4
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3782

PostPosted: Tue Apr 16, 2013 6:23 pm    Post subject: Reply with quote

miket wrote:
mv wrote:
You would have to convince Linus, probably several other kernel developers, Sievers and Poettering. Good luck :)

Poettering, at least, is not a kernel developer. Thank God.

It was meant as an enumeration: You have to convince four (groups of) people who are usually very hard to convince. In theory, this might be possible, in practice your suggestion is already doomed.
Back to top
View user's profile Send private message
Aiken
Tux's lil' helper
Tux's lil' helper


Joined: 22 Jan 2003
Posts: 112
Location: Toowoomba/Australia

PostPosted: Tue Apr 16, 2013 9:33 pm    Post subject: Reply with quote

Keep in mind this also affects usb networking gear. One thing that had been nice about usb was plug a device into a free port and start using it. With the new naming scheme depending on what is being done things like hostapd, wicd and firewall scripts could be broken multiple times a day. The annoying bit is having to take extra steps to get back the old and (for me) predictable behaviour.
_________________
Beware the grue.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2384

PostPosted: Wed Apr 17, 2013 12:32 pm    Post subject: Reply with quote

Having watched and been annoyed by this whole thing since it started, something finally crystallized in my mind a few moments ago...

The only truly stable thing about network devices is the MAC - period.

I hadn't realized until seeing other entries here that the PCI ID of one card could change based on other cards being plugged in, and hadn't thought through that scenario for USB, but there it's more obvious.

Given that, calling anything "persistent and predictable network device names" based on anything but the MAC is just plain wrong, and never had a chance of being right, at least not until those screws on the case are replaced by a lock and the USB ports expoxied.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3782

PostPosted: Wed Apr 17, 2013 3:08 pm    Post subject: Reply with quote

depontius wrote:
The only truly stable thing about network devices is the MAC - period

And this is not stable, either: I remember many angry comments in the beginning of udev when people expected eth0/wlan0 to remain when they had only one device and exchanged this device by another (with another MAC, of course). In a sense, these people were right: If there is only one device, connected in the same way as previously, why should it have another number?
I am afraid that there is not universal solution which works in all use cases... simply the idea of persistency and hotplug capability contradict each other.
This is why I consider the net*/wnet* solution the best: You can adapt it to your needs by writing your own rules. E.g. if you know that you will never have anything else than your eth0 in a pci slot, you can just hard-encode that eth* from pci should be named net0, and if you know that you will never have more than one wlan in an usb port you can hard-code that wlan* from usb should be names wnet0.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2384

PostPosted: Wed Apr 17, 2013 3:23 pm    Post subject: Reply with quote

Until you replace the network card, the MAC is stable. What others have been saying is that with the current default, changing other hardware can cause the network device name to change. I agree that using the MAC changing the network card would change the device name, but at least changing the sound card won't.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 2276
Location: Canada

PostPosted: Wed Apr 17, 2013 3:52 pm    Post subject: Reply with quote

depontius wrote:
Until you replace the network card, the MAC is stable. What others have been saying is that with the current default, changing other hardware can cause the network device name to change. I agree that using the MAC changing the network card would change the device name, but at least changing the sound card won't.


But, for this discussion, MAC has an opposite problem - it is TOO specific. That is, there is no chance that your script will work on another, even identical, machine without modification, if it is based on MAC address (*) Basing network interface name on MAC essentially equates the two - imagine firewall rules with hardcoded MAC - that's what you'll get. In essence you are hardcoding manufacturers serial numbers. And the point of network interface names is actaully to provide some level of abstraction from being purely hardware descriptors.

(*) it make me shiver to think of a class of 100 identical desktops where one would need to adjust scripts for every single one.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2384

PostPosted: Wed Apr 17, 2013 4:55 pm    Post subject: Reply with quote

On another thread I suggested that, wrapped in udev syntactic sugar, we needed a mapping of network MACs to device names, done kind of like the "good old way", or at least what I remembered as the good old way for /dev/dvd and /dev/cdrom - I never got that involved with networking - until udev-200. The first boot with a new piece of hardware would add a line to a different rule giving persistent names.

With that kind of sceme we could have our eth0, eth1, wlan0, etc, and as long as that card remained, it would get its name - in spite of any other plugging and unplugging.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
miket
Apprentice
Apprentice


Joined: 28 Apr 2007
Posts: 173
Location: Gainesville, FL, USA

PostPosted: Wed Apr 17, 2013 6:11 pm    Post subject: Reply with quote

dmpogo wrote:
But, for this discussion, MAC has an opposite problem - it is TOO specific. That is, there is no chance that your script will work on another, even identical, machine without modification, if it is based on MAC address (*) Basing network interface name on MAC essentially equates the two - imagine firewall rules with hardcoded MAC - that's what you'll get. In essence you are hardcoding manufacturers serial numbers. And the point of network interface names is actaully to provide some level of abstraction from being purely hardware descriptors.

(*) it make me shiver to think of a class of 100 identical desktops where one would need to adjust scripts for every single one.

Actually, this is where basing things on the PCI address makes more sense: rather than trigger the udev rule on the specific MAC address, one could go simply with device class and PCI slot--or even a small range of slots. This would have trouble, of course, if there are multiple NIC's of the class which have different roles: you might be back to MAC addresses, or you could go in the direction of making a rule like "LAN-facing NIC's go into slot 0 or 1 and WAN-facing NIC's go into slot 2 or 3".

This makes life *much* happier if you are provisioning bunches of hosts.

Don't mistake this for any advocacy for names of the insane pattern enpXxsYY. The target names ought to be of patterns like lan0, wan0, or, drum-roll, eth0. That makes things much better for other software in the system, including init scripts.
Back to top
View user's profile Send private message
gentoo_newguy
Guru
Guru


Joined: 10 Oct 2006
Posts: 539

PostPosted: Wed Apr 17, 2013 7:50 pm    Post subject: Reply with quote

Hi guys im really stuck reading through this it just makes no sense to me .

is there a simple way to have my network devices back to how they were

i have tried net.ifnames=o on the command line and that is not working.

wpa_supplicant is giving me some weird error when trying to start

lots of ioctil[siociwpmksa] invalid arguments going on

any ideas what this is ??
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3782

PostPosted: Wed Apr 17, 2013 8:20 pm    Post subject: Reply with quote

depontius wrote:
With that kind of sceme we could have our eth0, eth1, wlan0, etc, and as long as that card remained, it would get its name

No, it wouldn't, at least not reliably: udev would have to rename eth* to another eth* (depending on the previous rules and on the order in which the kernel initializes the drivers) - which is what udev did before but which is subject to a race condition: While udev is renaming the kernel could want to add the same device. If you want it in such a way, but reliably, you would still need to rename to e.g. net* which is not in danger to interfere with kernel names.
That being said, if you want to keep the automatic persistent-* generation you can have it if you switch to eudev instead of udev.
Back to top
View user's profile Send private message
khayyam
Veteran
Veteran


Joined: 07 Jun 2012
Posts: 1533

PostPosted: Wed Apr 17, 2013 8:32 pm    Post subject: Reply with quote

gentoo_newguy wrote:
is there a simple way to have my network devices back to how they were

gentoo_newguy ... yes, don't use udev use the eudev package. By *default* eudev keeps the old naming convention, and allows you to use the new naming schema if you so wish. Otherwise, read all the threads, news items, upgrade guides, etc, symlink what-have-you to /dev/null, write some udev rule ... take your pick.

gentoo_newguy wrote:
i have tried net.ifnames=o on the command line and that is not working.

I imagine this should be a "0" (zero, naught) and not an "o" (ohhhwww), and when you say "command line" you do mean passed to the kernel (ie, via grub, or you bootloader)?

gentoo_newguy wrote:
wpa_supplicant is giving me some weird error when trying to start lots of ioctil[siociwpmksa] invalid arguments going on, any ideas what this is??

Sounds as though wpa_supplicant is passed a interface name as a parameter that it can't translate into an actual device.

best ... khay
Back to top
View user's profile Send private message
gentoo_newguy
Guru
Guru


Joined: 10 Oct 2006
Posts: 539

PostPosted: Wed Apr 17, 2013 9:11 pm    Post subject: Reply with quote

Solved the ioctil[siociwpmksa] invalid arguments by switching my wifi switch on and off

how do i switch from udev to eudev ?

Afriad i didnt mean passed to the bootloader im guessing thats where it needs to be ? and yes u were correct i was trying a 0 and not o

This is so confusing :(
Back to top
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 7397
Location: Somewhere over Atlanta, Georgia

PostPosted: Wed Apr 17, 2013 9:31 pm    Post subject: Reply with quote

I'm actually going to try this tonight. Since virtual/udev is satisfied by any of udev, systemd, and eudev, it should be approximately as simple as this:
  • Keyword eudev.
  • Unmerge udev. Don't reboot until you...
  • Emerge --oneshot eudev.
- John
_________________
This space intentionally left blank.
Back to top
View user's profile Send private message
gentoo_newguy
Guru
Guru


Joined: 10 Oct 2006
Posts: 539

PostPosted: Wed Apr 17, 2013 9:58 pm    Post subject: Reply with quote

After hours of playing i have finally fixed this problem .

Adding the net.ifnames=0 to the kernel command line changes the devices back to normal

I did a
Code:

 rc-update add net.wlan0 default

but i have to manual type dhcpcd wlan0 to get an ip hwo can i start this automatically ?
Back to top
View user's profile Send private message
khayyam
Veteran
Veteran


Joined: 07 Jun 2012
Posts: 1533

PostPosted: Wed Apr 17, 2013 10:02 pm    Post subject: Reply with quote

gentoo_newguy wrote:
how do i switch from udev to eudev?

gentoo_newguy ... John's pretty much covered it above. By default the "rule-generator" useflag is set and this will provide an init "udev-postmount" you then add this to the default runlevel.

Code:
# rc-update add udev-postmount default

Thats about all there is to it ... all the information is provided in the einfo from the package merge, so you'd then restart udev and/or reboot. Your interfaces should then be eth0/wlan0 on boot.

best ... khay
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Page 5 of 8

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum