udev upgrade 197-r8 -> 200 confusion

[Seron]

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.

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.

I have these lines containing /dev:

Code: Select all

/dev/sda1               /boot           ext2            noauto,noatime  1 2
/dev/sda2               none            swap            sw              0 0
/dev/sda3               /               reiserfs        noatime         0 1

shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0 0

Am I supposed to look for a standalone line for /dev only, or as part of some path? What of this should I change or remove?

3.
The 70-persistent-net.rules format is described as

Code: Select all

This is the old format with reserved namespace:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="xx:xx:xx:xx:xx:xx", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="yy:yy:yy:yy:yy:yy", NAME="eth1"

This is the new format with free namespace:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="xx:xx:xx:xx:xx:xx", NAME="net0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="yy:yy:yy:yy:yy:yy", NAME="net1"

Byt my 70-persistent-net.rules has some different attributes.

Code: Select all

# PCI device 0x8086:0x4220 (ipw2200) (wireless)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:0e:xx:xx:xx:xx", KERNEL=="eth*", NAME="eth0"

# PCI device 0x10ec:0x8139 (8139too) (ethernet)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:0a:xx:xx:xx:xx", KERNEL=="eth*", NAME="eth1"

How should I modify this file?

[mv]

Am I supposed to look for a standalone line for /dev only

Yes. In your case no change is required.

Byt my 70-persistent-net.rules has some different attributes.

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

[Seron]

Thank you.

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?

Code: Select all

# PCI device 0x10ec:0x8139 (8139too) (ethernet) 
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:0a:xx:xx:xx:xx"

[ppurka]

Thank you.

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?

Code: Select all

# PCI device 0x10ec:0x8139 (8139too) (ethernet) 
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:0a:xx:xx:xx:xx"

If you want to use whatever udev suggests, then simply move the file away from /etc, like this

Code: Select all

$ mv /etc/udev/rules.d/70-persistent-net.rules $HOME

After that make sure that you update your init files in /etc/init.d, like this. I am assuming that eth0 corresponds to enp2s10; if not, make the changes to the appropriate files.

Code: Select all

$ rc-update del net.eth0 <runlevel>
$ cd /etc/init.d
$ rm net.eth0
$ ln -s net.lo net.enp2s10
$ rc-update add net.enp2s10 <runlevel>

[Seron]

I removed the 70-persistent-net.rules file and created the symlink. After reboot I had network connection using net.enp2s10.

I get these two warnings in rc.log:

Code: Select all

 * Bringing up interface enp2s10
 *   Starting ifplugd on enp2s10 ...                                                   [ ok ]
 *     Backgrounding ...
 * WARNING: net.enp2s10 has started, but is inactive
 * Starting metalog ...                                                                [ ok ]
 * WARNING: cnid_metad is scheduled to start when net.enp2s10 has started

What do they mean?

[ppurka]

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.

[direwolf]

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: Select all

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:

Code: Select all

dmesg|grep eth
[    1.418814] e1000 0000:02:00.0: eth0: (PCI:66MHz:32-bit) 00:0c:29:d7:96:96
[    1.418926] e1000 0000:02:00.0: eth0: Intel(R) PRO/1000 Network Connection
[    5.750269] systemd-udevd[1134]: renamed network interface eth0 to enp2s0

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.

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.

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

see small documentation of it if you like[2]

Okay, let's check that ...

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:

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.

Code: Select all

touch /etc/udev/rules.d/80-net-name-slot.rules
shutdown -r now
...
dmesg|grep eth
[    1.418814] e1000 0000:02:00.0: eth0: (PCI:66MHz:32-bit) 00:0c:29:d7:96:96
[    1.418926] e1000 0000:02:00.0: eth0: Intel(R) PRO/1000 Network Connection
[    5.750269] systemd-udevd[1134]: renamed network interface eth0 to enp2s0

ARRRGGGGH!!

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.

Code: Select all

cd /etc/conf.d
vi net
vi network
vi netmount
cd /etc/init.d
ln -s net.lo net.direnet0

(crosses fingers)

Code: Select all

shutdown -r now

...
dmesg|grep eth
[    1.418814] e1000 0000:02:00.0: eth0: (PCI:66MHz:32-bit) 00:0c:29:d7:96:96
[    1.418926] e1000 0000:02:00.0: eth0: Intel(R) PRO/1000 Network Connection
[    5.750269] systemd-udevd[1134]: renamed network interface eth0 to enp2s0

WHAT. THE. HELL, man??

[Seron]

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.

[mv]

There was not even any way to figure out this stupid name was going to be used

Of course, there was. You must just use the command which was documented in several places.

Code: Select all

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

This is a very clear error message: the syspath is missing from your arguments.

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

s/indecipherable/reliably working
a...and did the right thing for me at this boot by accident.

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

Because the colliding namespaces gave rise to race conditions.

Someone just didn't like using those (ubiquitous) names?

Because it was a very bad idea from the very beginning to use kernel names in user space and simultaneously trying to change the names in userspace while the kernel accesses them in kernel space.

Code: Select all

cd /etc/conf.d
vi net
vi network
vi netmount
cd /etc/init.d
ln -s net.lo net.direnet0

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.

[Anon-E-moose]

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

[mv]

Eth0 was a standard

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.

should be the new naming convention

s/new/userspace/

[Anon-E-moose]

Eth0 was a standard

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.

Just my opinion, of course
Have a great day/night

[Hu]

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

[direwolf]

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:

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

[mv]

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.

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.

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.

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.

[cwr]

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.

Will

[Anon-E-moose]

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.

[mv]

You just don't seem to get it.

I do, but apparently you do not understand the technical reason.

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.

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.

If you are too stupid to understand you should refrain from insults.

[John R. Graham]

@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

[SamuliSuominen]

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

- John

See,

http://cgit.freedesktop.org/systemd/sys ... ed7355eaad

And perhaps,

https://github.com/gentoo/eudev/issues/ ... t-16003597

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.

[John R. Graham]

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

[SamuliSuominen]

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:

http://453494.bugs.gentoo.org/attachment.cgi?id=336774

Of course it's not supported but it reportedly works.

And I wouldn't be completely against someone backporting...

http://github.com/gentoo/eudev/commit/df016d6

...to sys-fs/udev so we could have USE flag like "rename-to-reserved" that would reintroduce the racy code. But I haven't seen anyone working on the effort yet.

[mv]

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.

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.

[John R. Graham]

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

[SamuliSuominen]

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)