mkDerivedConfig : Option a -> (a -> Definition b) -> Definition b
Create config definitions with the same priority as the definition of another option.
This should be used for option definitions where one option sets the value of another as a convenience.
For instance a config file could be set with a `text` or `source` option, where text translates to a `source`
value using `mkDerivedConfig options.text (pkgs.writeText "filename.conf")`.
It takes care of setting the right priority using `mkOverride`.
Before this change, one could set environment.etc.*.text and .source.
.source would always take precedence, regardless of the priorities set.
This change means that if, for instance, .text is set with mkForce but
.source is set normally, the .text content will be the one to take
effect. If they are set with the same priority they will conflict.
The regexp was only matching numbers and not the '.', so everyone using
systemd-boot would always see `could not find any previously installed
systemd-boot` on a `nixos-rebuild`.
Some specialisations (such as those which affect various boot-time
attributes) cannot be switched to at runtime. This allows picking the
specialisation at boot time.
/etc/crypttab can contain the _netdev option, which adds crypto devices
to the remote-cryptsetup.target.
remote-cryptsetup.target has a dependency on cryptsetup-pre.target. So
let's add both of them.
Currently, one needs to manually ssh in and invoke `systemctl start
systemd-cryptsetup@<name>.service` to unlock volumes.
After this change, systemd will properly add it to the target, and
assuming remote-cryptsetup.target is pulled in somewhere, you can simply
pass the passphrase by invoking `systemd-tty-ask-password-agent` after
ssh-ing in, without having to manually start these services.
Whether remote-cryptsetup.target should be added to multi-user.target
(as it is on other distros) is part of another discussion - right now
the following snippet will do:
```
systemd.targets.multi-user.wants = [ "remote-cryptsetup.target" ];
```
This makes the order of operations the same in dry-activate and a "true"
activate. Also fixes the indentation I messed up and drop a useless
unlink() call (we are already unlinking that file earlier).
The previous logic failed to detect that units were socket-activated
when the socket was stopped before switch-to-configuration was run. This
commit fixes that and also starts the socket in question.
The first FIXME is removed because it doesn't make sense to use
/proc/1/exe since that points to a directory that doesn't have all tools
the activation script needs (like systemd-escape).
The second one is removed because there is already no error handling
(compare with the restart logic where the return code is checked).
This commit changes a lot more that you'd expect but it also adds a lot
of new testing code so nothing breaks in the future. The main change is
that sockets are now restarted when they change. The main reason for
the large amount of changes is the ability of activation scripts to
restart/reload units. This also works for socket-activated units now,
and honors reloadIfChanged and restartIfChanged. The two changes don't
really work without each other so they are done in the one large commit.
The test should show what works now and ensure it will continue to do so
in the future.
allows configuration of foo-over-udp decapsulation endpoints. sadly networkd
seems to lack the features necessary to support local and peer address
configuration, so those are only supported when using scripted configuration.
Checks whether all spaces are inside double quotes, thus ensuring that one
string parses as no more than one kernel param.
Co-authored-by: pennae <82953136+pennae@users.noreply.github.com>
On some systems bootctl cannot write the `LoaderSystemToken` EFI variable
during installation, which results in a failure to install the boot
loader. Upstream provides a flag (--graceful) to ignore such write failures -
this change exposes it as a configuration option.
As the exact semantics of this option appear to be somewhat volatile it
should be used only if systemd-boot otherwise fails to install.
The multipath-tools package had existed in Nixpkgs for some time but
without a nixos module to configure/drive it. This module provides
attributes to drive the majority of multipath configuration options
and is being successfully used in stage-1 and stage-2 boot to mount
/nix from a multipath-serviced iSCSI volume.
Credit goes to @grahamc for early contributions to the module and
authoring the NixOS module test.
