Since udev-197 my system became unusable. Upon booting the network interfaces randomly jumped around. on one boot I had eth0 and eth1. On the next boot eth1 and eth2. Yet on another boot eth0 and eth2. It's totally impossible to boot the system with jumping network interfaces like this. Udev claims to fight this problem but before udev-197 I had no such problem and now it's all broken.

By removing the file /etc/udev/rules.d/80-net-name-slot.rules I could prevent the jumping around. But now I've got eth1 and eth2 constantly which doesn't look right. Should udev not use crazy names instead of ethX?

udev 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?!_________________Leader and Head Programmer: Epsylon, Drag[en]gine and others

Note the filename, and the := assignation method, and the address being lower-case, and the fact that my new name doesn't follow the old style of having a number at the end, so that we know it's taking effect.

Get the address using e.g.:

Code:

udevadm info -a -p /sys/class/net/eth0 | grep address

Edit: Can't decide whether to bother adding ACTION=="add"

Last edited by PaulBredbury on Thu Apr 11, 2013 12:06 pm; edited 2 times in total

Actually I would not mind the names based on hardware position. The problem is only that udev-197 doesn't do this as advertized. It renames ethX to ethY and that's plain stupid to begin with. I can't even use the command outlined in the /etc/udev/rules.d/80-net-name-slot.rules as it complains. With other words:

Actually I would not mind the names based on hardware position. The problem is only that udev-197 doesn't do this as advertized. It renames ethX to ethY and that's plain stupid to begin with. I can't even use the command outlined in the /etc/udev/rules.d/80-net-name-slot.rules as it complains.

/etc/udev/rules.d/80-net-name-slot.rules
is a totally commented out file intended to just hide the real
/lib/udev/rules.d/80-net-name-slot.rules
for compatibility reasons.

Upstream Poettering&Co advise to use a more explicit syntax:
/etc/udev/rules.d/80-net-name-slot.rules -pointsTo- /dev/null
(These /dev/null pointers are commonly used at /etc/systemd/system by administrators to disable distribution default units at /usr/lib/systemd/system )_________________fun2gen2

udev can't rename hardware interfaces to already existing names, so when kernel assigns eth0 for the first card it finds, udev can't use it anymore since it's reserved
so what you can do is change the kernel naming before udev even starts using the script (attachment) from http://bugs.gentoo.org/show_bug.cgi?id=453494
but as already referenced in this thread, the real solution is to migrate to the new predictable networking name scheme which obsoletes the need for renaming

But deleting the /lib/udev/rules.d/80-net-name-slot.rules doesn't fix it. According to the comments in there this should enable the new names but instead udev gives me the ethX name-clash crap. Udev starts out with the volatile interfaces names before the renaming according to DMESG._________________Leader and Head Programmer: Epsylon, Drag[en]gine and others

But deleting the /lib/udev/rules.d/80-net-name-slot.rules doesn't fix it. According to the comments in there this should enable the new names but instead udev gives me the ethX name-clash crap. Udev starts out with the volatile interfaces names before the renaming according to DMESG.

Where did you find the information that you should delete /lib/udev/rules.d/80-net-name-slot.rules?
It should be kept there and /etc/udev/rules.d/80-net-name-slot.rules be deleted to enable it.

/bin, /sbin, /lib, /lib32, /lib64, /usr, should all be safe to mount read only, except /usr/src, /usr/portage, and KDE writing directly to polkit's files in /usr -- there is propably more but it SHOULD be supported, just that I'm not sure how well default'ish Gentoo setup runs like that (yet)

Last edited by ssuominen on Tue Jan 29, 2013 8:17 pm; edited 2 times in total

But deleting the /lib/udev/rules.d/80-net-name-slot.rules doesn't fix it. According to the comments in there this should enable the new names but instead udev gives me the ethX name-clash crap. Udev starts out with the volatile interfaces names before the renaming according to DMESG.

"...before the renaming" - which means there is some effect of
/lib/udev/rules.d/80-net-name-slot.rules
showing up in dmesg?_________________fun2gen2

But deleting the /lib/udev/rules.d/80-net-name-slot.rules doesn't fix it. According to the comments in there this should enable the new names but instead udev gives me the ethX name-clash crap. Udev starts out with the volatile interfaces names before the renaming according to DMESG.

"...before the renaming" - which means there is some effect of
/lib/udev/rules.d/80-net-name-slot.rules
showing up in dmesg?

See the first post in this topic. There is the DMESG output._________________Leader and Head Programmer: Epsylon, Drag[en]gine and others

Because the code to do those pseudo in-place switches Dragonlord relied upon was removed.

Dragonlord wrote:

By removing the file /etc/udev/rules.d/80-net-name-slot.rules I could prevent the jumping around. But now I've got eth1 and eth2 constantly which doesn't look right. Should udev not use crazy names instead of ethX?

Quite possibly other old net rules are interfering. Find and remove them?

There seems to be a file generated by the udev update that is not listed anywhere. Removing the file the names changed. But there is no way to figure out before the change what the new names will be. A problem for a server with 3 or more network cards. I'm not going to upgrade if I end up with a non-working server box._________________Leader and Head Programmer: Epsylon, Drag[en]gine and others

Udev can only ask the kernel to rename. It does only if there is an adminitrators instruction.
The kernel refuses by the same rules as he refuses for example:
ln -s /bin /etc
(But using a bind mount you could implement this by force)

wcg wrote:

Why does udev think it needs to rename something that the kernel
has already named in bus probe order?

Udev doesn't think, it only asks what the administrator wants to be asked by his set of rules.

Quote:

Since when? I have never seen a kernel come up with two network devices
in a different order in dmesg on two successive boots.

You are just in the herd of the lucky ones (like me too). But there are tons of possibilities of undefined situations:
- ide and sata
- flashed bios with other sequences occuring
- never tried combinations of devices

Quote:

I guess the question is why is udev renaming interfaces without explicit
instructions

It doesn't, Udev simply doesn't think ...

While we speak about Gentoo Udev we talk about a certain implemented set of rules ..._________________fun2gen2

While we speak about Gentoo Udev we talk about a certain implemented set of rules ...

While strictly speaking nothing in computer 'thinks', only carries out instructions put in by programmers (and you can go down to silicon),
in most cases the distinction is irrelevant for the user. In the case of udev, I suspect 98% of users never ever touched any rules (I am for one, never did), and for them 'rules' are part of udev, rather than configuration options that they chose. In that sense udev rule are further away from 'user configuration level' than even bash scripts of standard init system.

There seems to be a file generated by the udev update that is not listed anywhere. Removing the file the names changed. But there is no way to figure out before the change what the new names will be. A problem for a server with 3 or more network cards. I'm not going to upgrade if I end up with a non-working server box.

You still can give those interfaces individual names, just avoid using names the kernel would hand out as clashes are no longer resolved via temporaries. Ie, edit your old persistent net rules to use interface names like dragonegg, dragonhorst, dragonhart - well, you get the idea.

I know udev does not actually think. One can imagine it as
a state machine. It has a lot of values from kernel device
probes, programmed in defaults, and rules read from
config files (like /etc/udev/udev.conf and /etc/udev/rules.d/*)
that determine its state in this sense. Various states
determine what code paths the udev code follows.

But I think you get my point. What in this set of variables
is sending udev down a code path that tells it to request
that the kernel rename eth0 and eth1 immediately after
boot in the OP's example?

(I have no issue with the concept of persistent network
interface names. It can save a lot of administrative work
when things go haywire. It is similar to mounting by
filesystem label or UUID instead of by drive and partition
number: you can move drives or raid arrays around
in the box at will and still have the same filesystems
mounted on the same mountpoints at boot without
editing fstab to account for changed device probe
order.)_________________TIA

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.

Can you please either fix UDev-197 or better mask it since it's a broken mess?

sera wrote:

Dragonlord wrote:

There seems to be a file generated by the udev update that is not listed anywhere. Removing the file the names changed. But there is no way to figure out before the change what the new names will be. A problem for a server with 3 or more network cards. I'm not going to upgrade if I end up with a non-working server box.

You still can give those interfaces individual names, just avoid using names the kernel would hand out as clashes are no longer resolved via temporaries. Ie, edit your old persistent net rules to use interface names like dragonegg, dragonhorst, dragonhart - well, you get the idea.

I don't use custom network names as this is not the way a system should be build to begin with. I could do this but see the problem above the quote for why this doesn't get you anywhere with the mess called udev-197._________________Leader and Head Programmer: Epsylon, Drag[en]gine and others

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

Perhaps deleting the file was a bad advise in a sense that stable udev, 197-r4 always recopies the file there if it's not there, so instead of deleting the file, copy the one from /lib/udev/rules.d/80-net-name-slot.rules to /etc/udev/rules.d/

Code:

# cp -f /lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/

(For now, deleting the file is only okay for ~arch users due to the ebuild behavior)

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

Perhaps deleting the file was a bad advise in a sense that stable udev, 197-r4 always recopies the file there if it's not there, so instead of deleting the file, copy the one from /lib/udev/rules.d/80-net-name-slot.rules to /etc/udev/rules.d/

Code:

# cp -f /lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/

(For now, deleting the file is only okay for ~arch users due to the ebuild behavior)

Not a solution. The coments in 80-net-name-slot.rules state explicitly that:

Quote:

To activate this function, move this file to a name that doesn't end in.rules or remove it then reboot your system.

But if udev-197 keeps reinstalling this file this is totally impossible to get working properly.

With other words udev-197 is seriously broken and needs to be masked to protect innocent users.

EDIT:
To better show why this is broken the full quote of the important comment parts:

Quote:

# This file is here to prevent your interfaces from being renamed automatically,
# because the new names will be drastically different from the eth*, wlan*, etc
# names you are used to working with.
#
# To activate this function, move this file to a name that doesn't end in.rules,
# or remove it then reboot your system.

With other words to get interfaces with names like epXsY you need this file to be deleted... but udev reinstalls it always. That's the major problem.

EDIT: EDIT:
The file in question is empty only having comments. It's thus the mere presence of the file that is important not the content._________________Leader and Head Programmer: Epsylon, Drag[en]gine and others