udev-197 breaks system (ethX jumping around on boot)

[Bones McCracker]

@All:

WTF is this UDev crap? I managed to get the interface auto-named as enp3s0 which is fine for me as I don't need special names. But now I did a weekly emerge and udev got recompiled. What does this bitch do? It broke my system AGAIN! No more network devices. What happened? Udev recreated all the files I deleted to get it working and broke everything again.

This wouldn't be such a problem for you if you had bothered to read the guidance and figure out for yourself what you need to do for your system, instead of ranting, being obnoxious to the people who maintain this package voluntarily for you, and demanding like a child that other people tell you how to administer your system. Try to show a little more dignity and basic human courtesy.

[allaboutmike]

Perhaps it is sprained? But seriously...

If you upgrade when suggested (as I usually do) and then you follow the instructions given when upgrading (which I have learned to always read carefully) then you usually avoid problems.
Not this time.

udev-197 and newer introduces a new method of naming network
interfaces. The new names are a very significant change, so
they are disabled by default on live systems.

Ooh, better leave those alone then.

Upstream has removed the possibility of renaming to existing
network interfaces. For example, it's not possible to assign based
on MAC address to existing interface eth0.

Hmm, that sounds like how I sort out my three ethernet interfaces. Better read that 80-* rule file and see what to do!

From that file...

# This functionality has not been tested with gentoo. In fact, we are aware that
# things will break if you activate it.
#
# If you are not comfortable testing this, leave this file as is. We will
# publish a news item when you can migrate.

Holy crap! I don't want to break my server, better leave that alone then.

Reboot: renaming doesn't work now depending on what order the interfaces are detected.
Hmm, the old 70-persistent-net.rules file is making it try to do the (now) impossible!
Got rid of that and no more complaining or missing interfaces. Also no more knowing what interface will end up where. My system seems to randomly reorder every boot!

So. My choices according to the info so far seemed to be:
A. Leave old rules in place: randomly fails depending on detection order. Some interfaces work some times : No way!
or
B. Remove old persistent-net rules and go with unpredictable kernel names: random ethX devices! : No Way! (They invented that file for a reason.)
or
C. Remove old files and 80-* and go with new predictable names: "Untested on Gentoo. In fact, we are aware that things will break if you activate it." : Doesn't sound like a good idea either!

so...

D. Ask Google: After reading for about an hour, I deciphered the mess and went what I think is a much simpler way.

1. Leave the 80-* file as is. A reinstall of udev will apparently put it back anyway. (Surely that is broken? There must be a permanent way to set this on or off.)
2. Edit the old 70-persistent-net.rules file and simply change all ethX to netX. This gives predictable MAC->netX naming which doesn't trip over preexisting device names, because netX names are not used by the kernel. Detection order is no longer a problem.
3. Edit /etc/conf.d/net and other files (eg /var/lib/iptables/rules.save) that mention ethX and change them to use netX. (Is this what will break if you change to the new names?)
4. Reboot and live happily ever after! (Until the next unexpected udev change anyway.)

This way, everything works just the way it used to, only the eth's are all net's. I found that much easier to understand.

[Bones McCracker]

Somebody with a working brain! Imagine that!

[Dragonlord]

Somebody with a working brain! Imagine that!

For your information mister super-duper I did exactly what has been mentioned above... but only after everythign printed by eselect news, emerge messages and comments in the various udev files not only contradict each other but are flat out incorrect in some places. You really want to call this mess the "right way to do it"? I understand that this is voluntary work but GenToo has the notion of "stable" and "testing". If a mess like this happens with testing stuff I say nothing because it is not supposed to work out of the box. Stable stuff though should be safe enough to use except unforseen consequences which are again fine for me. That's what system administrators are for. But turning a stable package into such a mess is just not worth of the notion "stable" on GenToo. I just think a seriously broken package has to be demoted into "testing" (aka masked) until it is stable enough to deserve the "stable" spot. You can call names and and insult me as long as you want but it doesn't change the fact this package is not working correctly and doesn't deserve the "stable" notion. If I would program a mess like this I would be ashamed down into the ground and fix it and not go around insulting others like you just did.

[SamuliSuominen]

Somebody with a working brain! Imagine that!

For your information mister super-duper I did exactly what has been mentioned above... but only after everythign printed by eselect news, emerge messages and comments in the various udev files not only contradict each other but are flat out incorrect in some places. You really want to call this mess the "right way to do it"? I understand that this is voluntary work but GenToo has the notion of "stable" and "testing". If a mess like this happens with testing stuff I say nothing because it is not supposed to work out of the box. Stable stuff though should be safe enough to use except unforseen consequences which are again fine for me. That's what system administrators are for. But turning a stable package into such a mess is just not worth of the notion "stable" on GenToo. I just think a seriously broken package has to be demoted into "testing" (aka masked) until it is stable enough to deserve the "stable" spot. You can call names and and insult me as long as you want but it doesn't change the fact this package is not working correctly and doesn't deserve the "stable" notion. If I would program a mess like this I would be ashamed down into the ground and fix it and not go around insulting others like you just did.

You haven't yet mentioned how it's broken. It's not. Not in the business of masking working packages because some admins are unwilling to either read documentation, or change.

[Bones McCracker]

I didn't insult you. You insulted yourself, by behaving like a petulant, self-centered child. Rather than go on a rant and derogate volunteer developers you could offer helpful suggestions, or at least do your homework before wailing helplessly about your full diaper. That kind of negativity and insulting tone isn't helpful to anybody.

[Dragonlord]

Always funny how those insulting others crank up the insulting level and call others insulting them if poked at their behavior. Sorry to say this but I don't need these kinds of insults. They solve nothing... as pretenting problems don't exist doesn't solve anything. And helping is quite a problem if solutions are brushed aside and problems declared WONTFIX in the hope no extra work to fix it is required. But I guess this is the new GenToo style: problems? WONTFIX

[Bones McCracker]

I didn't insult you there either. I accurately described your behavior, which you had already exhibited for all to see and recognize as such.

Are you now going to continue to abrasively make a spectacle of yourself?

Or, maybe you should apologize for your hostility and rudeness, thank ssuominen for doing his best to maintain the software for you, thank those who offered useful help, and be on your way.

[Ant P.]

But I guess this is the new GenToo style: problems? WONTFIX :thumbsup:

The only way the problem in this thread can be fixed is with liberal application of a LART.

[emc]

Back to the topic after compiling udev-197-r8 should I add something like:

Code: Select all

SUBSYSTEM=="net", ATTR{address}=="54:04:a6:14:c3:ba", ACTION=="add", NAME:="eth1"
SUBSYSTEM=="net", ATTR{address}=="74:2f:68:a8:1d:bb", ACTION=="add", NAME:="wlan0"
SUBSYSTEM=="net", ATTR{address}=="54:04:a6:0a:9d:68", ACTION=="add", NAME:="eth0"

to /etc/udev/rules.d/80-net-name-slot.rules file or just leave it untouched and commented. I don't want new udev functionality....

[fbcyborg]

is totally craz. it moves eth1 to eth2 and eth0 to eth1. What the fuck is that? How in Gods name is one supposed to fix this f'ing mess?!

Holy words mate!

I'm still wating before upgrading udev from 171 to 197 on my laptop because it is a mess.
I have a lot of custom device mapping among network and disk devices.
For example, the /dev/sdX to /dev/foo remapping is no longer working as well on my desktop PC. Fortunately I don't have network card issues on such PC.
But the laptop has many more custom mappings and I certainly don't want to mess up things because of udev!

[lost+found]

Here's a trick I use, that prevents the jumping netcards. It might be useful for some people. It works, at least on my system, when the cards use different drivers. The one compiled into the kernel image always gets eth0, because it's detection is faster. The other one compiled as a module gets eth1.

[dch24]

Got bitten bad by this today on a production machine with 5 NICs. It took way too much downtime to figure out that the root cause was something done 2 reboots ago - the natural first place to look was the last reboot (when udev was upgraded we always check device mappings but this time device mappings changed on the 2nd reboot without notice).

Moving to option D:

D. Ask Google: After reading for about an hour, I deciphered the mess and went what I think is a much simpler way.

[tuner23]

..best explantation of udev, sysfs and all that stuff i ever read

http://tuomov.bitcheese.net/b/archives/ ... /T20_34_21

[_______0]

mm.... so how to use the new way?

also net.lo no longer exists??