Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #239477 > unrolled thread

How to avoid systemd/udev unpredictable NIC names

Back to article view | Back to linux.debian.user

Contents

  How to avoid systemd/udev unpredictable NIC names Steve Keller <keller.steve@gmx.de> - 2021-08-30 22:40 +0200
    Re: How to avoid systemd/udev unpredictable NIC names Greg Wooledge <greg@wooledge.org> - 2021-08-30 23:00 +0200
      Re: How to avoid systemd/udev unpredictable NIC names Andrei POPESCU <andreimpopescu@gmail.com> - 2021-08-31 12:50 +0200
        Re: How to avoid systemd/udev unpredictable NIC names Greg Wooledge <greg@wooledge.org> - 2021-08-31 13:40 +0200
        Re: How to avoid systemd/udev unpredictable NIC names Reco <recoverym4n@enotuniq.net> - 2021-08-31 16:00 +0200
          Re: How to avoid systemd/udev unpredictable NIC names Andrei POPESCU <andreimpopescu@gmail.com> - 2021-09-01 19:30 +0200
    Re: How to avoid systemd/udev unpredictable NIC names Dan Ritter <dsr@randomstring.org> - 2021-08-30 23:10 +0200
      Re: How to avoid systemd/udev unpredictable NIC names Dan Ritter <dsr@randomstring.org> - 2021-08-30 23:30 +0200
      Re: How to avoid systemd/udev unpredictable NIC names Greg Wooledge <greg@wooledge.org> - 2021-08-30 23:30 +0200
        Re: How to avoid systemd/udev unpredictable NIC names IL Ka <kazakevichilya@gmail.com> - 2021-08-30 23:50 +0200
          Re: How to avoid systemd/udev unpredictable NIC names Greg Wooledge <greg@wooledge.org> - 2021-08-31 00:10 +0200
            Re: How to avoid systemd/udev unpredictable NIC names Steve Keller <keller.steve@gmx.de> - 2021-08-31 02:10 +0200
              Re: How to avoid systemd/udev unpredictable NIC names Greg Wooledge <greg@wooledge.org> - 2021-08-31 02:50 +0200
                Re: How to avoid systemd/udev unpredictable NIC names Tixy <tixy@yxit.co.uk> - 2021-08-31 22:10 +0200
          Re: How to avoid systemd/udev unpredictable NIC names Thomas Hochstein <thh@thh.name> - 2021-08-31 00:50 +0200
        Re: How to avoid systemd/udev unpredictable NIC names Steve Keller <keller.steve@gmx.de> - 2021-08-31 01:30 +0200
          Re: How to avoid systemd/udev unpredictable NIC names <tomas@tuxteam.de> - 2021-08-31 08:30 +0200
          Re: How to avoid systemd/udev unpredictable NIC names Andrei POPESCU <andreimpopescu@gmail.com> - 2021-08-31 12:50 +0200
          Re: How to avoid systemd/udev unpredictable NIC names David Wright <deblis@lionunicorn.co.uk> - 2021-08-31 16:30 +0200
    Re: How to avoid systemd/udev unpredictable NIC names IL Ka <kazakevichilya@gmail.com> - 2021-08-30 23:30 +0200
    Re: How to avoid systemd/udev unpredictable NIC names Roberto C. Sánchez <roberto@debian.org> - 2021-08-31 01:30 +0200
      Re: How to avoid systemd/udev unpredictable NIC names Steve Keller <keller.steve@gmx.de> - 2021-08-31 02:10 +0200
    Re: How to avoid systemd/udev unpredictable NIC names George Shuklin <george.shuklin@gmail.com> - 2021-08-31 15:50 +0200

Page 1 of 2  [1] 2  Next page →

#239477 — How to avoid systemd/udev unpredictable NIC names

I plan to upgrade a server from	Debian stretch to buster.  Having read
the release notes I wonder what's the best way to avoid the new scheme
of unpredictable network interface names.

I don't	care what PCI bus and what slot	my NICs	are attached to, I
don't want to learn and don't want to have to remember this hardware
configurationan and I don't want to type these cumbersome and error
prone names.  I simply have eth0 for the internal network and eth1 for
my external network to the DSL router.  That's easy and I want to keep
it that way.

The Debian wiki	on this	shows several ways involving kernel cmdline,
udev, and systemd.  I've read it, I've also read some of the sparse
and incomplete systemd documentation for almost an hour.  Still I
don't know when and what software component (kernel, udev, systemd)
decides the NIC names and whether and in which way these conflict each
other. [1]

Also, after reading the	wiki it's still	unclear	to me, which of	the
several ways will survive the next upgrade to bullseye.

The safest way seems to	be what's called "Custom schemes" but this
section explicitly states the names eth0, etc. shouldn't be used.

So I'm still confused what to do after the upgrade to buster to	keep
my network names.

Steve


[1] Unfortunately, much	of the Linux community and many	distributions
    try to get as far away from its Unix roots as possible, away from
    the good KISS principle, and instead repeat all the mistakes
    Windows has made in making everything complex, automagic, obscure,
    instable, and unpredictable.

[toc] | [next] | [standalone]

#239478

On Mon, Aug 30, 2021 at 10:20:46PM +0200, Steve Keller wrote:
> I plan to upgrade a server from	Debian stretch to buster.  Having read
> the release notes I wonder what's the best way to avoid the new scheme
> of unpredictable network interface names.

You say "server", so I'm guessing it has more than one NIC.  That means
the old way (net.ifnames=0) is not viable.

Your best strategy is to create systemd.link(5) files, and give the NICs
the names you want them to have, based on their MAC addresses.

For example:

unicorn:~$ cat /etc/systemd/network/10-lan0.link 
[Match]
MACAddress=18:60:24:77:5c:ec

[Link]
Name=lan0
unicorn:~$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 18:60:24:77:5c:ec brd ff:ff:ff:ff:ff:ff

This is also viable on a single-NIC machine (like mine), but in that
case net.ifnames=0 would also suffice.

[toc] | [prev] | [next] | [standalone]

#239509

[Multipart message — attachments visible in raw view] — view raw

On Lu, 30 aug 21, 16:41:39, Greg Wooledge wrote:
> On Mon, Aug 30, 2021 at 10:20:46PM +0200, Steve Keller wrote:
> > I plan to upgrade a server from	Debian stretch to buster.  Having read
> > the release notes I wonder what's the best way to avoid the new scheme
> > of unpredictable network interface names.
> 
> You say "server", so I'm guessing it has more than one NIC.  That means
> the old way (net.ifnames=0) is not viable.
> 
> Your best strategy is to create systemd.link(5) files, and give the NICs
> the names you want them to have, based on their MAC addresses.
> 
> For example:
> 
> unicorn:~$ cat /etc/systemd/network/10-lan0.link 
> [Match]
> MACAddress=18:60:24:77:5c:ec
> 
> [Link]
> Name=lan0

Another completely different approach is to use some other tool to 
configure your network that can match on MAC address and just ignore the 
names completely.

For systemd-networkd

/etc/systemd/network/my.network

[Match]
MACAddress=ab:cd:ef:12:34:56

[Network]
Address=192.168.1.123/24
Gateway=192.168.1.1
DNS=192.168.1.1

and enable systemd-networkd (and optionally systemd-resolved), see 
/usr/share/doc/systemd/README.Debian.gz for more info.


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#239511

On Tue, Aug 31, 2021 at 01:32:32PM +0300, Andrei POPESCU wrote:
> Another completely different approach is to use some other tool to 
> configure your network that can match on MAC address and just ignore the 
> names completely.
> 
> For systemd-networkd
> 
> /etc/systemd/network/my.network
> 
> [Match]
> MACAddress=ab:cd:ef:12:34:56
> 
> [Network]
> Address=192.168.1.123/24
> Gateway=192.168.1.1
> DNS=192.168.1.1

This still leaves you with an unpredictable interface name.  If you
have to use that interface name in some other part of your configuration
(e.g. a firewall) then this isn't ideal.

If you don't care about the names at all, then this may be feasible.

It's good to have options, though.

[toc] | [prev] | [next] | [standalone]

#239516

On Tue, Aug 31, 2021 at 01:32:32PM +0300, Andrei POPESCU wrote:
> On Lu, 30 aug 21, 16:41:39, Greg Wooledge wrote:
> > On Mon, Aug 30, 2021 at 10:20:46PM +0200, Steve Keller wrote:
> > > I plan to upgrade a server from	Debian stretch to buster.  Having read
> > > the release notes I wonder what's the best way to avoid the new scheme
> > > of unpredictable network interface names.
> > 
> > You say "server", so I'm guessing it has more than one NIC.  That means
> > the old way (net.ifnames=0) is not viable.
> > 
> > Your best strategy is to create systemd.link(5) files, and give the NICs
> > the names you want them to have, based on their MAC addresses.
> > 
> > For example:
> > 
> > unicorn:~$ cat /etc/systemd/network/10-lan0.link 
> > [Match]
> > MACAddress=18:60:24:77:5c:ec
> > 
> > [Link]
> > Name=lan0
> 
> Another completely different approach is to use some other tool to 
> configure your network that can match on MAC address and just ignore the 
> names completely.

Surely you meant ifupdown.

auto mac/ab:cd:ef:12:34:56/=eth0
iface eth0 inet static
  address 192.168.1.123/24
  gateway 192.168.1.1
  dns-nameservers 192.168.1.1


And there's a small bonus of having to enable systemd-networkd and
optionally systemd-resolved.

This example was helpfully provided by
/usr/share/doc/ifupdown/examples/pattern-matching.

Reco

[toc] | [prev] | [next] | [standalone]

#239568

[Multipart message — attachments visible in raw view] — view raw

On Ma, 31 aug 21, 16:33:49, Reco wrote:
> On Tue, Aug 31, 2021 at 01:32:32PM +0300, Andrei POPESCU wrote:
> > 
> > Another completely different approach is to use some other tool to 
> > configure your network that can match on MAC address and just ignore the 
> > names completely.
> 
> Surely you meant ifupdown.

$ dpkg -l ifupdown
dpkg-query: no packages found matching ifupdown

> auto mac/ab:cd:ef:12:34:56/=eth0
> iface eth0 inet static
>   address 192.168.1.123/24
>   gateway 192.168.1.1
>   dns-nameservers 192.168.1.1

Good to know, if I ever need to deal with ifupdown again ;)

Interestingly, you still have to assign some logical name to it, that 
appears to be internal to ifupdown.

To me this looks like potential to create some confusion, especially if 
using eth*/wlan* names.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#239480

Steve Keller wrote: 
> I plan to upgrade a server from	Debian stretch to buster.  Having read
> the release notes I wonder what's the best way to avoid the new scheme
> of unpredictable network interface names.

In /etc/default/grub, assuming that you are booting with grub, 

GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0"

The "quiet" is not necessary and is a different feature.


-dsr-

[toc] | [prev] | [next] | [standalone]

#239482

Dan Ritter wrote: 
> Steve Keller wrote: 
> > I plan to upgrade a server from	Debian stretch to buster.  Having read
> > the release notes I wonder what's the best way to avoid the new scheme
> > of unpredictable network interface names.
> 
> In /etc/default/grub, assuming that you are booting with grub, 
> 
> GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0"
> 
> The "quiet" is not necessary and is a different feature.

The success of this method on my 5-nic router may be related to
not using systemd.

Also, an update-grub will be necessary.

-dsr-

[toc] | [prev] | [next] | [standalone]

#239485

On Mon, Aug 30, 2021 at 04:41:55PM -0400, Dan Ritter wrote:
> Steve Keller wrote: 
> > I plan to upgrade a server from	Debian stretch to buster.  Having read
> > the release notes I wonder what's the best way to avoid the new scheme
> > of unpredictable network interface names.
> 
> In /etc/default/grub, assuming that you are booting with grub, 
> 
> GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0"
> 
> The "quiet" is not necessary and is a different feature.

This gives unpredictable results if the system has more than one
ethernet interface, or more than one wireless interface.

It's fine on systems that have 0-1 ethernet and 0-1 wireless NICs.

[toc] | [prev] | [next] | [standalone]

#239486

[Multipart message — attachments visible in raw view] — view raw

>
> This gives unpredictable results if the system has more than one
> ethernet interface, or more than one wireless interface.
>
> It's fine on systems that have 0-1 ethernet and 0-1 wireless NICs.
>

Isn't that what the topic starter asked about?:)

To make names predictable one can either leave everything as-is and let
`systemd-udev` do its job, or create custom naming scheme using "link"
files:

https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
https://systemd.io/PREDICTABLE_INTERFACE_NAMES/
https://www.freedesktop.org/software/systemd/man/systemd.link.html

[toc] | [prev] | [next] | [standalone]

#239488

On Tue, Aug 31, 2021 at 12:27:57AM +0300, IL Ka wrote:
> >
> > This gives unpredictable results if the system has more than one
> > ethernet interface, or more than one wireless interface.
> >
> > It's fine on systems that have 0-1 ethernet and 0-1 wireless NICs.
> >
> 
> Isn't that what the topic starter asked about?:)

I sincerely hope that the OP will tell us how many ethernet interfaces
their "server" has, so we can stop the hypothetical tennis match.

> To make names predictable one can either leave everything as-is and let
> `systemd-udev` do its job, or create custom naming scheme using "link"
> files:
> 
> https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
> https://systemd.io/PREDICTABLE_INTERFACE_NAMES/
> https://www.freedesktop.org/software/systemd/man/systemd.link.html

I advocated creating the .link files in my original message.  I even
gave examples.

I do *not* advocate "letting systemd-udevd do its job", because it's
absolutely unqualified for duty.  The names it chooses are *not*
predictable.  The OP knew this.  I can tell by their wording.

I do *not* advocate using "net.ifnames=0" *unless* the system is known
to have fewer than 2 ethernet interfaces *and* fewer than 2 wireless
interfaces.

[toc] | [prev] | [next] | [standalone]

#239495

Greg Wooledge <greg@wooledge.org> writes:

> On Tue, Aug 31, 2021 at 12:27:57AM +0300, IL Ka wrote:
> > >
> > > This gives unpredictable results if the system has more than one
> > > ethernet interface, or more than one wireless interface.
> > >
> > > It's fine on systems that have 0-1 ethernet and 0-1 wireless NICs.
> > >
> >
> > Isn't that what the topic starter asked about?:)
>
> I sincerely hope that the OP will tell us how many ethernet interfaces
> their "server" has, so we can stop the hypothetical tennis match.

One interface is on the mainboard (eth0), the other is a PCI card
(eth1).  BTW, PCI really, not PCIe other something like that.  It's a
really old machine.

> I advocated creating the .link files in my original message.  I even
> gave examples.
>
> I do *not* advocate "letting systemd-udevd do its job", because it's
> absolutely unqualified for duty.  The names it chooses are *not*
> predictable.  The OP knew this.  I can tell by their wording.

Actually, I don't know this.  When I wrote unpredictable new naming
scheme I meant systemd's enp<pci-bus>s<slot> scheme, since it's
unpredictable for me as long as I don't learn these numbers for my
mainboard and PCI card config.

Why is systemd-udevd unqualified for this jobs?  As far as I
understand, systemd implements this new "predictavle" scheme by
calling udevd.  No?  Well, this is exactly what I dislike with systemd
& co.  I've read lots of docs & man pages, still I don't know the
exact process of how the interfaces are renamed after the kernel names
the eth<n>.  Does udevd run first, does systemd call udev, does
systemd do the renaming itself or is it done by "net_setup_link udev
builtin" as systemd.link(5) states?  And is this udev builtin a part
of udev or part of systemd or part of systemd-udevd?  At least there
is no man page for net_setup_link. So the admin has to guess.

This is the same picture with other systemd, udev, avahi, ... stuff.
In newer clients, I don't understand DNS lookup anymore.  In
/etc/resolv.conf you cannot find the DNS server used.  A rndc reload
on the server is ignored for quite a long time.  I recently had that
problem and couldn't figure out how to make the client (Ubuntu 20.04)
get the DNS entry from the server as it was told by DHCP, instead of
its local cache.  Even restarting several systemd service on the
client didn't help.  Since the man pages are very incomplete I
could only poke in the dark, trial and error until it somehow
magically worked again.

NFS with systemd is a nightmare.

20 years ago until about 10 years ago I knew every single daemon on my
system and I knew exactly what each one did do.  Now there are dozens
of daemons, interacing in obscure ways, poorly documented, so I don't
know much of a current system anymore.  I consider this a major
security problem since any malicous new daemon would probably go
unrecognized quite a long time.

Steve

[toc] | [prev] | [next] | [standalone]

#239499

On Tue, Aug 31, 2021 at 01:44:09AM +0200, Steve Keller wrote:
> One interface is on the mainboard (eth0), the other is a PCI card
> (eth1).  BTW, PCI really, not PCIe other something like that.  It's a
> really old machine.

OK.  I recommend making two "dot link" files, one for each card, in
order to assign the names you want them to have.

> Actually, I don't know this.  When I wrote unpredictable new naming
> scheme I meant systemd's enp<pci-bus>s<slot> scheme, since it's
> unpredictable for me as long as I don't learn these numbers for my
> mainboard and PCI card config.
> 
> Why is systemd-udevd unqualified for this jobs?

Because PCI slot numbers change.  They can change when you add a device,
or remove a device (even if they're not network interfaces), or upgrade
your motherboard firmware.

These names are not "predictable" because they're based on the PCI slot
number, which is not stable.

> Well, this is exactly what I dislike with systemd
> & co.  I've read lots of docs & man pages, still I don't know the
> exact process of how the interfaces are renamed after the kernel names
> the eth<n>.  Does udevd run first, does systemd call udev, does
> systemd do the renaming itself or is it done by "net_setup_link udev
> builtin" as systemd.link(5) states?

I don't pretend to know every permutation.  On my system, which is a
desktop PC with a builtin NIC configured with a .link file, I get this:

[    1.102914] libphy: r8169: probed
[    1.103400] r8169 0000:02:00.0 eth0: RTL8168gu/8111gu, 18:60:24:77:5c:ec, XID 509, IRQ 127
[    1.103761] r8169 0000:02:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[    1.104945] r8169 0000:02:00.0 lan0: renamed from eth0

In other words, the kernel probes NICs, and starts handing out names
to them based on the order in which the probing completes.  The first
one that successfully responds gets called eth0, the second one gets
called eth1, and so on.

Then, because I have a .link file, the matching interface is renamed to
the name I selected (lan0).  I chose this name specifically because it
is *not* one of the names the kernel will assign.

Nobody has ever explained to me how this all works, so I expect that
something will explode in the following scenario:

1) A .link file exists which maps one of the NICs to "eth0".
2) System is booted.
3) First interface is probed and named eth0.
4) Second interface is probed and named eth1.
5) The second interface matches the .link file, and is renamed to eth0.
6) Now there are two interfaces named "eth0", and things explode.

I don't know whether this is how it *actually* works, but I don't want
to find out the hard way.  So I chose names that make it impossible
for this to happen.

If there are no .link files, and assuming I'm not using net.ifnames=0,
the NICs will be renamed to the "predictable" names (eno0 or enp2s5 or
whatever) instead of the names that I selected.

If I use net.ifnames=0 then there won't be any renaming.  The NICs will
keep their probing-order-assigned named (eth0, eth1, and so on).

> NFS with systemd is a nightmare.

I haven't had an issue with it, personally.  Make sure your interfaces
are configured in /etc/network/interfaces with "auto" and not with
"allow-hotplug".  That solves 80% of the problems I hear about.

The only NFS issues I've had in recent years are related to NFS version
mismatches (NFSv3 vs. NFSv4 and so on).  Nothing caused by systemd.

[toc] | [prev] | [next] | [standalone]

#239545

On Mon, 2021-08-30 at 20:26 -0400, Greg Wooledge wrote:
> On Tue, Aug 31, 2021 at 01:44:09AM +0200, Steve Keller wrote:
[...]
> > Actually, I don't know this.  When I wrote unpredictable new naming
> > scheme I meant systemd's enp<pci-bus>s<slot> scheme, since it's
> > unpredictable for me as long as I don't learn these numbers for my
> > mainboard and PCI card config.
> > 
> > Why is systemd-udevd unqualified for this jobs?
> 
> Because PCI slot numbers change.  They can change when you add a device,
> or remove a device (even if they're not network interfaces), or upgrade
> your motherboard firmware.
> 
> These names are not "predictable" because they're based on the PCI slot
> number, which is not stable.
> 

Or 'Firmware/BIOS provided index numbers for on-board devices' [1]

I found this out when I decided to enable motherboard WiFi in the BIOS
settings on my new desktop PC and this caused my ethernet to stop
working. Upon investigation I found the ethernet was now called 'eno2'
and the Debian installer had put 'eno1' in /etc/network/interfaces
because I had installed with WiFi disabled.

[1] https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#239490

IL Ka schrieb:

> > It's fine on systems that have 0-1 ethernet and 0-1 wireless NICs.
> 
> Isn't that what the topic starter asked about?:)

I don't think so:
| I simply have eth0 for the internal network and eth1 for
| my external network to the DSL router.

That looks like two ethernet NICs.

[toc] | [prev] | [next] | [standalone]

#239493

Greg Wooledge <greg@wooledge.org> writes:

> On Mon, Aug 30, 2021 at 04:41:55PM -0400, Dan Ritter wrote:
> > Steve Keller wrote:
> > > I plan to upgrade a server from	Debian stretch to buster.  Having read
> > > the release notes I wonder what's the best way to avoid the new scheme
> > > of unpredictable network interface names.
> >
> > In /etc/default/grub, assuming that you are booting with grub,
> >
> > GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0"
> >
> > The "quiet" is not necessary and is a different feature.
>
> This gives unpredictable results if the system has more than one
> ethernet interface, or more than one wireless interface.
>
> It's fine on systems that have 0-1 ethernet and 0-1 wireless NICs.

OK, several people suggested the kernel command-line option
net.ifnames=0.  Since I almost never change hardware configurations
this is probably OK even with my two NICs, one on the mainboard, the
second is a PCI card.  If the kernel should really change the
enumeration of the cards in some future, I will do something about
that.

In buster I still need to disable the
/etc/udev/rules.d/70-persistent-net.rule file since the kernel cmdline
option doesn't deactivate this.  AFAIK, the kernel cmdline option only
ends up in the environment of process 1, i.e. systemd.  Will systemd
communicate this to udev in a future Debian release or how is that
supposed to work.  The wiki says, the plan for buster was to not
support this .rules file.

My other option would be customized names using systemd.link files.
While I prefer eth<n> I would then probably use en<0>, since the wiki
recommends not using eth<n>.  I still don't understand, why eth<n> in
a systemd.link file would be a problem, since in the udev .rules this
has worked for years.

Steve

[toc] | [prev] | [next] | [standalone]

#239504

[Multipart message — attachments visible in raw view] — view raw

On Tue, Aug 31, 2021 at 01:11:33AM +0200, Steve Keller wrote:

[...]

> OK, several people suggested the kernel command-line option
> net.ifnames=0.  Since I almost never change hardware configurations
> this is probably OK even with my two NICs, one on the mainboard, the
> second is a PCI card.  If the kernel should really change the
> enumeration of the cards in some future, I will do something about
> that.

A good alternative in your scenario above would be to take
control of udev rules yourself and rename your NICs based on
their MAC address (or on some other tidbit belonging to the
card and not to some boot lottery). See, for example [1] (just
a random find on the Intertubes, you might have to adapt the
rules to the newest fashion, yadda, yadda).

After all, systemd is doing just the same, albeit in a somewhat
obfuscated way.

Cheers

[1] http://www.debianhelp.co.uk/udev.htm

 - t

[toc] | [prev] | [next] | [standalone]

#239510

[Multipart message — attachments visible in raw view] — view raw

On Ma, 31 aug 21, 01:11:33, Steve Keller wrote:
> 
>                               I still don't understand, why eth<n> in
> a systemd.link file would be a problem, since in the udev .rules this
> has worked for years.

Greg already explained what problems might show up if you try to use 
eth<n>.

The udev .rules might have worked fine for your particular system, but 
it was unreliable for too many others.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#239522

On Tue 31 Aug 2021 at 01:11:33 (+0200), Steve Keller wrote:
> Greg Wooledge <greg@wooledge.org> writes:
> > On Mon, Aug 30, 2021 at 04:41:55PM -0400, Dan Ritter wrote:
> > > Steve Keller wrote:
> > > > I plan to upgrade a server from	Debian stretch to buster.  Having read
> > > > the release notes I wonder what's the best way to avoid the new scheme
> > > > of unpredictable network interface names.
> > >
> > > In /etc/default/grub, assuming that you are booting with grub,
> > >
> > > GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0"
> > >
> > > The "quiet" is not necessary and is a different feature.
> >
> > This gives unpredictable results if the system has more than one
> > ethernet interface, or more than one wireless interface.
> >
> > It's fine on systems that have 0-1 ethernet and 0-1 wireless NICs.
> 
> OK, several people suggested the kernel command-line option
> net.ifnames=0.  Since I almost never change hardware configurations
> this is probably OK even with my two NICs, one on the mainboard, the
> second is a PCI card.  If the kernel should really change the
> enumeration of the cards in some future, I will do something about
> that.

By which time, of course, the consequences of this mistake might well
have already happened, eg, juggling your internal network, dmz, and
external internet.

But it's your choice, of course.

> In buster I still need to disable the
> /etc/udev/rules.d/70-persistent-net.rule file since the kernel cmdline
> option doesn't deactivate this.  AFAIK, the kernel cmdline option only
> ends up in the environment of process 1, i.e. systemd.  Will systemd
> communicate this to udev in a future Debian release or how is that
> supposed to work.  The wiki says, the plan for buster was to not
> support this .rules file.
> 
> My other option would be customized names using systemd.link files.
> While I prefer eth<n> I would then probably use en<0>, since the wiki
> recommends not using eth<n>.  I still don't understand, why eth<n> in
> a systemd.link file would be a problem, since in the udev .rules this
> has worked for years.

It's rather futile as the result is two races instead of one. The
kernel happens to find first the NIC that you want named "eth1",
and so it enumerates it as eth0. (That's the first race.)

Now starts a second race:

. when the kernel finds the other NIC, it wants to enumerate it as eth1,

but meanwhile:

. your customisation immediately wants to rename the first (eth0) NIC
  as eth1.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#239483

[Multipart message — attachments visible in raw view] — view raw

On Mon, Aug 30, 2021 at 11:36 PM Steve Keller <keller.steve@gmx.de> wrote:

> So I'm still confused what to do after the upgrade to buster to keep
> my network names.
>
>
>
in /etc/default/grub add
"net.ifnames=0"
to GRUB_CMDLINE_LINUX
and execute "update-grub"

This service:
https://www.freedesktop.org/software/systemd/man/systemd-udevd.service.html
is responsible for device creation and renaming

Here is a good overview:
https://opensource.com/article/20/2/linux-systemd-udevd



>
>
> [1] Unfortunately, much of the Linux community and many distributions
>     try to get as far away from its Unix roots as possible, away from
>     the good KISS principle,


I agree:) Old good times when devices were created by makedev without any
magic.

Try devuan: https://www.devuan.org/
It doesn't have systemd

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web