Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
udev-197 breaks system (ethX jumping around on boot)
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
Dragonlord
Guru
Guru


Joined: 22 Aug 2004
Posts: 446
Location: Switzerland

PostPosted: Mon Jan 28, 2013 6:56 pm    Post subject: udev-197 breaks system (ethX jumping around on boot) Reply with quote

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:
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?!
_________________
DragonDreams: Leader and Head Programmer
Back to top
View user's profile Send private message
PaulBredbury
Watchman
Watchman


Joined: 14 Jul 2005
Posts: 7310

PostPosted: Mon Jan 28, 2013 8:59 pm    Post subject: Re: udev-197 breaks system (ethX jumping around on boot) Reply with quote

Dragonlord wrote:
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:
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:
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
Back to top
View user's profile Send private message
Dragonlord
Guru
Guru


Joined: 22 Aug 2004
Posts: 446
Location: Switzerland

PostPosted: Tue Jan 29, 2013 12:29 am    Post subject: Reply with quote

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:
# 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?
_________________
DragonDreams: Leader and Head Programmer
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Tue Jan 29, 2013 12:54 am    Post subject: Reply with quote

Dragonlord wrote:
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 )
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Tue Jan 29, 2013 2:41 pm    Post subject: Reply with quote

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 https://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
Back to top
View user's profile Send private message
Dragonlord
Guru
Guru


Joined: 22 Aug 2004
Posts: 446
Location: Switzerland

PostPosted: Tue Jan 29, 2013 7:02 pm    Post subject: Reply with quote

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.
_________________
DragonDreams: Leader and Head Programmer
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Tue Jan 29, 2013 7:11 pm    Post subject: Reply with quote

Dragonlord wrote:
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 SamuliSuominen on Tue Jan 29, 2013 8:17 pm; edited 2 times in total
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Tue Jan 29, 2013 7:51 pm    Post subject: Reply with quote

Quote:
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 ...
Back to top
View user's profile Send private message
Dragonlord
Guru
Guru


Joined: 22 Aug 2004
Posts: 446
Location: Switzerland

PostPosted: Tue Jan 29, 2013 11:44 pm    Post subject: Reply with quote

Typo. Of course it's /etc/udev/rules.d/80-net-name-slot.rules . Removing that one didn't change a thing.
_________________
DragonDreams: Leader and Head Programmer
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Wed Jan 30, 2013 12:43 am    Post subject: Reply with quote

Dragonlord wrote:
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?
Back to top
View user's profile Send private message
Dragonlord
Guru
Guru


Joined: 22 Aug 2004
Posts: 446
Location: Switzerland

PostPosted: Wed Jan 30, 2013 12:59 am    Post subject: Reply with quote

ulenrich wrote:
Dragonlord wrote:
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.
_________________
DragonDreams: Leader and Head Programmer
Back to top
View user's profile Send private message
sera
Retired Dev
Retired Dev


Joined: 29 Feb 2008
Posts: 1017
Location: CET

PostPosted: Wed Jan 30, 2013 9:46 am    Post subject: Reply with quote

ssuominen wrote:
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.

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?
Back to top
View user's profile Send private message
Dragonlord
Guru
Guru


Joined: 22 Aug 2004
Posts: 446
Location: Switzerland

PostPosted: Wed Jan 30, 2013 9:20 pm    Post subject: Reply with quote

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.
_________________
DragonDreams: Leader and Head Programmer
Back to top
View user's profile Send private message
emc
Guru
Guru


Joined: 02 Jul 2004
Posts: 564
Location: Cracow, Poland

PostPosted: Thu Jan 31, 2013 11:20 am    Post subject: Re: udev-197 breaks system (ethX jumping around on boot) Reply with quote

PaulBredbury wrote:

I use the old method, e.g. in /etc/udev/rules.d/10-local.rules:
Code:
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)
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Thu Jan 31, 2013 12:02 pm    Post subject: Re: udev-197 breaks system (ethX jumping around on boot) Reply with quote

emc wrote:
PaulBredbury wrote:

I use the old method, e.g. in /etc/udev/rules.d/10-local.rules:
Code:
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.
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Thu Jan 31, 2013 7:32 pm    Post subject: Reply with quote

Quote:
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/Software/systemd/PredictableNetworkInterfaceNames

Quote:
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.
_________________
TIA
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Fri Feb 01, 2013 12:32 am    Post subject: Reply with quote

I wish some strict semantics here:
Quote:
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)

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 ...
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3264
Location: Canada

PostPosted: Fri Feb 01, 2013 5:35 am    Post subject: Reply with quote

ulenrich wrote:
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.
Back to top
View user's profile Send private message
sera
Retired Dev
Retired Dev


Joined: 29 Feb 2008
Posts: 1017
Location: CET

PostPosted: Fri Feb 01, 2013 7:36 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Fri Feb 01, 2013 10:29 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Dragonlord
Guru
Guru


Joined: 22 Aug 2004
Posts: 446
Location: Switzerland

PostPosted: Sun Feb 03, 2013 3:30 pm    Post subject: Reply with quote

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

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.
_________________
DragonDreams: Leader and Head Programmer
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Sun Feb 03, 2013 5:09 pm    Post subject: Reply with quote

Dragonlord wrote:
@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)
Back to top
View user's profile Send private message
Dragonlord
Guru
Guru


Joined: 22 Aug 2004
Posts: 446
Location: Switzerland

PostPosted: Sun Feb 03, 2013 6:57 pm    Post subject: Reply with quote

ssuominen wrote:
Dragonlord wrote:
@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.
_________________
DragonDreams: Leader and Head Programmer
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Sun Feb 03, 2013 7:19 pm    Post subject: Reply with quote

Dragonlord wrote:

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.

Quote:

+ 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.
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Sun Feb 03, 2013 8:07 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum