Bug 53837 - udev: network device renaming broken
Summary: udev: network device renaming broken
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
Depends on:
Reported: 2012-08-20 11:54 UTC by Jan Rękorajski
Modified: 2013-06-06 11:58 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:

dmesg from faulty boot (46.00 KB, text/plain)
2012-08-20 11:54 UTC, Jan Rękorajski

Description Jan Rękorajski 2012-08-20 11:54:40 UTC
Created attachment 65824 [details]
dmesg from faulty boot

The commit 97595710b77aa162ca5e20da57d0a1ed7355eaad "udev: network device renaming - immediately give up if the target name isn't available" causes network device renaming breakage on kernel 3.5.2. Of the two rules:

KERNEL=="eth*", ATTRS{address}=="00:18:fe:28:ac:f2", NAME="wan"
KERNEL=="eth*", ATTRS{address}=="00:18:fe:28:ac:f3", NAME="eth0"

only the first one gets executed, attached dmesg from faulty boot.

Reverting that commit makes rename work again.
Comment 1 Kay Sievers 2012-08-20 12:12:56 UTC
Please use biosdevname or name the devices other than ethX.

We do not try to race against the kernel anymore, and therefore do not
support swapping names around in the kernel namespace.

In short: Devices can no longer be renamed to ethX.
Comment 2 Jan Rękorajski 2012-08-20 12:58:01 UTC
Ok, but I just want to point out that you are breaking a lot of existing configs with this policy. And I can't find any information concerning this change...
Comment 3 Michael Shigorin 2013-05-16 17:59:02 UTC
(In reply to comment #1)
> In short: Devices can no longer be renamed to ethX.
I do know the problems with renaming in ethX namespace but kindly request that you restore the functionality that was broken with the commit referenced.

It may come with a big red warning for those of lame us who still prefer racing against kernel to having broken user systems after upgrades as there are other distros than Fedora which don't neccessarily stick to "reinstall your gnome desktop each time" approach and do actually try and support upgrades over years.

And even Fedora 18 had this "enhancement" reverted (F19 doesn't):

Please do udev maintenance responsibly as Linus has urged you already and write better commit messages than "udev: network device renaming - immediately give up if the target name isn't available" one-liner in this particular case.

Credits for the research and references: Sergey Vlasov <vsu altlinux org>
Comment 4 Kay Sievers 2013-05-16 20:13:52 UTC
It's too broken to support it, we finally get rid of this sick game nobody
can win, and it's not coming back. It was a mistake to ever do that in the
first place. "Responsibly" closing it.
Comment 5 Michael Shigorin 2013-05-16 20:31:22 UTC
I would volunteer to write a README [section] explaining the root cause and to field the related questions so that you don't have to if you might accept that.

Kay, I asked to be responsible, not "responsible".  Breaking backwards compatibility is something that should be more seriously backed than "we have thought and I ripped it out".  That patch works for me right now over 204 (applied with minor fuzz), just in case.

Even GNOME folks seem to have been getting the message finally, please listen to your users too.

TIA :-)
Comment 6 Kay Sievers 2013-05-16 20:56:49 UTC
I see only one option and that would be to teach the kernel with an option
to reserve 0-99 or whatever of ethX, so this range can be used by userspace to
rename *to*. That tunable could be set by the system before any kernel module
is loaded.

We will not play the silly games with retry-loops in hotplug paths to
race against the kernel creating new device while we try to rename in
userspace the same thing, and fail.

What we had is not coming back to udev, no matter how many times you
open the bug again. :) If you really care and do the kernel work, all would
just work without racy unreliable loops in udev.

Newer udev versions will not play these wrong games in userspace fighting
*against* the kernel.

I spent far too much time over the years with supporting the fallout of that
bad idea in the first place, and I'll not waste any more time with it.

It just did not work reliably, and never will, and we stopped pretending
to solve problems we cannot solve in that way.

As mentioned, I guess it's a problem that can be solved with help of the
kernel, but not by udev alone.

Closing it again.
Comment 7 Michael Shigorin 2013-05-16 21:14:54 UTC
Hey thanks for the time taken to express the current upstream position (I get a lot of interrupts either so do value the effort); asked our kernel folks to have a look.

But my reasoning is: why kill off the legacy behaviour in haste instead of just letting it be deprecated for a few years so those upgrading would have a bit less surprises left for them?  Just declare it unsupported so it doesn't bite you.

If there's a more appropriate state for bugs depending on other fixes, let's drop the bug into that one.
Comment 8 Michael Shigorin 2013-06-06 11:58:53 UTC
It's fixed in ALT Linux package, our maintainer is a sane person indeed.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.