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
Hello everyone,
There seems to be a bug in LAVA. I was on version 2022.04 and have also tried 2023.03. Both versions have the same bug.
The same configurations works in a 2018 build of LAVA on an old machine.
I am trying to connect to an always on board via ssh.
The healthcheck is failing with this error :
lava-dispatcher, installed at version: 2023.03<https://10.1.52.17/scheduler/job/8857#L1>start: 0 validate<https://10.1.52.17/scheduler/job/8857#L2>Start time: 2023-04-12 14:07:00.373707+00:00 (UTC)<https://10.1.52.17/scheduler/job/8857#L3>Traceback (most recent call last): File "/usr/lib/python3/dist-packages/lava_dispatcher/job.py", line 198, in validate self._validate() File "/usr/lib/python3/dist-packages/lava_dispatcher/job.py", line 183, in _validate self.pipeline.validate_actions() File "/usr/lib/python3/dist-packages/lava_dispatcher/action.py", line 190, in validate_actions action.validate() File "/usr/lib/python3/dist-packages/lava_dispatcher/actions/deploy/ssh.py", line 81, in validate if "serial" not in self.job.device["actions"]["deploy"]["connections"]: KeyError: 'connections' <https://10.1.52.17/scheduler/job/8857#L4> validate duration: 0.00<https://10.1.52.17/scheduler/job/8857#results_244238>case: validate
case_id: 244238
definition: lava
result: fail
<https://10.1.52.17/results/testcase/244238><https://10.1.52.17/scheduler/job/8857#L6>Cleaning after the job<https://10.1.52.17/scheduler/job/8857#L7>Root tmp directory removed at /var/lib/lava/dispatcher/tmp/8857<https://10.1.52.17/scheduler/job/8857#L8>LAVABug: This is probably a bug in LAVA, please report it.<https://10.1.52.17/scheduler/job/8857#results_244239>case: job
case_id: 244239
definition: lava
error_msg: 'connections'
error_type: Bug
result: fail<https://10.1.52.17/results/testcase/244239>
The health check looks like this:
job_name: SSH check
timeouts:
job:
minutes: 10
action:
minutes: 2
priority: medium
visibility: public
actions:
- deploy:
timeout: # timeout for the connection attempt
seconds: 30
to: ssh
os: oe
- boot:
timeout:
minutes: 2
prompts: ['root@(.*):~#']
method: ssh
connection: ssh
- test:
timeout:
minutes: 5
definitions:
- repository:
metadata:
format: Lava-Test Test Definition 1.0
name: smoke-tests-basic
description: "Basic smoke test"
run:
steps:
- lava-test-case linux-linaro-ubuntu-pwd --shell pwd
- lava-test-case linux-linaro-ubuntu-uname --shell uname -a
- lava-test-case linux-linaro-ubuntu-vmstat --shell vmstat
- lava-test-case linux-linaro-ubuntu-ip --shell ip a
from: inline
name: smoke-tests-basic
Any ideas ?
Best regards,
Sebastian
Hi Team,
Is there any implementation in LAVA for reboot mechanism of USB booted devices ? basically x86 architecture. I found there are options in sd card booted devices using "uuu" , but is there a similar way approach for USB booted devices ?
Ideally LAVA does not have a provision to identify the "login prompt" without any "boot" method.
Regards,
Sarath P T
Hello Team,
Good Day to you!
I have a requirement to pass "enter" key after u-boot process completion,
to enter into the system.
Without pressing any key cannot enter into prompt and it stays stagnant.
Please let me know how to pass "enter" press key at the end of u-boot log.
Thanks
Pavan kumar
Hi, team,
I remember I once saw a video about how to use docker in lava to test zephyr, by kumar gala or someone else I'm not sure? But I forget the detail, can you kindly share something about that? Sample job, video or how others test zephyr with lava are highly appreciated, thanks in advance.
Hello,
I have 2 versions of a device which are identical in terms of the deploy and boot and DUT control command,
but they need different images to boot, I differentiate between them with tags,
how can I have the same health-check job running on both of them, but use different images ?
or shall I create 2 device-types for them ? ( doesn't sound like a clean solution )
Thanks
Vote +1, we have same requirements. Either LAVA could support different health check for different chip versions, or take one step back, just can disable health check on old version device, enable health on newest version only. Currently to avoid too many variants, we disable all healthy check for chipV1, chipV2, chipV3 etc.
------------------------------------------------------------------
Sender:lava-users-request <lava-users-request(a)lists.lavasoftware.org>
Sent At:2023 May 13 (Sat.) 08:00
Recipient:lava-users <lava-users(a)lists.lavasoftware.org>
Subject:Lava-users Digest, Vol 56, Issue 4
Send Lava-users mailing list submissions to
lava-users(a)lists.lavasoftware.org
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
lava-users-request(a)lists.lavasoftware.org
You can reach the person managing the list at
lava-users-owner(a)lists.lavasoftware.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Lava-users digest..."
Today's Topics:
1. Design decision help reagrding device-types and health-check
(gemad(a)outlook.com)
----------------------------------------------------------------------
Message: 1
Date: Fri, 12 May 2023 14:31:22 -0000
From: gemad(a)outlook.com
Subject: [Lava-users] Design decision help reagrding device-types and
health-check
To: lava-users(a)lists.lavasoftware.org
Message-ID:
<168390188210.1209.11677411661920883493(a)op-lists.linaro.org>
Content-Type: text/plain; charset="utf-8"
Hello,
I have 2 versions of a device which are identical in terms of the deploy and boot and DUT control command,
but they need different images to boot, I differentiate between them with tags,
how can I have the same health-check job running on both of them, but use different images ?
or shall I create 2 device-types for them ? ( doesn't sound like a clean solution )
Thanks
------------------------------
Subject: Digest Footer
_______________________________________________
Lava-users mailing list -- lava-users(a)lists.lavasoftware.org
To unsubscribe send an email to lava-users-leave(a)lists.lavasoftware.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
------------------------------
End of Lava-users Digest, Vol 56, Issue 4
*****************************************
Hello,
I am using the deploy action to:download to download a file from http server and decompress it,
I want to pass the path of which the file is decompressed to a user defined function in the device.jinja2,
Is there a way to do do so ? I this variable exposed somehow to the environment ?
Thanks
Hey everyone!
As I got last problems solved, I am able to boot my device - but that doesn't work out to be reliable.
During inspection of console output, I see that there are "random" chars where I don't expect them to be, these chars are the next command that gets sent - before the previous command is finished.
For me it seems as U-Boot bootloader-commands doesn't wait for the prompt. Can this be the case here? Or is something other going wrong?
Configuration basically the same as in https://lists.lavasoftware.org/archives/list/lava-users@lists.lavasoftware.…
Serial console of the device is connected via USB2Serial adapter which uses ser2net to make this available with Telnet (which seems to be the LAVA default way to go).
In console I can see things like this, e.g. when tftp command shows its progress, only '#' should be displayed, but there are chars in between:
Loading: *################s#####################################e############
###############t######################################e############
########################n#####################################v####
The chars in there are "setenv" which is the next command that LAVA wants to execute.
This causes the boot to fail in some occurrences, e.g. if dhcp command is not yet fully executed and zImage already tried to load, thus it fails and boot fails.
See attached (stripped to relevant parts) log for details.
As workaround I set character delay to 100 milliseconds, which seems to make it a bit more reliable, but that can only be a temporary solution, as the characters still appear at the wrong place.
Thanks in advance!
Stefan