Predictable Network Interface Names

[basti]

Hello,

as I can read here [1] network names should be stable.
(Stable interface names even when hardware is added or removed)

First of all I have multiple PCIe NIC in a server.

What I see now is:

When I add or remove a PCIe card (USB card) the name is changed from
enp5s3 to enp6s3 and back for example.

This is not what I understand with "Stable interface names", especially
when it rename multiple nic's.

I guess an empty PCI / PCIe slot is ignored.

Is there a way to not ignore empty slots?

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

[Greg Wooledge]

Post by basti
as I can read here [1] network names should be stable.
(Stable interface names even when hardware is added or removed)
[1] https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Sorry, but you've been lied to.

Post by basti
When I add or remove a PCIe card (USB card) the name is changed from enp5s3
to enp6s3 and back for example.

Yes. You've now seen direct evidence of the lie. I guess I won't need
to post links to the wiki articles that say the same thing you've already
observed.

For most people, there are two paths forward:

1) If your system has exactly one ethernet interface, and if this is not
likely to change at any point in the future, you can go back to the
old old way of doing things -- let the kernel assign "eth0" to the
first interface it finds, "eth1" to the second interface it finds,
and so on. Since it will only ever find one interface, that interface
will always be named "eth0", and you can configure from there.

2) If you have multiple ethernet interfaces, or the possibility of this
occurring in the future, take control of their names yourself. Set
up systemd.link(5) files to assign a name to each interface based on
its MAC address, or some other identifying characteristic.

[Brian]

Post by Greg Wooledge

Post by basti
as I can read here [1] network names should be stable.
(Stable interface names even when hardware is added or removed)
[1] https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Sorry, but you've been lied to.

I would see that as a bit strong. A lie is a deliberate action,
knowing the reality rests elesewhere. Good faith and all that :).

Post by Greg Wooledge

Post by basti
When I add or remove a PCIe card (USB card) the name is changed from enp5s3
to enp6s3 and back for example.

Yes. You've now seen direct evidence of the lie. I guess I won't need
to post links to the wiki articles that say the same thing you've already
observed.

I would be interested in a couple of links to the same observations
as given by the OP.

Post by Greg Wooledge
1) If your system has exactly one ethernet interface, and if this is not
likely to change at any point in the future, you can go back to the
old old way of doing things -- let the kernel assign "eth0" to the
first interface it finds, "eth1" to the second interface it finds,
and so on. Since it will only ever find one interface, that interface
will always be named "eth0", and you can configure from there.

Recently, we have had a mail or two about iwd. It uses the kernel
interface wlan0, which broke my /e/n/i. In the end I went with the
flow on the basis that wlan0 is stable enough and changed /e/n/i
rather than fighting iwd.

If you were of the opinion that, with a single interface, a user
gets a stable. *easily memorable* name, I could agree with you.

Post by Greg Wooledge
2) If you have multiple ethernet interfaces, or the possibility of this
occurring in the future, take control of their names yourself. Set
up systemd.link(5) files to assign a name to each interface based on
its MAC address, or some other identifying characteristic.

That's good advice, but are MAC addresses memorable?

[Greg Wooledge]

Post by Brian

Post by Greg Wooledge
Yes. You've now seen direct evidence of the lie. I guess I won't need
to post links to the wiki articles that say the same thing you've already
observed.

I would be interested in a couple of links to the same observations
as given by the OP.

<https://wiki.debian.org/NetworkInterfaceNames#Complications_and_corner_cases>
tries very hard to avoid mentioning the issue directly, but ultimately
has this paragraph down near the bottom of the section:

it turns out even after all this there are still reported cases of
interfaces changing their name on a reboot. All that needs to happen
is that some buggy BIOS (or some new, less buggy version of a driver
module, or systemd's naming policy) changes its mind about some detail
like whether or not your hardware counts as the kind that should have
an ONBOARD name. There are even reports of devices changing their
PCI-port numbering due to other hardware being installed.

This links to
<https://utcc.utoronto.ca/~cks/space/blog/linux/PCINamesNotStable> which
goes into some detail.

I'm sure there are many more pages like this one.

Post by Brian
Recently, we have had a mail or two about iwd. It uses the kernel
interface wlan0, which broke my /e/n/i. In the end I went with the
flow on the basis that wlan0 is stable enough and changed /e/n/i
rather than fighting iwd.

Wireless interfaces are not my strong suit. I don't have any advice
for those.

Post by Brian

Post by Greg Wooledge
2) If you have multiple ethernet interfaces, or the possibility of this
occurring in the future, take control of their names yourself. Set
up systemd.link(5) files to assign a name to each interface based on
its MAC address, or some other identifying characteristic.

That's good advice, but are MAC addresses memorable?

Doesn't matter. You can choose a memorable name. The MAC address is
simply the data point you place in the config file, so the system knows
this is the interface you're talking about.

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

[Link]
Name=lan0

That's what I'm using. Of course, this relies on the MAC address being
consistent across boots. I've heard of some cases where this isn't
true, but I believe those cases involved removable devices (USB network
interfaces or similar).

"lan0" is familiar to me from HP-UX, and it also isn't "eth0", so there's
no risk of collision with the kernel's default name scheme. I have
no idea what happens if you try to assign the names "eth0" and "eth1"
to a pair of interfaces that come up as "eth1" and "eth0" by default.
Are the renames done sequentially? Will they fail in this case? I don't
know, and I don't want to find out the hard way.

[Erwan David]

Post by Greg Wooledge
Doesn't matter. You can choose a memorable name. The MAC address is
simply the data point you place in the config file, so the system knows
this is the interface you're talking about.
unicorn:~$ cat /etc/systemd/network/10-lan0.link
[Match]
MACAddress=18:60:24:77:5c:ec
[Link]
Name=lan0
That's what I'm using. Of course, this relies on the MAC address being
consistent across boots. I've heard of some cases where this isn't
true, but I believe those cases involved removable devices (USB network
interfaces or similar).
"lan0" is familiar to me from HP-UX, and it also isn't "eth0", so there's
no risk of collision with the kernel's default name scheme. I have
no idea what happens if you try to assign the names "eth0" and "eth1"
to a pair of interfaces that come up as "eth1" and "eth0" by default.
Are the renames done sequentially? Will they fail in this case? I don't
know, and I don't want to find out the hard way.

Be aware that bridge or bond interfaces get their mac address from one
of the inner inetrface, thus you may have to add a macth (eg a match on
the driver)

[Brian]

Post by Greg Wooledge

Post by Brian

Post by Greg Wooledge
Yes. You've now seen direct evidence of the lie. I guess I won't need
to post links to the wiki articles that say the same thing you've already
observed.

I would be interested in a couple of links to the same observations
as given by the OP.

<https://wiki.debian.org/NetworkInterfaceNames#Complications_and_corner_cases>
tries very hard to avoid mentioning the issue directly, but ultimately
it turns out even after all this there are still reported cases of
interfaces changing their name on a reboot. All that needs to happen
is that some buggy BIOS (or some new, less buggy version of a driver
module, or systemd's naming policy) changes its mind about some detail
like whether or not your hardware counts as the kind that should have
an ONBOARD name. There are even reports of devices changing their
PCI-port numbering due to other hardware being installed.
This links to
<https://utcc.utoronto.ca/~cks/space/blog/linux/PCINamesNotStable> which
goes into some detail.

Thanks. Very informative. As the second link says:

The resulting reality is that your PCI based names are only
stable if you change no hardware in the system. The moment
you change any hardware all bets are off for all hardware.

This, plus your advice, could point the OP to a way forward.

How hardare specific the claim is is not explored.

Post by Greg Wooledge
I'm sure there are many more pages like this one.

Post by Brian
Recently, we have had a mail or two about iwd. It uses the kernel
interface wlan0, which broke my /e/n/i. In the end I went with the
flow on the basis that wlan0 is stable enough and changed /e/n/i
rather than fighting iwd.

Wireless interfaces are not my strong suit. I don't have any advice
for those.

I only mentioned what I did bcause, om the whole, I am prepared to
accept interface renaming. The vast majority of users will not notice
that it has taken place.

[Erwan David]

=<https://utcc.utoronto.ca/~cks/space/blog/linux/PCINamesNotStable> which

Post by Greg Wooledge
goes into some detail.

The resulting reality is that your PCI based names are only
stable if you change no hardware in the system. The moment
you change any hardware all bets are off for all hardware.
This, plus your advice, could point the OP to a way forward.

I also got a name change with an upgrade (I do not remember wether it
was kernel, systemd or udev).

SInce interfaces where combined in a bond, imagine the mess...

[Anssi Saari]

Post by Erwan David
I also got a name change with an upgrade (I do not remember wether it
was kernel, systemd or udev).
SInce interfaces where combined in a bond, imagine the mess...

I think I noticed something like that too as I've updated my desktop HW
and booted from some different media. Not a big deal on the desktop but
I have to say I don't much ilke the enpXsY scheme. I guess I'll be going
to eth0 on systems with one wired interface and wlan0 if there's single
wireless interface. Which means my desktop, stuff server and my two
currently working Raspberry Pis.

Not so sure what to do with other systems that have multiple
interfaces. My file server has three, router has four or four and a half
since there's an LTE module which presents as "kinda" ethernet. On the
router especially my firewall rules depend on interface names.

[Nicholas Geovanis]

Post by Greg Wooledge

Post by Greg Wooledge

Post by Brian

Post by Greg Wooledge
Yes. You've now seen direct evidence of the lie. I guess I won't

need

Post by Greg Wooledge

Post by Brian

Post by Greg Wooledge
to post links to the wiki articles that say the same thing you've

already

Post by Greg Wooledge

Post by Brian

Post by Greg Wooledge
observed.

I would be interested in a couple of links to the same observations
as given by the OP.

<

https://wiki.debian.org/NetworkInterfaceNames#Complications_and_corner_cases

Post by Greg Wooledge
tries very hard to avoid mentioning the issue directly, but ultimately
it turns out even after all this there are still reported cases of
interfaces changing their name on a reboot. All that needs to happen
is that some buggy BIOS (or some new, less buggy version of a driver
module, or systemd's naming policy) changes its mind about some detail
like whether or not your hardware counts as the kind that should have
an ONBOARD name. There are even reports of devices changing their
PCI-port numbering due to other hardware being installed.
This links to
<https://utcc.utoronto.ca/~cks/space/blog/linux/PCINamesNotStable> which
goes into some detail.

The resulting reality is that your PCI based names are only
stable if you change no hardware in the system. The moment
you change any hardware all bets are off for all hardware.
This, plus your advice, could point the OP to a way forward.
How hardare specific the claim is is not explored.

Post by Greg Wooledge
I'm sure there are many more pages like this one.

Post by Brian
Recently, we have had a mail or two about iwd. It uses the kernel
interface wlan0, which broke my /e/n/i. In the end I went with the
flow on the basis that wlan0 is stable enough and changed /e/n/i
rather than fighting iwd.

Wireless interfaces are not my strong suit. I don't have any advice
for those.

I only mentioned what I did bcause, om the whole, I am prepared to
accept interface renaming. The vast majority of users will not notice
that it has taken place.

Does anyone here know how the BSD-derived "free" unices handle this
situation?
And how about free-ish Oracle/Solaris?
And AIX running on Intel hard/firmware?

[Greg Wooledge]

Post by Nicholas Geovanis
Does anyone here know how the BSD-derived "free" unices handle this
situation?

I haven't used OpenBSD in several years, but the last time I used it,
it went something like this:

The OpenBSD kernel has drivers for lots of different kinds of network
interfaces. Each driver has a separate concise name. Some examples:

ath — Atheros IEEE 802.11a/b/g wireless network device with GPIO
fxp — Intel EtherExpress PRO/100 10/100 Ethernet device
ie — Intel i82596 Ethernet device
rl — Realtek 8129/8139 10/100 Ethernet device

When the kernel boots and does its hardware detection, any devices that
are detected are "claimed" by the appropriate drivers, and given a name
according to the driver which claims it. E.g. if the system has one
Realtek 8129 interface, that interface will be named "rl0", regardless
of whether it's detected before or after an Intel PRO/100, which is
claimed by the fxp driver and named "fxp0".

As long as there's only one interface claimed by each driver, there will
never be any unpredictability in the names.

I'm not sure how it handles the naming when there are two or more
interfaces claimed by the same driver. They'll be called "rl0" and "rl1"
for example, but I don't know how it determines which one gets which
name.

[Dan Ritter]

Post by Greg Wooledge

Post by Brian
That's good advice, but are MAC addresses memorable?

Doesn't matter. You can choose a memorable name. The MAC address is
simply the data point you place in the config file, so the system knows
this is the interface you're talking about.
unicorn:~$ cat /etc/systemd/network/10-lan0.link
[Match]
MACAddress=18:60:24:77:5c:ec
[Link]
Name=lan0
That's what I'm using. Of course, this relies on the MAC address being
consistent across boots. I've heard of some cases where this isn't
true, but I believe those cases involved removable devices (USB network
interfaces or similar).

Some NICs can have their MAC addresses changed permanently.

There were at least a few terrible NICs in history where an
entire production run got the same MAC address assigned.

Most NICs can have their MAC addresses reassigned after boot,
which will almost always be reset on next power cycle.

lan0 is a good name. I like names like "internal" and "dmz" and "internet"
or "cogent" and "level3" -- either functional descriptors or
where their other ends are connected.

-dsr-

[Cindy Sue Causey]

Post by Dan Ritter

Post by Greg Wooledge

Post by Brian
That's good advice, but are MAC addresses memorable?

Doesn't matter. You can choose a memorable name. The MAC address is
simply the data point you place in the config file, so the system knows
this is the interface you're talking about.
unicorn:~$ cat /etc/systemd/network/10-lan0.link
[Match]
MACAddress=18:60:24:77:5c:ec
[Link]
Name=lan0
That's what I'm using. Of course, this relies on the MAC address being
consistent across boots. I've heard of some cases where this isn't
true, but I believe those cases involved removable devices (USB network
interfaces or similar).

Some NICs can have their MAC addresses changed permanently.
There were at least a few terrible NICs in history where an
entire production run got the same MAC address assigned.
Most NICs can have their MAC addresses reassigned after boot,
which will almost always be reset on next power cycle.
lan0 is a good name. I like names like "internal" and "dmz" and "internet"
or "cogent" and "level3" -- either functional descriptors or
where their other ends are connected.

macchanger.. I tried it a couple years ago for some forgotten reason.
I think it was when the names first started changing on us, and I was
trying to take control of the situation. I remember it working and
then not working. Can't remember now why I gave up on it. Thankfully
things have ironed out some since so it hasn't been needed in my usage
case.

Post by Dan Ritter
From "apt-cache show," it seems to reference the same vendor MAC

duplication instances (Point #4):

Features:
.
* set specific MAC address of a network interface
* set the MAC randomly
* set a MAC of another vendor
* set another MAC of the same vendor
* set a MAC of the same kind (eg: wireless card)
* display a vendor MAC list (today, 6200 items) to choose from

Afterthought, my problems eased up after I figured out I could grep
dmesg for "renamed from" and plug that result into where I needed the
name. Tripped over that by accident. Might have started out grepping
for eth0, maybe.

Have fun!

Cindy :)

[Sven Hartge]

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

Careful with that one. If you use VLANs then you suddenly get multiple
interface with the same MAC and strange things will happen, because it
matches for all of them.

The failure-proof way of doing this is by adding "Type=ether" to the
Match clause, which will only match the physical interfaces and not the
subinterfaces. (Which will be of Type=vlan.):

,----
| [Match]
| MACAddress=18:60:24:77:5c:ec
| Type=ether
|
| [Link]
| Name=lan0
`----

Grüße,
Sven.

[Markus Schönhaber]

Post by Sven Hartge

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

Careful with that one. If you use VLANs then you suddenly get multiple
interface with the same MAC and strange things will happen, because it
matches for all of them.
The failure-proof way of doing this is by adding "Type=ether" to the
Match clause, which will only match the physical interfaces and not the

Since I haven't (yet) used the combination VLAN/systemd.link I haven't
run into this issue. But it is definitely something to keep in mind.
Thanks for the hint!

[t***@tuxteam.de]

Post by Brian

Post by Greg Wooledge

Post by basti
as I can read here [1] network names should be stable.
(Stable interface names even when hardware is added or removed)
[1] https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Sorry, but you've been lied to.

I would see that as a bit strong. A lie is a deliberate action,
knowing the reality rests elesewhere. Good faith and all that :).

Perhaps. But once I understood what problem this is trying to solve,
and how, I decided I haven't that problem, I have net.ifnames=0 in
my GRUB_CMDLINE_LINUX_DEFAULT, in /etc/default/grub.

Cheers

[Brian]

Post by t***@tuxteam.de

Post by Brian

Post by Greg Wooledge

Post by basti
as I can read here [1] network names should be stable.
(Stable interface names even when hardware is added or removed)
[1] https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Sorry, but you've been lied to.

I would see that as a bit strong. A lie is a deliberate action,
knowing the reality rests elesewhere. Good faith and all that :).

Perhaps.

Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
the truth and peddles false information purposefully?

Post by t***@tuxteam.de
But once I understood what problem this is trying to solve,
and how, I decided I haven't that problem, I have net.ifnames=0 in
my GRUB_CMDLINE_LINUX_DEFAULT, in /etc/default/grub.

Well done! But, if there isn't any problem for you, why go to this
trouble? Leaving things as they are would seem not to do any harm.

[Michael Stone]

Post by Brian
Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
the truth and peddles false information purposefully?

Some people get excessively worked up over things like interface names
and like to throw around strong words for dramatic effect. Just ignore
the noise.

We've been over all this before. In general, for server-class systems,
predictable interface names Just Work. These are the kinds of systems
mostly likely to have 1) lots of interfaces and 2) a need for
standardized build profiles. I've got quite a lot of these in
production, and it works as advertised. One really nice thing this gets
you that MAC-based renamed interfaces can't (apart from not needing to
plug hundreds of MAC addresses into config files) is that when a NIC
goes bad and you pop in a replacement...it has the same name.

For most consumer sytems the interface name matters not one bit, because
it's auto-discovered on install, will never change, and there's little
likelihood that another interface will be added.

Then there's a small sliver of systems whose users like to shuffle
things around, but for some reason can't stand having to learn anything
new or change a config file or whatever, so they get unbelievably angry
about a rather sensible naming scheme and throw out hot words like
"lies" rather than just getting on with their lives. You'd think they'd
just set their defaults the way they want them instead of venting on
mailing lists, but the internet is the internet.

[Greg Wooledge]

Post by Michael Stone
For most consumer sytems the interface name matters not one bit, because
it's auto-discovered on install, will never change, and there's little
likelihood that another interface will be added.

It's like you haven't even read this thread.

Predictable interface names *do* sometimes change. And when that happens,
it's a huge deal, because all of the configuration files are set up for
the old name. Things break, in an extremely visible way.

This is not some theoretical issue. This is real.

[Michael Stone]

Post by Greg Wooledge
It's like you haven't even read this thread.

of course I have

Post by Greg Wooledge
Predictable interface names *do* sometimes change. And when that happens,
it's a huge deal, because all of the configuration files are set up for
the old name. Things break, in an extremely visible way.

And they also broke before the predictable name scheme! And they can
break if you lock names to MAC addresses! There are always ways things
can break. If they break in an extremely visible way that's actually a
good thing--the impact of simple interface reordering can be much more
severe. And when they do break, the fix is generally pretty
straightforward (that is, not such a big deal as to justify the bytes
wasted complaining about it).

Post by Greg Wooledge
This is not some theoretical issue. This is real.

It's also real that for the majority of systems it works fine. Why are
you so invested in denying that reality?

[Nicholas Geovanis]

Post by Michael Stone

Post by Greg Wooledge
It's like you haven't even read this thread.

of course I have

Post by Greg Wooledge
Predictable interface names *do* sometimes change. And when that happens,
it's a huge deal, because all of the configuration files are set up for
the old name. Things break, in an extremely visible way.

And they also broke before the predictable name scheme! And they can
break if you lock names to MAC addresses! There are always ways things
can break. If they break in an extremely visible way that's actually a
good thing--the impact of simple interface reordering can be much more
severe. And when they do break, the fix is generally pretty
straightforward (that is, not such a big deal as to justify the bytes
wasted complaining about it).

Post by Greg Wooledge
This is not some theoretical issue. This is real.

It's also real that for the majority of systems it works fine. Why are
you so invested in denying that reality?

Because some of us work in corporate data centers. And everything you claim
that helps us here really does the opposite. Because it was introduced in
large part to support mobile computing. Which does not and will never be
valuable on the back-end, the server end, where commerce occurs.

It's what we call a different "use-case".

[Michael Stone]

Post by Nicholas Geovanis
Because some of us work in corporate data centers. And everything you claim
that helps us here really does the opposite. Because it was introduced in large
part to support mobile computing. Which does not and will never be valuable on
the back-end, the server end, where commerce occurs.

Weird, because it works fine for me in that use case.

[gene heskett]

Post by Michael Stone

Post by Greg Wooledge
It's like you haven't even read this thread.

of course I have

Post by Greg Wooledge
Predictable interface names *do* sometimes change. And when that
happens, it's a huge deal, because all of the configuration files are
set up for the old name. Things break, in an extremely visible way.

And they also broke before the predictable name scheme! And they can
break if you lock names to MAC addresses! There are always ways things
can break. If they break in an extremely visible way that's actually a
good thing--the impact of simple interface reordering can be much more
severe. And when they do break, the fix is generally pretty
straightforward (that is, not such a big deal as to justify the bytes
wasted complaining about it).

Post by Greg Wooledge
This is not some theoretical issue. This is real.

It's also real that for the majority of systems it works fine. Why are
you so invested in denying that reality?

Perhaps because to the OP, it is a big deal, being locked away from the
info that makes it and easy fix. I'm one that that fairly numerous crowd
who has suffered thru fixing that, but from reading the mail for 20 some
years, I've learned that complaining is a waste of time, the coder are
gonna do it their way regardless of the crowd wanting blood. So I don't,
until this attitude pushes my button.

Take care and stay well, thats more important than complaining to a stone
wall today.

Cheers, Gene Heskett.

[Intense Red]

Post by Michael Stone
Some people get excessively worked up over things like interface names
and like to throw around strong words for dramatic effect. Just ignore
the noise.

I've just come to accept that the actual interface name is going to be some
bizarre name. So I look it up, and then promptly rename it in "/etc/network/
interfaces" like so:

- - - snip - - -
iface enp18s0f0 inet manual

auto LAN
iface LAN inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.1.1
dns-nameservers 192.168.168.1
dns-search locallan.net
bridge_ports enp18s0f0
- - - snip - - -

This uses Debian's bridge-utils package to rename the interface.

From then on, my machines have an interface named LAN, WAN, DMZ, etc. --
all "logical" names and I don't have to deal with enp18s0f0 or enp18s1e0 or
some such nonsense.

[t***@tuxteam.de]

Post by Brian
Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
the truth and peddles false information purposefully?

Some people get excessively worked up over things like interface names and
like to throw around strong words for dramatic effect. Just ignore the
noise.

Somewhat self-referential. I'm not the one getting worked up here ;-)

Let's not quarrel over it. You like your predictable names. I like
mine. Let's Just Get Along (TM) :)

Cheers

[Michael Stone]

Post by t***@tuxteam.de
Somewhat self-referential. I'm not the one getting worked up here ;-)

And I'm not the one accusing people of lying.

[t***@tuxteam.de]

Post by Michael Stone

Post by t***@tuxteam.de
Somewhat self-referential. I'm not the one getting worked up here ;-)

And I'm not the one accusing people of lying.

I hope my clarification --uh-- clears things up.

Cheers

[t***@tuxteam.de]

Post by Brian

Post by t***@tuxteam.de

Post by Brian

Post by Greg Wooledge

Post by basti
as I can read here [1] network names should be stable.
(Stable interface names even when hardware is added or removed)
[1] https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Sorry, but you've been lied to.

I would see that as a bit strong. A lie is a deliberate action,
knowing the reality rests elesewhere. Good faith and all that :).

Perhaps.

Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
the truth and peddles false information purposefully?

Calm down. There are many shades between Truth (TM) and Lie (TM).
My take is that this specific shade is failing to admit that the
freedesktop folks set out to solve a generally unsolvable problem.

This is one weakness I see with freedesktop often. They try to
fight complexity with ever more complexity, with the end result
of a more user-unfriendly (because less understandable) system.

Nevertheless I thank freedesktop for keeping X (which I do use
a lot) up and running. It's not that I hate them (much less the
people working there). I'm thankful.

Good intentions, pavements, hell, all that.

But hey, this is my take. I'm not in the mood to wage a war over
it. You get to keep your take, I get to keep mine. We could even
remain friends over that.

Post by Brian

Post by t***@tuxteam.de
But once I understood what problem this is trying to solve,
and how, I decided I haven't that problem, I have net.ifnames=0 in
my GRUB_CMDLINE_LINUX_DEFAULT, in /etc/default/grub.

Well done! But, if there isn't any problem for you, why go to this
trouble? Leaving things as they are would seem not to do any harm.

To what trouble? Adding a boot option to my kernel? The trouble
was to find out which one. After that, I'm a happy camper :)

See, for an anecdote: long time ago (this was Linux kernel 2.0.36)
a group of us customised a distro (yes, it was a Debian. Must
have been around Potato or Woody) for a local hardware vendor.
It was a firewall appliance, with four network cards. One of
the ethernet ports was labelled "Internet", the other three "internal
net".

Guess which kind of problem we faced?

After a dive into the PCI spec, the specs of the motherboard
we used at the time, etc. we reached the conclusion that there
is no way to be sure we know which is which (if you follow the
thread here you'll discover exactly that pattern, years down
the history). PCI slots ain't it, because, at the end, hardware
does what it wants. Things become even worse when devices are
hanging off an USB tree. MACs? Some cards are chamaleons and
can change that [1] on the fly. Some can even have more than
one. Yadda, yadda.

Since then, I learnt that I like to relax call my interfaces
"eth0" and "wlan0".

Can we still be friends?

Cheers

[1] I won't bore you with /that/ anecdote, although it's
funny :)

[Brian]

On Thu 31 Mar 2022 at 07:28:47 +0200, ***@tuxteam.de wrote:

[...]]

Post by t***@tuxteam.de
Since then, I learnt that I like to relax call my interfaces
"eth0" and "wlan0".
Can we still be friends?

Of course! After all, we are both playing in the same game.

[t***@tuxteam.de]

Post by Brian
[...]]

Post by t***@tuxteam.de
Since then, I learnt that I like to relax call my interfaces
"eth0" and "wlan0".
Can we still be friends?

Of course! After all, we are both playing in the same game.

Glad :)

(No, seriously: I might sound somewhat sarcastic, but my relief is genuine)

Cheers

[The Wanderer]

Post by t***@tuxteam.de
This is one weakness I see with freedesktop often. They try to
fight complexity with ever more complexity, with the end result
of a more user-unfriendly (because less understandable) system.

Very well expressed. I've added that to the "complete" edition of my
signature (although I rotate out the pieces so rarely that I'd guess it
might see the light of day... sometime in the next decade?).