If our old Nix can’t evaluate the Nixpkgs channel, try the fallback
from the new channel /first/. That way we can upgrade Nix to a newer
version and support breaking changes to Nix (like seen in the upgrade
o Nix 2.0).
This change should be backported to older NixOS versions!
(cherry picked from commit 475c8aa018bbdd99e7e9d693c7207cdccdcde7b3)
mke2fs has this annoying property that it uses getrandom() to get random
numbers (for whatever purposes) which blocks until the kernel's secure
RNG has sufficient entropy, which it usually doesn't in the early boot
(except if your CPU supports RDRAND) where we may need to create the
root disk.
So let's give the VM a virtio RNG to avoid the boot getting stuck at
mke2fs.
(cherry picked from commit dda74d9e50dbd8a412de743a53e9cfd585407342)
This has been reported by @qknight in his Stack Overflow question:
https://stackoverflow.com/q/50678639
The correct way to override a single value would be to use something
like this:
systemd.services.nagios.serviceConfig.Restart = lib.mkForce "no";
However, this doesn't work because the check is applied for the attrsOf
type and thus the attribute values might still contain the attribute set
created by mkOverride.
The unitOption type however did already account for this, but at this
stage it's already too late.
So now the actual value is unpacked while checking the values of the
attribute set, which should allow us to override values in
serviceConfig.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra, @qknight
(cherry picked from commit 0e7c945e15117e88ac494e29c9828ccea2ec32ee)
Reason: Another user has hit this problem on Discourse[1] and I thought
I had already backported it to 18.03, apparently I didn't. Given
the time of the original commit I think this had enough testing
already so it shouldn't break anything and rather make things
less annoying.
[1]: https://discourse.nixos.org/t/is-there-a-universal-way-to-enable-a-service-auto-restart/592/3
Use nixos-fw chain instead of INPUT so that the rules don't keep
stacking everytime the firewall is reloaded.
This also adds a comment to each rule about the associated exporter.
(cherry picked from commit 9216da8928bc17878635ef50dac089f01a8c6466)
Problem: Restarting (stopping) system.slice would not only stop X11 but
also most system units/services. We obviously don't want this happening
to users when they switch from 18.03 to 18.09 or nixos-unstable.
Reason: The following change in systemd:
d8e5a93382
The commit adds system.slice to the perpetual units, which means
removing the unit file and adding it to the source code. This is done so
that system.slice can't be stopped anymore but in our case it ironically
would cause this script to stop system.slice because the unit file was
removed (and an older systemd version is still running).
Related issue: https://github.com/NixOS/nixpkgs/issues/39791
(cherry picked from commit 7098b0fcdfd7fa4b82c036d8116b60b78f497316)
Reason: Make sure that this problem wouldn't occur if we would update
the systemd version.
Commit 42c35dea37, which is a cherry-pick
of 28c20a4731da9d5ba539e2d1ef6bcf3ddf1026ac uses the variable 'gitea',
which is not defined in the 18.03 module.
Fix this by: gitea -> pkgs.gitea
The hooks directory contains now one level deep subdirectories which
need to be updated as well.
If you use gitea via ssh, ~/.ssh/authorized_keys also needs to be
updated because of the hardcoded path to gitea in the "command" option.
(cherry picked from commit 28c20a4731da9d5ba539e2d1ef6bcf3ddf1026ac)
The regression in ext4 kernel code appears to cause no real issue
to anyone, so I hate it would block other fixes from 18.03 for longer
than a full week.
(The ext4 changes themselves fix some CVE, though apparently minor.)
With a config like
{
networking.interfaces."lo".ip4 = [
{ address = "10.8.8.8"; prefixLength = 32; }
];
}
a nixos-rebuild switch would take a long time, and you'd see:
$ systemctl list-jobs
JOB UNIT TYPE STATE
734400 network-interfaces.target start waiting
734450 sys-subsystem-net-devices-lo.device start running
734449 network-link-lo.service start waiting
and:
systemd[1]: sys-subsystem-net-devices-lo.device: Job sys-subsystem-net-devices-lo.device/star>
systemd[1]: sys-subsystem-net-devices-lo.device: Job sys-subsystem-net-devices-lo.device/star>
systemd[1]: Timed out waiting for device sys-subsystem-net-devices-lo.device.
This removes the device dependency for `lo` and fixes this bug.
Closes#7227
(cherry picked from commit 48d292e8a14bec3926dc3963e167859b35fc60af)
to be consistent with the rest of the manual
Reported-By: Cedric Shahabi <cedric.shahabi@gmail.com>
(cherry picked from commit 329983f6c72bf5acf68cdfd29bf1a9dac7050968)
Is called like this since 14321ae, but
docs were still using the old option in some cases.
Reported-By: Cedric Shahabi <cedric.shahabi@gmail.com>
(cherry picked from commit 6cabce9abd916f219c1c003719f2e8ba547654c3)
Peviously only the timesyncd systemd unit was disabled. This meant
that when you activate a system that has chronyd enabled the following
strange startup behaviour takes place:
systemd[1]: Starting chrony NTP daemon...
systemd[1]: Stopping Network Time Synchronization...
systemd[1]: Stopped chrony NTP daemon.
systemd[1]: Starting Network Time Synchronization...
(cherry picked from commit 56ef1068488c64af7c1e5b811caa24255a818bf4)
Without `ROOT_PATH` set, `gogs serv` tries to open logs in writing in
its store directory. This blocks cloning or pushing over ssh, and
results in a gogs internal error.
(cherry picked from commit b59570eac05b65e23b6a0ccc8a665027d740b1d9)
This change allows users to specify an alternative database method. For
example an mpd satellite setup where another mpd on the network shares
it's database with the local instance. The `dbFile` parameter must not be
configured in that case.
(cherry picked from commit a0797bad2c9ea3781367703bb603ab21e5d64d3e)