Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
How to avoid systemd/udev unpredictable NIC names
1,180 views
Skip to first unread message
Steve Keller
Aug 30, 2021, 4:40:06 PM8/30/21
to
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.
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.
Greg Wooledge
Aug 30, 2021, 5:00:04 PM8/30/21
to
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
> 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.
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.
Dan Ritter
Aug 30, 2021, 5:10:05 PM8/30/21
to
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,
> 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.
GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0"
The "quiet" is not necessary and is a different feature.
-dsr-
Greg Wooledge
Aug 30, 2021, 5:30:05 PM8/30/21
to
ethernet interface, or more than one wireless interface.
It's fine on systems that have 0-1 ethernet and 0-1 wireless NICs.
IL Ka
Aug 30, 2021, 5:30:05 PM8/30/21
to
On Mon, Aug 30, 2021 at 11:36 PM Steve Keller <keller...@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:
is responsible for device creation and renaming
Here is a good overview:
[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
Dan Ritter
Aug 30, 2021, 5:30:05 PM8/30/21
to
not using systemd.
Also, an update-grub will be necessary.
-dsr-
IL Ka
Aug 30, 2021, 5:50:05 PM8/30/21
to
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:
Greg Wooledge
Aug 30, 2021, 6:10:05 PM8/30/21
to
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
> >
> > 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?:)
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
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.
Thomas Hochstein
Aug 30, 2021, 6:50:04 PM8/30/21
to
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:
> > 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 simply have eth0 for the internal network and eth1 for
| my external network to the DSL router.
That looks like two ethernet NICs.
| my external network to the DSL router.
Roberto C. Sánchez
Aug 30, 2021, 7:30:04 PM8/30/21
to
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.
>
> 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.
>
Since nobody else has mentioned this link, here is where I recommend you
> 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.
>
start: https://wiki.debian.org/NetworkInterfaceNames
Regards,
-Roberto
--
Roberto C. Sánchez
Steve Keller
Aug 30, 2021, 7:30:04 PM8/30/21
to
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
Steve Keller
Aug 30, 2021, 8:10:04 PM8/30/21
to
Roberto C. Sánchez <rob...@debian.org> writes:
> Since nobody else has mentioned this link, here is where I recommend you
> start: https://wiki.debian.org/NetworkInterfaceNames
Oh, that's what I meant by "wiki" in my posts. Sorry, I should have
> Since nobody else has mentioned this link, here is where I recommend you
> start: https://wiki.debian.org/NetworkInterfaceNames
given the URL. It's linked from the buster release-notes in section
5.1.6
Steve
Steve Keller
Aug 30, 2021, 8:10:04 PM8/30/21
to
Greg Wooledge <gr...@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
> 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.
(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.
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
Greg Wooledge
Aug 30, 2021, 8:50:04 PM8/30/21
to
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
> 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.
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?
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?
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.
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.
to...@tuxteam.de
Aug 31, 2021, 2:30:05 AM8/31/21
to
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
[...]
> 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.
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
Andrei POPESCU
Aug 31, 2021, 6:50:04 AM8/31/21
to
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
> 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
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
Andrei POPESCU
Aug 31, 2021, 6:50:04 AM8/31/21
to
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
>
> 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.
eth<n>.
The udev .rules might have worked fine for your particular system, but
it was unreliable for too many others.
Greg Wooledge
Aug 31, 2021, 7:40:05 AM8/31/21
to
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
> 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
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.
George Shuklin
Aug 31, 2021, 9:50:05 AM8/31/21
to
On 30/08/2021 23:20, Steve Keller
wrote:
'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
In my opinion explicit naming via systemd is the best:
#/etc/systemd/network/10-persistent-net.link [Match] MACAddress=01:23:45:67:89:ab [Link] Name=eth1
Put names and macs as you wish.
Reco
Aug 31, 2021, 10:00:04 AM8/31/21
to
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.
> > 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.
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
David Wright
Aug 31, 2021, 10:30:05 AM8/31/21
to
On Tue 31 Aug 2021 at 01:11:33 (+0200), Steve Keller wrote:
> Greg Wooledge <gr...@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
> Greg Wooledge <gr...@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.
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.
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.
Tixy
Aug 31, 2021, 4:10:04 PM8/31/21
to
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:
[...]
> 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]
> > 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.
>
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
Andrei POPESCU
Sep 1, 2021, 1:30:06 PM9/1/21
to
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
> 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-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
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.
0 new messages