Hi Phil On Sat, 14 Oct 2017 21:56:40 +0100 Philip Hands <p...@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?
signature.asc
Description: OpenPGP digital signature