Hi all,
I'm basically repeating [1] here as there was no reaction for some
months now. Maybe I used the wrong communication channel, let's see...
We have a testsuite that is able to trigger a RCU WARNING inside the
Linux kernel. My expectation was that whenever a kernel warning / oops
/ call stack dump / ... occurs the LAVA job is marked as "failed".
This assumption seems to be wrong. It took some time to realize that we
have a real problem as manual inspection of test logs only happens from
time to time.
After scanning the code my understanding is that the output of the
connection (serial connection in my case) is only parsed during kernel
boot (until the login action takes over). That is not sufficient for
detecting problems that happen during test execution.
Is there a way to scan the full log for the same patterns that are used
by the boot action? If so, how to configure that? Whenever a kernel
problem occurs my test run should be marked as "failed".
Any ideas? Did I overlook something?
Best regards,
Florian
[1] https://git.lavasoftware.org/lava/lava/-/issues/576
Hi All,
I am trying to setup LAVA 2023.08 lava-server and lava-dispatcher on a
single machine, I successfully installed and was able to add workers and a
QEMU device.
From logs, it seems the workers are communicating with the lava server, I
am trying to execute a simple QEMU sample job and it always going in the
submitted state. I verified the device dictionary is correct.
As per my understanding if communication is happening between
lava-server/worker then a device should be assigned that is configured on
the worker, but in my case, no device is assigned to the test job and it
always keeps in a submitted state.
Can someone let me know if any special settings are required for running a
test job on a QEMU device? or share any docs link s to resolve this, any
input will be appreciated.
My Testjob YAML:
https://docs.lavasoftware.org/lava/examples/test-jobs/qemu-amd64-standard-s…
Thanks,
Ankit
Hello,
Is there a standard way to reboot the ECU by calling the reboot command defined in the device type (hard_reset_command),
between test case, so we are sure the tests are not impacting each other?
Thanks.
Hi All,
I am setting an HTTPS instance of LAVA, I can access the LAVA UI and am
able to log in as well. I am using a self-signed SSL certificate.
I have added *URL="https://172.16.60.178/ <https://172.16.60.178/>"* in the
/etc/lava-dispatcher/lava-worker file and restarted the service. It's
giving me the below error.
*2023-10-30 07:10:47,383 ERROR -> server error: code 5032023-10-30
07:10:47,383 DEBUG --> HTTPSConnectionPool(host='172.16.60.178',
port=443): Max retries exceeded with url:
/scheduler/internal/v1/workers/debian/?version=2023.10 (Caused by
SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: self signed certificate (_ssl.c:1123)')))*
Do we need to configure some extra settings in case we are using a
self-signed certificate? any help will be appreciated.
Thanks,
Ankit