Depending on the network management backend being used, if the interface
configuration in stage 1 is not cleared, there might still be some old
addresses or routes from stage 1 present in stage 2 after network
configuration has finished.
This makes predictable interfaces names available as soon as possible
with udev by adding the default network link units to initrd which are read
by udev. Also adds some udev rules that are needed but which would normally
loaded from the udev store path which is not included in the initrd.
In 87a19e9048773d5a363679617406ad148d36c3b8 I merged staging-next into master using the GitHub gui as intended.
In ac241fb7a570d6cf81d229ad22a8889602639160 I merged master into staging-next for the next staging cycle, however, I accidentally pushed it to master.
Thinking this may cause trouble, I reverted it in 0be87c79797a5fa384fbc356c74ed54f9f7829ea. This was however wrong, as it "removed" master.
This reverts commit 0be87c79797a5fa384fbc356c74ed54f9f7829ea.
I merged master into staging-next but accidentally pushed it to master.
This should get us back to 87a19e9048773d5a363679617406ad148d36c3b8.
This reverts commit ac241fb7a570d6cf81d229ad22a8889602639160, reversing
changes made to 76a439239eb310d9ad76d998b34d5d3bc0e37acb.
Memtest86+ doesn't support EFI, so unfree Memtest86 is used when EFI
support is enabled (systemd-boot currently also uses Memtest86 when
memtest is enabled).
In some cases like we've noticed in https://github.com/NixOS/nixpkgs/issues/76169,
having duplicate packages in systemd.packages like
```
systemd.packages = [ gnome-shell gnome-shell gnome-session ];
```
breaks.
Here we use an associative array to ensure no
duplicate paths when we symlink all the units listed
in systemd.packages.
This fixes the dhcpcd issue in https://github.com/NixOS/nixpkgs/issues/76969,
which was exposed by https://github.com/NixOS/nixpkgs/pull/75031
introducing changes in the module ordering and therefore option ordering
too.
The dhcpcd issue would also be fixable by explicitly putting
dhcpcd's paths before others, however it makes more sense for systemd's
default paths to be after all others by default, since they should only
be a fallback, which is how binary finding will work if they come after.
When using a modified systemd-package (e.g. to test a patch), it's
recommended to use the `systemd.package`-option to avoid rebuilding all packages
that somehow depend on systemd.
With this change, the modified package is also used by `systemd-nspawn@`
units.
A centralized list for these renames is not good because:
- It breaks disabledModules for modules that have a rename defined
- Adding/removing renames for a module means having to find them in the
central file
- Merge conflicts due to multiple people editing the central file
The options at `systemd.network` (`links`, `netdevs` and `networks`) are
directly mapped to the three different unit types of `systemd-networkd(8)`.
However there's also the option `systemd.network.units` which is
basically used as a container for generated unit-configs that are linked
to `/etc/systemd/networkd`[1].
This should not be exposed to the user as it's unclear whether or not it
should be used directly which can be pretty confusing which is why I decided to
declare this option as internal (including all sub-options as `internal`
doesn't seem to be propagated to submodules).
[1] 9db75ed88f/nixos/modules/system/boot/networkd.nix (L933-L937)
This adds an `extraConfig` option to timesyncd for setting additional
options in `/etc/systemd/timesyncd.conf`.
This is similar to things like `services.journald.extraConfig` and
`services.logind.extraConfig`.
This has been there since v209 [1]
```
The interface name to use. This option has lower precedence than NamePolicy=, so for this setting to take effect, NamePolicy= must either be unset, empty, disabled, or all policies configured there must fail. Also see the example below with "Name=dmz0".
Note that specifying a name that the kernel might use for another interface (for example "eth0") is dangerous because the name assignment done by udev will race with the assignment done by the kernel, and only one interface may use the name. Depending on the order of operations, either udev or the kernel will win, making the naming unpredictable. It is best to use some different prefix, for example "internal0"/"external0" or "lan0"/"lan1"/"lan3".
```
[1] 43b3a5ef61
