lava-users April 2023

lava-users@lists.lavasoftware.org

5 participants
6 discussions

by Sebastian Lucas

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

5 months, 4 weeks

U-Boot Bootloader Commands - mixed output, commands sent too fast?

by Stefan

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

11 months, 3 weeks

Problem while testing a new device type template

by gemad＠outlook.com

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

11 months, 4 weeks

Bug using SSH as primary connection

by Seb L

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

1 year

Bug using SSH as primary connection

by Sebastian Lucas

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

1 year

How to set particular connection from available connection list from job description yaml

by Nagendra Singamsetti

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

1 year

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users April 2023