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
I was trying to follow the section testing new device template here :
https://validation.linaro.org/static/docs/v2/development-intro.html#develop…
but I am getting the error :
root@master1:/# lava-server manage device-dictionary
Unknown command: 'device-dictionary'. Did you mean device-tags?
Type 'lava-server help' for usage.
Some versions information :
master1:/#lava-server manage version
2.2.28
lab-slave-0:/# lavacli system version
2023.01
Is the documentation outdated, or am I trying to execute the command in the wrong place ?
Also what is the best way to debug and check the errors in a new device template ?
Thanks in advance.
G.Emad
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
start: 0 validate
Start time: 2023-04-12 14:07:00.373707+00:00 (UTC)
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'
validate duration: 0.00
case: validate
case_id: 244238
definition: lava
result: fail
Cleaning after the job
Root tmp directory removed at /var/lib/lava/dispatcher/tmp/8857
LAVABug: This is probably a bug in LAVA, please report it.
case: job
case_id: 244239
definition: lava
error_msg: 'connections'
error_type: Bug
result: fail
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
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 Everyone,
My board has multiple uarts and they are designed to act as different
serial consoles of platform OS. So I am trying to set the desired
connection (serial) while calling the respective platform boot/flash
method from the job description. Means i need to utilise the same board and
have to call suitable serial console from connection list to get boot
logs.
{% set UART_PORTS = {"SE-UART": "AB0KOQF7", "UART2": "A10LOBA4", "UART4":
"AB0LPSO7"} %}
{% set connection_list = ['uart2', 'uart4'] %}
{% set connection_tags = {'uart2': ['primary','telnet'], 'uart4':
['telnet']} %}
{% set connection_commands = {'uart2': 'telnet 10.10.4.140 4004', 'uart4':
'telnet 10.10.4.140 4002'} %}
How to set required serial(uart2 or uart4) from connection list in job
description??
Regards
Nagendra S
You may want to have a look for Antonio's MR: https://git.lavasoftware.org/lava/lava/-/merge_requests/2038, not sure if it's your case.
-----Original Message-----
From: lava-users-request(a)lists.lavasoftware.org <lava-users-request(a)lists.lavasoftware.org>
Sent: Friday, March 24, 2023 8:00 AM
To: lava-users(a)lists.lavasoftware.org
Subject: [EXT] Lava-users Digest, Vol 54, Issue 8
Caution: EXT Email
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. Re: Not able to unpack the overlay other than "/" directory
(P T, Sarath)
----------------------------------------------------------------------
Message: 1
Date: Thu, 23 Mar 2023 07:14:49 +0000
From: "P T, Sarath" <Sarath_PT(a)mentor.com>
Subject: [Lava-users] Re: Not able to unpack the overlay other than
"/" directory
To: Milosz Wasilewski <milosz.wasilewski(a)foundries.io>
Cc: "lava-users(a)lists.lavasoftware.org"
<lava-users(a)lists.lavasoftware.org>, "Bhola, Bikram (PLM)"
<bikram.bhola(a)siemens.com>
Message-ID: <035b0a2cc7dd40f19552ce319acae2d9(a)mentor.com>
Content-Type: text/plain; charset="utf-8"
Hi Milosz,
Any update on below query ?
I changed "lava_test_results_dir": "/etc/lava-%s", from "lava_test_results_dir": "/lava-%s", from the above code session. Somehow the lava_test_results_dir variable which we defined in the job definition is not getting override by the default value , that’s why we did the change. Can you post your code snippet from the worker ? and do you know why the job definition is not able to identify the lava_test_results_dir value ?
Regards,
Sarath PT
-----Original Message-----
From: P T, Sarath
Sent: 15 March 2023 19:21
To: 'Milosz Wasilewski' <milosz.wasilewski(a)foundries.io>
Cc: lava-users(a)lists.lavasoftware.org; Bhola, Bikram (PLM) <bikram.bhola(a)siemens.com>
Subject: RE: [Lava-users] Re: Not able to unpack the overlay other than "/" directory
Hi Milosz,
Thanks for the support you have given. And I could able to achieve the scenario by changing the code from worker side as below
Navigate to the directory : cd /usr/lib/python3/dist-packages/lava_dispatcher
debian = {
"TESTER_PS1": r"linaro-test [rc=$(echo \$?)]# ",
"TESTER_PS1_PATTERN": r"linaro-test \[rc=(\d+)\]# ",
"TESTER_PS1_INCLUDES_RC": True,
"boot_cmds": "boot_cmds",
"line_separator": "\n",
# for lava-test-shell
"distro": "debian",
"tar_flags": "--warning no-timestamp",
"lava_test_sh_cmd": "/bin/bash",
"lava_test_dir": "/lava-%s",
"lava_test_results_part_attr": "root_part",
"lava_test_results_dir": "/etc/lava-%s",
"lava_test_shell_file": "~/.bashrc", }
I changed "lava_test_results_dir": "/etc/lava-%s", from "lava_test_results_dir": "/lava-%s", from the above code session. Somehow the lava_test_results_dir variable which we defined in the job definition is not getting override by the default value , that’s why we did the change. Can you post your code snippet from the worker ? and do you know why the job definition is not able to identify the lava_test_results_dir value ?
Regards,
Sarath P T
-----Original Message-----
From: Milosz Wasilewski <milosz.wasilewski(a)foundries.io>
Sent: 13 March 2023 14:50
To: P T, Sarath <Sarath_PT(a)mentor.com>
Cc: lava-users(a)lists.lavasoftware.org; Bhola, Bikram (PLM) <bikram.bhola(a)siemens.com>
Subject: Re: [Lava-users] Re: Not able to unpack the overlay other than "/" directory
Sarath,
Sorry, I can't reproduce any of your issues. You need to debug yourself.
Best Regards,
Milosz
On Mon, Mar 13, 2023 at 6:11 AM P T, Sarath <Sarath_PT(a)mentor.com> wrote:
>
> Hi Milosz,
>
> Any update ?
>
> Regards,
> Sarath P T
>
> -----Original Message-----
> From: P T, Sarath
> Sent: 08 March 2023 15:53
> To: 'Milosz Wasilewski' <milosz.wasilewski(a)foundries.io>
> Cc: lava-users(a)lists.lavasoftware.org; Bhola, Bikram (PLM)
> <bikram.bhola(a)siemens.com>
> Subject: RE: [Lava-users] Re: Not able to unpack the overlay other
> than "/" directory
>
> Hi Milosz,
>
> Now we could able to unpack the overlay in the path that we have given in the job definition. But after exporting the shell (export SHELL=/bin/bash) its not able to proceed with ". /<path_defined_in_definition>/lava-13030/environment" and "/<path_defined_in_definition>/lava-13030/bin/lava-test-runner /<path_defined_in_definition>/lava-13030/0 ". Below I am giving the job definition.
>
>
> priority: high
> visibility: public
> device_type: industrial-mtda-simatic-ipc227e-01
> visibility: public
> timeouts:
> job:
> minutes: 30
> action:
> minutes: 20
> connection:
> minutes: 20
> job_name: SLLL_CI_MTDA_SIMATIC_IPC227E_DEPLOY_BOOT_TEST_JOB
> actions:
> - deploy:
> to: overlay
> os: debian
> - boot:
> method: minimal
> reset: true
> failure_retry: 2
> auto_login:
> login_prompt: 'ebsy-isar login:'
> username: root
> password_prompt: "Password:"
> password: root
> prompts:
> - 'root@ebsy-isar:~#'
> transfer_overlay:
> download_command: sleep 10; cd /home/test ; wget
> unpack_command: tar -C /home/test -xzf
> - test:
> role:
> - node1
> timeout:
> minutes: 5
> definitions:
> - repository:
> metadata:
> description: basic test for some devices on board
> format: Lava-Test Test Definition 1.0
> name: kernel-version
> os:
> - debian
> run:
> steps:
> - cd /usr/libexec/ebsy-qa-suites/swupdate
> - ./swupdate_new.sh
> from: inline
> name: mtda-restart
> path: inline/mtda.yaml
> context:
> lava_test_results_dir: /home/test/lava-%s
> test_character_delay: 10
> tags:
> - slll-industrial-mtda-simatic-ipc227e-01
> timeouts:
> action:
> minutes: 20
> connection:
> minutes: 20
> job:
> hours: 7
> visibility: public
> job_name: SLLL_X86_TEST_JOB
> metadata:
> Description: '"Lava jobs for deploy, boot and usb test"'
> DEVICES: slll-simatic-ipc227e-mtda-01
>
> Regards,
> Sarath P T
>
>
>
> -----Original Message-----
> From: Milosz Wasilewski <milosz.wasilewski(a)foundries.io>
> Sent: 01 March 2023 14:27
> To: P T, Sarath <Sarath_PT(a)mentor.com>
> Cc: lava-users(a)lists.lavasoftware.org; Bhola, Bikram (PLM)
> <bikram.bhola(a)siemens.com>
> Subject: Re: [Lava-users] Re: Not able to unpack the overlay other
> than "/" directory
>
> On Wed, Mar 1, 2023 at 5:51 AM P T, Sarath <Sarath_PT(a)mentor.com> wrote:
> >
> > Hi Milosz,
> >
> > Yes it’s a strange behaviour that there is no command sent over serial to start overlay decompression. And is there any server configuration changes you made for accomplishing it ?
>
> No, I'm running vanilla LAVA dispatcher in a container from dockerhub
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhub.
> docker.com%2Fr%2Flavasoftware%2Flava-dispatcher%2F&data=05%7C01%7Clarr
> y.shen%40nxp.com%7C4bc23a099b864eb0dfbb08db2bfac2a1%7C686ea1d3bc2b4c6f
> a92cd99c5c301635%7C0%7C0%7C638152128229848153%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> 000%7C%7C%7C&sdata=D3wz%2BoY6viVxsjK%2FtFpRFBTeiftt%2B%2Bv6iB6E1oXwR%2
> BY%3D&reserved=0
>
> Best Regards,
> Milosz
------------------------------
End of Lava-users Digest, Vol 54, Issue 8
*****************************************