Your message dated Fri, 23 Aug 2019 23:26:55 +0200
with message-id <[email protected]>
and subject line Re: systemd: jessie to stretch upgrade resulted in eth0 being
given a new style predictable name (enp1s9)
has caused the Debian Bug report #878590,
regarding systemd: jessie to stretch upgrade resulted in eth0 being given a new
style predictable name (enp1s9)
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 [email protected]
immediately.)
--
878590: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878590
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd
Version: 232-25+deb9u1
Severity: important
Hi,
After upgrading to Stretch, the system came up with its NIC named as
enp1s9, and thus had no working network (since eth0 was configured
in /etc/network/interfaces), requiring me to get console access to
fix things.
I suspect that this is the result of me having two empty udev rules
files on the system, prior to the upgrade:
udev/rules.d/70-persistent-net.rules
udev/rules.d/75-persistent-net-generator.rules
Those empty files being there in order to ensure that the one NIC in
the machine will never end up being called anything other than eth0,
not even if the NIC gets replaced.
It is my suspicion that something is checking for the existence of
the persistent-net rules file, and if it is there, is assuming that it
contains a rule to keep the NIC named as whatever it was named before.
If that is the case, I broke that assumption.
I can imagine that dealing with this case automatically might be rather
tiresome.
I would have been happy if the upgrade had failed with a warning that
having an empty 70-persistent-net.rules is not supported, and that I
should take steps to either define the new names in network/interfaces,
or add net.ifnames=0 to the kernel command line, or perhaps recommending
a new udev rule that would have the effect of naming the one NIC in the
machine as 'en0' say, if there is a nice way of doing that which survives
the NIC being replaced.
If something else is going on, I realise that this report is very light
on detail, and will be happy to do any tests, or provide any further
details to work out what's really going on here -- please just ask.
I believe that what I did was the recommended way of getting the behaviour
I wanted, and that the intention was that NIC naming should be preserved
on upgrade, hence the severity of important, since this breaks networking,
which might cause significant inconvenience for people.
I'm sorry if this should be reported against e.g. udev instead, but the
persistent naming seems to be under the aegis of systemd, so this seemed
like a reasonable starting point -- please reassign as appropriate.
BTW I note that the recommendation from here:
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
to restore the old behaviour by doing:
ln -s /dev/null /etc/systemd/network/99-default.link
does not work on this system, so at present I'm adding net.ifnames=0 to
the kernel command line to restore the 'eth0' name.
Cheers, Phil.
-- Package-specific info:
-- System Information:
Debian Release: 9.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii adduser 3.115
ii libacl1 2.2.52-3+b1
ii libapparmor1 2.11.0-3
ii libaudit1 1:2.6.7-2
ii libblkid1 2.29.2-1
ii libc6 2.24-11+deb9u1
ii libcap2 1:2.25-1
ii libcryptsetup4 2:1.7.3-4
ii libgcrypt20 1.7.6-2+deb9u2
ii libgpg-error0 1.26-2
ii libidn11 1.33-1
ii libip4tc0 1.6.0+snapshot20161117-6
ii libkmod2 23-2
ii liblz4-1 0.0~r131-2+b1
ii liblzma5 5.2.2-1.2+b1
ii libmount1 2.29.2-1
ii libpam0g 1.1.8-3.6
ii libseccomp2 2.3.1-2.1
ii libselinux1 2.6-3+b3
ii libsystemd0 232-25+deb9u1
ii mount 2.29.2-1
ii procps 2:3.3.12-3
ii util-linux 2.29.2-1
Versions of packages systemd recommends:
ii dbus 1.10.22-0+deb9u1
ii libpam-systemd 232-25+deb9u1
Versions of packages systemd suggests:
pn policykit-1 <none>
pn systemd-container <none>
pn systemd-ui <none>
Versions of packages systemd is related to:
pn dracut <none>
ii initramfs-tools 0.130
ii udev 232-25+deb9u1
-- no debconf information
--- End Message ---
--- Begin Message ---
On Sat, 9 Mar 2019 23:03:19 +0100 Michael Biebl <[email protected]> wrote:
> Hi Phil
>
> On Sat, 14 Oct 2017 21:56:40 +0100 Philip Hands <[email protected]> wrote:
> > Package: systemd
> > Version: 232-25+deb9u1
> > Severity: important
> >
> > Hi,
> >
> > After upgrading to Stretch, the system came up with its NIC named as
> > enp1s9, and thus had no working network (since eth0 was configured
> > in /etc/network/interfaces), requiring me to get console access to
> > fix things.
> >
> > I suspect that this is the result of me having two empty udev rules
> > files on the system, prior to the upgrade:
> >
> > udev/rules.d/70-persistent-net.rules
> > udev/rules.d/75-persistent-net-generator.rules
> >
> > Those empty files being there in order to ensure that the one NIC in
> > the machine will never end up being called anything other than eth0,
> > not even if the NIC gets replaced.
> >
> > It is my suspicion that something is checking for the existence of
> > the persistent-net rules file, and if it is there, is assuming that it
> > contains a rule to keep the NIC named as whatever it was named before.
>
> There is
> https://salsa.debian.org/systemd-team/systemd/blob/master/debian/udev.postinst#L52
>
>
> > If that is the case, I broke that assumption.
>
> In a way, yes. The assumption is, that if
> /etc/udev/rules.d/70-persistent-net.rules exists it was used to setup
> static names using the old scheme.
>
> Afaics, you wanted to disable the generator, so only overriding
> udev/rules.d/75-persistent-net-generator.rules would not have broken the
> above assumption.
>
> > I can imagine that dealing with this case automatically might be rather
> > tiresome.
>
> We already have quite a few corner cases and and I'm worried to change
> anything now in stable which has the potential to break other setups in
> subtle ways.
> Somehow I feel the boat has sailed here and since we didn't have other
> user bug reports about running into the same issue, I wonder if simply
> closing this bug report is the sanest thing to do at this point.
>
> Wdyt?
Given my earlier remarks and no further feedback, I'm closing this issue.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
