This should make the composability of kernel configurations more straigthforward.
- now distinguish freeform options from tristate ones
- will look for a structured config in kernelPatches too
one can now access the structuredConfig from a kernel via linux_test.configfile.structuredConfig
in order to reinject it into another kernel, no need to rewrite the config from scratch
The following merge strategies are used in case of conflict:
-- freeform items must be equal or they conflict (mergeEqualOption)
-- for tristate (y/m/n) entries, I use the mergeAnswer strategy which takes the best available value, "best" being defined by the user (by default "y" > "m" > "n", e.g. if one entry is both marked "y" and "n", "y" wins)
-- if one item is both marked optional/mandatory, mandatory wins (mergeFalseByDefault)
Right now it's not at all obvious that one can override this option
using `services.logind.extraConfig`; we might as well add an option
for `killUserProcesses` directly so it's clear and documented.
The new reuse behaviour is cool and really useful but it breaks one of
my use cases. When using kexec, I have a script which will unlock the
disks in my initrd. However, do_open_passphrase will fail if the disk is
already unlocked.
The previous version contained a false positive case, where boot would
continue when the stage 2 init did not exist at all, and a false
negative case, where boot would stop if the stage 2 init was a symlink
which cannot be resolved in the initramfs root.
Fixes#49519.
Thanks @michas2 for finding and reporting the issue!
* journald: forward message to syslog by default if a syslog implementation is installed
* added a test to ensure rsyslog is receiving messages when expected
* added rsyslogd tests to release.nix
* Lets container@.service be activated by machines.target instead of
multi-user.target
According to the systemd manpages, all containers that are registered
by machinectl, should be inside machines.target for easy stopping
and starting container units altogether
* make sure container@.service and container.slice instances are
actually located in machine.slice
https://plus.google.com/112206451048767236518/posts/SYAueyXHeEX
See original commit: https://github.com/NixOS/systemd/commit/45d383a3b8
* Enable Cgroup delegation for nixos-containers
Delegate=yes should be set for container scopes where a systemd instance
inside the container shall manage the hierarchies below its own cgroup
and have access to all controllers.
This is equivalent to enabling all accounting options on the systemd
process inside the system container. This means that systemd inside
the container is responsible for managing Cgroup resources for
unit files that enable accounting options inside. Without this
option, units that make use of cgroup features within system
containers might misbehave
See original commit: https://github.com/NixOS/systemd/commit/a931ad47a8
from the manpage:
Turns on delegation of further resource control partitioning to
processes of the unit. Units where this is enabled may create and
manage their own private subhierarchy of control groups below the
control group of the unit itself. For unprivileged services (i.e.
those using the User= setting) the unit's control group will be made
accessible to the relevant user. When enabled the service manager
will refrain from manipulating control groups or moving processes
below the unit's control group, so that a clear concept of ownership
is established: the control group tree above the unit's control
group (i.e. towards the root control group) is owned and managed by
the service manager of the host, while the control group tree below
the unit's control group is owned and managed by the unit itself.
Takes either a boolean argument or a list of control group
controller names. If true, delegation is turned on, and all
supported controllers are enabled for the unit, making them
available to the unit's processes for management. If false,
delegation is turned off entirely (and no additional controllers are
enabled). If set to a list of controllers, delegation is turned on,
and the specified controllers are enabled for the unit. Note that
additional controllers than the ones specified might be made
available as well, depending on configuration of the containing
slice unit or other units contained in it. Note that assigning the
empty string will enable delegation, but reset the list of
controllers, all assignments prior to this will have no effect.
Defaults to false.
Note that controller delegation to less privileged code is only safe
on the unified control group hierarchy. Accordingly, access to the
specified controllers will not be granted to unprivileged services
on the legacy hierarchy, even when requested.
The following controller names may be specified: cpu, cpuacct, io,
blkio, memory, devices, pids. Not all of these controllers are
available on all kernels however, and some are specific to the
unified hierarchy while others are specific to the legacy hierarchy.
Also note that the kernel might support further controllers, which
aren't covered here yet as delegation is either not supported at all
for them or not defined cleanly.
"machine.target" doesn't actually exist, it's misspelled version
of "machines.target". However, the "systemd-nspawn@.service"
unit already has a default dependency on "machines.target"
The autoupgrade service defined in `system.autoUpgrade`
(`nixos/modules/installer/tools/auto-upgrade.nix`) doesn't have `su` in
its path and thus yields a warning during the `daemon-reload`.
Specifying the absolute path fixes the issue.
Fixes#47648
The improved lspci command shows all available ethernet controllers and
their kernel modules. Previously, the user had to provide the slot name
of a specific device.
I think pam_lastlog is the only thing that writes to these files in
practice on a modern Linux system, so in a configuration that doesn't
use that module, we don't need to create these files.
I used tmpfiles.d instead of activation snippets to create the logs.
It's good enough for upstream and other distros; it's probably good
enough for us.
Nix 2.0 no longer uses these directories.
/run/nix/current-load was moved to /nix/var/nix/current-load in 2017
(Nix commit d7653dfc6dea076ecbe00520c6137977e0fced35). Anyway,
src/build-remote/build-remote.cc will create the current-load directory
if it doesn't exist already.
/run/nix/remote-stores seems to have been deprecated since 2014 (Nix
commit b1af336132cfe8a6e4c54912cc512f8c28d4ebf3) when the documentation
for $NIX_OTHER_STORES was removed, and support for it was dropped
entirely in 2016 (Nix commit 4494000e04122f24558e1436e66d20d89028b4bd).
The default value for journald's Storage option is "auto", which
determines whether to log to /var/log/journal based on whether that
directory already exists. So NixOS has been unconditionally creating
that directory in activation scripts.
However, we can get the same behavior by configuring journald.conf to
set Storage to "persistent" instead. In that case, journald will create
the directory itself if necessary.
Previously, the activation script was responsible for ensuring that
/etc/machine-id exists. However, the only time it could not already
exist is during stage-2-init, not while switching configurations,
because one of the first things systemd does when starting up as PID 1
is to create this file. So I've moved the initialization to
stage-2-init.
Furthermore, since systemd will do the equivalent of
systemd-machine-id-setup if /etc/machine-id doesn't have valid contents,
we don't need to do that ourselves.
We _do_, however, want to ensure that the file at least exists, because
systemd also uses the non-existence of this file to guess that this is a
first-boot situation. In that case, systemd tries to create some
symlinks in /etc/systemd/system according to its presets, which it can't
do because we've already populated /etc according to the current NixOS
configuration.
This is not necessary for any other activation script snippets, so it's
okay to do it after stage-2-init runs the activation script. None of
them declare a dependency on the "systemd" snippet. Also, most of them
only create files or directories in ways that obviously don't need the
machine-id set.
Evaluation error introduced in 599c4df46a.
There is only a "platformS" attribute in kexectools.meta, so let's use
this and from the code in the kexec module it operates on a list,
matching the corresponding platforms, so this seems to be the attribute
the original author intended.
Tested by building nixos/tests/kexec.nix on x86_64-linux and while it
evaluates now, the test still fails by timing out shortly after the
kexec:
machine: waiting for the VM to finish booting
machine# Cannot find the ESP partition mount point.
This however seems to be an unrelated issue and was also the case before
the commit mentioned above.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra, @dezgeg
Changes the evaluation order in that it evaluates assertions before
warnings, so that eg. the following would work:
{ config, lib, ... }:
{
options.foo = lib.mkOption {
type = lib.types.bool;
default = true;
description = "...";
};
options.bar = lib.mkOption {
type = lib.types.bool;
default = false;
description = "...";
};
config = lib.mkMerge [
(lib.mkIf config.bar {
system.build.bar = "foobar";
})
(lib.mkIf config.foo {
assertions = lib.singleton {
assertion = config.bar;
message = "Bar needs to be enabled";
};
systemd.services.foo = {
description = "Foo";
serviceConfig.ExecStart = config.system.build.bar;
};
})
];
}
This is because the systemd module includes definitions for warnings
that would trigger evaluation of the config.system.build.bar definition.
The original pull request references a breakage due to the following:
{
services.nixosManual.enable = false;
services.nixosManual.showManual = true;
}
However, changing the eval order between asserts and warnings clearly is
a corner case here and it only happens because of the aforementioned
usage of warnings in the systemd module and needs more discussion.
Nevertheless, this is still useful because it lowers the evaluation time
whenever an assertion is hit, which is a hard failure anyway.
or else at least the following config will fail with an evaluation error
instead of an assert
```
{
services.nixosManual.enable = false;
services.nixosManual.showManual = true;
}
```
* acquire DHCP on the interfaces with networking.interface.$name.useDHCP == true or on all interfaces if networking.useDHCP == true (was only only "eth0")
* respect "mtu" if it was in DHCP answer (it happens in the wild)
* acquire and set up staticroutes (unlike others clients, udhcpc does not do the query by default); this supersedes https://github.com/NixOS/nixpkgs/pull/41829
This fixes an issue with shells like fish that are not fully POSIX
compliant. The syntax `ENV=val cmd' doesn't work properly in there.
This issue has been addressed in #45932 and #45945, however it has been
recommended to use a single shell (`stdenv.shell' which is either
`bash' or `sh') to significantly reduce the maintenance overload in the
future.
See https://github.com/NixOS/nixpkgs/issues/45897#issuecomment-417923464Fixes#45897
/cc @FRidh @xaverdh @etu
Although double '/' in paths is not a problem for GRUB supplied with nixpkgs, sometimes NixOS's grub.conf read by external GRUB and there are versions of GRUB which fail
The instructions to install nixos behind a proxy were not clear. While
one could guess that setting http_proxy variables can get the install
rolling, one could end up with an installed system where the proxy
settings for the nix-daemon are not configured.
This commit updates the documentation with
1. steps to install behind a proxy
2. configure the global proxy settings so that nix-daemon can access
internet.
3. Pointers to use nesting.clone in case one has to use different proxy
settings on different networks.
The background color option is self-explanatory.
The mode is either `normal` or `stretch`, they are as defined by GRUB,
where normal will put the image in the top-left corner of the menu, and
stretch is the default, where it stretches the image without
consideration for the aspect ratio.
* https://www.gnu.org/software/grub/manual/grub/grub.html#background_005fimage
When rebuilding you have to manually run `systemctl --user
daemon-reload`. It gathers all authenticated users using
`loginctl list-user` and runs `daemon-reload` for each of them.
This is a first step towards a `nixos-rebuild` which is able to reload
user units from systemd. The entire task is fairly hard, however I
consider this patch usable as it allows to restart units without running
`daemon-reload` for each authenticated user.
