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