lava-users May 2023

lava-users@lists.lavasoftware.org

8 participants
9 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

1 month, 2 weeks

Reboot mechanism in LAVA for USB booted devices

by P T, Sarath

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

6 months, 3 weeks

Pass Enter key press after u-boot:

by pawanKumar

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

6 months, 3 weeks

How to fail a test run on kernel warnings that happen after the boot action?

by Florian Bezdeka

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

6 months, 4 weeks

zephyr support in lava.

by cnspring2002

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.

6 months, 4 weeks

Design decision help reagrding device-types and health-check

by gemad＠outlook.com

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

6 months, 4 weeks

Re: Lava-users Digest, Vol 56, Issue 4

by cnspring2002

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 *****************************************

7 months

Question regarding to:download deploy action

by gemad＠outlook.com

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

7 months, 1 week

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

7 months, 2 weeks

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users May 2023