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

[Dragonlord]

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?

Here an excert of the DMESG:

Code: Select all

r8169 0000:03:00.0: eth0: RTL8168b/8111b at 0xffffc9000000c000, 00:1f:e2:5c:c7:f8, XID 18000000 IRQ 44
r8169 0000:03:00.0: eth0: jumbo features [frames: 4080 bytes, tx checksumming: ko]
r8169 0000:04:00.0: eth1: RTL8168b/8111b at 0xffffc9000000e000, 00:1f:e2:5c:c7:f9, XID 18000000 IRQ 45
r8169 0000:04:00.0: eth1: jumbo features [frames: 4080 bytes, tx checksumming: ko]
systemd-udevd[2095]: renamed network interface eth1 to eth2
systemd-udevd[2094]: renamed network interface eth0 to eth1
r8169 0000:03:00.0: eth1: link down
r8169 0000:03:00.0: eth1: link down
IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
r8169 0000:03:00.0: eth1: link up
IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

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

[PaulBredbury]

Should udev not use crazy names instead of ethX?

You probably want predictable network interface names.

I use the old method, e.g. in /etc/udev/rules.d/10-local.rules:

Code: Select all

ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="00:11:6d:4c:9e:d5", NAME:="inet"

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

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

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

[Dragonlord]

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:

Code: Select all

# udevadm test-builtin net_id /sys/class/net/ifname
calling: test-builtin
=== trie on-disk ===
tool version:          197
file size:         5481459 bytes
header size             80 bytes
strings            1230475 bytes
nodes              4250904 bytes
load module index
unable to open device '/sys/class/net/ifname'

unload module index

Did I say already that udev-197 is a fucking broken mess?

[ulenrich]

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 )

[SamuliSuominen]

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

[Dragonlord]

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.

[SamuliSuominen]

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)

[ulenrich]

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.

The old wisdom:
Where something can go wrong it will some time, where is the slightest chance something can be misunderstood ....

Perhaps pointers to /dev/null carry no chance at all to be misunderstood ...

[Dragonlord]

Typo. Of course it's /etc/udev/rules.d/80-net-name-slot.rules . Removing that one didn't change a thing.

[ulenrich]

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?

[Dragonlord]

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.

[sera]

udev can't rename hardware interfaces to already existing names

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

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?

[Dragonlord]

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.

[emc]

I use the old method, e.g. in /etc/udev/rules.d/10-local.rules:

Code: Select all

SUBSYSTEM=="net", ATTR{address}=="00:11:6d:4c:9e:d5", ACTION=="add", NAME:="wlan"

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.

I did (2 first steps advised from udev-197 ebuild):
- rename 70-persistent-net.rules to 70-net-persistent.rules
- revdep-rebuild --library '/lib64/libudev.so.0' && rm '/lib64/libudev.so.0'
- add 10-local.rules (I just add eth0 and wlan0)

And it work as before udev-197 (from end-user perspective)

[SamuliSuominen]

I use the old method, e.g. in /etc/udev/rules.d/10-local.rules:

Code: Select all

SUBSYSTEM=="net", ATTR{address}=="00:11:6d:4c:9e:d5", ACTION=="add", NAME:="wlan"

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.

I did (2 first steps advised from udev-197 ebuild):
- rename 70-persistent-net.rules to 70-net-persistent.rules
- revdep-rebuild --library '/lib64/libudev.so.0' && rm '/lib64/libudev.so.0'
- add 10-local.rules (I just add eth0 and wlan0)

And it work as before udev-197 (from end-user perspective)

If you do the renaming in 10-local.rules, then why do you have (the now renamed) 70-net-persistent.rules file at all? If you haven't edited it yourself, you shouldn't have it at all.

And it won't work unless you also grabbed the workaround script from bug 453494. It may seem to work if kernel assigned the names like you would have.

[wcg]

udev can't rename hardware interfaces to already existing names

Why does udev think it needs to rename something that the kernel
has already named in bus probe order? Why does it not simply use
the kernel's name, in the case of eth? and wlan? interfaces?

edit:
From http://www.freedesktop.org/wiki/Softwar ... rfaceNames

the driver probing is generally not predictable for modern technology

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

In theory, I understand this. It would be cool to be able to have "upstream"
(eth0) hardware fail without changing the device names of "downstream"
(ethX with X > 0) network interfaces on a reboot.

I guess the question is why is udev renaming interfaces without explicit
instructions to name specific mac addresses with specific device names.

[ulenrich]

I wish some strict semantics here:

udev can't rename hardware interfaces to already existing names

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)

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.

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

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

[dmpogo]

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

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.

[sera]

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.

[wcg]

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

[Dragonlord]

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

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

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.

[SamuliSuominen]

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

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

[Dragonlord]

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

# 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:

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:

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

[SamuliSuominen]

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

You seriously need to calm down. Not masking working udev because of a "bug" in a comment. Heh.

+ 03 Feb 2013; Samuli Suominen <ssuominen@gentoo.org>
+ files/80-net-name-slot.rules:
+ Recommend copying the file from /lib/udev/rules.d/ to /etc/udev/rules.d/
+ instead of deleting this dummy file because stable udev's ebuild will always
+ put the file in place if it isn't there already.

[ulenrich]

Why not, if new-net-stable-slot-names are aspired:
ln -sf /lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules