Communication happens on Github so names should be consistent.
(cherry picked from commit 2b6dcdfcd0)
Best be consistent with active release branches as well.
Commit 9bfe92ecee ("docker: Minor improvements, fix failing test") added
the services.docker.storageDriver option, made it mandatory but didn't
give it a default value. This results in an ugly traceback when users
enable docker, if they don't pay enough attention to also set the
storageDriver option. (An attempt was made to add an assertion, but it
didn't work, possibly because of how "mkMerge" works.)
The arguments against a default value were that the optimal value
depends on the filesystem on the host. This is, AFAICT, only in part
true. (It seems some backends are filesystem agnostic.) Also, docker
itself uses a default storage driver, "devicemapper", when no
--storage-driver=x options are given. Hence, we use the same value as
default.
Add a FIXME comment that 'devicemapper' breaks NixOS VM tests (for yet
unknown reasons), so we still run those with the 'overlay' driver.
Closes#10100 and #10217.
(cherry picked from commit 5f17aeb403)
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>
(cherry picked from commit baf1d1dcd7)
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>
(cherry picked from commit 764a767d5f)
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>
(cherry picked from commit 3e6bb402b1)
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>
(cherry picked from commit 9a39c2e943)
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>
(cherry picked from commit da0e642c2b)
Signed-off-by: Domen Kožar <domen@dev.si>
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>
(cherry picked from commit 17f58275a0)
Signed-off-by: Domen Kožar <domen@dev.si>
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>
(cherry picked from commit 8f98226f50)
Signed-off-by: Domen Kožar <domen@dev.si>
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>
(cherry picked from commit 0d4a3ce485)
Signed-off-by: Domen Kožar <domen@dev.si>
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>
(cherry picked from commit 7707c7df7f)
Signed-off-by: Domen Kožar <domen@dev.si>
- Replace usage of deprecated CLI flag `--daemon`
- Introduce `storageDriver` option for module
- Fix failing test by using `overlay` storage driver
(cherry picked from commit 9bfe92ecee)
Signed-off-by: Domen Kožar <domen@dev.si>
Using waitForWindow on the IceWM root window doesn't necessarily mean
that the panel will be shown. In the lightdm test, we only make sure
that the login is working and thus it doesn't matter how the session
itself will look or whether IceWM is broken, so we don't need that
screenshot.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Currently the lightdm test detects a successful login by OCR'ing the
screen and searching for the clock widget's text. Since the last
IceWM update (commit bdd20ced), either the font or the colors of the
clock changed such that the OCR doesn't pick it up anymore.
Instead, just look for a matching (root) window title, e.g.
"IceWM 1.3.9 (Linux/i686)"
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>
This removes all references to .../sbin for the guest additions and also
installs all binaries to .../bin instead (so no more .../sbin).
The main motivation for doing this is commit 98cedb3 (which
unfortunately had to be reverted in a9f2e10) and pull request #9063,
where the latter is an initial effort to move mount.vboxsf to .../bin
instead of .../sbin.
The commit I made afterwards is finishing the removal of .../sbin
entirely.
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>
We no longer need have "SUID sandbox" enabled in the chrome://sandbox
status page and we now also check for "You are adequately sandboxed." to
be absolutely sure that we're running with proper sandboxing.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We already have separate tests for checking whether the ISO boots
correctly, so it's not necessary to do that here. So now
tests/installer.nix just tests nixos-install, from a regular NixOS VM
that uses the host's Nix store. This makes running the tests more
convenient because we don't have to build a new ISO after every
change.
Serves as a regression test for #7902.
It's not yet referenced in release(-combined)?.nix because it will fail
until the issue is resolved. Tested successfully against libgcrypt with
libcap passed as null however.
As for the test itself, I'm not quite sure whether checking for the time
displayed by IceWM is a good idea, but we can still fix that if it turns
out to be a problem.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
