Should make it even easier to use custom channels, because whenever the
user does a "nixos-rebuild --upgrade", it will also upgrade possibly
used ("used" as in referenced in configuration.nix) channels besides
"nixos". And if you also ship a channel tied to a particular version of
nixpkgs or even remove the "nixos" channels, you won't run into
unexpected situations where the system is not updating your custom
channels.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is very useful if you want to distribute channels (and thus
expressions as well) in a similar fashion to Debians APT sources (or
PPAs or whatnot).
So, for example if you have a channel with some additional functions
or packages, you simply add that channel with:
sudo nix-channel --add https://example.com/my-nifty-channel foo
And you can access that channel using <foo>, for example in your
configuration.nix:
{
imports = [ <foo/modules/shiny-little-module> ];
environment.systemPackages = with import <foo/pkgs> {}; [ bar blah ];
services.udev.extraRules = import <foo/lib/udev/mkrule.nix> {
kernel = "eth*";
attr.address = "00:1D:60:B9:6D:4F";
name = "my_fast_network_card";
};
}
Within nixpkgs, we shouldn't have <nixos> used anywhere anymore, so we
shouldn't get into conflicts.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
If a kernel without CONFIG_UEVENT_HELPER set is used with NixOS, the file
/proc/sys/kernel/hotplug does not exist. Before writing to it to disable
this deprecated mechanism, we have to ensure it actually exists because
otherwise the activation script will fail.
This updates rdnssd to the following:
* Using the systemd interfaces directly
* Using the rdnssd user instead of the root user
* Integrating with resolvconf instead of writing directly to /etc/resolv.conf
The i686-linux test has never worked and I wrote the VM test only on
x86_64-linux to verify whether hardening mode works. I don't know why it
fails on i686-linux, but that might be because the inner VirtualBox VM
we're starting during the VM test doesn't use hardware virtualization.
Closes#5708.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Sometimes, keys aren't properly recognized the first time, so in order
to make sure they get through, always resend the key again on retry.
In this case the worst that could happen is that the VM is started over
and over again, but never in parallel, so that's fine because we're
checking for successful startup 10 seconds after the keypress.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It's not nice to send the escape key over and over again just to ensure
the popup is closed, because even *if* it fails to close the popup 4
times in a row it's just very unlikely that it will be closed. But in
order to make really sure, we might need to do a screenshot and detect
visual changes.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is essentially what's been done for the official NixOS build slaves
and I'm using it as well for a few of my machines and my own Hydra
slaves.
Here's the same implementation from the Delft server configurations:
f47c2fc7f8/delft/common.nix (L91-L101)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Many bus clients get hopelessly confused when dbus-daemon is
restarted. So let's not do that.
Of course, this is not ideal either, because we end up stuck with a
possibly outdated dbus-daemon. But that issue will become irrelevant
in the glorious kdbus-based future.
Hopefully this also gets rid of systemd getting stuck after
dbus-daemon is restarted:
Apr 01 15:37:50 mandark systemd[1]: Failed to register match for Disconnected message: Connection timed out
Apr 01 15:37:50 mandark systemd[1]: Looping too fast. Throttling execution a little.
Apr 01 15:37:51 mandark systemd[1]: Looping too fast. Throttling execution a little.
...
It has been removed by 71a197bc6e.
I'm reintroducing the test mainly because it actually *is* useful,
because right now, machines with mdraid will not boot. In order to
prevent such things from happening in the future, we should *not* remove
this VM test again.
If it really goes back to failing randomly, we should really try to fix
it instead of removing it again.
Of course it fails right now because of the mdraid bump in 7719f7f.
Also, if you want to have additional info about the reasons, have a look
at the commit message of 666cf992f0.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I'm increasing it to 100MB to make sure, any bootloader will fit with
all its stages. Of course, right now the reason why GRUB doesn't fit
into the partition is because of mdadm 3.3.2 and thus the initrd taking
all the space, but in order to avoid confusion on why the *boot* loader
fails in the VM tests, I've increased the size.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
