We want to avoid getting broken LUKS systems into the latest channel, so
let's ensure that the channel update won't happen if LUKS support is
broken again.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This serves as a regression test for #7859.
It's pretty straightforward, except from the fact that nixos-generate-
config doesn't detect LUKS devices and the "sleep 60".
As for the former, I have tried to add support for LUKS devices for
nixos-generate-config, but it's not so easy as it sounds, because we
need to create a device tree across all possible mappers and/or LVM up
to the "real" device and then decide whether it is relevant to what is
currently mounted. So I guess this is something for the nixpart branch
(see #2079).
And the latter isn't very trivial as well, because the LUKS passphrase
prompt is issued on /dev/console, which is the last "console=..." kernel
parameter (thus the `mkAfter`). So we can't simply grep the log, because
the prompt ends up being on one terminal only (tty0) and using select()
on $machine->{socket} doesn't work very well, because the FD is always
"ready for read". If we would read the FD, we would conflict with
$machine->connect and end up having an inconsistent state. Another idea
would be to use multithreading to do $machine->connect while feeding the
passphrase prompt in a loop and stop the thread once $machine->connect
is done. Turns out that this is not so easy as well, because the threads
need to share the $machine object and of course need to do properly
locking.
In the end I decided to use the "blindly hope that 60 seconds is enough"
approach for now and come up with a better solution later. Other VM
tests surely use sleep as well, but it's $machine->sleep, which is bound
to the clock of the VM, so if the build machine is on high load, a
$machine->sleep gets properly delayed but the timer outside the VM won't
get that delay, so the test is not deterministic.
Tested against the following revisions:
5e3fe39: Before the libgcrypt cleanup (a71f78a) that broke cryptsetup.
69a6848: While cryptsetup was broken (obviously the test failed).
15faa43: After cryptsetup has been switched to OpenSSL (fd588f9).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
These commands will be executed directly after the machine is created,
so it gives us the chance to for example type in passphrases using the
virtual keyboard.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We're going to need it for installer tests where nixos-generate-config
isn't yet able to fully detect the filesystems/hardware. for example for
device mapper configurations other than LVM.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This module generates a /boot/extlinux/extlinux.conf bootloader
configuration file that is supported by e.g. U-Boot:
http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.distro;hb=refs/heads/master
With this, all ARM boards supported by U-Boot can be booted in a common
way (a single boot file generator, all boards booting via initrd like
x86) and with same boot menu functionality as GRUB has.
-- sample extlinux.conf file --
# Generated file, all changes will be lost on nixos-rebuild!
# Change this to e.g. nixos-42 to temporarily boot to an older configuration.
DEFAULT nixos-default
TIMEOUT 50
LABEL nixos-default
MENU LABEL NixOS - Default
LINUX ../nixos/n7vxfk60nb5h0mcbhkwwxhcz2q2nvxzv-linux-4.1.0-rc3-cpufreq-zImage
INITRD ../nixos/0ss2zs8sb6d1qn4gblxpwlxkfjsgs5f0-initrd-initrd
FDTDIR ../nixos/n7vxfk60nb5h0mcbhkwwxhcz2q2nvxzv-linux-4.1.0-rc3-cpufreq-dtbs
APPEND systemConfig=/nix/store/469qvr43ln8bfsnk5lzcz6m6jfcgdd4r-nixos-15.06.git.0b7a7a6M init=/nix/store/469qvr43ln8bfsnk5lzcz6m6jfcgdd4r-nixos-15.06.git.0b7a7a6M/init loglevel=8 console=ttyS0,115200n8 drm.debug=0xf
LABEL nixos-71
MENU LABEL NixOS - Configuration 71 (2015-05-17 21:32 - 15.06.git.0b7a7a6M)
LINUX ../nixos/n7vxfk60nb5h0mcbhkwwxhcz2q2nvxzv-linux-4.1.0-rc3-cpufreq-zImage
INITRD ../nixos/0ss2zs8sb6d1qn4gblxpwlxkfjsgs5f0-initrd-initrd
FDTDIR ../nixos/n7vxfk60nb5h0mcbhkwwxhcz2q2nvxzv-linux-4.1.0-rc3-cpufreq-dtbs
APPEND systemConfig=/nix/store/469qvr43ln8bfsnk5lzcz6m6jfcgdd4r-nixos-15.06.git.0b7a7a6M init=/nix/store/469qvr43ln8bfsnk5lzcz6m6jfcgdd4r-nixos-15.06.git.0b7a7a6M/init loglevel=8 console=ttyS0,115200n8 drm.debug=0xf
It seems like there's an upstream bug in the "lpstat" command. We need
to specify the server's port.
Further information: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711327
[root@client:~]# lpstat -H
/var/run/cups/cups.sock
[root@client:~]# lpstat -h server -H
/var/run/cups/cups.sock:631
[root@client:~]# CUPS_SERVER=server lpstat -H
server:631
[root@client:~]# lpstat -h server:631 -H
server:631
It seems like there's an upstream bug in the "lpstat" command. We need
to specify the server's port.
Further information: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=711327
[root@client:~]# lpstat -H
/var/run/cups/cups.sock
[root@client:~]# lpstat -h server -H
/var/run/cups/cups.sock:631
[root@client:~]# CUPS_SERVER=server lpstat -H
server:631
[root@client:~]# lpstat -h server:631 -H
server:631
This reverts commit d170c98d13.
niksnut argues that we need smaller system closures, not bigger.
So users facing the trouble of getting gcc rebuilds after nix-collect-garbage
for any minimal nixos configuration change should use other means of
not losing the stdenv output.
One way is to keep one somewhere: nix-build -A stdenv -o stdenv '<nixpkgs>'.
Another may be to use nix.conf options like gc-keep-outputs, gc-keep-derivations
or env-keep-derivations.
This will help a lot on ARM, where nix-collect-garbage erases gcc; then, any
change to a small system config file requires rebuilding gcc again.
I don't know why it does not happen on x86. Maybe it just pulls the gcc from
hydra, if garbage is collected.
It boots, but some things still don't work:
1) Installation of DTBs
2) Boot of initrd
Booting still needs a proper config.txt in /boot, which could probably be
managed by NixOS.
During the refactor of the networkd stuff in f8dbe5f, a lot of the
options are now needed by systemd.nix as well as networkd.nix but
weren't moved by that commit as well.
For now, this fixes all networkd VM tests except for the macvlan one and
thus it should fix#7505 for at least DHCP-based configuration.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
In f8dbe5f, the default value for networking unit "enabled" option
suddenly flipped to false. I have no idea of whether this happened by
accident, but I'm setting it to true again, because it essentially
breaks systemd networking support and we have systemd.network.enable to
have a "turn the world off" switch.
And of course, because the mentioned commit obviously wasn't done with
even a run of the simplest run of one of the network VM tests, we now
get an evaluation error if we switch useNetworkd to true.
Fixes the core issue of #7505.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Passing the chroot flag to nixos-install without arguments should now give you a
Bash shell as intended rather than try an empty path.
This was masked by the user's shell (usually /bin/bash) being defaulted to by
chroot, and being found since their paths used NixOS conventions.
When bootstrapping from other distributions, nixos-install is unable to find
various tools in the chroot since their paths aren't aware of NixOS conventions.
This makes a small change to existing code by specifying nixpkgs/nixos instead
of just nixos when running nix-instantiate in the chroot. I haven't tested this
outside of bootstrapping, but the same specification is used elsewhere in the
code so I don't see why it wouldn't work.
These services don't create files on disk, let alone on a network
filesystem, so they don't really need a fixed uid. And this also gets
rid of a warning coming from <= 14.12 systems.
Otherwise, the enabled -> disabled transition won't be handled
correctly (switch-to-configuration currently assumes that if a unit is
running and exists, it should be restarted).
This avoids the following warning:
Apr 19 10:53:48 xen systemd[1]: [/nix/store/...-unit-ddclient.service/ddclient.service:19] Unknown lvalue 'type' in section 'Service'
As `Type=simple` is the default in systemd, the assignment to the
service type can be simply dropped.
Added support for managing Plex plugins via Nix. This is done via an
"extraPlugins" configuration option which takes a list of paths to
plugin bundles, which are then symlinked into Plex's plugin directory
when the service is started.
Specifically, this fixes dnsmasq, which failed with
Apr 16 19:00:30 mandark dnsmasq[23819]: dnsmasq: DBus error: Connection ":1.260" is not allowed to own the service "uk.org.thekelleys.dnsmasq" due to security policies in the configuration file
Apr 16 19:00:30 mandark dnsmasq[23819]: DBus error: Connection ":1.260" is not allowed to own the service "uk.org.thekelleys.dnsmasq" due to security policies in the configuration file
after being enabled, due to dbus not being reloaded.
Thanks to @domenkozar for implicitly reminding me that documentation is
probably our biggest issue. And I'm a dumbass for contributing to that
situation, so let's do better than that and document it.
The current changes are only preparation for a bigger change coming real
soon[TM] in Hydra and release-tools, so right now it's still a bit
tedious to create custom channels.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This option causes the specified user to be automatically logged in at
the virtual console.
While at it, refactor and make a helper function for building the getty
command line.
This partially reverts commit 3a4fd0bfc6.
Addresses another concern by @edolstra that users might not want to
update *all* channels. We're now reverting to the old behaviour but
after updating the "nixos" channel, we just check whether the channel
ships with a file called ".update-on-nixos-rebuild" and if it exists, we
update that channel as well.
Other channels than these are not touched anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
My original reason to put it at the beginning of NIX_PATH was to allow
shipping a particular version <nixpkgs> with a channel. But in order to
do that, we can still let the channel expression ship with a custom
version of nixpkgs by something like <channel/nixpkgs> and the builder
of the channel could also rewrite self-references.
So the inconvenience is now shifted towards the maintainer of the
channel rather than the user (which isn't nice, but better err on the
side of the developer rather than on the user), because as @edolstra
pointed out: Having the channels of root at the beginning of NIX_PATH
could have unintended side-effects if there a channel called nixpkgs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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>
