He prefers to contribute to his own nixpkgs fork triton.
Since he is still marked as maintainer in many packages
this leaves the wrong impression he still maintains those.
I've started digging into the actual cause of the problem a week ago but
didn't continue fixing this.
The reason why the tests are failing is because
torvalds/linux/commit/72f5e08dbba2d01aa90b592cf76c378ea233b00b has
remapped the location of the TSS into the CPU entry area and we did
update our default kernel to version 4.14 in NixOS/nixpkgs@88530e02b6.
Back to VirtualBox: The guru meditation happens in
selmRCGuestTssPostWriteCheck, which I think is only a followup error. I
believe the right location couldn't be determined by VirtualBox and thus
the write check function triggers that panic because it's reading from
the wrong location.
So the actual problem *only* surfaces whenever we use software
virtualization, which we do for our tests because we don't have nested
virtualization available.
Our tests are also for testing the functionality of VirtualBox itself
and not certain kernel versions or kernel features, so for the time
being and until this is fixed, let's actually use kernel version 4.9 for
the guests within the VM tests. Kernel 4.9 didn't have the mentioned
change of the TSS location and thus the tests succeed.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @dtzWill
-s, --script: never prompts for user intervention
Sometimes the NixOS installer tests fail when they invoke parted, e.g.
https://hydra.nixos.org/build/62513826/nixlog/1. But instead of exiting
right there, the tests hang until the Nix builder times out (and kills
the build). With this change the tests would instead fail immediately,
which is preferred.
While at it, use "parted --script" treewide, so nobody gets build
timeout due to parted error (or misuse). (Only nixos/ use it, and only
non-interactive.)
A few instances already use the short option "-s", convert them to long
option "--short".
This has surfaced since f803270b7e.
The commit bumped bash to version 4.4, which caused to change the order
of --subst-var flags in substituteAll, which this test was relying on,
because it added a @shell@ to boot.initrd.postMountCommands.
Our substituter is currently working a bit like this:
original.replace('@var1@', 'val1').replace('@var2@', 'val2')...
Unfortunately, this means that if @var2@ occurs within @var1@ it is
replaced by the new value, so the order of the substvars actually
matter. I highly doubt that we want a behaviour like this and I'm
wondering why it didn't occur to me as a problem while writing the
initial implementation of the VirtualBox tests.
Whether to get rid of this and disallowing substitution of substvars
within substvars is another topic which I think needs discussion in a
different place.
As for now, I'm using stdenv.shell, because the closure size of this
should fit within the initrd, so it's fine especially because it's just
a test.
Tested with the net-hostonlyif and systemd-detect-virt tests and they
both succeed with this change.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: @globin on IRC
The motivation for this change is the following: As gnu-netcat,
e. g. does not support ipv6, it is not suitable as default netcat.
This commit also fixes all obvious build issues caused by this change.
The test complains[1][2] that
Failed to start message bus: Failed to bind socket "/run/dbus/system_bus_socket": No such file or directory
In 639e5401ff, the dbus socket dir is set
to `/run/dbus`; in the test vm `/var/run/dbus` is used, but the standard
`/run -> /var/run` link is typically not created until stage 2 init, not
in the minimal init used here. Thus, dbus fails to run within the test
environment . Fix by changing `/var/run/dbus` to simply `/run/dbus`.
[1]: https://hydra.nixos.org/build/42534725
[2]: https://hydra.nixos.org/build/42523834
One reason why it took me so long for debugging the test failure with
systemd-detect-virt was that simple-cli has succeeded while the former
has not.
This now makes sure we have consistency accross all the subtests and if
problems like the one in the previos commit ever show up again, we will
have just the headless test succeeding and it's more obvious where the
actual problem resides.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We don't have (simulated) sound hardware within the qemu VM, neither do
we have it available within VirtualBox that's running within the qemu
VMs.
With sound hardware the VirtualBox UI displays an error dialog, which in
turn causes the VM process to hang on unregister. This in turn has
caused the tests to fail because of the following error:
Cannot unregister the machine '...' while it is locked
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Using waitUntilSucceeds for testing whether the shutdown signalling
files have vanished is quite noisy because it prints two lines for every
try. This is now fixed with a while loop on the guest VM which does the
same check but with only one output for the command that's executed and
another one when the conditions are met.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
VBoxService needs dbus in order to work properly, which failed to start
up so far, because it was searching in /run/current-system/sw for its
configuration files.
We now no longer run with the --system flag but specify the
configuration file directly instead.
This fixes at least the "simple-gui" test and probably the others as
well, which I haven't tested yet.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We can't use waitForWindow here because it runs xwininfo as user root,
who in turn is not authorized to connect to the X server running as
alice.
So instead, we use xprop from user alice which should fix waiting for
the VirtualBox manager window.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The VirtualBox tests so far ran the X server as root instead of user
"alice" and it did work, because we had access control turned off by
default.
Fortunately, it was changed in 1541fa351b.
As a side effect, it caused all the VirtualBox tests to fail because
they now can't connect to the X server, which is a good thing because
it's a bug of the VirtualBox tests.
So to fix it, let's just start the X server as user alice.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Now subtests are separate derivations, because the individual tests do
not depend on state from previous test runs.
This has the advantage that it's easier to run individiual tests and
it's also easier to pinpoint individual tests that randomly fail.
I ran all of these tests locally and they still succeed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I'm not quite sure why the official Hydra gets a kernel panic in one of
two VMs using the exact same kernels:
https://hydra.nixos.org/build/26339384
Because the kernel panic happens before stage 1, let's wait for the
first VM to boot up and after the bootup is done, start the second one
in hope that it won't trigger the panic.
Oddly enough, whenever I run the test on my own Hydra and on my local
machines, I don't get anything like that.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I forgot to do this in da0e642. It shouldn't be a big problem but it's
more clean to destroy the VM once we're done testing.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We previously had 1024 MB of memory to fit a VirtualBox VM with 512 MB
plus the memory needed of the VirtualBox host VM. That obviously won't
work for two VirtualBox VMs, which are used for testing networking
between two VirtualBox guests.
Now, we have 2048 MB on the qemu guest (the VirtualBox host) and 768 MB
for each VirtualBox guest. That should be enough to fit in two
VirtualBox guests (I hope).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Unfortunately, we can't test whether USB is really working, but we can
make sure that VirtualBox has access to the USB devices.
This is essentially testing #9736, which I haven't yet been able to
reproduce though, but it makes sense to test it so it won't happen in
future releases.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Addresses #9876 in the way that we want to make sure that VirtualBox 5.x
is going to be properly detected. Right now the result is "kvm", so the
subtest fails as expected with:
error: systemd-detect-virt returned "kvm" instead of "oracle" at (eval
14) line 414, <__ANONIO__> line 92.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Makes it easier to debug and find out for which machine a certain log
socket has been started or stopped.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We're simply using antiquotation, since it's been a while since these
got introduced (in Nix 1.7). So we can use them because it makes the
code much more readable.
As usual, I made sure that I didn't accidentally change something in
functionality:
$ nix-instantiate nixos/tests/virtualbox.nix
...
/nix/store/cldxyrxqvwpqm02cd3lvknnmj4qmblyn-vm-test-run-virtualbox.drv
$ git stash pop
...
$ nix-instantiate nixos/tests/virtualbox.nix
...
/nix/store/cldxyrxqvwpqm02cd3lvknnmj4qmblyn-vm-test-run-virtualbox.drv
$
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is essentially not only "wrapping" the line but refactoring into a
shorter name which is used in two places.
And yes, I know I'm very pedantic if it comes to whitespaces and line
lengths, but I made sure this doesn't change any functionality:
$ nix-instantiate nixos/tests/virtualbox.nix
...
/nix/store/cldxyrxqvwpqm02cd3lvknnmj4qmblyn-vm-test-run-virtualbox.drv
$ git stash pop
...
$ nix-instantiate nixos/tests/virtualbox.nix
...
/nix/store/cldxyrxqvwpqm02cd3lvknnmj4qmblyn-vm-test-run-virtualbox.drv
$
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Instead of manually setting debug to true or false, this should make it
possible to now run the test like this:
nix-build nixos/tests/virtualbox.nix --arg debug true
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Sometimes there are random kernel panics do to the lack of memory in the
qemu guests, but as we're setting the VirtualBox memory size relatively
low, 1024 MB should be enough for the qemu guests.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We want to check whether DBus functionality is working, so let's make
sure it is running in our mini-initrd.
DBus unfortunately requires to have users properly set up and another
configuration file other than in ${dbus.daemon}/etc/dbus-1/system.conf,
so we do provide that as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Commit 687caeb renamed services.virtualboxHost to programs.virtualbox,
but according to the discussion on the commit, it's probably a better to
put it into virtualisation.virtualbox instead.
The discussion can be found here:
https://github.com/NixOS/nixpkgs/commit/687caeb#commitcomment-12664978
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Using $storepath/sbin is deprecated according to commit 98cedb3, so
let's avoid putting anything in .../sbin for the guest additions.
This is a continuation of the initial commit done by @ctheune at
1fb1360, which unfortunately broke VM tests and only changed the path of
the mount.vboxsf helper.
With this commit, the VM test is fixed and I've also verified on my
machine that it is indeed working again.
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>
Especially if the user isn't in the vboxusers group anymore, this gets
VERY noisy, because the VBoxSVC process emits warnings for every single
USB device noting that it's only possible to access it when the user is
in the vboxusers group.
So, we now have a debug attribute, where we can enable it when
necessary.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Creates unnecessary cruft in the root users home directory, which we
really don't need. Except the log, but therefore we now cat the log to
stderr and the private temporary directory is cleaned up afterwards.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Essentially adds two more VirtualBox VMs to the test and also increases
the memory size of the qemu VM to 768 MB to make sure we don't run out
of memory too soon.
We're testing whether those two VMs can talk to either each other
(currently via ICMP only) or to/from the host via TCP/IP.
Also, this restructures the VM test a bit, so that we now pass in a
custom stage2Init script that has access to the store via a private
mount over the /nix/store that's already in the initrd. The reason why
this is a private mount is that we don't want to shadow the Nix store of
the initrd, essentially breaking cleanup functionality after the custom
stage 2 script (currently this is only "poweroff -f").
Note that setting the hostname inside the VirtualBox VM is *not* for
additional fanciness but to produce a different store path for the VM
image, so that VirtualBox doesn't bail out when trying to use an image
which is already attached to another VM.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We're going to create more than one VirtualBox VM, so let's dynamically
generate subs specific to a particular VirtualBox VM, merging everything
into the testScript and machine expressions.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Currently it pretty much tests starting up virtual machines and just
shutting down afterwards, but for both VBoxManage and the VirtualBox
GUI.
This helps catching errors in hardened mode, however we still need to
test whether networking works the way intended (and I fear that this is
broken at the moment).
The VirtualBox VM is _not_ using hardware virtualization support (thus
we use system = "i686-linux", because x86_64 has no emulation support),
because we're already within a qemu VM, which means it's going to be
slow as hell (that's why I've written own subs just for testing
startup/shutdown/whatnot with respective timeouts).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
