lava-users June 2023

lava-users@lists.lavasoftware.org

7 participants
7 discussions

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

4 months, 1 week

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

6 months

is https://docs.lavasoftware.org server for LAVA document not supported anymore?

by 김서지 Lily

Hi. Is https://docs.lavasoftware.org server for LAVA document not supported anymore? I can't access the site anymore. Thank you.

6 months, 3 weeks

Notify User is not sending notification to user:

by Pavankumar Reddy

Hello Team, I'm using notify action in the job definition to notify users about the status of the job. I'm already a registered user in lava and after completion of my job, the administration site shows the status as "*not sent*". Please let me know what can be the reason, and how can i achieve it? [image: lava-notify.PNG] Below is the job definition i'm using: *device_type: ADT-UNIT1job_name: sample test to notify usertimeouts: job: minutes: 15 action: minutes: 10 connection: minutes: 5visibility: publicactions:- command: name: relay_pwr_on timeout: minutes: 1- deploy: to: flasher images: package: url: https://artifactory.softwaretools.com/artifactory/gop-generic-stable-local/… <https://artifactory.softwaretools.com/artifactory/gop-generic-stable-local/…>- boot: method: u-boot commands: - setenv factorymode 1 - boot auto_login: login_prompt: 'login:' username: root password_prompt: 'Password:' password: root login_commands: - touch /home/root/test_file - ifconfig prompts: - 'root@hon-grip' - 'root@GRIP'notify: recipients: - to: method: email user: pavan criteria: status: finished verbosity: verbose* Thanks & Regards, Pavan

6 months, 3 weeks

Notify User in Lava:

by pawanKumar

8 months, 1 week

test levels in lava test result

by gemad＠outlook.com

Hello, I am trying to understand how the result levels are constructed for example when I run "lavacli results <job-id>" I get an output looking like so : Results: * lava.git-repo-action [pass] * lava.test-overlay [pass] * lava.test-install-overlay [pass] * lava.test-runscript-overlay [pass] * lava.my_test_case_1 [pass] * lava.my_test_case_2[pass] what I want to do is to have a test categories, for example * lava.category1.my_test_case_1[pass] * lava.category3.my_test_case_3[pass] and so on. I tried adding tags and namespaces but the results are not impacted, Can someone please guide me through this or mention part of the documentation that might be helpful ? Thanks in advance.

10 months, 2 weeks

UUID mismatching error while rootfs mounting for qemu

by P T, Sarath

Hi Team, Is there any provision that LAVA provides for passing the uuid for qemu platforms ? Because I am getting an error while mounting the rootfs like "Can't find the root device with the matching UUID!". Does LAVA provide any provision to pass the uuid along with the "image_arg" for qemu ? Or is it something I am missing in the job definition file ? - deploy: timeout: minutes: 5 to: tmpfs images: kernel: image_arg: -kernel {kernel} -append "console=ttyS0,115200 root=/dev/sda vga=0x305 rw" url: <URL_to_vmlinuz>/vmlinuz type: zimage ramdisk: image_arg: -initrd {ramdisk} url: <URL_to_initrd>/initrd.img compression: gz rootfs: image_arg: -drive file={rootfs},format=raw " url: <URL_to_rootfs>/rootfs-qemu-amd64.squashfs os: debian root_partition: 1 [cid:image002.png@01D99A39.9F6574A0] Regards , Sarath P T

10 months, 3 weeks

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users June 2023