Discussion:
Bug#881771: release-notes: No mention of "predictable network interface names" in Debian 10
(too old to reply)
Karl O. Pinc
2017-11-14 23:10:02 UTC
Permalink
Package: release-notes
Severity: normal

Hi,

Section 4.7 "Preparing for the next release" of the jessie->stretch
release notes do not mention that Debian 10 will require migration to
the kernel's "predictable network names". (Or, I imagine, manual
assignment of network names.)

Because users are going to have to migrate anyway it might be useful
to do so sooner rather than later and "prepare for the next release". :-)

See:
/usr/share/doc/udev/README.Debian.gz
https://sources.debian.org/src/systemd/235-2/debian/udev.README.Debian/
Bug#881769

-- System Information:
Debian Release: 9.0
APT prefers stable
APT policy: (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Debian Bug Tracking System
2019-03-23 09:50:01 UTC
Permalink
This post might be inappropriate. Click to display it.
Paul Gevers
2019-03-23 09:50:01 UTC
Permalink
Control: tags -1 moreinfo

Hi Karl,
Post by Karl O. Pinc
Section 4.7 "Preparing for the next release" of the jessie->stretch
release notes do not mention that Debian 10 will require migration to
the kernel's "predictable network names". (Or, I imagine, manual
assignment of network names.)
Because users are going to have to migrate anyway it might be useful
to do so sooner rather than later and "prepare for the next release". :-)
/usr/share/doc/udev/README.Debian.gz
https://sources.debian.org/src/systemd/235-2/debian/udev.README.Debian/
Bug#881769
We have missed the boat for the stretch release-notes, but I think this
would also be good to mention in the buster release notes, right. I am
not familiar with this change, could you propose a text for the release
notes? If not, do you have ideas on who to ask?

Paul
PS: ideally the proposed text comes as a merge request against the
release notes (https://salsa.debian.org/ddp-team/release-notes/) but
just plain text here is also fine.
Karl O. Pinc
2019-03-27 02:40:01 UTC
Permalink
On Sat, 23 Mar 2019 10:44:15 +0100
Post by Paul Gevers
Post by Karl O. Pinc
Section 4.7 "Preparing for the next release" of the jessie->stretch
release notes do not mention that Debian 10 will require migration
to the kernel's "predictable network names". (Or, I imagine, manual
assignment of network names.)
Because users are going to have to migrate anyway it might be useful
to do so sooner rather than later and "prepare for the next
release". :-)
/usr/share/doc/udev/README.Debian.gz
https://sources.debian.org/src/systemd/235-2/debian/udev.README.Debian/
Bug#881769
We have missed the boat for the stretch release-notes, but I think
this would also be good to mention in the buster release notes,
right.
Yes. It is very important to mention. The udev README.Debian says
that new-style (not eth*, wlan*) interface names are required
under buster. If this is true, anyone upgrading a stretch system
that was upgraded from wheezy will have networking break, badly.
Post by Paul Gevers
I am not familiar with this change, could you propose a text
for the release notes? If not, do you have ideas on who to ask?
I will see if I can get you something next week. I started,
but am unable to finish right now.

I am no expert on this. I hope to provide a starting point for
someone else to verify and build upon.

Regards,

Karl <***@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Paul Gevers
2019-04-06 12:50:01 UTC
Permalink
Kind ping :)
Post by Karl O. Pinc
I will see if I can get you something next week. I started,
but am unable to finish right now.
I am no expert on this. I hope to provide a starting point for
someone else to verify and build upon.
Paul
Karl O. Pinc
2019-04-06 15:40:01 UTC
Permalink
On Sat, 6 Apr 2019 14:43:40 +0200
Post by Paul Gevers
Kind ping :)
Thanks. Did some work this week, but have nothing final.
There's a jumble of text needing assembly, editing, so forth.

I can send you a patch so you can see where I am if you'd
like early feedback.

A) Added text in "what's new" section explaining the (sorta-new)
interface naming scheme and why it's good. Mention there
that if you upgrade from a stretch which was itself
upgraded to stretch you need to migrate interface names,
so people see the warning.

Want to say "why the name change" to give people motivation.
This is also a place to put links to outside resources so people can
answer the question "what's this all about?".

Try to keep the new text brief but
there is an itemized list.

B) Added text in "preparing for upgrade" section to provide
a test code fragment that shows if old interface names are
used and must be upgraded. If so, refers user to "issues
to be aware of" for migration instructions.

Keep this text brief too.

C) Actual upgrade instructions. This is in-progress.

There are really 2 paths for manual migration of
interface names: one for when you have console/physical
access and another when you don't. In the first case,
you can try the new names, see what name you get, and
migrate /etc/. Without console access you need to
calculate the new interface name, migrate, and hope
you got the right name after reboot. To calculate
the right interface name you need additional background
information. I've whacked up a teeny script, with
no dependencies, to compute the common case. But it
does require the pciid as input, and I suggest installing
pciutils to get lspci to find pciids.

Regards,

Karl <***@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Andrei POPESCU
2019-04-06 18:40:01 UTC
Permalink
Post by Karl O. Pinc
C) Actual upgrade instructions. This is in-progress.
There are really 2 paths for manual migration of
interface names: one for when you have console/physical
access and another when you don't. In the first case,
you can try the new names, see what name you get, and
migrate /etc/. Without console access you need to
calculate the new interface name, migrate, and hope
you got the right name after reboot. To calculate
the right interface name you need additional background
information. I've whacked up a teeny script, with
no dependencies, to compute the common case. But it
does require the pciid as input, and I suggest installing
pciutils to get lspci to find pciids.
According to [1] here are two other options:

3. assign own names (e.g. internet0, dmz0, lan0, etc.) by creating a
.link file in /etc/systemd/network/ and migrate your configuration
accordingly.

4. disable the naming policy (via kernel parameter or udev) and
optionally migrate later (e.g. when one has console access to the
system).

It should be possible to use the kernel parameter in combination with a
"boot once" grub entry to both get the new name and test the new
configuration for remote systems.

Wouldn't it make sense to ask also the udev/systemd maintainers for
input?

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

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Karl O. Pinc
2019-04-06 20:00:01 UTC
Permalink
On Sat, 6 Apr 2019 21:31:42 +0300
Post by Andrei POPESCU
Post by Karl O. Pinc
C) Actual upgrade instructions. This is in-progress.
There are really 2 paths for manual migration of
interface names: one for when you have console/physical
access and another when you don't. In the first case,
you can try the new names, see what name you get, and
migrate /etc/. Without console access you need to
calculate the new interface name, migrate, and hope
you got the right name after reboot. To calculate
the right interface name you need additional background
information. I've whacked up a teeny script, with
no dependencies, to compute the common case. But it
does require the pciid as input, and I suggest installing
pciutils to get lspci to find pciids.
3. assign own names (e.g. internet0, dmz0, lan0, etc.) by creating a
.link file in /etc/systemd/network/ and migrate your configuration
accordingly.
This I was not thinking of, although I'd skimmed [1].

This is sort of like choice 2, in that it requires digging
into hardware identifiers. But being able to use, say, a
MAC address instead of digging into the intricacies of the bus
makes this a simpler approach. It would also be nice
to use this approach to keep the old eth* name and not
have to change the rest of /etc/ at all.

On the other hand, it does
not really help in migrating to the new naming scheme.
Post by Andrei POPESCU
4. disable the naming policy (via kernel parameter or udev) and
optionally migrate later (e.g. when one has console access to the
system).
It should be possible to use the kernel parameter in combination with
a "boot once" grub entry to both get the new name and test the new
configuration for remote systems.
Humm. Yes. [2] says this will work. For some reason I thought
it said this approach was going away, but it does not say that.

This might be simplest when updating remote systems. Although
it would require an "at" job to reboot after the "boot once". Right?
At least if trying to migrate remotely.
Post by Andrei POPESCU
Wouldn't it make sense to ask also the udev/systemd maintainers for
input?
Absolutely. But it might be best to wait and let them review something
already written. From my experience with [3] they don't seem
particularly interested in coming up with specific procedures
when console access is not available. All that got added
to the udev/systemd instructions was a warning that you'd
better have console access when migrating to the new interface
names.

I am using [2] and [3] as my starting point for the instructions
on migrating to the new network interface naming scheme.

I don't feel I'm an expert here. But something needs to be done
or a lot of people's networking is going to break on upgrading
to buster.

I'm attaching new_if_names_v1.patch, so you can see what I have.
(The upgrading.dbk file is not even close to valid.)
The patch may also give you URLs to other useful resources.
Post by Andrei POPESCU
[1]
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
[2]
https://sources.debian.org/src/systemd/241-2/debian/udev.README.Debian/
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/udev.README.Debian

[3]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881769

Karl <***@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Justin B Rye
2019-04-07 01:50:01 UTC
Permalink
diff --git a/en/issues.dbk b/en/issues.dbk
index 35841ee6..6d831f62 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -1,3 +1,4 @@
+<?xml version="1.0" encoding="utf-8"?>
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
@@ -39,6 +40,196 @@ information mentioned in <xref linkend="morereading"/>.
</para>
</section>
+ <section id="migrate-interface-names">
+ <title>Migrating from legacy <literal>eth</literal> and
+ <literal>wlan</literal> style network interface names</title>
+
We should probably start by pointing back at the deprecation stage in
the Stretch release-notes. Make this "issues" file the primary one
explaining the situation, with just a cross-reference in the
"upgrading" file, and introduce this in terms of "if your system was
upgraded from Jessie without migrating away from the network interface
naming scheme deprecated in the Stretch release, and depends on
/e/u/r/70-persistent-network-blah.txt to maintain these legacy names,
you should be aware that udev on Buster no longer recognises that
file. To avoid the danger of your machine losing networking after the
upgrade to Buster, it is recommended that you switch to the new naming
scheme in advance, updating any interface names hardcoded in
configuration files."
+ <para>Debian buster requires the new network interface naming
+ scheme. Legacy network interface names, names beginning with
+ <literal>eth</literal> or <literal>wlan</literal> are no longer
+ supported.</para>
That's not quite true; the change isn't that they're unsupported (if
you set up an appropriate .link file or something), it's that the
legacy support for configuring them in /etc/udev/rules.d/ has gone.
+
+ <tip>
+ <para>This section applies only to systems upgraded to stretch,
+ Debian 9. Systems installed as stretch, using the stretch
+ installer, already use the new naming scheme.</para>
+ </tip>
The <tip> element isn't used anywhere else in the release-notes.

I suppose it's also technically not true that the change in udev
behaviour applies only to upgraded systems; it's entirely possible to
set up a freshly installed Stretch box with an /e/u/r/ file.
+
+ <para>Interface names must be be manually migrated to the new
+ naming scheme before upgrading to Debian 10. If you rely on the
+ old names in custom ifupdown stanzas, firewall scripts, or other
+ networking configuration, these will also need to be updated to
+ the new names.</para>
(For people with only a single wireless connection, handled by
network-manager, is there in fact any "manual" work that they need to
do? Or will nm just bring up whatever wireless card it finds?)
+
+ <warning>
+ <para>This process may render your machine inaccessible through
+ ssh. Be sure to have physical or console access to the machine,
+ or a way to revert to your existing configuration.</para>
+ </warning>
Again, <warning> isn't currently used in release-notes.

(It seems to me the simplest safety net would be a grub entry using
the kernel net.ifnames=0 option.)
+
+ <para>First, determine all relevant network interface names: those
+ in <literal>/etc/udev/rules.d/70-persistent-net.rules</literal>,
+ or if that does not exist (in the case of virtual machines), in
+ <literal>ip link</literal> or
+ <literal>/sys/class/net/</literal>.</para>
+
+ <para>The following command may be helpful</para>
+
+ <screen>
+# ls /sys/class/net | egrep '^[0-9]+: (eth)|(wlan)[0-9]+'
+ </screen>
This looks like a halfway-converted "ip link" recipe - the "ls"
invocation will output some string like "eth0 lo wlan0", and the
"grep" won't match it. But if you're listing /sys/net for human
consumption there's not much need for filtering anyway - just:

<para>
First, determine all relevant network interface names by running:
</para>
<screen>
$ echo /sys/class/net/[ew]*
</screen>

I suppose you might want to add here:

<para>
In the legacy system, ethernet cards had names like
<literal>eth0</literal>; wireless cards had ones like
<literal>wlan0</literal>. The new system uses hardware-based
names like <literal>enp1s0</literal> or <literal>wlp2s1</literal>,
where the numbers encode PCI device bus- and slot-numbers.
</para>

(Apparently USB wifi hardware may use a MAC-based name, so that might
need to be mentioned, though on the plus side I think it's a case that
doesn't require any changes in Buster.)
+
+ <para>Then for every interface name use a command like</para>
+
+ <screen>
+# grep -rlF eth0 /etc
+ </screen>
+
+ <para>to find out where it is being used.</para>
+
+ <para>Then on "real hardware" machines, rename the file to
+ <literal>70-persistent-net.rules.old</literal>; alternately, if
+ you have multiple interfaces, instead of renaming you may wish to
+ comment out specific lines to convert a single interface at a
+ time.</para>
The stage at which they need to edit that ifupdown stanza or whatever
is also the stage at which they need the information about "how to
predict predictable names", so put that here.
+
+<para>On VMs remove the files /etc/systemd/network/99-default.link and
+/etc/systemd/network/50-virtio-kernel-names.link (the latter only exists on VMs
+that use virtio network devices).
Should there be extra </para><para>s here? Does the following apply
to both physical and VM systems?
+
+Rebuild the initrd with
+
+ update-initramfs -u
+
+and reboot. Then your system should have a new network interface name (or
+names). Adjust configuration files as discovered with the grep above, and test
+your system.
+
+Repeat for each network interface name, as necessary.
+
+--- README.Debian 2017-11-14 15:17:27.811548233 -0600
++++ README.Debian.new 2017-11-14 16:41:13.417161455 -0600
Oh, is this a patch for the udev README.Debian? There's nothing
Debian-specific about how the wlpXsX system works, so maybe it should
just point to some other source.
+
++Migration to the current network interface naming scheme
+
+<para>On a typical mass-market computer the new interface naming
+scheme for network interfaces on a PCI bus is based on the PCI bus and
(Less redundantly, "is based on the bus and slot numbers".)

Wait, if this is the README, why is it using markup?
+slot number. Ethernet interfaces are prefixed with
+<literal>en</literal> and wireless interfaces with
+<literal>wl</literal>. The bus and slot portion of an interface's PCI
+identifier can be found in <literal>dmesg</literal> output, the
+system's boot logs, or with the <literal>lspci</literal> command,
If this is a udev README we can probably hope to get some reliable
input on the best udevadm invocation for this purpose.
+found in the <literal>pciutils</literal> package. The logs and
+<literal>dmesg</literal> will display a typical pciid in the form
+<literal>0000:PP:SS.0</literal>. The <literal>lspci</literal> command
+displays pciids in the form <literal>[PP:SS]</literal>. In all cases
+pciids are shown in hexidecimal.</para>
+
+<para>The new name of a <emphasis>typical</emphasis> ethernet
+interface on a PCI bus is <literal>enpPPsSS</literal>, where
+<literal>PP</literal> is the (base 10) PCI bus number and
+<literal>SS</literal> is the (base 10) PCI slot number. The following
+script prints the new name of a typical ethernet interface. The
+(hexidecimal) pciid is given on the first line.</para>
^
It's "hexa-".
+
+<screen>
+printf '0A:30' \
+ | perl -e 'while (<>)
+ {printf("enp%ss%s\n",
+ oct("0x".substr($_,0,2)),
+ oct("0x".substr($_,3,2)));};'
+</screen>
This seems an overcomplicated way of converting a number from hex to
dec, though I may be biassed due to the fact that for my own hardware
I've never seen a slot or bus number higher than 7. Couldn't you just
use a bash function like:

$ ethname() { echo "enp$((16#$1))s$((16#$2))"; }
$ ethname 0a 30
enp10s48
+
+<para>The new name of a <emphasis>typical</emphasis> wireless
+interface on a PCI bus is <literal>enpPPsSS</literal>, where
^^
Typo. But this whole thing boils down to "and likewise for wireless
interfaces, but with a wl- prefix instead of en-".
+<literal>PP</literal> is the (base 10) PCI bus number and
+<literal>SS</literal> is the (base 10) PCI slot number. The following
+script prints the new name of a typical ethernet interface. The
^^^^^^^^
+(hexidecimal) pciid is given on the first line.</para>
+
+<screen>
+printf '0A:30' \
+ | perl -e 'while (<>)
+ {printf("wlp%ss%s\n",
+ oct("0x".substr($_,0,2)),
+ oct("0x".substr($_,3,2)));};'
+</screen>
+
+<para>Determining the name of an <emphasis>atypical</emphasis> network
+interface can be done by examining <ulink
+url="https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L4">the
+specifications</ulink>.</para>
+
+
++Begin by discovering the mapping between the new name(s) of your interface(s)
++and the old.
Wait, what's happening? Why is this text being preincremented?
++
++There appears to be no tool available to report the new, automatically
++determined, predictable network interface names. The approach taken here is
I thought that was what "udevadm test-builtin net_id" was intended
for, but I haven't tried it on a very wide range of machines.
++to de-configure the existing interfaces and discover the new interface names
++by observation after reboot. Because the new naming scheme is predictable it
++is also possible, if you know enough about your hardware configuration, to
++manually construct the new names. This is generally more laborious and error
++prone than simply seeing what the system does.
++
++WARNING: This process will disconnect your interface(s) from the network. Be
++sure to have physical access to the machine or a way to revert to your
++existing configuration. If you have multiple interfaces it may be prudent to
++work with only a single interface at a time -- this will also assist in
++mapping the old names to the new. If you have a single interface you could
++instead construct a custom initramfs, reboot into it after installing and
++testing an automated reboot into the default initramfs, and then examining
++the system logs to discover the new interface name. This latter approach is
++not discussed in this document.
++
++Determine all relevant network interface names: look in
++/etc/udev/rules.d/70-persistent-net.rules, or if that does not exist (in the
++case of virtual machines), in "ip link", or in /sys/class/net/.
It's simpler and more reliable just to standardise on pointing at
/sys/class/net/, and we don't need to do that in every file.
++
++On "real hardware" machines, rename the file to 70-persistent-net.rules.old;
++on VMs remove the file /etc/udev/rules.d/80-net-setup-link.rules instead.
++Alternately, if you have multiple interfaces, instead of renaming you may
++wish to comment out specific lines in these files so as to work with a single
++interface at a time.
++
++
++ update-initramfs -u
+
+-Then for every interface name use a command like
++Reboot.
++
++After reboot your system should have a new network interface name (or names).
++Repeat for each network interface name, as necessary.
++
++The new names must replace all occurences of the old in configuration files.
++
+
+ grep -r eth0 /etc
+
+ to find out where it is being used.
+
+-Then on "real hardware" machines, rename the file to
+-70-persistent-net.rules.old; on VMs remove the file
+-/etc/udev/rules.d/80-net-setup-link.rules instead.
+-
+-Reboot, adjust configuration files, and test your system.
++Adjust configuration files, run `update-initramfs -u`, reboot, and test your
++system.
+
+ Custom net interface naming
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
+</para>
What file is this? What file format? I... what...?
+
+ <para>For further information, including options available for
+ custom network interface naming, see</para>
+
+ <screen>
+# zless /usr/share/doc/udev/README.Debian.gz
+ </screen>
(That looks like a useless use of root!)
+ </section>
+
<section id="noteworthy-obsolete-packages" condition="fixme">
<title>Noteworthy obsolete packages</title>
<para>
diff --git a/en/upgrading.dbk b/en/upgrading.dbk
index b779789f..9c6d4eb8 100644
--- a/en/upgrading.dbk
+++ b/en/upgrading.dbk
@@ -275,6 +275,23 @@ $ apt-forktracer | sort
instructions in <xref linkend="old-upgrade"/>.
</para>
+ <section id="review-interface-names">
+ <title>Verify network interface name support</title>
+
+ <para>Network interface names beginning with
+ <literal>eth</literal> or <literal>wlan</literal> are not
+ supported in buster. Check for the existence of legacy interface
+ names with</para>
+
+ <screen>
+# ls /sys/class/net | egrep '^[0-9]+: (eth)|(wlan)[0-9]+'
+ </screen>
As above, just use something like "echo /sys/class/net/*". Or
preferably the upgrading file should just have a crossreference and a
warning that you need to fix this *before* dist-upgrading.
+
+ <para>If legacy network interface names are found the instructions
+ in <xref linkend="migrate-interface-names"/> must be followed.
+ Otherwise the interfaces will become unusable.</para>
+ </section>
Is this true for uncustomised network-managerised laptops? (Not that
people usually upgrade those via SSH, I suppose.)
<section id="review-actions">
<title>Review actions pending in aptitude if you use that package manager</title>
<programlisting condition="fixme">
diff --git a/en/whats-new.dbk b/en/whats-new.dbk
index 9965419f..f650324a 100644
--- a/en/whats-new.dbk
+++ b/en/whats-new.dbk
TODO: (JFS) List other server software? RADIUS? Streaming ?
</programlisting>
We don't need to say the same thing over and over again in every
file. The most it needs is cross-references pointing to one HOWTO,
which could even be on the wiki. The what's-new-in-buster list
shouldn't be going into detail on deprecations that were announced for
what's-new-in-stretch.
+<section id="new-netnames">
+ <title>New network interface names</title>
+ <para>Starting with buster, Debian now requires the <ulink
+ url="https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/">assignment
+ of fixed network interface names</ulink> based on
+ firmware/topology/bus location information.</para>
+
+ <!-- Put the important information up-front. People must upgrade! -->
+ <warning>
+ <para>Network interface names beginning with <literal>eth</literal>
+ or <literal>wlan</literal> are no longer supported. Debian systems
+ installed before stretch (Debian 9.0) and later upgraded to stretch
^^
Technically it's "Debian 9"; only point releases get two sig-figs.
But why say any more than "Systems upgraded to stretch from an earlier
release"?
+ require manual migration of their network interface names to the new
+ naming scheme. See: <xref linkend="migrate-interface-names"/></para>
+ </warning>
+
+ <para>The <ulink
+ url="https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L4">specifications</ulink>
+ for the new interface naming scheme is found in the code.</para>
Grammar nitpick: the specifications (plural) *are* found there.
+
+ <!-- Give people a reason to be happy. -->
+ <!-- List from the freedesktop.org URL above. -->
+ <para>Some advantages of the new scheme are:</para>
But the *scheme* isn't new... something like this might perhaps have
belonged in the Stretch release-notes, but for Buster the change we
need to explain the advantages of is that it has gone ahead with
deprecating the use of the old /etc/udev/ stuff and now only pays
attention to the kernel commandline and the standard systemd.link(5)
mechanism.
+
+ <itemizedlist>
+ <listitem>
+ <para>Stable interface names when kernels or drivers are
+ updated/changed</para>
+ </listitem>
+ <listitem>
+ <para>Applicability to both x86 and non-x86 machines</para>
+ </listitem>
+ <listitem>
+ <para>Uniformity across all distributions that use
+ systemd/udev</para>
+ </listitem>
+ <listitem>
+ <para>Interface names that are predictable, based on PCI slot
+ number<footnote>
+
+ <para>This is also a disadvantage. It can be harder to upgrade
+ hardware by moving the hard drives of an old computer to a new
+ computer. Unless the network cards in both machines use the
+ same PCI slot numbers, the names of the network interfaces will
+ change.</para>
+
+ </footnote></para>
+ </listitem>
+ <listitem>
+ <para>Stable interface names when broken Ethernet cards are
+ replaced, so long as the new card is fitted into the bus in the
+ old card's slot</para>
+ </listitem>
+ </itemizedlist>
+</section>
+
<section id="cd">
<title>CDs, DVDs, and BDs</title>
<para>
An attempt to compress this:
<para>
The old scheme had problems with interfaces changing names after
driver updates; the new scheme provides names that are stable,
uniform across architectures and systemd-using distributions, and
(in principle) predictable.
</para>

But as I say, it's not a new feature added for Buster, so it belongs
somewhere else.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Karl O. Pinc
2019-04-07 02:50:01 UTC
Permalink
Hi Justin,

Very briefly: the issues.dbk file contains
lots-o-stuff that seemed like it might be
relevant to include in the final text. A lot
of it is a hodge-podge and not ready to be reviewed.

Of course you're welcome to come up with something
yourself. :-)

On Sun, 7 Apr 2019 02:43:21 +0100
Post by Justin B Rye
+<screen>
+printf '0A:30' \
+ | perl -e 'while (<>)
+ {printf("enp%ss%s\n",
+ oct("0x".substr($_,0,2)),
+ oct("0x".substr($_,3,2)));};'
+</screen>
This seems an overcomplicated way of converting a number from hex to
dec, though I may be biassed due to the fact that for my own hardware
I've never seen a slot or bus number higher than 7. Couldn't you just
$ ethname() { echo "enp$((16#$1))s$((16#$2))"; }
$ ethname 0a 30
enp10s48
Technically, bash is not a required package. So it
won't necessarily be on every Debian system. The
perl-base package is required, so I used perl.
(printf is Posix and in dash, which is also required.)

This may be over-thinking, but I thought it a factor.

Regards,

Karl <***@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Andrei POPESCU
2019-04-07 07:10:01 UTC
Permalink
Post by Karl O. Pinc
Technically, bash is not a required package. So it
won't necessarily be on every Debian system. The
perl-base package is required, so I used perl.
(printf is Posix and in dash, which is also required.)
On my system bash is both Priority: required and Essential: yes.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Andrei POPESCU
2019-04-07 08:00:01 UTC
Permalink
Post by Karl O. Pinc
On Sat, 6 Apr 2019 21:31:42 +0300
Post by Andrei POPESCU
3. assign own names (e.g. internet0, dmz0, lan0, etc.) by creating a
.link file in /etc/systemd/network/ and migrate your configuration
accordingly.
This I was not thinking of, although I'd skimmed [1].
This is sort of like choice 2, in that it requires digging
into hardware identifiers. But being able to use, say, a
MAC address instead of digging into the intricacies of the bus
makes this a simpler approach. It would also be nice
to use this approach to keep the old eth* name and not
have to change the rest of /etc/ at all.
This approach seems much less error prone to me.
Post by Karl O. Pinc
On the other hand, it does
not really help in migrating to the new naming scheme.
It could be mentioned at least as an option, as many sysadmins might not
want to migrate anyway.
Post by Karl O. Pinc
Post by Andrei POPESCU
4. disable the naming policy (via kernel parameter or udev) and
optionally migrate later (e.g. when one has console access to the
system).
It should be possible to use the kernel parameter in combination with
a "boot once" grub entry to both get the new name and test the new
configuration for remote systems.
Humm. Yes. [2] says this will work. For some reason I thought
it said this approach was going away, but it does not say that.
This might be simplest when updating remote systems. Although
it would require an "at" job to reboot after the "boot once". Right?
At least if trying to migrate remotely.
Untested:

# echo "/usr/bin/systemd-run --on-boot=10min /bin/systemctl reboot" >> /etc/rc.local
# chmod +x /etc/rc.local

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Justin B Rye
2019-04-06 20:50:02 UTC
Permalink
Post by Karl O. Pinc
A) Added text in "what's new" section explaining the (sorta-new)
interface naming scheme and why it's good. Mention there
I hope you're aware that the last release-notes announced in
https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#new-interface-names
that "predictable"-style nicnames were already the default for
Stretch unless overridden in /etc/udev/rules.d/. And they
referenced the udev README that says this mechanism won't be
supported in Buster - the justifications struck me as weak, but
given a full release cycle's advance warning I wasn't going to
object.
Post by Karl O. Pinc
C) Actual upgrade instructions. This is in-progress.
There are really 2 paths for manual migration of
interface names: one for when you have console/physical
access and another when you don't. In the first case,
you can try the new names, see what name you get, and
migrate /etc/. Without console access you need to
calculate the new interface name, migrate, and hope
you got the right name after reboot. To calculate
the right interface name you need additional background
information. I've whacked up a teeny script, with
no dependencies, to compute the common case. But it
does require the pciid as input, and I suggest installing
pciutils to get lspci to find pciids.
Whether I'm accessing it physically or via ssh, can't I use something
like:
udevadm test /sys/class/net/$ETHX 2>/dev/null | grep NET
or
udevadm test-builtin net_id /sys/class/net/$ETHX 2>/dev/null
...? That worked for me even on Jessie machine.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Karl O. Pinc
2019-04-06 21:30:01 UTC
Permalink
On Sat, 6 Apr 2019 21:40:52 +0100
Post by Justin B Rye
Post by Karl O. Pinc
A) Added text in "what's new" section explaining the (sorta-new)
interface naming scheme and why it's good. Mention there
I hope you're aware that the last release-notes announced in
https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#new-interface-names
that "predictable"-style nicnames were already the default for
Stretch unless overridden in /etc/udev/rules.d/. And they
referenced the udev README that says this mechanism won't be
supported in Buster
Nope. I'm not aware. I don't tend to read the "what's new",
just the upgrade instructions and the section that says what
I need to do to get ready for the next release.

Or maybe I did read it and that's
what led me to file this bug report,
because there's no mention in the "what needs
to happen for the next release" section.

I do know that the new names are the default for new
stretch installs. But stretch systems upgraded
from jessie retain old names. Upgrading them
to buster without migrating names will break
networking. This is what needs to be addressed.

Anyway, it is new in buster, and pretty major for anyone with
old interface names, that new names are required.
_Somewhere_ it should say what the rationale is,
and how to parse the new names. Especially
for those who manage remote systems, for whom
maintaining connectivity throughout the upgrade
process is critical.

Sorry for running-on. I guess I'm not sure what
your point is. Is there something specific in
the patch of whats-new.dbk or upgrading.dbk
that you'd like changed?
Post by Justin B Rye
Post by Karl O. Pinc
C) Actual upgrade instructions. This is in-progress.
There are really 2 paths for manual migration of
interface names: one for when you have console/physical
access and another when you don't. In the first case,
you can try the new names, see what name you get, and
migrate /etc/. Without console access you need to
calculate the new interface name, migrate, and hope
you got the right name after reboot. To calculate
the right interface name you need additional background
information. I've whacked up a teeny script, with
no dependencies, to compute the common case. But it
does require the pciid as input, and I suggest installing
pciutils to get lspci to find pciids.
Whether I'm accessing it physically or via ssh, can't I use something
udevadm test /sys/class/net/$ETHX 2>/dev/null | grep NET
or
udevadm test-builtin net_id /sys/class/net/$ETHX 2>/dev/null
...? That worked for me even on Jessie machine.
I don't know. I just tried both the above on a
jessie box running on a VM and it did not show me
an ID_NET_NAME_PATH, which I presume is what
shows me the new-style interface name?

I don't have a stretch box with old-style names to test on.

Regards,

Karl <***@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Justin B Rye
2019-04-06 22:40:02 UTC
Permalink
Post by Karl O. Pinc
I do know that the new names are the default for new
stretch installs. But stretch systems upgraded
from jessie retain old names. Upgrading them
to buster without migrating names will break
networking. This is what needs to be addressed.
Yes, sorry that I always sound so negative - you're right that this
needs an entry in the release notes, and I'm glad you've made the
effort to get it sorted out! I'm looking at your patch now but it'll
take me a while to come up with suggestions.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Justin B Rye
2019-04-07 14:40:02 UTC
Permalink
Post by Karl O. Pinc
Post by Justin B Rye
Whether I'm accessing it physically or via ssh, can't I use something
udevadm test /sys/class/net/$ETHX 2>/dev/null | grep NET
or
udevadm test-builtin net_id /sys/class/net/$ETHX 2>/dev/null
...? That worked for me even on Jessie machine.
I don't know. I just tried both the above on a
jessie box running on a VM and it did not show me
an ID_NET_NAME_PATH, which I presume is what
shows me the new-style interface name?
(By "$ETHX" I mean "eth0 or whatever you've currently got"...)

Is the VM one that supports the ports-and-slots scheme? Some
apparently don't. I don't know exactly what happens instead, but
udevadm seems the most reliable way of narrowing that down.
Post by Karl O. Pinc
I don't have a stretch box with old-style names to test on.
If I boot a physical stretch box with the net.ifnames=0 option, it
comes up with an eth0 but udevadm says ID_NET_PATH=enp1s0.

I know udevadm worked for me on physical machines running jessie,
since that's how I predicted their names for my own upgrades. But if
it *is* the officially approved way of predicting predictable names, I
wish the upstream docs would say so.

Okay, here's a significantly trimmed-down version that we might be
able to use if it's bulked out with good external references.

In issues.dbk:

<section id="migrate-interface-names">
<title>Migrating from legacy network interface names</title>
<para>
If your system was upgraded from an earlier release, and still uses
the old-style network interface names that were deprecated with
stretch (such as <literal>eth0</literal> or <literal>wlan</literal>),
you should be aware that <systemitem role="package">udev</systemitem>
in buster no longer supports 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
naming scheme (usually meaning names like <literal>enp0s1</literal> or
<literal>wlp2s5</literal>, which incorporate PCI bus- and
slot-numbers). Take care to update any interface names hard-coded in
configuration for firewalls, <systemitem role="package">ifupdown</systemitem>.
and so on.
</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.
</para>
<para>
To find the new-style names that will be used, first find the
current names of the relevant interfaces:
</para>
<screen
$ echo /sys/class/net/[ew]*
</screen>
<para>
For each one, check whether it is used in configuration files:
</para>
<screen>
$ sudo rgrep -w eth0 /etc
</screen>
<para>
And what name <systemitem role="package">udev</systemitem> would prefer to
use for it:
</para>
<screen>
$ udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null
</screen>
<para>
(One of these may be a fallback MAC-based name, sometimes needed
for USB network hardware.)
</para>

[Possibly add extra details there for other special cases]

<para>
To switch over, disable <filename>70-persistent-net.rules</filename>
either by renaming it or by commenting out individual lines.
On virtual machines you will need to remove the files
<filename>/etc/systemd/network/99-default.link</filename> and
(if using virtio network devices)
<filename>/etc/systemd/network/50-virtio-kernel-names.link</filename>.
Then rebuild the <filename>initrd</filename>:
</para>
<screen>
$ sudo update-initramfs -u
</screen>
<para>
and reboot. Your system should now have new-style network interface
names. Adjust any remaining configuration files, and test your system.
</para>

[possibly a paragraph about safe upgrades over SSH]

<para>
See the
<ulink url="https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/">upstream
documentation</link> and the <literal>udev</literal>
<filename>README.Debian</file> for further information.
</para>
</section>

And/or maybe a pointer to some useful page in the Debian Wiki, but I
suspect we'd need to write one first.

Then in upgrading.dbk

<section id="review-interface-names">
<title>Verify network interface name support</title>
<para>
Systems upgraded from older releases that still use network interfaces
with names like <literal>eth</literal> or <literal>wlan</literal> are
at risk of losing networking once they switch to buster; see
<xref linkend="migrate-interface-names"/> for migration instructions.
</para>
</section>
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Andrei POPESCU
2019-04-07 15:20:01 UTC
Permalink
Post by Justin B Rye
Okay, here's a significantly trimmed-down version that we might be
able to use if it's bulked out with good external references.
<section id="migrate-interface-names">
<title>Migrating from legacy network interface names</title>
<para>
If your system was upgraded from an earlier release, and still uses
the old-style network interface names that were deprecated with
stretch (such as <literal>eth0</literal> or <literal>wlan</literal>),
s/eth0/eth/ ? (since you used the non-numbered names also in upgrading.dbk)
Post by Justin B Rye
you should be aware that <systemitem role="package">udev</systemitem>
in buster no longer supports 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
naming scheme (usually meaning names like <literal>enp0s1</literal> or
<literal>wlp2s5</literal>, which incorporate PCI bus- and
slot-numbers). Take care to update any interface names hard-coded in
configuration for firewalls, <systemitem role="package">ifupdown</systemitem>.
and so on.
</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.
Point to systemd.link(5)?
Post by Justin B Rye
</para>
<para>
To find the new-style names that will be used, first find the
</para>
<screen
$ echo /sys/class/net/[ew]*
</screen>
<para>
</para>
<screen>
$ sudo rgrep -w eth0 /etc
</screen>
<para>
And what name <systemitem role="package">udev</systemitem> would prefer to
</para>
<screen>
$ udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null
</screen>
<para>
(One of these may be a fallback MAC-based name, sometimes needed
for USB network hardware.)
</para>
[Possibly add extra details there for other special cases]
<para>
To switch over, disable <filename>70-persistent-net.rules</filename>
either by renaming it or by commenting out individual lines.
On virtual machines you will need to remove the files
<filename>/etc/systemd/network/99-default.link</filename> and
(if using virtio network devices)
<filename>/etc/systemd/network/50-virtio-kernel-names.link</filename>.
</para>
<screen>
$ sudo update-initramfs -u
</screen>
<para>
and reboot. Your system should now have new-style network interface
names. Adjust any remaining configuration files, and test your system.
</para>
https://wiki.debian.org/NetworkConfiguration#Predictable_Network_Interface_Names
suggests this might not be sufficient to activate the predictable naming
on stretch, is this tested?
Post by Justin B Rye
[possibly a paragraph about safe upgrades over SSH]
I believe your text above provides sufficient information to enable a
remote sysadmin to deal with this without further help.
Post by Justin B Rye
<para>
See the
<ulink url="https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/">upstream
documentation</link> and the <literal>udev</literal>
<filename>README.Debian</file> for further information.
</para>
</section>
And/or maybe a pointer to some useful page in the Debian Wiki, but I
suspect we'd need to write one first.
Then in upgrading.dbk
<section id="review-interface-names">
<title>Verify network interface name support</title>
<para>
Systems upgraded from older releases that still use network interfaces
with names like <literal>eth</literal> or <literal>wlan</literal> are
at risk of losing networking once they switch to buster; see
<xref linkend="migrate-interface-names"/> for migration instructions.
</para>
</section>
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Otherwise (FWIW) this looks good for me.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Justin B Rye
2019-04-07 16:50:01 UTC
Permalink
Post by Andrei POPESCU
<section id="migrate-interface-names">
<title>Migrating from legacy network interface names</title>
<para>
If your system was upgraded from an earlier release, and still uses
the old-style network interface names that were deprecated with
stretch (such as <literal>eth0</literal> or <literal>wlan</literal>),
s/eth0/eth/ ? (since you used the non-numbered names also in upgrading.dbk)
Here I'm just giving a familiar example to identify the scheme from.
(Oh, you're right, I'm inconsistent.)
Post by Andrei POPESCU
you should be aware that <systemitem role="package">udev</systemitem>
in buster no longer supports 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
naming scheme (usually meaning names like <literal>enp0s1</literal> or
<literal>wlp2s5</literal>, which incorporate PCI bus- and
slot-numbers). Take care to update any interface names hard-coded in
configuration for firewalls, <systemitem role="package">ifupdown</systemitem>.
and so on.
</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.
Point to systemd.link(5)?
Oh yes, I forgot to come back to this. It's not completely clear what
the approved method of doing manpage links is, but one option is to
point at
<ulink url="https://manpages.debian.org/stretch/udev/systemd.link.5.html">systemd.link(5)</ulink>.
or maybe just
<ulink url="https://manpages.debian.org/systemd.link">systemd.link(5)</ulink>.
Post by Andrei POPESCU
</para>
<para>
To find the new-style names that will be used, first find the
</para>
<screen
$ echo /sys/class/net/[ew]*
</screen>
<para>
</para>
<screen>
$ sudo rgrep -w eth0 /etc
</screen>
<para>
And what name <systemitem role="package">udev</systemitem> would prefer to
</para>
<screen>
$ udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null
</screen>
<para>
(One of these may be a fallback MAC-based name, sometimes needed
for USB network hardware.)
</para>
[Possibly add extra details there for other special cases]
(In particular there are onboard cards and PCI hotplug cards, but the
upstream docs explain these better than I could.)
Post by Andrei POPESCU
<para>
To switch over, disable <filename>70-persistent-net.rules</filename>
either by renaming it or by commenting out individual lines.
On virtual machines you will need to remove the files
<filename>/etc/systemd/network/99-default.link</filename> and
(if using virtio network devices)
<filename>/etc/systemd/network/50-virtio-kernel-names.link</filename>.
</para>
<screen>
$ sudo update-initramfs -u
</screen>
<para>
and reboot. Your system should now have new-style network interface
names. Adjust any remaining configuration files, and test your system.
</para>
https://wiki.debian.org/NetworkConfiguration#Predictable_Network_Interface_Names
suggests this might not be sufficient to activate the predictable naming
on stretch, is this tested?
It was enough for me, but there are also at least two other ways of
complicating matters:
* a net.ifnames=0 option in your grub config
* masking /dev/null symlinks in /etc/systemd/network/
Setting up one of those then forgetting about it might cause problems.
Post by Andrei POPESCU
[possibly a paragraph about safe upgrades over SSH]
I believe your text above provides sufficient information to enable a
remote sysadmin to deal with this without further help.
Given unlimited space and copious reliable sources we could also
produce a decision tree for which configuration files to modify before
or after the reboot, and whether to do test-runs with one-off kernel
options and dead-man's-handle cronjobs, and so on, but a small and
inaccurate version would probably do more harm than good.
Post by Andrei POPESCU
<para>
See the
<ulink url="https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/">upstream
documentation</link> and the <literal>udev</literal>
<filename>README.Debian</file> for further information.
</para>
</section>
And/or maybe a pointer to some useful page in the Debian Wiki, but I
suspect we'd need to write one first.
Then in upgrading.dbk
<section id="review-interface-names">
<title>Verify network interface name support</title>
<para>
Systems upgraded from older releases that still use network interfaces
with names like <literal>eth</literal> or <literal>wlan</literal> are
at risk of losing networking once they switch to buster; see
<xref linkend="migrate-interface-names"/> for migration instructions.
</para>
</section>
Oh, you're right; there's no reason for that to say "eth" that
wouldn't also apply in the previous one. This should either say "like
eth0 or wlan0" or "with names starting with eth- or wlan-".
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Justin B Rye
2019-04-13 17:30:01 UTC
Permalink
<section id="migrate-interface-names">
<title>Migrating from legacy network interface names</title>
<para>
[...]
Then in upgrading.dbk
<section id="review-interface-names">
<title>Verify network interface name support</title>
<para>
[...]

I wasn't sure exactly where in upgrading.dbk to add it, but here's a
suggested patch.

Meanwhile I notice a new grammar nitpick in issues.dbk: "to login"
should be "to log in" (just as with "backup", "setup", and so on, the
noun is a single word, but the verb is two words that can be separated
in phrases like "log yourself straight back in".).
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Debian Bug Tracking System
2019-04-13 18:20:01 UTC
Permalink
Your message dated Sat, 13 Apr 2019 20:11:12 +0200
with message-id <bc78fa37-341d-6d6a-e69c-***@debian.org>
and subject line Re: Bug#881771: release-notes: No mention of "predictable network interface names" in Debian 10
has caused the Debian Bug report #881771,
regarding release-notes: No mention of "predictable network interface names" in Debian 10
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)
--
881771: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881771
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Greg Wooledge
2019-04-23 17:50:02 UTC
Permalink
In the release notes, there's a udevadm command which is supposed to
tell us what the new interface name will be, but I had some trouble
interpreting the output.

wooledg:~$ udevadm test-builtin net_id /sys/class/net/eno1 2>/dev/null
ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_MAC=enxa08cfdc389e0
ID_OUI_FROM_DATABASE=Hewlett Packard
ID_NET_NAME_ONBOARD=eno1
ID_NET_LABEL_ONBOARD=enOnboard Lan
ID_NET_NAME_PATH=enp0s31f6

That's after the upgrade to buster; I did not save the results from
before the upgrade, but basically it would have been the same command
with /sys/class/net/eth0 as the final argument, with the same output.

I thought the new interface name would be enp0s31f6 but it turned out
to be eno1 instead.

tl;dr: there's nothing "predicatable" about these names.
Justin B Rye
2019-04-23 20:10:01 UTC
Permalink
Post by Greg Wooledge
In the release notes, there's a udevadm command which is supposed to
tell us what the new interface name will be, but I had some trouble
interpreting the output.
wooledg:~$ udevadm test-builtin net_id /sys/class/net/eno1 2>/dev/null
ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_MAC=enxa08cfdc389e0
ID_OUI_FROM_DATABASE=Hewlett Packard
ID_NET_NAME_ONBOARD=eno1
ID_NET_LABEL_ONBOARD=enOnboard Lan
ID_NET_NAME_PATH=enp0s31f6
Adding a "| grep ID_NET_NAME" would still leave three hits; is it
worth the extra complication?

(Yes, in a sane world it would be something like
$ udevadm nicnames
eno1 (enp0s31f6, enxa08cfdc389e0, eth0)
but in a sane world all of those alternatives would be directly usable
as aliases, just like "mount LABEL=FOO", and we don't seem to be
anywhere near that world...)
Post by Greg Wooledge
That's after the upgrade to buster; I did not save the results from
before the upgrade, but basically it would have been the same command
with /sys/class/net/eth0 as the final argument, with the same output.
I thought the new interface name would be enp0s31f6 but it turned out
to be eno1 instead.
tl;dr: there's nothing "predicatable" about these names.
I have to agree, which is why I avoided the word! The complication
you've run into there is the fact that ID_NET_NAME_ONBOARD names,
where present, take priority over ID_NET_NAME_PATH names (and your
ID_NET_NAME_PATH name is itself a complicated one). It's hard to
summarise completely and concisely (there are further problems with
USB dongles and virtual machines and so on), so what we most need is
good external sources we can point to. The upstream docs at
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
*do* cover your case (the bit about "1. Names [...] for on-board
devices"), but it doesn't exactly leap out at you.

Maybe what we need is a good clear Debian Wiki page we can point at?
But https://wiki.debian.org/NetworkConfiguration isn't it...

Oh, looking at it again: maybe where it currently says

<para>
This should give enough information to devise a migration plan.
(The <literal>udevadm</literal> output will include a fallback
MAC-based name, sometimes needed for USB network hardware.)
</para>

We could fit in some sort of mention of ID_NET_NAME_ONBOARD as well?
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Karl O. Pinc
2019-04-23 20:40:02 UTC
Permalink
On Tue, 23 Apr 2019 21:05:05 +0100
Post by Justin B Rye
Post by Greg Wooledge
In the release notes, there's a udevadm command which is supposed to
tell us what the new interface name will be, but I had some trouble
interpreting the output.
wooledg:~$ udevadm test-builtin net_id /sys/class/net/eno1
2>/dev/null ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_MAC=enxa08cfdc389e0
ID_OUI_FROM_DATABASE=Hewlett Packard
ID_NET_NAME_ONBOARD=eno1
ID_NET_LABEL_ONBOARD=enOnboard Lan
ID_NET_NAME_PATH=enp0s31f6
Adding a "| grep ID_NET_NAME" would still leave three hits; is it
worth the extra complication?
No. At least not for me because I'd still be confused as to
which ID_NET_NAME* will be used.

Regards,

Karl <***@karlpinc.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Karl O. Pinc
2019-04-24 03:30:01 UTC
Permalink
On Tue, 23 Apr 2019 21:05:05 +0100
Post by Justin B Rye
Post by Greg Wooledge
In the release notes, there's a udevadm command which is supposed to
tell us what the new interface name will be, but I had some trouble
interpreting the output.
wooledg:~$ udevadm test-builtin net_id /sys/class/net/eno1
2>/dev/null ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_MAC=enxa08cfdc389e0
ID_OUI_FROM_DATABASE=Hewlett Packard
ID_NET_NAME_ONBOARD=eno1
ID_NET_LABEL_ONBOARD=enOnboard Lan
ID_NET_NAME_PATH=enp0s31f6
I thought the new interface name would be enp0s31f6 but it turned
out to be eno1 instead.
The complication
you've run into there is the fact that ID_NET_NAME_ONBOARD names,
where present, take priority over ID_NET_NAME_PATH names (and your
ID_NET_NAME_PATH name is itself a complicated one). It's hard to
summarise completely and concisely (there are further problems with
USB dongles and virtual machines and so on), so what we most need is
good external sources we can point to. The upstream docs at
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
*do* cover your case (the bit about "1. Names [...] for on-board
devices"), but it doesn't exactly leap out at you.
Oh, looking at it again: maybe where it currently says
<para>
This should give enough information to devise a migration plan.
(The <literal>udevadm</literal> output will include a fallback
MAC-based name, sometimes needed for USB network hardware.)
</para>
We could fit in some sort of mention of ID_NET_NAME_ONBOARD as well?
It would sure be nice to have an ordered list where the topmost
in the list which appears in the udevadm output is used:

ID_NET_NAME_ONBOARD
ID_NET_NAME_PATH
ID_NET_NAME_MAC

And so forth. I don't even know if this makes sense but
without some guidance there's just no way for
the reader to know what name the kernel will use.

Regards,

Karl <***@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Justin B Rye
2019-04-24 10:30:01 UTC
Permalink
Post by Karl O. Pinc
Post by Andrei POPESCU
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
[...]
Post by Karl O. Pinc
Post by Andrei POPESCU
Oh, looking at it again: maybe where it currently says
<para>
This should give enough information to devise a migration plan.
(The <literal>udevadm</literal> output will include a fallback
MAC-based name, sometimes needed for USB network hardware.)
</para>
We could fit in some sort of mention of ID_NET_NAME_ONBOARD as well?
It would sure be nice to have an ordered list where the topmost
ID_NET_NAME_ONBOARD
ID_NET_NAME_PATH
ID_NET_NAME_MAC
And so forth. I don't even know if this makes sense but
without some guidance there's just no way for
the reader to know what name the kernel will use.
Yes, if you study the freedesktop.org page (which unhelpfully leaves
out the actual ID_NET_NAME_ terms) you'll see that by default it's
ONBOARD (eno1)
SLOT (ens1)
PATH (which may look like anything from enp0s1f1 to eth0)
MAC (enx101010101010)
*except* that there are several ways of overriding these defaults, and
one of them may have been set up without the user knowing about it
(this whole thing is after all being set off by the fact that they've
got a "legacy" .rules file). Then again Google also tells me horror
stories of firmware/kernel/udev interactions that unexpectedly
resurrect different name schemes. And this is just ethernet NICs!

I don't think it's realistic to expect that the Buster release-notes
could contain an accurate, user-friendly guide covering everything
that people need to know, even if they're running a laptop with a
phone dongle, a VM with an out-of-date kernel, or a server with
infiniband hardware where the previous sysadmin set up crazy .rules
files! We're going to have to leave corner cases to external
sources, and it isn't clear to me how common even things like ONBOARD
and SLOT names are.

After sleeping on it, here's an attempt to stuff more advice into the
above paragraph:

<para>
This should give enough information to devise a migration plan.
(If the <literal>udevadm</literal> output includes an
<quote>onboard</quote> name, that takes priority; MAC-based names
are normally treated as a fallback, but may be needed for USB
network hardware.)
</para>
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Paul Gevers
2019-05-02 20:50:01 UTC
Permalink
Hi,
<para>
This should give enough information to devise a migration plan.
(If the <literal>udevadm</literal> output includes an
<quote>onboard</quote> name, that takes priority; MAC-based names
are normally treated as a fallback, but may be needed for USB
network hardware.)
</para>
Pushed in commit ed066ff.

Paul

Loading...