`nixos-generate-config` detects the `cpuFreqGovernor` suited best for my
machine, e.g. `powerManagement.cpuFreqGovernor = lib.mkDefault "powersave";`.
However the `powerManagement` module sets a sensitive default for
`cpuFreqGovernor` using `mkDefault` to avoid breackage with older
setups. Since 140ac2f1 the `hardware-configuration.nix` sets the
gorvernor with `mkDefault` as well which causes evaluation errors if the
powermanagement module is enabled:
```
error: The unique option `powerManagement.cpuFreqGovernor' is defined multiple times, in `/home/ma27/Projects/nixos-config/hardware-configuration.nix' and `/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/config/power-management.nix'.
```
Using `mkOptionDefault` rather than `mkDefault` in the powermanagement
module fixes this issue as it decreases the priority of the module and
prefers the value set in `hardware-configuration.nix`.
I have confirmed the change using the following VM declaration:
```
{
cpuFreq = { lib, ... }: {
powerManagement.cpuFreqGovernor = lib.mkDefault "powersave";
powerManagement.enable = true;
};
}
```
- /var/run -> /run as the former is deprecated
- configure openal to use pulseaudio if pulseaudio is enabled
- configure libao to use pulseaudio if pulseaudio is enabled
Commit 987aac7 and issue #18183 were intended to fix support for other
things, but in the process, changed mdns_minimal to use the wrong return
setting, resulting in permanent failures in early boot, affecting things
like issue #30459.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
This reverts commit 670b4e29adc16e0a29aa5b4c126703dcca56aeb6. The change
added in this commit was controversial when it was originally suggested
in https://github.com/NixOS/nixpkgs/pull/29205. Then that PR was closed
and a new one opened, https://github.com/NixOS/nixpkgs/pull/29503,
effectively circumventing the review process. I don't agree with this
modification. Adding an option 'resolveLocalQueries' to tell the locally
running name server that it should resolve local DNS queries feels
outright nuts. I agree that the current state is unsatisfactory and that
it should be improved, but this is not the right way.
(cherry picked from commit 23a021d12e8f939cd0bfddb1c7adeb125028c1e3)
When the user specifies the networking.nameservers setting in the
configuration file, it must take precedence over automatically
derived settings.
The culprit was services.bind that made the resolver set to
127.0.0.1 and ignore the nameserver setting.
This patch adds a flag to services.bind to override the nameserver
to localhost. It defaults to true. Setting this to false prevents the
service.bind and dnsmasq.resolveLocalQueries settings from
overriding the users' settings.
Also, when the user specifies a domain to search, it must be set in
the resolver configuration, even if the user does not specify any
nameservers.
(cherry picked from commit 670b4e29adc16e0a29aa5b4c126703dcca56aeb6)
This commit was accidentally merged to 17.09 but was intended for
master. This is the cherry-pick to master.
In order for DynamicUser = true to work in services, we need the
nss-systemd module to be able to resolve the user and group names
generated dynamically.
Evaluation error introduced in a0d464033c.
If the value for timeZone is null it shouldn't be even tried to coerce
it into a string.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @lheckemann, @joachifm
Creating and then erasing the key relies on the disk erasing data
correctly, and otherwise allows attackers to simply decrypt swap just
using "secretkey". We don't actually need a LUKS header, so we can save
ourselves some pointless disk writes and identifiability.
In addition, I wouldn't have made the awful mistake of backing up my swap partition's LUKS header instead of my zpool's. May my data rest in peace.
