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


Joined: 13 Sep 2006
Posts: 2160
Location: The Peanut Gallery

PostPosted: Fri May 03, 2013 10:10 pm    Post subject: Reply with quote

Anon-E-moose wrote:
I explicitly start udev-postmount but not the other two. Udev used to keep track of what devices failed initialization
and then retry them later, maybe it was in postmount, but I think that's one of the "features" that they are trying to do away with.

That's exactly right. iirc there was another race around when it tried the second stage and it would end up initialising devices twice. I don't recall the details though.
Quote:
I don't keep up much with where they are going as I refuse to update.

Heh, I've just always kept my Gentoo installs relatively current, even if I don't update for a couple of months, which is when I'm holding off as I want to sort some new feature out in update, and my system and the tree need to be in a certain state. ATM it's toolchain after the recent gcc upgrade hit stable, combined with linux-headers and glibc incoming, as well as a running kernel lower than linux-headers. That's a pretty rare combo, and just the situation the new handling I've wanted since the beginning, and been playing with for the last 2 years, is meant for. The first time was expat, when I didn't upgrade for nearly 6 months, just built loads of chroots trying out the ABI procedure in /etc/warning.

Now I digress ;-) I just don't feel comfortable leaving base system software lagging. If I can't use separate /usr for some new crazy reason, then I'll switch to eudev.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Fri May 03, 2013 10:21 pm    Post subject: Reply with quote

steveL wrote:
Quote:
I don't keep up much with where they are going as I refuse to update.

Heh, I've just always kept my Gentoo installs relatively current, even if I don't update for a couple of months,


I meant that I'm not updating udev. I keep up with everything else. :lol:

Quote:
I just don't feel comfortable leaving base system software lagging.


Agreed.
_________________
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: 3784

PostPosted: Sat May 04, 2013 7:55 am    Post subject: Reply with quote

Anon-E-moose wrote:
mv wrote:
Anon-E-moose wrote:
The kernel should always finish up what it's doing with a device
before something else (udev for example) tries to do something with that device

whether it is built into the kernel or a module loading.

I am not a kernel hacker, but AFAIK, this is happening. The problem is that then - while udev is running - the next device might be initialized, and this is what gives the race with udev.


I bolded what I originally said.
If udev waited for the kernel to be done with a device there would be NO race condition it would be impossible.

No, it would have to know whether there is a next eth* device coming before it starts its work - which it cannot know in principle.
Quote:
Udev is the problem not the solution [...] until the development of it started being driven by systemd instead of the kernel.

Perhaps you should be more objective. I also hate systemd, but for technical reasons. Anyway, the network related changes obviously have nothing to do with that. The race existed before and needed to be fixed.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2160
Location: The Peanut Gallery

PostPosted: Sat May 04, 2013 8:19 pm    Post subject: Reply with quote

mv wrote:
The race existed before and needed to be fixed.

Yes, they designed it with a race, despite all their purported expertise, and it needed to be dealt with: but not like that.

If only they'd thought through the design for the "fix" before they pushed it.

Exactly the same as if they'd thought through the original design, and discussed it more widely, instead of assuming the first bright idea they had must be the one, since they're the "dynamic experts" and everyone else "just doesn't understand."
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Sat May 04, 2013 10:31 pm    Post subject: Reply with quote

steveL wrote:
mv wrote:
The race existed before and needed to be fixed.

Yes, they designed it with a race, despite all their purported expertise, and it needed to be dealt with: but not like that.


Wow a "race condition" that didn't affect ~99% of users, I can hear it now "damn we must fix this injustice"

Quote:
If only they'd thought through the design for the "fix" before they pushed it.


Kind of like when they pushed "hal" as the solution of the gods,
then walked away from it (after convincing most users to switch)
"because it was too complicated to do properly" :roll:

Oh well!
_________________
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
oliv3r
n00b
n00b


Joined: 06 Jan 2013
Posts: 16

PostPosted: Sun May 05, 2013 9:49 am    Post subject: Reply with quote

So what about USB devices, while less likely used, do they get re-enumerated? I can quite imagine they can.

I believe we can conclude quite safely, that this fix is just as broken as how it was. And the only reliable way now is to use the MAC address in udev rules.

So who will bring this up with upstream? Let them know that their 'one way to rule them all' is just as flawed as the rest. I guess they can always argue, the previous method was 99% 'workable' and this is 99.1% 'workable' this is still better then what we had.

Even though it causes haywire everywhere and more trouble then its worth.

OT:
I must say I quite liked the Virtual Machine using identical MAC addresses, I'm surprised that identical MAC addresses wouldn't clash on the KVM layer. I mean, normally, you want unique MAC address on a LAN level, because otherwise switches get confused. So KVM does the switching here, does that care about clashing MAC addresses? If i'm not mistaken, KVM creates on vlan interface on the host per guest and that gets internally connected to VM. So should be okay still, right?
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: Sun May 05, 2013 12:46 pm    Post subject: Reply with quote

oliv3r wrote:
So what about USB devices, while less likely used, do they get re-enumerated? I can quite imagine they can.


I complained about this in page 3 where my nice stable wlan0 becomes a choice of wlp0s29f7u1 wlp0s29f7u2 wlp0s29f7u3 wlp0s29f7u4 wlp0s29f7u5 wlp0s29f7u6 wlp0s29f7u7 wlp0s29f7u8 on 1 of the computers I look after. Even more choices on the machines with more usb ports.

Have a group of machines where networking is provided by usb wifi adaptors. Without udev stuffing with network names it is a case of grab a spare wifi adaptor and plug it into any empty usb port. The kernel gives wlan0 and all configs and scripts work. If udev is allowed to rename the interfaces all a person has to do is move the wifi adaptor to a different usb port and things are broken.

I just want to use which ever wifi adaptor is available and plug it in to a free usb port. I get that with the consistent name I get from the kernel. Without stuffing around I do not get that with udev.
_________________
Beware the grue.
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2160
Location: The Peanut Gallery

PostPosted: Sun May 05, 2013 1:44 pm    Post subject: Reply with quote

Anon-E-moose wrote:
Quote:
If only they'd thought through the design for the "fix" before they pushed it.

Kind of like when they pushed "hal" as the solution of the gods,
then walked away from it (after convincing most users to switch)
"because it was too complicated to do properly"

Yes, exactly. The pattern seems to be "mess things up then make everyone switch, with a lot of pain, to a new shiny setup, that's messed up in a way we don't know about yet". And at each stage, it's the new "One True Way." Unfortunately commercial Linux appears to be following the Windoze path of "N+1 True Way" layer on top of layer, each one making the previous kludge "more convenient". XML in base system software (on Unix!) is the legacy.
oliv3r wrote:
I must say I quite liked the Virtual Machine using identical MAC addresses, I'm surprised that identical MAC addresses wouldn't clash on the KVM layer. I mean, normally, you want unique MAC address on a LAN level, because otherwise switches get confused. So KVM does the switching here, does that care about clashing MAC addresses? If i'm not mistaken, KVM creates on vlan interface on the host per guest and that gets internally connected to VM. So should be okay still, right?

Heh that just shows you I'm not a network admin :) It was just an idea that surfaced when we were discussing the whole thing on irc: given what you've said, it would require MAC spoofing based on configuration, similar to /etc/mactab for mapping or rather reservation of ifname; perhaps an optional field in that file, in the same way that dump/pass in fstab is optional? Just don't worry if it's not there at all, so users who don't need it, don't have to worry about it.

Ideally you'd want the config to come from another machine, since the whole point is to use a fixed MAC for easy configuration. So I'm not sure how you'd best do it (BOOTP uses MAC doesn't it?) as I don't have enough knowledge. It might turn out to be unworkable, but I'd love to hear your ideas, and from other people who know networking better than I do. My thought on a test LAN was just to grab a DHCP address, but if as you say the switch is going to work via MAC then it's fairly likely DHCP will too, and even if it doesn't then we need to have a unique MAC before we send anything across the LAN.

But you could still use the same hardware MAC for each virtual device, and map that to the same ifname on each machine. All networking config would go from there, and the base would be the same across all of them.
Then provisioning (ie install) would simply be a question of putting the MAC addresses to spoof to into /etc/mactab; that could be derived from a machine number in /etc.

Another thing I was thinking is that you might not actually be connecting many of the virtual interfaces to a real network. For instance, people hacking network software often setup a small virtual network of 2 or 3 VMs on their machine, to test the implementation, which never communicates with the outside world, or even the LAN, at all. I guess that's what you mean by the KVM thing? Again, I'm totally ignorant; since I don't have virtualisation extensions on my CPU (yes I need to get a new machine, but I have several which still work ;) I can't use KVM.

In any event, you have much more control over a VM installation, so why not make it use the same ifnames predictably, and then spoof the MAC for external interfaces if necessary (which it clearly is.) As ever, it's only needed if the machine actually has more than one NIC of the same type.

Thanks for bouncing the idea round :)
Back to top
View user's profile Send private message
oliv3r
n00b
n00b


Joined: 06 Jan 2013
Posts: 16

PostPosted: Wed Jun 12, 2013 10:37 pm    Post subject: Reply with quote

Since there hasn't been a reply in a while, I will re-iterate (or repeat) one thing.

This whole predictable name thing is stupid and broken.


A little example. Onboard LAN0, disabled in bios. PCI-E LAN1; used. Everything fine.

Enable onboard LAN0.

Guess what happens.

The PCI bus gets re-enumerated. Guess what is all messed up? Right. What was enp3s0 is now enp4s0. *G*. I guess it is not predictable at all and does make it harder for all.

I guess the most resiliant way, is rename by MAC. As it has always been. What does this new behaviour bring? Absolutly. NOTHING. As it simply does not work.
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2000
Location: Finland

PostPosted: Thu Jun 13, 2013 6:41 am    Post subject: Reply with quote

oliv3r wrote:
Since there hasn't been a reply in a while, I will re-iterate (or repeat) one thing.
This whole predictable name thing is stupid and broken.
A little example. Onboard LAN0, disabled in bios. PCI-E LAN1; used. Everything fine.
Enable onboard LAN0.
Guess what happens.
The PCI bus gets re-enumerated. Guess what is all messed up? Right. What was enp3s0 is now enp4s0. *G*. I guess it is not predictable at all and does make it harder for all.
I guess the most resiliant way, is rename by MAC. As it has always been. What does this new behaviour bring? Absolutly. NOTHING. As it simply does not work.


It almost looks like as if you were confusing the terms of 'predictable' and 'persistent'. It's 'predictable' that the order of course will change because you are inserting new device that takes priority, as in, leave the enabling/disabling to the operating system instead of BIOS.
If you are looking for 'persistent', then you can indeed go with the easiest option which is custom interface name .rules based on MAC like you already pointed out. However, 'predictable' can be 'persistent' too if used in a way it's meant to be used, which is not flipping devices 'on' and 'off' within hardware level configuration method like BIOS.
Claiming it brings nothing couldn't be futher from the truth. It's the working replacement for the old, removed rule-generator which tried to keep the kernel assigned names consistent but never worked correctly for everyone with all the race conditions.

In other words, it works as designed and the way it's documented.

For example, sys-fs/eudev brought back the broken rule-generator and soon after the release people came complaining the generated persistent rules are not persistent,

Quote:

17:19 <@Chainsaw> Good afternoon. Same question as yesterday.
17:19 <@Chainsaw> Is the "old style" persistent net naming now usable in 1.0 please?
17:22 <@_AxS_> Chainsaw: with an older kernel and essentially the same environment as udev-171, should be yes. Will
double-check tonight.
17:23 <@Chainsaw> _AxS_: I was trying 3.8.6-hardened
17:23 <@Chainsaw> _AxS_: And it didn't seem to work there. Do you have a list of what I need to do?
17:23 <@_AxS_> Chainsaw: ah, no then. there is no stable means to rename an iface into the same base name as the kernel.
17:24 <@_AxS_> Am working on it but it'll take some time.
17:24 <@Chainsaw> _AxS_: Okay.
17:24 <@Chainsaw> _AxS_: And the old-style eth1 -> eth1_rename -> eth0 isn't viable?
17:25 <@_AxS_> Chainsaw: not at the moment, no, for a couple of reasons. #1 is a race condition against the kernel,
another is the way rules are processed in newer udevs (rules don't seem to chain on top of the results of
previous rules)
17:25 * Chainsaw sighs deeply
17:26 <@Chainsaw> The one reason why I'd want eudev over udev.
7:26 <@_AxS_> Chainsaw: i'm sure we can sort it out, tho; it'll just take some time to do.
17:26 <@Chainsaw> And you carried the breakage into your releases.
17:26 <@_AxS_> it's not -just- udev's breakage, tho..
17:27 <@Chainsaw> If you can identify kernel-side commits that broke it, can't we undo those in hardened-sources?
17:27 <@_AxS_> ....probably, although it's a long way back ... didn't the change happen around 3.0 ?
17:28 * Chainsaw has about a decade's worth of bash/perl scripts that rely on eth2 & eth3 meaning very specific interfaces
17:28 <@Chainsaw> And whilst I know all the steps to the ifrename dance, it means my machines are no longer safe to restart.
17:29 * _AxS_ nods
17:30 <@_AxS_> Unfortunately my availability is extremely limited over the next week or two, but i'll do my best to sort it
out. I don't suppose you can in the meantime have an init script do the rename? Or are these ifaces
hotplugged?
17:31 <@Chainsaw> I'll write an init script that does it. I've been trying very hard to find a polite filename for it, but
not much luck so far.
17:32 <@_AxS_> Question -- you already have the rename rules in place, right? So all you really need is to support to make
sure that rename actually occurrs at boot?
17:32 <@_AxS_> IE, it's not an issue with the rule-generator so much as making sure you can have a NAME=eth0 ?
17:33 <@Chainsaw> _AxS_: Yes, I have hand-edited the relevant file. It's ignoring it.
17:34 <@_AxS_> OK. That's a much smaller problem; i'll see if I can track that down and get it working
17:34 <@Chainsaw> _AxS_: I've e-mailed you an example.
17:34 <@_AxS_> Chainsaw: tnx!
17:34 <@_AxS_> Chainsaw: do all the rules get ignored? or just some?
17:35 <@Chainsaw> _AxS_: Seemingly all. It's eth2 & eth3 that I really, really care about.
17:35 <@Chainsaw> _AxS_: On this occasion eth2 was assigned correctly but eth3 wasn't.
17:36 <@_AxS_> OK so then it's definitely the race-condition issue.
19:58 <+ssuominen> random-rule-generator :p


Yes, I'm saying every release of sys-fs/eudev with USE="rule-generator" is broken for a fact.
Back to top
View user's profile Send private message
oliv3r
n00b
n00b


Joined: 06 Jan 2013
Posts: 16

PostPosted: Thu Jun 13, 2013 10:29 am    Post subject: Reply with quote

So it 'almost' works. Well so far, it's little benefit.

* It doesn't work with USB as one would hope (unless you always use the same USB port)
* It doesn't work reliably with PCI, if PCI bus can be enumerated (Which is out of our control).

I really tried to use this new system, I really did. I moved over my servers (one fails, it has a quad port card that it refuses to rename), on my desktop it messed up and having 1 usb NIC makes things interesting to say the least.

So for me, as someone who didn't really like the MAC way, I will switch to the MAC way. And least that works as one would expect.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Thu Jun 13, 2013 10:58 am    Post subject: Reply with quote

oliv3r wrote:
So for me, as someone who didn't really like the MAC way, I will switch to the MAC way. And least that works as one would expect.


Of course it works, despite the woeful cries of the "udev persistent/predictable name" sycophants.
It's worked for years and still does work.

Worse case, you replace a network card, then you modify one file "once" with the new mac addy and voila, it works ever after.
That is predictable AND persistent.
_________________
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
Dr Croubie
Tux's lil' helper
Tux's lil' helper


Joined: 21 Nov 2006
Posts: 78

PostPosted: Sat Jun 15, 2013 11:30 pm    Post subject: Reply with quote

Hi all, I'm another victim of the perpetual mess that is udev. I've read through the past few pages and I just can't seem to make sense of anything.
So here's what I've got (firstly, i've only got 1 inbuilt network, on-motherboard so it ain't ever changing):

> dmesg | grep udev
systemd-udevd[839] renamed network interface eth0 to enp4s0

in /etc/init.d:
net.enp4s0 -> net.lo

in /etc/conf.d/net:
config_enp4s0="192.168.8.128
config_enp4s0="default via etc

in /etc/conf.d/network everything is commented out

in /etc/conf.d/netmount everything is commented out except the line:
rc_need="net.enp4s0"
(it started off just saying plain "net" so i changed it to "net.enp4s0", neither work)

/etc/udev/rules.d/ was an empty directory, I've tried it as a symlink to /dev/null, neither work.

> rc-update
net.enp4s0 | boot
net.lo | boot

and finally:
> grep -i eth0 /etc/* (and /etc/*/* etc)
all turn out no more references to "eth0" that aren't commented out.


Now, system boots at least. But I get:
ERROR: cannot start netmount as net.eth0 would not start
ERROR: cannot start sshd as net.eth0 would not start
both on boot and when just typing 'rc'.

And:
> ping 192.168.8.1
connect: Network is unreachable

> ifconfig
lo: flags etc
and no reference to net.eth0 or net.enp4s0 or anything.



Seems every time I upgrade anything to do with udev it takes me a few hours to get a working system again. thnkfully I'm just a desktop and not a webserver or I'd be boned about now.
Can someone please explain what files have to say what? I've never written a udev rule, so if that's the answer then please walk me through it.

Option 1, I keep using 'net.enp4s0' and update every reference to use that. What other references are there that are not in /etc/*, because there's none there.

Option 2, I stop/kill/uninstall udev or whatever I have to do to just keep using eth0 like I've used for the last 15 years. Something somewhere said about 'just type something on the kernel command line'. Does that mean every time I boot I have to press a key in Grub and do something manually, or how do I do it automatically (and gracefully, not kludgy)? The news item says something about "you can't use eth* you have to use free namespace like net*", so if I can't use net.eth0 and have to rename everything anyway, then I may as well use net.enp4s0.

Either way I don't care, whichever is easiest. anything to get my network going again (which I seem to write every time udev upstream changes its mind on something)
Back to top
View user's profile Send private message
Dr Croubie
Tux's lil' helper
Tux's lil' helper


Joined: 21 Nov 2006
Posts: 78

PostPosted: Sat Jun 15, 2013 11:44 pm    Post subject: Reply with quote

ps, I also just tried re-creating eth0 as much as I had before:
> rc-update
net.enp4s0 | boot default
net.eth0 | boot default

/etc/init.d
net.enp4s0 -> net.lo
net.eth0 -> net.lo

That also does nothing. So I can't even fool the system into trying to access a deice that doesn't exist.




Further testing, I rebooted to Grub, pressed 'c' for a command line, and:

grub> net.ifnames=0
Error 27: Unrecognized command.

So how is that meant to work again?
Back to top
View user's profile Send private message
Jaglover
Advocate
Advocate


Joined: 29 May 2005
Posts: 4560
Location: Saint Amant, Acadiana

PostPosted: Sun Jun 16, 2013 12:21 am    Post subject: Reply with quote

For last method, put it in kernel command line, like this
Code:
kernel /boot/bzImage root=/dev/sda1 net.ifnames=0 video=LVDS-1:d
this is a live example from one of my boxes.
_________________
Please learn how to denote units correctly!
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3784

PostPosted: Sun Jun 16, 2013 4:51 am    Post subject: Reply with quote

Dr Croubie wrote:
Now, system boots at least. But I get:
ERROR: cannot start netmount as net.eth0 would not start
ERROR: cannot start sshd as net.eth0 would not start
both on boot and when just typing 'rc'.

This message comes when you still have the /etc/init.d/net.eth0 or /etc/runlevels/*/net.eth0 symlink - remove it. Just to be sure, I would call
Code:
/lib/rc/bin/rc-depend --update
afterwards.
Back to top
View user's profile Send private message
John R. Graham
Administrator
Administrator


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

PostPosted: Mon Jun 17, 2013 1:08 am    Post subject: Reply with quote

ssuominen wrote:
It almost looks like as if you were confusing the terms of 'predictable' and 'persistent'. It's 'predictable' that the order of course will change because you are inserting new device that takes priority, as in, leave the enabling/disabling to the operating system instead of BIOS.
As if that doesn't look unpredictable. It almost looks as if you're saying unpredictable device naming before, which was caused by a nasty race condition, is far inferior to the de-facto unpredictable device naming now, because at least we got rid of that nasty race condition.

- John
_________________
This space intentionally left blank.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2384

PostPosted: Mon Jun 17, 2013 1:29 am    Post subject: Reply with quote

Having been in corporate America for over thirty years, I've learned of and can recognize "institutionalized bad decisions." Those situations where enough people have bought into a bad decision, with enough skin, that they can't back down. Then more reasons start to materialize after the fact to justify that decision, and those reasons start looking trumped up, too.

IMHO, this was a bad decision, and we've begun the trumping-up phase. It's an institutionalized bad decision. The old way wasn't a decision, it just kind of happened, historical accident.

Here's what it comes down to - the old way only ever crossed me once, on a dual-homed machine, when something changed and my network cards swapped. I don't remember why they were swapped, but had it been due to a change in pci enumeration, the new way would have crossed me just as surely. If you have any sort of USB networking hardware old or new way would be equally unreliable.

Basically the new scheme has not significantly improved things, and has broken a whole heck of a lot of legacy.

Oh, and one other thing - the new scheme is NOT predictable. Until you plug that device in, you don't really know what it's going to be named. The only predictability is after-the-fact, and the fact is that enumeration-based names can get tweaked by other hardware getting plugged/unplugged that happens to be earlier in the enumeration sequence.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
broken_chaos
Guru
Guru


Joined: 18 Jan 2006
Posts: 370
Location: Ontario, Canada

PostPosted: Mon Jun 17, 2013 2:03 am    Post subject: Reply with quote

I accept it being called "predictable" in cases where changing the physical port changes the device name -- not ideal, no, but predictable (as long as it goes back to the previous name when moved to the previous port). I'd not accept it being "predictable" in cases where enabling/disabling or adding/removing a completely unrelated piece of hardware results in a new name, though. One might be able to rules-lawyer an explanation as to how it's 'technically' predictable, but that's a pretty big cop-out if the piece of hardware that was renamed was never moved or touched. Perhaps the use cases of the new scheme's designers just never had to add or remove hardware before...

Also, perhaps I'm missing something, but it seems like the best solution would have been the simplest -- keep on using "persistent" rather than "predictable" names. Meaning keep the old rules generator intact, and just use a new, non-kernel, namespace. You would have undoubtedly had a bit of grumbling, but getting used to "en0" and "wl0" instead of "eth0" and "wlan0" (for example) seems like a much better solution than "enp3s48" and friends. Unless I'm completely missing something about how the old rules generator was broken, of course. That's actually the sort of solution I'd love to see pop up in something like eudev, since there is that awkward race condition with the reuse of kernel namespaces.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3784

PostPosted: Mon Jun 17, 2013 8:13 am    Post subject: Reply with quote

broken_chaos wrote:
Meaning keep the old rules generator intact, and just use a new, non-kernel, namespace. You would have undoubtedly had a bit of grumbling, but getting used to "en0" and "wl0" instead of "eth0" and "wlan0" (for example) seems like a much better solution than "enp3s48" and friends.

On machines with more than one eth device this is certainly not better since it is practically guaranteed to be unpredictable (and in contrast to what you consider as "unpredictable" it is here really so since the numbering may change randomly even if no hardware is changed). Anyway, you can very simple have this by adding the configuration line
Code:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNEL=="eth*", NAME="en%n", OPTIONS="last_rule"

(and a simiar line for wlan). To be honest, I still do not understand the heaty discussion about having to add one line of configuration when there is obviously no default possible which works for all use cases. You also do not expect your local network addresses and iptables rules to be set up correctly by default without configuration for all use cases. However, I agree that perhaps the gentoo documentation could provide some such examples for the most frequent cases instead of only mentioning the "enp3s48" case and thus giving the (false) impression that this behavior is hard to change. But somebody would have to write the text...
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: Mon Jun 17, 2013 9:25 am    Post subject: Reply with quote

mv wrote:
On machines with more than one eth device this is certainly not better since it is practically guaranteed to be unpredictable


Under what conditions? I have wondered about cards that may have multiple ports. Those I have no experience with. In my multi nic machines each nic is on a separate card and eth swapping is not something I am seeing. The only eth swap I have had to deal with involved a mother board change and that was dealt with 1st boot. With the current machines I look after

The eth0 only machines never needed renaming.

The eth0 eth1 machines come up in the same order every time.

The eth0 wlan0 machines never needed renaming. Udev's renaming is more trouble that it is worth with these machines.

The eth0 eth0 wlan0 machine comes up in the same order every time.

I still do not see why the network interfaces could not have been left alone with a pointer to appropriate documentation for those that did need a fix. That way anyone who did not have a problem could have done nothing and anyone who did have a problem had a fix it.
_________________
Beware the grue.
Back to top
View user's profile Send private message
broken_chaos
Guru
Guru


Joined: 18 Jan 2006
Posts: 370
Location: Ontario, Canada

PostPosted: Mon Jun 17, 2013 3:29 pm    Post subject: Reply with quote

mv wrote:
On machines with more than one eth device this is certainly not better since it is practically guaranteed to be unpredictable (and in contrast to what you consider as "unpredictable" it is here really so since the numbering may change randomly even if no hardware is changed).

Sorry, I suppose I wasn't very clear.

I mean keeping the old rule generator exactly as it was, meaning the rules would be generated for each new network device that maps them, via MAC address, to a persistent device name, just done under a new, non-kernel namespace. This would avoid the race condition with the multiple renamings, and would function largely as things did before -- which I'd not heard any serious complaints about the general idea of generating custom rules automatically that set a MAC to a particular device.

A system which I haven't updated udev on lately, for example, has this in 70-persistent-net.rules:
Code:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR(address)=="ff:ff:ff:ff:ff:ff", ATTR(dev_id)=="0x0", ATTR(type)=="1", KERNEL=="eth*", NAME=="eth0"

I think all that would have been needed to avoid both the race condition and the new mess of 'predictable' names would be to change that last "eth0" to "en0" or "lan0" or "net0" or anything similar.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2384

PostPosted: Tue Jun 18, 2013 12:24 am    Post subject: Reply with quote

Could someone please explain the naming race condition to me.

Have the kernel devs said that this race condition can't be fixed?
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
broken_chaos
Guru
Guru


Joined: 18 Jan 2006
Posts: 370
Location: Ontario, Canada

PostPosted: Tue Jun 18, 2013 12:41 am    Post subject: Reply with quote

depontius wrote:
Could someone please explain the naming race condition to me.

If a new network device was activated while the rename was happening, it could fail. If udev was trying to rename eth0 to eth1 and a new ethernet device was plugged in just prior to doing this, the kernel will name it eth1 and udev's rename would fail. This would sometimes cause weird results like having eth0_rename and eth0 at the end of boot. It wasn't extremely common to have problems, but it definitely did happen (I saw it at least once about five years ago).

Basically, there's no way to prevent this from being able to happen (in some form) while using the same namespace as the kernel (eth/wlan/etc.), so there was a need to move to a new namespace. The entirely redesigned name scheme (rather than just a new namespace) was the part that was tacked on in what probably seemed like a good idea to someone at some time.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 3784

PostPosted: Tue Jun 18, 2013 12:01 pm    Post subject: Reply with quote

Aiken wrote:
The eth0 eth1 machines come up in the same order every time.

Then you had good luck. It is likely that the order remains, but you cannot rely on it. If you just rely on the automatic kernel order my experience is that the order differs in about 1 of 20 boots, but this number depends very much on what you have built as modules (even completly unrelated modules!) your disk layout etc. If you risk the race condition with udev it is even much less likely, but still it may happen. It is not acceptable to have such a risk e.g. on a machine which is hundred miles away.
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 7 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