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.

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

(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):
https://bugzilla.redhat.com/show_bug.cgi?id=896135
http://pkgs.fedoraproject.org/cgit/systemd.git/diff/0013-F18-Revert-udev-network-device-renaming-immediately-.patch?h=f18&id=54dbdc6c2a513fed37fdec82d70fbba1f9cc37e6

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>

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.

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

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.

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.

It's fixed in ALT Linux package, our maintainer is a sane person indeed.