The main goal of this commit is to replace the rather fragile passing of
multiple arrays which could break in cases like #130935.
While I could have just added proper shell escaping to the variables
being passed, I opted for the more painful approach of replacing the
fragile and somewhat strange construct with the 5 bash lists. While
there are currently no more problems present with the current approach
(at least none that I know of), the new approach seems more solid and
might get around problems that could arise in the future stemming from
either the multiple-lists situation or from the absence of proper shell
quoting all over the script.
- The order of NSS (host) modules has been brought in line with upstream
recommendations:
- The `myhostname` module is placed before the `resolve` (optional) and `dns`
entries, but after `file` (to allow overriding via `/etc/hosts` /
`networking.extraHosts`, and prevent ISPs with catchall-DNS resolvers from
hijacking `.localhost` domains)
- The `mymachines` module, which provides hostname resolution for local
containers (registered with `systemd-machined`) is placed to the front, to
make sure its mappings are preferred over other resolvers.
- If systemd-networkd is enabled, the `resolve` module is placed before
`files` and `myhostname`, as it provides the same logic internally, with
caching.
- The `mdns(_minimal)` module has been updated to the new priorities.
If you use your own NSS host modules, make sure to update your priorities
according to these rules:
- NSS modules which should be queried before `resolved` DNS resolution should
use mkBefore.
- NSS modules which should be queried after `resolved`, `files` and
`myhostname`, but before `dns` should use the default priority
- NSS modules which should come after `dns` should use mkAfter.
os.readlink only resolves one layer of symlinks. This script explicitly relies on the real path of a file for deduplication, hence symlink resolution should recurse.
Previously the code took the kernelPatches of the final derivation, which
might or might not be what was passed to the derivation in the original call.
The previous behaviour caused various hacks to become neccessary to avoid duplicates in kernelPatches.
`systemd.network.networks.*.dhcpServerConfig` did not accept all of
the options which are valid for networkd's [DHCPServer] section. See
systemd.network(5) of systemd 247 for details.
Since 03eaa48 added perl.withPackages, there is a canonical way to
create a perl interpreter from a list of libraries, for use in script
shebangs or generic build inputs. This method is declarative (what we
are doing is clear), produces short shebangs[1] and needs not to wrap
existing scripts.
Unfortunately there are a few exceptions that I've found:
1. Scripts that are calling perl with the -T switch. This makes perl
ignore PERL5LIB, which is what perl.withPackages is using to inform
the interpreter of the library paths.
2. Perl packages that depends on libraries in their own path. This
is not possible because perl.withPackages works at build time. The
workaround is to add `-I $out/${perl.libPrefix}` to the shebang.
In all other cases I propose to switch to perl.withPackages.
[1]: https://lwn.net/Articles/779997/
Adding template overrides allows for custom behavior for specific
instances of a template. Previously, it was not possible to provide
bind mounts for systemd-nspawn. This change allows it.
Currently, kernel config options whose value is "yes" always override
options whose value is "no".
This is not always desired.
Generally speaking, if someone defines an option to have the value
"no", presumably they are disabling the option for a reason, so it's
not always OK to silently enable it due to another, probably unrelated
reason.
For example, a user may want to reduce the kernel attack surface and
therefore may want to disable features that are being enabled in
common-config.nix.
In fact, common-config.nix was already silently enabling options that
were intended to be disabled in hardened/config.nix for security
reasons, such as INET_DIAG.
By eliminating the custom merge function, these config options will
now use the default module option merge functions which make sure
that all options with the highest priority have the same value.
A user that wishes to override an option defined in common-config.nix
can currently use mkForce or mkOverride to do so, e.g.:
BINFMT_MISC = mkForce (option no);
That said, this is not going to be necessary in the future, because
the plan is for kernel config options defined in nixpkgs to use a
lower priority by default, like it currently happens for other module
options.
Catch and ignore errors during writing of the boot entries. These
errors could stem from profile names that are not valid filenames on
vfat filesystems.
fixes #114552
The BGRT theme is probably a close as to "FlickerFree" we can
get without https://github.com/NixOS/nixpkgs/pull/74842.
It's more agnostic than the Breeze theme.
We also install all of themes provided by the packages, as it's possible
that one theme needs the ImageDir of another, and they're small files
anyways.
Lastly, how plymouth handles logo and header files is
a total mess, so hopefully when they have an actual release
we won't need to do all this symlinking.
