[systemd-devel] 70-persistent-net.rules

[Kay Sievers]

On Thu, Apr 11, 2013 at 12:41 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Andrey Borzenkov at 11/04/13 10:25 did gyre and gimble:
>> On Thu, Apr 11, 2013 at 2:50 AM, Reindl Harald <h.reindl at thelounge.net> wrote:
>>> /usr/share/doc/systemd/README.Fedora-18
>>>
>>> - A hacky workaround that allows udev to rename network interfaces into
>>>   kernel's ethX namespace has been re-added. This is to support users who still
>>>   rely on udev rules such as 70-persistent-net.rules generated in previous
>>>   Fedora releases to name their network interfaces. Note that the workaround is
>>>   only temporary and will go away in a future Fedora release
>>> ______________________________________
>>>
>>> PLEASE DO NOT remove this mechanism

It is already. There was a backport for Fedora 18, it will not be part
of Fedora 19.

>>> well, you are not creating it since a long time, BUT do not
>>> stop use this config file if it is present!
>>>
>>
>> Mmm ... if rules file exists in correct directory it of course will be
>> used. Or do you mean to not remove auto-generation of this file?

Renaming will fail if the target name is busy, and it will be busy in
most cases.

> Isn't the mechanism used to shuffle around conflictingly named
> interfaces gone from udev these days (it is after all racy and buggy).

It is gone for good and will not come back, yes.

> If so then things might not work nicely when processing the old rules.
> Users should be strongly encouraged to migrate to the persistent network
> interface names which avoids the design flaws inherent with the
> previously approach.

Yes, that breaks. The solution for such legacy requirements is to not
have any renaming active and manually enforce module loading order.

The base os will not make any promises again about predictable ethX
names, it was a really big mistake to ever do that. It creates far
more problems than it solves on machines which are not very simple
setups. It's not a solvable problem, and we should not pretend we can
solve it.

Kay