Bug#878590: systemd: jessie to stretch upgrade resulted in eth0 being given a new style predictable name (enp1s9)

[Michael Biebl]

Hi Phil

On Sat, 14 Oct 2017 21:56:40 +0100 Philip Hands <phil at hands.com> 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?




> 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

You need to rebuild the initramfs after doing that.





-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20190309/1f2f8cab/attachment.sig>