[systemd-devel] Stable interface names even when hardware is added or removed, not true

Pekka Sarnila sarnila at adit.fi
Thu Nov 17 21:29:16 UTC 2016



On 11/16/16 23:26, Dave Reisner wrote:
>
>
> On Wed, Nov 16, 2016 at 4:19 PM, Pekka Sarnila <sarnila at adit.fi
> <mailto:sarnila at adit.fi>> wrote:
>
>
>
>     On 11/16/16 18:11, Greg KH wrote:
>
>         On Wed, Nov 16, 2016 at 03:33:42PM +0200, Pekka Sarnila wrote:
>
>             On 'Predictable Network Interface Names' it states as a
>             benefit of the new
>             policy:
>
>               Stable interface names even when hardware is added or
>             removed, i.e.
>               no re-enumeration takes place
>
>             Unfortunately this is not true.
>
>             I'm running a mail server, kernel 4.8.6. Graphics card
>             started to fail.
>             Replaced it with new one (newer model). Booted the system.
>
>             All seemed to be fine, network seemed to work. But after
>             some time got angry
>             cries: 'can't read the mail !!!'. A big headache.
>
>             Although the new card was in the same slot as the old one
>             kernel had changed
>             the name enp6s0 -> enp3s0 (no firmware/BIOS index available
>             and kernel
>             policy was used as default). Since enp6s0 was not found our
>             server instead
>             of fixed ip address used our dhcp-server to get a random
>             temp address. Thus
>             network worked, but not in the mail-servers correct address.
>
>             To figure this out took some nervous time.
>
>             Now, I don't know why kernel driver got a different name for
>             this network
>             interface (ethernet hardware is on the motherboard, and it
>             is the only net
>             hardware on the system). But obviously it can happen.
>
>
>         That is because your PCI devices renumbered themselves, which is
>         quite
>         common when changing PCI devices around (or adding/removing
>         them).  Not
>         much systemd can do about this, sorry.
>
>         greg k-h
>
>
>     Well my first point was that the web page should not say
>
>     >>   Stable interface names even when hardware is added or removed, i.e.
>     >>   no re-enumeration takes place
>
>     But second was that in principle persistent naming would be possible
>     for systems with only one interface. And it should possible to
>     implement it in systemd-network, and make it systemd package default
>     for such case.
>
>
> No, it's not. It sounds more like you want to disable the naming policy,
> which means you get "eth0" for the first device that shows up.

No thats not at all what I'm suggesting. I have also had my time getting 
gray hair for this 'is it eth0 or eth1 this time'.

But on servers that have only one interface (and no one is allowed to 
hot plug anything what so ever) the old method was better: always eth0. 
And you didn't need to understand how the names are given even when 
upgrading hardware. Of course for other cases the old way was not good.

I still believe that people who's job is to see that servers hardware is 
running don't in most cases know how to configure systemd or much 
anything about the os to that matter.

I'm sure systemd could be developed to count the interfaces right after 
boot, and there could be in the configuration setting saying that if 
there is only one interface at the boot time a name in that 
configuration would be given to that interface.

So what I'm saying, it should be possible the have the good of the old 
and good of the new way in the same package. I don't believe it is alway 
win loose situation

Anyway no big deal.

pekka

>
>
>     pekka
>
>     _______________________________________________
>     systemd-devel mailing list
>     systemd-devel at lists.freedesktop.org
>     <mailto:systemd-devel at lists.freedesktop.org>
>     https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>     <https://lists.freedesktop.org/mailman/listinfo/systemd-devel>
>
>


More information about the systemd-devel mailing list