After reading the news item 2013-03-29-udev-upgrade, the Gentoo Wiki Udev/upgrade page as well as Predictable Network Interface Names there are still a number of things from the news item that I'm uncertain about. I'm running Gentoo on an old laptop that has two network devices, ethernet (eth1) and wlan (currently disabled).

I'd like to use the new udev naming scheeme and not the old unpredictable one even though there's currently only one active network device.

The numbered headers correspond to the headers in the news item.

2.

Quote:

If you have a line for /dev in /etc/fstab, make sure it is configured
for file system type devtmpfs (not tmpfs or any other type). Also, you
can remove this line if you prefer, since devtmpfs is mounted
automatically.

It depends on which version of udev has generated this file. Both sets of attributes should work, although I would suggest to add "ACTION="add"". The important point is to change NAME="net..." (and to modify the rest of your configs to change from eth0/1 to net0/1).

Suppose I'd like to use the name found by udevadm test-builtin net_id, enp2s10, could I skip the NAME attribute in 70-persistent-net.rules like below, and also remove the DRIVERS and KERNEL attributes?

Suppose I'd like to use the name found by udevadm test-builtin net_id, enp2s10, could I skip the NAME attribute in 70-persistent-net.rules like below, and also remove the DRIVERS and KERNEL attributes?

Those warnings are fine. As long as you have your network up, it is OK. FYI, since the network process can take a bit long to start up, it is automatically backgrounded so that the rest of your boot can proceed quickly._________________emerge --quiet redefined | E17 vids: I, II | Now using e17 | e18, e19, and kde4 sucks :-/

This has got to be the most asinine thing I've ever seen anyone do to a working system, just to update a module. enp2s0? Really? WHY???? There was not even any way to figure out this stupid name was going to be used - all I get is

Code:

udevadm test-builtin net_id
calling: test-builtin
syspath missing

Oh, yea, that worked. Instead I suppose I could guess, if only there was some convention I could look up and do the language translation (or whatever is going on in this thing) to figure out what it MIGHT be and EDIT ALL MY CONFIG FILES (since apparently that's too hard for an update script to do). But instead I get this:

WHY???? Why did you rename it, to something indecipherable, when the kernel knows what it is right there (and I do too).

I guess I should be thankful I no longer run a bridge interface connected to a bunch of virtual TAP and ETH devices for virtual machines on this server - who knows how much I would have to deal with then.

Quote:

Pay attention also to every message printed by emerge of sys-fs/udev
and sys-fs/udev-init-scripts as this news item may not be complete.

Well, thanks. At least I get a warning that I'm going to either capture those messages or merge those items separately to figure out on my own what to do. Nothing like picking through packages instead of doing a full system update to make things go smoothly.

Quote:

you must use free namespace (like net* or internet*) instead of kernel namespace (like eth* or wlan*) because in-place renaming has been deprecated

For ... what, exactly??? Someone just didn't like using those (ubiquitous) names? I can only assume this decision came from some dev that needs some significant amount of counseling, because they obviously suffer from a mental illness (got to be something beyond NIH syndrome).

Quote:

see small documentation of it if you like[2]

Okay, let's check that ...

Quote:

Don't call this function. Currently, the networking layer calls this function, but that will change.

Oh, good, I can't wait. Can I tell the networking layer not to call it? Seems there's this:

Quote:

If /etc/udev/rules.d/80-net-name-slot.rules is an empty file or a symlink to /dev/null, the new names will be disabled and the kernel will do all the interface naming

Okay, well doesn't work if the file isn't there at all. Let's just create it and try it out.

Okay, so it seems I should be able to create something like "/etc/udev/rules.d/70-a-name-emerge-will-not-complain-about.rules" and use the new syntax (carefully avoiding any name that the kernel might use now or at some time in the future or if the devs decide to include or change) and call it something like "direnet0", then just change all my network config files and init scripts to refer to "direnet0". ACK UGH Stuck with it, it seems, let's try it out.

For ... what, exactly??? Someone just didn't like using those (ubiquitous) names? I can only assume this decision came from some dev that needs some significant amount of counseling, because they obviously suffer from a mental illness (got to be something beyond NIH syndrome).

Did you read Predictable Network Interface Names? The rationale behind it is there. I can't say that I understand all of it, but basically it was done to solve the problem of unpredictable device names due to big racing condition problems.

Also, I suggest that you create your own thread for your own problems._________________man cannot be brave without being afraid

It seems your /etc/udev/rules.d/70-a-name-emerge-will-not-complain-about.rules does not contain the correct content. You should post it here if you really want help.
BTW, I would use the name "net0" since it seems to become some sort of standard.

BTW, I would use the name "net0" since it seems to become some sort of standard.

Eth0 was a standard, up until some jerk thought <throw random numbers/letters together for a new name> should be the new naming convention, then change that to net0 _________________Asus m5a99fx, FX 8320 - amd64-multilib, 3.15.9-zen, glibc-2.19, gcc-4.9.2, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4(2011)

and it still is in the kenel namespace. Using the same name for a different purpose (namely to access a device which had not yet persistent name in user space) was a very bad idea from the very beginning. Understandably in the beginning, since no other way was possible some years ago in the lack of a tool like udev, but a bad idea as soon as udev was able to provide permanent names.

and it still is in the kenel namespace. Using the same name for a different purpose (namely to access a device which had not yet persistent name in user space) was a very bad idea from the very beginning.

I disagree that it was a very bad idea since it worked for the great majority of people.

When I bought my new motherboard I had trouble using the onboard ethernet with iommu enabled (fixed since then)
so I added an add in ethernet card and disabled the onboard, it worked fine.
I got the iommu problem solved and enabled the onboard, booted, saw that eth0 was now eth1 so I edited the persistent name file to make the mac addresses match where I wanted them to go. Rebooted and it's been fine ever since and this is with udev-171-r6.

Just what is so damed difficult about doing something like that for the few (very few in the scheme of things) that have multiple ethernet cards? This was just another case of some ignorant dev changing things simply because they could with, so it seems no forethought about repurcussions (the number of threads about it on gentoo alone says there were repurcussions).

Yes, people that have usb ethernet adapters or those who open their boxes and swap the order of cards in their system or those who change from module to builtin or reverse might have problems. Those types of people are supposed to know a little about their system and what they are doing with it.

Trying to dumb linux down to the lowest common denominator and then piling on complexity willy-nilly ala windows will be the death of it.

Anon-E-moose (and others): I agree with you, but I think it would be better to mail directly to the individuals who put through such a disruptive change. They easily could have done everything as-is except make the non-mnemonic names default to off with a note that you should enable them if you have unreliable ordering due to multiple NICs. Instead, they chose to make most systems broken-by-default for the benefit of those rare people who (1) have multiple NICs and (2) use a hardware/kernel combination that does not order the NICs consistently across reboots. I have machines that satisfy (1) but I have never had a machine that satisfied (2).

BTW, I would use the name "net0" since it seems to become some sort of standard.

No way - some dev will use that as a standard for something else, udev will change, and then something else will collide. This is clearly bad advice.

From the device_rename doc:

Quote:

It is the responsibility of the caller to provide mutual exclusion between two different calls of device_rename on the same device to ensure that new_name is valid and won't conflict with other devices.

Currently, the networking layer calls this function, but that will change.

I've been burned enough by having stuff renamed underneath me to not (again) make the mistake of following some "standard" that get deprecated into "you can no longer use that name"._________________========================================================
"Somebody has to do something, and it's just incredibly pathetic that it has to be us."
- Jerry Garcia

I disagree that it was a very bad idea since it worked for the great majority of people.

s/people/boots. But only by accident. Do you really want to rely on a system which works only by accident? This is especially an issue if you are physically away far from the system.

Quote:

Rebooted and it's been fine ever since and this is with udev-171-r6.

Yes, it lies in the nature of things that race conditions usually do not happen. But this does not mean that you are safe from them. And by Murphy they happen then in the worst moment.

Quote:

Yes, people that have usb ethernet adapters or those who open their boxes and swap the order of cards in their system or those who change from module to builtin or reverse might have problems.

Everybody for which the kernel might offer more than eth0 might have problems - whether it occurs or not is a matter of probability at every new booting.

Quote:

Trying to dumb linux down to the lowest common denominator and then piling on complexity willy-nilly ala windows will be the death of it.

Exactly. This is why it is good that a clean solution like separating the namespaces for kernel and userspace has been chosen instead of complex hacks which try to work around this real issue by locks just in order to hide this problem from those users whose kernel/hardware offers only one eth0: This would have had exactly the effect that you describe.

People keep saying that the new setup is a wonderful cure for the race conditions which long
to destroy systems at every opportunity. Oddly enough these race conditions have come
nowhere near me for the last 15 years because ON MY SYSTEMS AND MOST OTHERS
THERE AREN'T ANY ALTERNATIVE PORTS TO RACE WITH.

Perhaps developers are so used to high-end, multiport hardware that they don't realise
that in general people don't use systems with several competing ethX ports, and hence
race conditions will never be a problem. For them the new fix is therefore a wonderful
solution for a problem that will never exist; and a considerable aggravation.

I disagree that it was a very bad idea since it worked for the great majority of people.

s/people/boots. But only by accident. Do you really want to rely on a system which works only by accident? This is especially an issue if you are physically away far from the system.

You just don't seem to get it. You keep claiming this is a "solution" to some problem that simply doesn't exist for the great majority.
Meanwhile the "solution" is causing problems for many of the great majority.

I've been using linux since before it hit 1.0 and never had some "random renaming" and this is true for the great majority.
Hell I've even used multiple ethernet cards for years and never had any random renaming/reordering.
And despite the claims of those who simply parrot someone else's speech, it's not by blind luck.
The whole remote server example is simply silliness, as I would not be using udev,
nor modules, nor doing any of the silly things that might trigger off a rename/reorder, nor would most others.

I got better things to do than waste my time with someone that simply seems to be parroting what someone else said once upon a time
with no thought put into it at all.
Have a great day/night._________________Asus m5a99fx, FX 8320 - amd64-multilib, 3.15.9-zen, glibc-2.19, gcc-4.9.2, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4(2011)

I've been using linux since before it hit 1.0 and never had some "random renaming" and this is true for the great majority.

Once again: Just because you had good luck, and in fact it works in a majority of boots, it does not make a system reliable.
Of course, in 1.0 the issue did not exist: The renaming only became an issue since the kernel initialized modules in parallel - which is essentially the case since udev exists, since udev was the solution proposed by the kernel developers to solve the issues with this parallelization. I don't remember the exact kernel history, but I guess this was about 2.6.*. If it worked for you since then and you had two cards it was sheer luck. Not unllikely but not reliable.

Quote:

I got better things to do than waste my time with someone that simply seems to be parroting what someone else said once upon a time with no thought put into it at all.
Have a great day/night.

@mv, do you think there would have been such a hue and cry if the conventional kernel namespace names were changed to the new predictable names (or some other nontraditional names), leaving the traditional ethx names conflict free for assignment in userspace (probably by default)? Why wouldn't this have been a better solution?

- John_________________I can confirm that I have received between 0 and 999 National Security Letters.

@mv, do you think there would have been such a hue and cry if the conventional kernel namespace names were changed to the new predictable names (or some other nontraditional scheme), leaving the traditional ethx names conflict free for assignment in userspace (probably by default)? Why wouldn't this have been a better solution?

The point being is that there was a reason the possibility of renaming into kernel reserved names were dropped, the code was very racy since it worked with loops.

I don't know about others, but since I've used Linux for past 15+ years I've had problems dozens of times with eth0<->eth1 swapping places. At home, and at work. I used to write custom udev .rules file for it, or use iproute2 to rename the interfaces with custom init script. Now I don't have to, and I'm pleased about it.

As interesting as those threads might be, that's not what I asked. If as part of the change, eth0 and friends were made to no longer be kernel reserved names, then the possibility of race conditions with their userspace use would be gone, right?

- John_________________I can confirm that I have received between 0 and 999 National Security Letters.

As interesting as those threads might be, that's not what I asked. If as part of the change, eth0 and friends were made to no longer be kernel reserved names, then the possibility of race conditions with their userspace use would be gone, right?

- John

Right. If kernel used some other names like kerneleth* and kernelwlan* then when udev starts, eth* and wlan* would be free to use. In fact, there is an init script laying in the bugzilla that uses iproute2 to rename eth0 to eth0tmp, eth1 to eth1tmp, ... before udev starts, making the eth* namespace free again:

In fact, there is an init script laying in the bugzilla that uses iproute2 to rename eth0 to eth0tmp, eth1 to eth1tmp, ... before udev starts, making the eth* namespace free again.

How can you be sure that this script is run after all eth* introduced by the kernel have been initialized? I am afraid that this just introduces the same race again, only perhaps with an even lowered probability.

ssuominen wrote:

If kernel used some other names like kerneleth* and kernelwlan* then when udev starts, eth* and wlan* would be free to use

It is strange to require a kernel change when it was udev which introduced the race. I doubt that you could convince Linus to make such a change which works only if you upgrade kernel and udev simultaneously and otherwise breaks all older systems: Linus will say that userspace is responsible for userspace, and the kernel should not change its interface, especially if it was not this interface which was buggy but only the way how userspace udev used it.

Fixed your attribution above. I certainly agree that if it's implemented in a broken fashion, then it'll be broken. You all are acting as if there was no choice.

- John

My preference would have been to keep the old rule_generator but modify it to use net* namespace instead of eth* or wlan* or other kernel reserved, and because this would mean
udev doesn't need any code for it, it can be packaged separately like net-misc/rule_generator and make it install /lib/udev/rules.d/70-persistent-net.rules and /lib/udev/net-rule_generator

And I still haven't abandoned that idea, but making it part of sys-fs/udev would be diverging too much from what upstream is doing, so I'll propably end up packaging it as separate application
if at all

But the rename code itself that was dropped has been like that for years and the problems with the name swapping has been there for years, if there really are/were that many choices, why haven't nobody fixed it differently earlier? I doubt it would be easy to fix, and the fix would propably be worse than the predictable names (which is the fix)