The issue was that grub was not building the default entry which would
leave systems unbootable. This can now be safely reverted as the default
entry is being built once again.
This reverts commit fd1fb0403c.
JVMs exit with exit code 128+signal when receiving a (terminating)
signal. This means graceful termination of a JVM will result in 143, so
add that to `SuccessExitStatus` in systemd service unit.
- Usage of docker containerizer is currently hardcoded, this PR makes it
optional. Default is to enable it if docker is enabled.
- Make IP address to listen on part of service configuration.
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>
The man page for ssh-keygen(1) has a section "MODULI GENERATION" that describes
how to generate your own moduli file. The following script might also be helpful:
| #! /usr/bin/env bash
|
| moduliFiles=()
|
| generateModuli()
| {
| ssh-keygen -G "moduli-$1.candidates" -b "$1"
| ssh-keygen -T "moduli-$1" -f "moduli-$1.candidates"
| rm "moduli-$1.candidates"
| }
|
| for (( i=0 ; i <= 16 ; ++i )); do
| let bitSize="2048 + i * 128"
| generateModuli "$bitSize" &
| moduliFiles+=( "moduli-$bitSize" )
| done
| wait
|
| echo >moduli "# Time Type Tests Tries Size Generator Modulus"
| cat >>moduli "${moduliFiles[@]}"
| rm "${moduliFiles[@]}"
Note that generating moduli takes a long time, i.e. several hours on a fast
machine!
This patch resolves https://github.com/NixOS/nixpkgs/pull/5870.
This will make the test a lot more reliable, because we no longer need
to press ESC multiple times hoping that it will close the popup.
Unfortunately in order to run this test I needed to locally revert the
gyp update from a305e6855d.
With the old gyp version however the test runs fine and it's able to
properly detect the popup.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Only include the English language for the VM tests, because we most
likely won't need other languages. At least for now.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
By default this is now enabled, and it has to be explicitely enabled
using "enableOCR = true". If it is set to false, any usage of
getScreenText or waitForText will fail with an error suggesting to pass
enableOCR.
This should get rid of the rather large dependency on tesseract which
we don't need for most tests.
Note, that I'm using system("type -P") here to check whether tesseract
is in PATH. I know it's a bashism but we already have other bashisms
within the test scripts and we also run it with bash, so IMHO it's not a
problem here.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes the "blindly hope that 60 seconds is enough" issue from 1f34503,
so that we now have a (hopefully) reliable way to wait for the
passphrase prompt.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
As promised in the previous commit, this can be used similarly to
$machine->waitForWindow, where you supply a regular expression and it's
retrying OCR until the regexp matches.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Basically, this creates a screenshot and throws tesseract at it to
recognize the characters from the screenshot. In order to produce a
result that is well enough, we're using lanczos scaling and scale the
image up to 400% of its original size.
This provides the base functionality for a new Machine method which will
be called waitForText. I originally had that idea long ago when writing
the VM tests for VirtualBox and Chromium, but thought it would be
disproportionate to the case.
The downside however is that VM tests now depend on tesseract, but given
the average runtime of our tests it really shouldn't have a too big
impact and it's only a runtime dependency after all.
Another issue is that the OCR process takes quite some time to finish,
but IMHO it's better (as in more deterministic) than to rely on sleep().
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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>
