Discussion:
Installing chapter in the release notes
(too old to reply)
Baptiste Jammet
2017-03-19 16:40:01 UTC
Permalink
Hello -boot people,

(Cc debian-doc for information)

I don't know if there will be a d-i Stretch RC 3, but I would like to
complete the "installing" chapter of the release notes.

I have already done some easy update [1]:
* ports: mips64el added and none removed
* i586 bumped to i686
* Graphical installer by default in supported arches
* No new languages

I have seen some important news:
* multiarch default is now amd64
* ifname instead of mac address
* Full CD sets were removed
* Almost all alternative options for CD#1 were removed,
since the installer gives en easy choice of desktop selection during
task selection, since Jessie.
Only Xfce CD#1 remains as a single-CD desktop system.
* Produce two beeps when booted with grub instead of one,
so the user knows he has to use the grub way to edit entries.
* Install MATE desktop by default when brltty or espeakup is used in
d-i.
* Add HTTPS support

Please comment if I forgot something you think is important, or if I
add something that is not.

Also, I'd like to know if the sentence about UEFI:
"Note that this does not include support for UEFI Secure Boot." is
still valid.

I intend to send the attached patch in the ddp svn next week-end if
nobody complains.

Thanks for your feedback.
Baptiste

[1]https://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/en/installing.dbk?r1=10852&r2=11356
Vincent McIntyre
2017-03-19 22:20:01 UTC
Permalink
On Sun, Mar 19, 2017 at 05:31:53PM +0100, Baptiste Jammet wrote:

Thanks for raising these important items.

...
+<term>ifname instead of mac address</term>
+<listitem>
+<para>
+The installer and the installed systems will now use ifnames by default
+instead of mac for network interface names.
+</para>
+</listitem>
+</varlistentry>
Not having really worked with stretch yet (ie target audience member),
I'm had no real idea what this meant when I first read it.
Can you say what you mean in fuller terms that we could pare back
to something suitable for the notes?

Currently jessie systems use e.g. eth0 for the interface names.
Reading [1] it seems it is possible to use the MAC address, eg
enx78e7d1ea46da for the interface with MAC 78:e7:d1:ea:46:da.
IIUC your text is stating that the eth0 scheme will be default?

Kind regards
Vince

[1]
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
Baptiste Jammet
2017-03-21 20:50:02 UTC
Permalink
Hi Vince,
Post by Vincent McIntyre
+<term>ifname instead of mac address</term>
...
Post by Vincent McIntyre
Not having really worked with stretch yet (ie target audience member),
I'm had no real idea what this meant when I first read it.
Found in the Alpha 1 release annoucement:
https://www.debian.org/devel/debian-installer/News/2015/20150721
linking to this thread:
https://lists.debian.org/debian-devel/2015/05/msg00170.html
Post by Vincent McIntyre
Can you say what you mean in fuller terms that we could pare back
to something suitable for the notes?
I understand it as: Network interfaces will be named using their
firmware/BIOS name, or their physical location, or using a static
mapping (as before). This won't depend on the discoveriong order. This
won't apply for the upgrade.
(I see it as the /dev/hdXY -> UUID transition)
Post by Vincent McIntyre
Currently jessie systems use e.g. eth0 for the interface names.
Reading [1] it seems it is possible to use the MAC address, eg
enx78e7d1ea46da for the interface with MAC 78:e7:d1:ea:46:da.
Reading it (thanks for the link), I see that mac-adress naming is
available but not used. So network interfaces will have unusual name,
but not as exotic as this!
Post by Vincent McIntyre
IIUC your text is stating that the eth0 scheme will be default?
I try to say the opposite!

Baptiste

[1]
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
Vincent McIntyre
2017-03-22 02:30:01 UTC
Permalink
Post by Baptiste Jammet
Hi Vince,
Post by Vincent McIntyre
+<term>ifname instead of mac address</term>
...
Post by Vincent McIntyre
Not having really worked with stretch yet (ie target audience member),
I'm had no real idea what this meant when I first read it.
https://www.debian.org/devel/debian-installer/News/2015/20150721
https://lists.debian.org/debian-devel/2015/05/msg00170.html
Thanks for the background. I now see the terms 'ifname' and 'mac'
have special meanings in this context.

That's quite a thread to plow through but worth the read.
Round 2 is here
http://lists.debian.org/debian-devel/2015/06/msg00018.html

But I failed to find the final resolution of this on a mailing list,
the last word seems to be the Alpha 2 announcement
https://www.debian.org/devel/debian-installer/News/2015/20150815

So let's take the version 2 proposal and try to work with that.

+<!-- new in Stretch-->
+<varlistentry>
+<term>New method for naming network interfaces</term>
+<listitem>
+<para>
+The installer and newly installed systems will use a different
+naming scheme for network interfaces instead of eth0, eth1 etc.
+The old naming method suffered from enumeration race conditions
+that made it possible for interface names to change unexpectedly
+and is incompatible with mounting the root filesystem read-only.
+The new enumeration method relies on more sources of information,
+to produce a more repeatable outcome. It uses the firmware/BIOS
+provided index numbers and then tries PCI card slot numbers,
+producing names line ens0 or enp1s1 (ethernet) or wlp3s0 (wlan).
+USB devices, which can be added to the system at any time,
+will have names based upon their ethernet MAC addresses.
+</para>
+<para>
+This change does not apply to upgrades of jessie systems,
+the naming will continue to be enforced by
+/etc/udev/rules.d/70-persistent-net.rules.
+For more information, see /usr/share/doc/udev/README.Debian.gz
+</para>
+</listitem>
+</varlistentry>
Post by Baptiste Jammet
I understand it as: Network interfaces will be named using their
firmware/BIOS name, or their physical location, or using a static
mapping (as before). This won't depend on the discoveriong order.
This won't apply for the upgrade.
(I see it as the /dev/hdXY -> UUID transition)
My suggested text above is far from the final word here
and I have questions:
* Is it even accurate?
* How are the firmware/BIOS and PCI slot methods that were discussed
related to the NamePolicy methods in the udev file:
NamePolicy=kernel database onboard mac
* Is biosdevname still out of the picture?

Cheers
Vince

PS it would be nice to have a cumulative list of all changes (wiki?)
as well as the debian-installer/News items. Happy to help with
setting something up if I can.
Baptiste Jammet
2017-03-25 17:30:02 UTC
Permalink
Hello systemd maintainers,

We [1] are trying to find good words to put in the release notes about
the new network interfaces naming scheme.
Post by Vincent McIntyre
+<!-- new in Stretch-->
+<varlistentry>
+<term>New method for naming network interfaces</term>
+<listitem>
+<para>
+The installer and newly installed systems will use a different
+naming scheme for network interfaces instead of eth0, eth1 etc.
+The old naming method suffered from enumeration race conditions
+that made it possible for interface names to change unexpectedly
+and is incompatible with mounting the root filesystem read-only.
+The new enumeration method relies on more sources of information,
+to produce a more repeatable outcome. It uses the firmware/BIOS
+provided index numbers and then tries PCI card slot numbers,
+producing names line ens0 or enp1s1 (ethernet) or wlp3s0 (wlan).
+USB devices, which can be added to the system at any time,
+will have names based upon their ethernet MAC addresses.
+</para>
+<para>
+This change does not apply to upgrades of jessie systems,
+the naming will continue to be enforced by
+/etc/udev/rules.d/70-persistent-net.rules.
+For more information, see /usr/share/doc/udev/README.Debian.gz
+</para>
+</listitem>
+</varlistentry>
My suggested text above is far from the final word here
* Is it even accurate?
* How are the firmware/BIOS and PCI slot methods that were discussed
NamePolicy=kernel database onboard mac
* Is biosdevname still out of the picture?
Thanks for your answer.

Baptiste
[1]https://lists.debian.org/msgid-search/***@mailoo.org
Baptiste Jammet
2017-04-27 12:40:02 UTC
Permalink
Hello all,

(This is a kind ping for systemd maintainers.)

Before finalising the wording for the release notes, we would like to
know if we understood correctly this new network interface naming
method.
I would like to add a quick note about it in the "installing" chapter,
and a full explanation in "whats-new".

Below are the questions from last month, and atttached is an updated
patch for the release notes.

Thanks for your work, and your answers.
Post by Baptiste Jammet
Hello systemd maintainers,
We [1] are trying to find good words to put in the release notes about
the new network interfaces naming scheme.
Post by Vincent McIntyre
+<!-- new in Stretch-->
+<varlistentry>
+<term>New method for naming network interfaces</term>
+<listitem>
+<para>
+The installer and newly installed systems will use a different
+naming scheme for network interfaces instead of eth0, eth1 etc.
+The old naming method suffered from enumeration race conditions
+that made it possible for interface names to change unexpectedly
+and is incompatible with mounting the root filesystem read-only.
+The new enumeration method relies on more sources of information,
+to produce a more repeatable outcome. It uses the firmware/BIOS
+provided index numbers and then tries PCI card slot numbers,
+producing names line ens0 or enp1s1 (ethernet) or wlp3s0 (wlan).
+USB devices, which can be added to the system at any time,
+will have names based upon their ethernet MAC addresses.
+</para>
+<para>
+This change does not apply to upgrades of jessie systems,
+the naming will continue to be enforced by
+/etc/udev/rules.d/70-persistent-net.rules.
+For more information, see /usr/share/doc/udev/README.Debian.gz
+</para>
+</listitem>
+</varlistentry>
My suggested text above is far from the final word here
* Is it even accurate?
* How are the firmware/BIOS and PCI slot methods that were discussed
NamePolicy=kernel database onboard mac
* Is biosdevname still out of the picture?
Thanks for your answer.
Baptiste
Baptiste Jammet
2017-05-18 12:50:01 UTC
Permalink
Hello,

Dixit Baptiste Jammet, le 27/04/2017 :

[...]
Post by Baptiste Jammet
Before finalising the wording for the release notes, we would like to
know if we understood correctly this new network interface naming
method.
I would like to add a quick note about it in the "installing" chapter,
and a full explanation in "whats-new".
As nobody answers, I've commited the last proposed patch as r11493.
Feel free to open a bug against release-notes if you want a
better tracking.

Baptiste
Michael Biebl
2017-05-18 21:30:01 UTC
Permalink
Hi Baptiste!

Sorry for not replying earlier.
Post by Baptiste Jammet
Hello,
[...]
Post by Baptiste Jammet
Before finalising the wording for the release notes, we would like to
know if we understood correctly this new network interface naming
method.
I would like to add a quick note about it in the "installing" chapter,
and a full explanation in "whats-new".
As nobody answers, I've commited the last proposed patch as r11493.
Feel free to open a bug against release-notes if you want a
better tracking.
I quickly glanced of the text a while back and it looks fine to me.
A link to the upstream documentation at
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
would probably be useful,
but then again, you already refer to
/usr/share/doc/udev/README.Debian.gz which contains a link to that wiki.

Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Baptiste Jammet
2017-05-19 18:00:01 UTC
Permalink
Hi Michael,

Thanks for your answer. Its good to know we didn't write erroneous
infos.
Post by Michael Biebl
A link to the upstream documentation at
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
would probably be useful,
Added, thanks again.

Baptiste
Holger Wansing
2017-05-19 19:10:02 UTC
Permalink
Hi,
Post by Baptiste Jammet
Hello,
[...]
Post by Baptiste Jammet
Before finalising the wording for the release notes, we would like to
know if we understood correctly this new network interface naming
method.
I would like to add a quick note about it in the "installing" chapter,
and a full explanation in "whats-new".
In "installing" we have now:

The installer and the installed systems use a different
naming scheme for network interfaces.

I understood it that way, that the Stretch installer and an installed
Stretch system don't use the same naming scheme.
But that's not what was meant, right?

I would propose something like:

The installer and the installed systems have changed the
naming scheme for network interfaces.

or

The installer and the installed systems use a changed
naming scheme for network interfaces.



Holger
--
============================================================
Created with Sylpheed 3.5.0 under
D E B I A N L I N U X 8 . 0 " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/
============================================================
Baptiste Jammet
2017-05-20 09:20:01 UTC
Permalink
Hi Holger,

(Cc l10n-english, because their help would be very helpful in this case)
Post by Holger Wansing
The installer and the installed systems use a different
naming scheme for network interfaces.
I understood it that way, that the Stretch installer and an installed
Stretch system don't use the same naming scheme.
But that's not what was meant, right?
No, I meant "different from what was used until Jessie".
Post by Holger Wansing
The installer and the installed systems have changed the
naming scheme for network interfaces.
The installer have changed, but the new system "just" get the new
scheme!
Post by Holger Wansing
or
The installer and the installed systems use a changed
naming scheme for network interfaces.
Or more directly:
The installer and the installed systems use a new
naming scheme for network interfaces.

l10n-english, do you have a favorite, or another better one?

Baptiste
Justin B Rye
2017-05-20 09:40:01 UTC
Permalink
Post by Baptiste Jammet
Post by Holger Wansing
The installer and the installed systems use a different
naming scheme for network interfaces.
I understood it that way, that the Stretch installer and an installed
Stretch system don't use the same naming scheme.
But that's not what was meant, right?
No, I meant "different from what was used until Jessie".
It doesn't naturally read as "mutually different" for me - that would
have to be "use different naming schemes" (or "each use a different
naming scheme"); but it isn't clear what the scheme *is* different
from.
Post by Baptiste Jammet
Post by Holger Wansing
The installer and the installed systems have changed the
naming scheme for network interfaces.
The installer have changed, but the new system "just" get the new
scheme!
Post by Holger Wansing
or
The installer and the installed systems use a changed
naming scheme for network interfaces.
The installer and the installed systems use a new
naming scheme for network interfaces.
Yes, each of these seems like an improvement.
Post by Baptiste Jammet
l10n-english, do you have a favorite, or another better one?
Perhaps "use a new standard naming scheme", just in case pedants
insist that technically it's been available for years? But it's new
to the installer, so probably don't bother - stick with "use a new
naming scheme".

It's about time I did my first sweep of the release notes.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Baptiste Jammet
2017-05-22 19:20:01 UTC
Permalink
Hi,
Post by Justin B Rye
Perhaps "use a new standard naming scheme", just in case pedants
insist that technically it's been available for years?
I've choosen this one. Thanks Justin.

Baptiste

Baptiste Jammet
2017-04-28 11:40:01 UTC
Permalink
Hello all,
Post by Baptiste Jammet
I don't know if there will be a d-i Stretch RC 3, but I would like to
complete the "installing" chapter of the release notes.
Except for the ifname/systemd part (discussion is ongoing on -doc, see
https://lists.debian.org/debian-doc/2017/04/msg00039.html),
nobody complains about my proposal.
Post by Baptiste Jammet
"Note that this does not include support for UEFI Secure Boot." is
still valid.
Reading the last Bits from the release team,
(https://lists.debian.org/debian-devel-announce/2017/04/msg00013.html)
secure boot is not ready, so I leave this sentence here.

So, I've updated the release notes (without ifname) as r11449.

Thanks.
Baptiste
Loading...