| Commit message (Collapse) | Author | Age |
|---|
| |\
| |
| | |
Replace several activation script snippets with declarative configuration
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
| | |
| |
| |
| |
| | |
As far as I can tell, systemd has never used this directory, so I think
this is a holdover from before udev merged into systemd.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| | |
As far as I can tell, the systemd snippet hasn't depended on groups
being initialized since 5d02c02a9bfd6912e4e0f700b1b35e76d1d6bd3f in
2015, when a `setfacl` call was removed.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Evaluation error introduced in 599c4df46a90c7415a6cc0689f0b23d22e7fdb67.
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
|
| | |
| |
| |
| |
| | |
This sort of code breaks config.{allowBroken, allowUnsupportedSystem} =
true by making them do unpredictable things.
|
| |/
|
|
|
| |
Likewise logind we should not try to restart this service after upgrade,
the user's current session depends on it.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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;
}
```
|
| |/ |
|
| |
|
|
|
| |
(#46851)
This fixes #46750. This should also work with non-POSIX shells like in #46042.
|
| |
|
|
|
| |
A route via a tunnel interface does not require a gateway to be
specified, so do not check for the Gateway= field on routes at all.
|
| | |
|
| |
|
|
|
| |
Support Multicast= option in [Link] section of network units,
introduced in systemd/systemd#9118.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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-417923464
Fixes #45897
/cc @FRidh @xaverdh @etu
|
| |\
| |
| |
| |
| | |
samueldr/feature/actiavation-failure-identification
nixos/activation: Identifies the snippet that failed
|
| | |
| |
| |
| |
| |
| | |
This allows a developer to better identify in which snippet the
failure happened. Furthermore, users seeking help will have more
information available about the failure.
|
| | |
| |
| | |
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.
|
| | |
| |
| | |
fsck of a mounted filesystems fails with error code 8 "Operational error" and halts the boot processing
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | | |
This also includes a set of defaults *for this option*, where when not
used, other saner defaults are used.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | | |
| | |
| | |
| | | |
It is deprecated and will be removed after 18.09.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
systemd-fsck-generator only produces these lines if it can find the
necessary fsck executable in its PATH.
fixes #29139.
|
| |\ \ \
| |/ /
|/| | |
nixos/switch-to-configuration: reload user units
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Progress towards #27069
|
| |\ \ \
| | | |
| | | | |
$toplevel/system: buildPlatform.system -> hostPlatform.system
|
| | | | | |
|
| |/ / /
| | |
| | | |
because stdenv.platform is stdenv.buildPlatform.platform
|
| |\ \ \
| | | |
| | | |
| | | | |
Hydra: ?compare=1473892
|
| | |\ \ \
| | |/ /
| |/| | |
nixos/networkd: add missing options
|
| | | | | |
|
| |\| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts: gobby and libinfinity - I took the hand-edited versions
instead of those resuting from the mass-replacement.
Hydra: ?compare=1473190
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This fixes an issue where setting both
`boot.loader.systemd-boot.editor` to `false` and
`boot.loader.systemd-boot.consoleMode` to any value would concatenate
the two configuration lines in the output, resulting in an invalid
`loader.conf`.
|
| |\| | | |
|
| | |\ \ \
| | | | |
| | | | | |
nixos: initrd/luks: allow to reuse passphrases, cleanup
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
From reading the source I'm pretty sure it doesn't support multiple Yubikeys, hence
those options are useless.
Also, I'm pretty sure nobody actually uses this feature, because enabling it causes
extra utils' checks to fail (even before applying any patches of this branch).
As I don't have the hardware to test this, I'm too lazy to fix the utils, but
I did test that with extra utils checks commented out and Yubikey
enabled the resulting script still passes the syntax check.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Also reuse common cryptsetup invocation subexpressions.
- Passphrase reading is done via the shell now, not by cryptsetup.
This way the same passphrase can be reused between cryptsetup
invocations, which this module now tries to do by default (can be
disabled).
- Number of retries is now infinity, it makes no sense to make users
reboot when they fail to type in their passphrase.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Also fix Yubikey timeout handling mess.
|
| | | | | | |
|
| | |/ / /
| | | |
| | | |
| | | |
| | | | |
Also store scripts directly in the nix store rather than having the
superfluous /bin/ tree.
|