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

[andreimpopescu at gmail.com]

On Mi, 03 iul 19, 16:47:36, Michael Biebl wrote:
> Am 03.07.19 um 16:12 schrieb Michael Biebl:
> > Am 03.07.19 um 15:50 schrieb andreimpopescu at 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
> > 
> > We want people to switch to the new naming scheme for two reasons:
> > 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
-- 
http://wiki.debian.org/FAQsFromDebianUser
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-udev-stil-supports-the-old-method-net.ifnames-0-is-n.patch
Type: text/x-diff
Size: 1977 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20190703/55f6daff/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20190703/55f6daff/attachment.sig>