Change:
change versions under the hood during the lifetime of a stable release and might include breaking changes. </para> </listitem> <ins> <listitem> <para> Because of the systemd upgrade, some network interfaces might change their name. For details see <link xlink:href="https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html#History"> upstream docs</link> or <link xlink:href="https://github.com/NixOS/nixpkgs/issues/71086"> our ticket</link>. </para> </listitem> </ins> </itemizedlist> </section>

Discussion:
Describe the bug NixOS 19.09 updates systemd from version 239 to version 243 which comes with a changed network device naming algorithm which can result in hosts coming up with different interface names after upgrading NixOS 19.09. In turn, this means previously set up network configuration may no longer apply and thus the host might loose network connectivity. To Reproduce Steps to reproduce the behavior: NixOS to 19.09, for example using the procedure in the manual. to apply the OS upgrade machine enacting unexpected network behavior, for example missing network connectivity, unreachability from the outside, etc. Of course, step 3 happens depending on whether the new interface naming algorithm decides to generate a new name for the hardware configuration or not. Expected behavior I don't have a problem with the interface names changing in itself, just that it should be explicitly considered for the upgrade procedure to NixOS 19.09. For this I can come up with two potential solutions: mention in the release notes that the upgrade to systemd 243 may result in interface names changing and suggest a procedure for administrators to check interface names before rebooting after the upgrade. default systemd configuration to keep using old interface naming algorithm. See section Additional context for more info. Additional context Luckily, systemd make changes to the interface naming algorithm explicit and keep old versions around for backwards compatibility. Previous versions are documented in and can be configured with the . Workaround In case one is affected by the changing network interface name and depends on network connectivity to access a machine (such as a remote server) and doesn't have access to out-of-band management, but has to use a crappy rescue image one can change the interface naming using the kernel command line by in : or by doing a quick'n'dirty edit to the grub config at : switches to the version of the algorithm used by the systemd version included in NixOS 19.03. Metadata Maintainer information:
In my particular case, the name for an Intel Ethernet controller changed from to : before upgrade: journal output after the upgrade: Kernel version was 4.19.79 in both cases.
See also
Let's merge the discussion into a single thread.
This mentioned issue seems to based on predictable interface names being gone entirely, which is different to this issue about predictable names being, well... unpredictable. I don't think this should be closed.

Oh, right, that's weird [the other issue]. I'll reopen until it's clearer. EDIT: and you posted a much better description/analysis anyway :-)
Restating my problem: What I'm describing isn't a bug in NixOS per se, just that NixOS 19.09 updated from systemd 239 to systemd 243 and from time to time, systemd updates bring slight changes to the way network interfaces are named. This may affect certain hardware configurations resulting in network interface names changing, though in the majority of cases nothing will happen. What I'm proposing is that it should be made clear in the release notes, that these changes might occur and to suggest a procedure for admins to be able to check before rebooting and adjust network configuration. This would be most important for servers (without out-of-band management), such as the system on which I first discovered this problem. An alternative solution I propose is to explicitly roll back to the old naming algorithm in the default NixOS configuration to the algorithm from version 239. Although, all this does is delay the inevitable when systemd drops the legacy version of the algorithm, but gives more time to find a solution for a smoother transition.
I assume we'll go the way of adding a line into ? /cc
Notes on checking if interface name will change: The persistent interface names are documented in . You can use to see the variables from which udev draws to set a "persistent" name: can be set to the version of the naming algorithm as listed in the manpage mentioned above. To see how udev draws from the variable, we have to check : The important setting here is : , , and correspond to the udev variables , , and , , . The first policy that matches is used. To give an example, here is how the interface on my affected system got changed: You can see that stayed the same, but v243 and looking at : we can see that is listed before meaning is chosen before .
The problem with the procedure outlined above is, that only it works , meaning you'd first have to upgrade systemd from 239 in order to see if interface names change and in turn meaning you'd have to upgrade to NixOS 19.09 using which is not the best idea for distro upgrades ( ). I'm not sure what the solution here is.

Well, if we really cared about it, we could theoretically have one release (19.09) with forcing the previous naming by default. The main problem I see with that: it's relatively late, so I'm afraid changing back may cause also issues to some people. A compromise approach could be to make it easily configurable and suggest setting the older scheme manually &ndash; even if just for one boot to do this procedure.
If they keep the old scheme around indefinitely, can't we just set the old one conditional on ?
People already might have switched their system and dealt with the changes, so applying any changes to 19.09 in that regard will change their system behaviour again. I think the proper way to address this should be to add this more prominent to the 19.09 release notes, and make sure major systemd changes are mentioned. I'm not talking about copying in all of their release notes, but adding pointers to possibly more invasive changes.
What about this formulation?
I'm fine with that. Thank you.
For the record, we got bitten by another interface rename (investigation kindly helped by We found that our older kernel classified 1 of the 2 NICs of our HP server as , but the newer kernel classified both as , resulting in the interface newly being named ).
This issue (or one like it) just recurred for me, after a kernel version bump. It appears that became with no warning. Suggested fix: Allow referring to network interfaces (in ) by MAC address. Something along the lines of: would also need to be able to refer by MAC address in e.g. , and everywhere else (, etc.) This would be substantially more stable for config, given how mutable linux kernel ethernet interface naming scheme has become
The way to do this is documented in - You can either use , create something in , or use a plain udev rule.