[systemd-devel] Udev won't rename interfaces that are already UP

[Tom Gundersen]

On Thu, Feb 19, 2015 at 11:32 AM, Reindl Harald <h.reindl at thelounge.net> wrote:
> @Tom: sorry for the off-list reply, your reply-all disabled "reply to list"
> in my MUA :-(
>
> Am 19.02.2015 um 11:23 schrieb Tom Gundersen:
>> That is a related problem, but it is a minor detail. The point is that
>> we don't want to have to store state on disk (about which interface
>> should have which name). The only way then is to find an algorithm
>> that will always compute the same name for the same interface without
>> referring to any state. Topology is one way. Firmware information is
>> another. MAC addresses is another. Using the kernel names as-is is out
>> of the question. Having a list on disk mapping interfaces to names is
>> also out of the question.
>
> "Having a list on disk mapping interfaces to names is also out of the
> question" because it would solve the problem?

Yes. We don't like solving problems. Only creating them ;-)

No, seriously, the problem is that while in most cases writing state
to disk would be fine, there are cases where we don't have a writeable
disk at the right time. We can never assume /etc to be writable
(except due to explicit admin requests, never automatically due to
hardware events etc) and we can not assume /var to be available during
early boot. Moreover, the more state we rely on the more things can
break. To the extent possible we don't want the admin to have to worry
about wiping state from disk (having this attitude from the get-go
makes it much nicer when we do things like fresh /etc and/or /var on
every boot).

> frankly that worked over many years with udev rules and still works if you
> put the MAC in the ifcfg-ethX

You can still have a list of MAC addresses and interface names with
today's udev. What we won't do is to generate the list on-the-fly when
interfaces appear. And yeah, you'll have to name them something else
than ethX to avoid the kernel race. But that is surely not a huge
problem (solving it, would be really ugly).

> get rid of the race with kernel it would only have needed a agreement that
> the kernel autonaming use a different scheme not colliding with ethX and as
> all the years before on Fedora facing the first time a new ethernet card
> appears configure the ethX in the udev rules

We don't explicitly ban ethX in udev, we just say that you have to use
different names than the kernel. If you convince the kernel developers
to call all the links fooZ you can rename to ethX just fine.

> the problem with the current way is that you can't rely any longer that
> eth0, eth1, eth2 are present on different hardware as long as you don't
> disable "predictable interface names" - well, i can live with that and have
> my ethX but that don't make the new scheme better

Yeah, if you really want eth0,1,2, then just disable the logic. It
cannot be the default though. It just does not work. Feel free to
prove me wrong by posting a patch implementing this whilst keeping the
properties we need. I think you should know all the concerns by now,
so no need for me to repeat myself yet again.

> there are people with the need to re-use unmodified config files instead
> fork them on every machine.....

Yeah, this is something we have kept in mind with our own config files
(in networkd in particular). We have an elaborate matching logic
precisely because we want config files to be reusable to the greatest
degree possible. It probably works for you by just making sure the
naming scheme for your links is the same on all your machines (or
maybe your machines just give that to you for free because you are
lucky), but in general that is not powerful enough and not reliable
enough.