Release Notes for buster: 70-persistent-net-rules still supported?

[a***@gmail.com]

Full quote for some context, relevant part of the thread starts at
https://lists.debian.org/debian-user/2019/07/msg00084.html

Not even that, it seems (no longer affects systemd).

Have you confirmed that? It seems possible that on a systemd
machine, things in other packages (such as whatever would provide
that 99-default.link file, which unfortunately - because it's under
/etc/ - can't be easily found through 'apt-file search') might
still be overriding 70-persistent-net.rules, even with this change
reverted.

https://github.com/systemd/systemd/issues/11436
https://github.com/systemd/systemd/commit/ed30802324365dde6c05d0b7c3ce1a0eff3bf571
Let's revert, and start with a clean slate. This fixes #11436.
(#11436 being 'network interface is renamed although NAME has been
set by udev rule'.)

Yeah, I read that, although I didn't read #11436.

Maybe I'm not understanding this (quite possible).

I think you're reading it the same way I am. I'm just questioning
whether what we're seeing here represents the whole picture, and partly
also whether this is the latest word on the subject.
It might be interesting to know when that section of the release notes
was last modified, relative to when this change was made.

https://lists.debian.org/debian-doc/2019/04/msg00012.html

Somebody on an up-to-date Buster could perform Michael Biebl's bug

In particular, someone on a machine running full-on systemd. My
available machines are either non-systemd or not systemd-as-init, so my
observed results aren't applicable.

My upgrade from stretch to buster left networking as it was before. My
70-persistent-net.rules is
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:90:dc:a2:4d:26",
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
Following Curt's suggestion I removed the relevant module and rebooted.
'ip a' shows eth0. The advice in the Release Notes

....you should be aware that udev in buster no longer supports the mechanism
of defining their names via /etc/udev/rules.d/70-persistent-net.rules.

does not accord with my experience. In the light of #919390 it seems
doubtful to me that the "Migrating from legacy network interface names"
section is useful.

Dear udev Maintainers,

Please kindly confirm this Release Notes entry is needed/correct/etc.
https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names

#919390 appears to contradict /usr/share/doc/udev/README.Debian.gz.

Kind regards,
Andrei

[a***@gmail.com]

Post by a***@gmail.com
Please kindly confirm this Release Notes entry is needed/correct/etc.
https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names
#919390 appears to contradict /usr/share/doc/udev/README.Debian.gz.

In short: yes please keep this section in the release notes.
We still ship
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch
in buster, which sort of makes 70-persistent-net.rules work most of the
time.
This patch is a horrible hack though and has already been removed in the
experimental branch which will be buster+1
https://salsa.debian.org/systemd-team/systemd/commit/3d45a7af959cf260bffcb1ad0262973b5750ae36
1/ It makes buster backports of newer systemd versions possible
2/ People are already prepared when they upgrade to buster+1. Say the
buster+1 kernel fails, they can still boot with the buster kernel+initramfs.
I can go into more detail but hope that clarifies the situation.

Hm, reading the release notes again, there should be a big fat warning
when using net.ifnames=0 (there is also a typo, note the missing 's').
It does not enforce the old naming scheme, it simply means use the
kernel provided names. This is only advisable if you ever have a single
interface. If you have multiple interfaces it is possible that the names
change as the kernel probes devices asynchronously nowadays.

Would the kernel opetion work in case the interfaces are of different
types (e.g. one ethernet and one wireless)?

Based on your comments I prepared the patch below (also attached for
convenience), that I could push anytime.

diff --git a/en/issues.dbk b/en/issues.dbk
index 4769f9d6..c7634151 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -136,7 +136,7 @@ information mentioned in <xref linkend="morereading"/>.
the old-style network interface names that were deprecated with
stretch (such as <literal>eth0</literal> or <literal>wlan0</literal>),
you should be aware that <systemitem role="package">udev</systemitem>
- in buster no longer supports the mechanism of defining their names via
+ in buster does not reliably support the mechanism of defining their names via
<filename>/etc/udev/rules.d/70-persistent-net.rules</filename>. To
avoid the danger of your machine losing networking after the upgrade
to buster, it is recommended that you migrate in advance to the new
@@ -148,10 +148,11 @@ information mentioned in <xref linkend="morereading"/>.
</para>
<para>
The alternative is to switch to a supported mechanism for enforcing
- the old naming scheme, such as the <literal>net.ifname=0</literal>
- kernel commandline option or a systemd <filename>.link</filename>
- file (see <ulink
- url="https://manpages.debian.org/systemd.link">systemd.link(5)</ulink>).
+ the old naming scheme, such as a systemd <filename>.link</filename>
+ file (see <ulink url="https://manpages.debian.org/systemd.link">
+ systemd.link(5)</ulink>).
+ The <literal>net.ifnames=0</literal> kernel commandline option might
+ also work for systems with only one network interface.
</para>
<para>
To find the new-style names that will be used, first find the

Kind regards,
Andrei

[Michael Biebl]

Post by a***@gmail.com

Post by a***@gmail.com
Please kindly confirm this Release Notes entry is needed/correct/etc.
https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names
#919390 appears to contradict /usr/share/doc/udev/README.Debian.gz.

In short: yes please keep this section in the release notes.
We still ship
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch
in buster, which sort of makes 70-persistent-net.rules work most of the
time.
This patch is a horrible hack though and has already been removed in the
experimental branch which will be buster+1
https://salsa.debian.org/systemd-team/systemd/commit/3d45a7af959cf260bffcb1ad0262973b5750ae36
1/ It makes buster backports of newer systemd versions possible
2/ People are already prepared when they upgrade to buster+1. Say the
buster+1 kernel fails, they can still boot with the buster kernel+initramfs.
I can go into more detail but hope that clarifies the situation.

Hm, reading the release notes again, there should be a big fat warning
when using net.ifnames=0 (there is also a typo, note the missing 's').
It does not enforce the old naming scheme, it simply means use the
kernel provided names. This is only advisable if you ever have a single
interface. If you have multiple interfaces it is possible that the names
change as the kernel probes devices asynchronously nowadays.

Would the kernel opetion work in case the interfaces are of different
types (e.g. one ethernet and one wireless)?
Based on your comments I prepared the patch below (also attached for
convenience), that I could push anytime.
diff --git a/en/issues.dbk b/en/issues.dbk
index 4769f9d6..c7634151 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -136,7 +136,7 @@ information mentioned in <xref linkend="morereading"/>.
the old-style network interface names that were deprecated with
stretch (such as <literal>eth0</literal> or <literal>wlan0</literal>),
you should be aware that <systemitem role="package">udev</systemitem>
- in buster no longer supports the mechanism of defining their names via
+ in buster does not reliably support the mechanism of defining their names via

I'd prefer if we rephrased that and declared the old naming scheme as
officially unsupported in buster.
It might still work under certain circumstances (not sure if it makes
sense to go into detail here what those circumstances are) but users are
strongly advised to migrate to the new naming scheme.

Post by a***@gmail.com
<filename>/etc/udev/rules.d/70-persistent-net.rules</filename>. To
avoid the danger of your machine losing networking after the upgrade
to buster, it is recommended that you migrate in advance to the new
@@ -148,10 +148,11 @@ information mentioned in <xref linkend="morereading"/>.
</para>
<para>
The alternative is to switch to a supported mechanism for enforcing
- the old naming scheme, such as the <literal>net.ifname=0</literal>
- kernel commandline option or a systemd <filename>.link</filename>
- file (see <ulink
- url="https://manpages.debian.org/systemd.link">systemd.link(5)</ulink>).
+ the old naming scheme, such as a systemd <filename>.link</filename>

As said, net.ifnames=0 does not enforce the old naming scheme, it means
use the kernel provided names.

If users want to stick with the kernel provided interfaces names, they
should be aware that this is can lead to interfaces having different
names on each boot if they have multiple interfaces.


Usually ethernet interfaces are name eth* and wifi interfaces are named
wlan*, so yeah, if you have a single ethernet interface which is named
eth0 and a single wifi interface that is named wlan0, then you are safe
as well. I do vaguely remember seeing wifi interfaces named as eth*
though. I've seen this a long time ago, not sure if this is still valid
today and you can safely say nowadays that wifi interfaces are always
called wlan*.

Post by a***@gmail.com
+ file (see <ulink url="https://manpages.debian.org/systemd.link">
+ systemd.link(5)</ulink>).
+ The <literal>net.ifnames=0</literal> kernel commandline option might
+ also work for systems with only one network interface.
</para>
<para>
To find the new-style names that will be used, first find the
Kind regards,
Andrei
_______________________________________________
Pkg-systemd-maintainers mailing list
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

[Justin B Rye]

(Thanks to Andrei for coming up with a better revision than the draft
I was too slow with!)

Post by Michael Biebl

Post by a***@gmail.com
Based on your comments I prepared the patch below (also attached for
convenience), that I could push anytime.
diff --git a/en/issues.dbk b/en/issues.dbk
index 4769f9d6..c7634151 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -136,7 +136,7 @@ information mentioned in <xref linkend="morereading"/>.
the old-style network interface names that were deprecated with
stretch (such as <literal>eth0</literal> or <literal>wlan0</literal>),
you should be aware that <systemitem role="package">udev</systemitem>
- in buster no longer supports the mechanism of defining their names via
+ in buster does not reliably support the mechanism of defining their names via

I'd prefer if we rephrased that and declared the old naming scheme as
officially unsupported in buster.
It might still work under certain circumstances (not sure if it makes
sense to go into detail here what those circumstances are) but users are
strongly advised to migrate to the new naming scheme.

Maybe we need something like

you should be aware that <systemitem role="package">udev</systemitem>
upstream officially no longer supports the mechanism of defining their
names via <filename>/etc/udev/rules.d/70-persistent-net.rules</filename>
(though this may continue to work for now in buster). To avoid the
danger of your machine losing networking, it is strongly recommended
that you migrate to the new

Post by Michael Biebl

Post by a***@gmail.com
<filename>/etc/udev/rules.d/70-persistent-net.rules</filename>. To
avoid the danger of your machine losing networking after the upgrade
to buster, it is recommended that you migrate in advance to the new
@@ -148,10 +148,11 @@ information mentioned in <xref linkend="morereading"/>.
</para>
<para>
The alternative is to switch to a supported mechanism for enforcing
- the old naming scheme, such as the <literal>net.ifname=0</literal>
- kernel commandline option or a systemd <filename>.link</filename>
- file (see <ulink
- url="https://manpages.debian.org/systemd.link">systemd.link(5)</ulink>).
+ the old naming scheme, such as a systemd <filename>.link</filename>

As said, net.ifnames=0 does not enforce the old naming scheme, it means
use the kernel provided names.

I don't follow. Surely the old naming scheme *is* to use the
kernel-provided names? Where did names like "eth0" come from if not
the kernel?

Post by Michael Biebl
If users want to stick with the kernel provided interfaces names, they
should be aware that this is can lead to interfaces having different
names on each boot if they have multiple interfaces.

Is this the same risk they're already running, or has it got worse
between stretch and buster?

[Michael Biebl]

Post by Justin B Rye

Post by Michael Biebl
As said, net.ifnames=0 does not enforce the old naming scheme, it means
use the kernel provided names.

I don't follow. Surely the old naming scheme *is* to use the
kernel-provided names? Where did names like "eth0" come from if not
the kernel?

Not quite. The old scheme (let's called it 70-persistent-net.rules for
that matter) used the same name space as the kernel (i.e. eth* and
wlan*) but it bound it to the MAC address.

So, an interface could be called eth0 by the kernel but
70-persistent-net.rules would map this to eth1 (this can happen if
70-persistent-net.rules already had an old eth0 entry from a card that
no longer existed).

The result is that 70-persistent-net.rules renames eth0 to eth1.
This is one, if not the most problematic aspect of the old scheme as it
was using the kernel name space to pick the new names from. It's not
hard to see that this is riddled with race conditions if you have
multiple interfaces.

Now, with net.ifnames=0 we don't do any renaming in user space at all.
We just take the interface names that are given to us by the kernel.

[a***@gmail.com]

Post by Michael Biebl

Post by a***@gmail.com
diff --git a/en/issues.dbk b/en/issues.dbk
index 4769f9d6..c7634151 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -136,7 +136,7 @@ information mentioned in <xref linkend="morereading"/>.
the old-style network interface names that were deprecated with
stretch (such as <literal>eth0</literal> or <literal>wlan0</literal>),
you should be aware that <systemitem role="package">udev</systemitem>
- in buster no longer supports the mechanism of defining their names via
+ in buster does not reliably support the mechanism of defining their names via

I'd prefer if we rephrased that and declared the old naming scheme as
officially unsupported in buster.

As per the e-mail thread that started this, users will find out it does
work. If the Release Notes entry contradicts their experience they will
dismiss the advice as outdated/incorrect/etc.

Would attached patch be better?

Post by Michael Biebl
It might still work under certain circumstances (not sure if it makes
sense to go into detail here what those circumstances are) but users are
strongly advised to migrate to the new naming scheme.

Sure.

Post by Michael Biebl

Post by a***@gmail.com
<filename>/etc/udev/rules.d/70-persistent-net.rules</filename>. To
avoid the danger of your machine losing networking after the upgrade
to buster, it is recommended that you migrate in advance to the new
@@ -148,10 +148,11 @@ information mentioned in <xref linkend="morereading"/>.
</para>
<para>
The alternative is to switch to a supported mechanism for enforcing
- the old naming scheme, such as the <literal>net.ifname=0</literal>
- kernel commandline option or a systemd <filename>.link</filename>
- file (see <ulink
- url="https://manpages.debian.org/systemd.link">systemd.link(5)</ulink>).
+ the old naming scheme, such as a systemd <filename>.link</filename>

As said, net.ifnames=0 does not enforce the old naming scheme, it means
use the kernel provided names.
If users want to stick with the kernel provided interfaces names, they
should be aware that this is can lead to interfaces having different
names on each boot if they have multiple interfaces.

I believe systems with multiple interfaces of the same type are not very
common outside data centers and such.

Post by Michael Biebl
Usually ethernet interfaces are name eth* and wifi interfaces are named
wlan*, so yeah, if you have a single ethernet interface which is named
eth0 and a single wifi interface that is named wlan0, then you are safe
as well. I do vaguely remember seeing wifi interfaces named as eth*
though. I've seen this a long time ago, not sure if this is still valid
today and you can safely say nowadays that wifi interfaces are always
called wlan*.

My new patch tries to address this.

Kind regards,
Andrei

[Michael Biebl]

Post by a***@gmail.com

Post by Michael Biebl

Post by a***@gmail.com
diff --git a/en/issues.dbk b/en/issues.dbk
index 4769f9d6..c7634151 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -136,7 +136,7 @@ information mentioned in <xref linkend="morereading"/>.
the old-style network interface names that were deprecated with
stretch (such as <literal>eth0</literal> or <literal>wlan0</literal>),
you should be aware that <systemitem role="package">udev</systemitem>
- in buster no longer supports the mechanism of defining their names via
+ in buster does not reliably support the mechanism of defining their names via

I'd prefer if we rephrased that and declared the old naming scheme as
officially unsupported in buster.

As per the e-mail thread that started this, users will find out it does
work. If the Release Notes entry contradicts their experience they will
dismiss the advice as outdated/incorrect/etc.

Being a supported configuration and still working (to some extent) are
two different issues, I'd say.

[a***@gmail.com]

Post by Michael Biebl

Post by a***@gmail.com
As per the e-mail thread that started this, users will find out it does
work. If the Release Notes entry contradicts their experience they will
dismiss the advice as outdated/incorrect/etc.

Being a supported configuration and still working (to some extent) are
two different issues, I'd say.

I think we agree, let me rephrase to make sure ;)

The original entry stated "it doesn't work" (or it could be understood
like this).

Users found it does work (for them) and as a consequence they dismissed
the entire entry as incorrect/outdated/etc. and didn't bother to migrate
(don't fix if working, etc.).

My intention is to explain that, while it may work in some cases, it's
not something to rely on and users should migrate[1].

We could make it stronger by pointing out that it will definitely be
disabled in bullseye and backports at the expense of making the entry
slightly longer.

[1] if my wording does not convey this properly hopefully Justin will
chime in to improve it ;)

Kind regards,
Andrei

[Paul Gevers]

Hi,

Post by a***@gmail.com
My new patch tries to address this.

Pushed this version already.

Paul

[Andrei POPESCU]

Post by Michael Biebl
Usually ethernet interfaces are name eth* and wifi interfaces are named
wlan*, so yeah, if you have a single ethernet interface which is named
eth0 and a single wifi interface that is named wlan0, then you are safe
as well. I do vaguely remember seeing wifi interfaces named as eth*
though. I've seen this a long time ago, not sure if this is still valid
today and you can safely say nowadays that wifi interfaces are always
called wlan*.

Here is a confirmed report of a wireless that is named ethX by the
kernel.

https://lists.debian.org/debian-user/2019/07/msg00610.html

(I received full dmesg off list if someone is interested)

To be on the safe side the entry could be adjusted as per this patch
(also attached for convenience):


diff --git a/en/issues.dbk b/en/issues.dbk
index 7b46d168..3b463f2d 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -153,7 +153,10 @@ information mentioned in <xref linkend="morereading"/>.
file (see <ulink url="&url-man;systemd.link">
systemd.link(5)</ulink>).
The <literal>net.ifnames=0</literal> kernel commandline option might
- also work for systems with only one network interface (of a given type).
+ also work for systems with only one network interface<footnote><para>
+ It should also work for systems with interfaces of different types (e.g.
+ Ethernet and wireless) as the kernel it typically using different
+ different naming conventions for them (i.e. eth0 and wlan0).</para></footnote>.
</para>
<para>
To find the new-style names that will be used, first find the


Kind regards,
Andrei

[Justin B Rye]

Post by Andrei POPESCU

Post by Michael Biebl
Usually ethernet interfaces are name eth* and wifi interfaces are named
wlan*, so yeah, if you have a single ethernet interface which is named
eth0 and a single wifi interface that is named wlan0, then you are safe
as well. I do vaguely remember seeing wifi interfaces named as eth*
though. I've seen this a long time ago, not sure if this is still valid
today and you can safely say nowadays that wifi interfaces are always
called wlan*.

Here is a confirmed report of a wireless that is named ethX by the
kernel.
https://lists.debian.org/debian-user/2019/07/msg00610.html
(I received full dmesg off list if someone is interested)

(Groan. Any hope they would be willing to go to the trouble of
booting a buster-backport kernel and seeing what that one thinks?)

Post by Andrei POPESCU
To be on the safe side the entry could be adjusted as per this patch
diff --git a/en/issues.dbk b/en/issues.dbk
index 7b46d168..3b463f2d 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -153,7 +153,10 @@ information mentioned in <xref linkend="morereading"/>.
file (see <ulink url="&url-man;systemd.link">
systemd.link(5)</ulink>).
The <literal>net.ifnames=0</literal> kernel commandline option might
- also work for systems with only one network interface (of a given type).
+ also work for systems with only one network interface<footnote><para>
+ It should also work for systems with interfaces of different types (e.g.
+ Ethernet and wireless) as the kernel it typically using different

e is
(Ethernet is technically a trademark, but elsewhere we leave it lowercase)

This could be interpreted as saying that it will work for systems with
any number of interfaces of any number of different types. Maybe:

It should also work for systems with one ethernet and one wireless
interface, as the kernel typically uses different

Post by Andrei POPESCU
+ different naming conventions for them (i.e. eth0 and wlan0).</para></footnote>.

^^^^^^^^^
(Repeated word)

Post by Andrei POPESCU
</para>
<para>
To find the new-style names that will be used, first find the

I'm not sure what you're trying to achieve with this change, since all
it seems to do is assert more specifically that the thing you've got a
confirmed report of typically doesn't happen, which is what we were
all assuming anyway.

Would it help if instead of saying "only one network interface (of a
given type)" it said something like "only one network interface in a
given type namespace (e.g. ethX)"?

[Andrei POPESCU]

Post by Justin B Rye

Post by Andrei POPESCU
To be on the safe side the entry could be adjusted as per this patch

I'm not sure what you're trying to achieve with this change, since all
it seems to do is assert more specifically that the thing you've got a
confirmed report of typically doesn't happen, which is what we were
all assuming anyway.

As per above "to be on the safe side", but maybe I'm too cautious :)

Post by Justin B Rye
Would it help if instead of saying "only one network interface (of a
given type)" it said something like "only one network interface in a
given type namespace (e.g. ethX)"?

From my translator's point of view, please avoid the jargon
("namespace"), though I can't come up with something better...

Kind regards,
Andrei

[Justin B Rye]

Post by Andrei POPESCU

Post by Justin B Rye
Would it help if instead of saying "only one network interface (of a
given type)" it said something like "only one network interface in a
given type namespace (e.g. ethX)"?

From my translator's point of view, please avoid the jargon
("namespace"), though I can't come up with something better...

Unfortunately I'd chosen the jargon word carefully for its usefulness
as a way of equivocating... you may not be safe using one wired and
one wireless card, since in very rare cases the kernel may misclassify
them as eth0 and eth1; but as long as it's only putting one interface
in each namespace you *are* guaranteeably safe! (Or at least, you're
safe from them coming up as eth1 and eth0 the next time; you aren't
safe from finding they've turned into eth0 and wlan0. But the
"predictable names" system doesn't protect you from that anyway; the
only thing that does is identifying them by MAC addresses.)

Another way of phrasing it would be to say something like "only one
network interface recognised as belonging to a given type (e.g.
ethX)". But that's getting too contorted. Maybe it would be better
to simplify down to this:

On systems with simple network hardware (e.g. only an <literal>eth0</literal>
and no <literal>eth1</literal>) the <literal>net.ifnames=0</literal> kernel
commandline option should also work.

[Paul Gevers]

Hi,

Post by Justin B Rye
Another way of phrasing it would be to say something like "only one
network interface recognised as belonging to a given type (e.g.
ethX)". But that's getting too contorted. Maybe it would be better
On systems with simple network hardware (e.g. only an <literal>eth0</literal>
and no <literal>eth1</literal>) the <literal>net.ifnames=0</literal> kernel
commandline option should also work.

Shall I push this?

Paul

[Justin B Rye]

Post by Paul Gevers

[...] But that's getting too contorted. Maybe it would be better
On systems with simple network hardware (e.g. only an <literal>eth0</literal>
and no <literal>eth1</literal>) the <literal>net.ifnames=0</literal> kernel
commandline option should also work.

Shall I push this?

If you like it - I think it's a slight improvement, but I may have
been missing the point of Andrei's suggested changes.