lava-users July 2023

lava-users@lists.lavasoftware.org

6 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, 1 week

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

Error upgrading to lava-server 2023.06

by Tim Jaacks

Hello, I tried upgrading from lava-server 2023.03 to 2023.06 on Debian 11 and got the following error: Setting up lava-server (2023.06+11+bullseye) ... /var/run/postgresql:5432 - accepting connections Updating configuration: * generate SECRET_KEY [SKIP] * generate DATABASES [SKIP] Run fixups: * fix permissions: - /var/lib/lava-server/home/ - /var/lib/lava-server/default/ - /var/lib/lava-server/default/media/ - /var/lib/lava-server/default/media/job-output/ - /etc/lava-server/dispatcher-config/ - /etc/lava-server/dispatcher.d/ - /var/lib/lava-server/default/media/job-output/2017/ - /etc/lava-server/dispatcher-config/devices/ - /etc/lava-server/dispatcher-config/devices/* - /etc/lava-server/dispatcher-config/device-types/ - /etc/lava-server/dispatcher-config/device-types/* - /etc/lava-server/dispatcher-config/health-checks/ - /etc/lava-server/dispatcher-config/health-checks/* * drop duplicated templates: * fix permissions: - /etc/lava-server/settings.conf - /etc/lava-server/instance.conf - /var/log/lava-server/ - /var/log/lava-server/* - /etc/lava-server/secret_key.conf Create database: psql -q NOTICE: not creating role lavaserver -- it already exists NOTICE: not creating role devel -- it already exists lava-server manage migrate --noinput --fake-initial Operations to perform: Apply all migrations: admin, auth, authtoken, contenttypes, lava_results_app, lava_scheduler_app, linaro_django_xmlrpc, sessions, sites Running migrations: Applying lava_results_app.0019_auto_20230307_1545...Traceback (most recent call last): File "/usr/bin/lava-server", line 55, in <module> main() File "/usr/bin/lava-server", line 51, in main execute_from_command_line([sys.argv[0]] + options.command) File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 381, in execute_from_command_line utility.execute() File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 375, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 323, in run_from_argv self.execute(*args, **cmd_options) File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 364, in execute output = self.handle(*args, **options) File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 83, in wrapped res = handle_func(*args, **kwargs) File "/usr/lib/python3/dist-packages/django/core/management/commands/migrate.py", line 232, in handle post_migrate_state = executor.migrate( File "/usr/lib/python3/dist-packages/django/db/migrations/executor.py", line 117, in migrate state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial) File "/usr/lib/python3/dist-packages/django/db/migrations/executor.py", line 147, in _migrate_all_forwards state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial) File "/usr/lib/python3/dist-packages/django/db/migrations/executor.py", line 245, in apply_migration state = migration.apply(state, schema_editor) File "/usr/lib/python3/dist-packages/django/db/migrations/migration.py", line 114, in apply operation.state_forwards(self.app_label, project_state) File "/usr/lib/python3/dist-packages/django/db/migrations/operations/models.py", line 256, in state_forwards state.remove_model(app_label, self.name_lower) File "/usr/lib/python3/dist-packages/django/db/migrations/state.py", line 100, in remove_model del self.models[app_label, model_name] KeyError: ('lava_results_app', 'actiondata') migration dpkg: error processing package lava-server (--configure): installed lava-server package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: lava-server E: Sub-process /usr/bin/dpkg returned an error code (1) Does anybody know what I can do in this case? Uninstalling lava-server and installing it again does not resolve the issue. Kind regards, Tim -- Tim Jaacks SOFTWARE DEVELOPER SECO Northern Europe GmbH Schlachthofstrasse 20 21079 Hamburg Germany T: +49 40 791899-183 E: tim.jaacks(a)seco.com Register: Amtsgericht Hamburg, HRB 148893 Represented by: Dirk Finstel, Marc-Michael Braun, Massimo Mauri

8 months, 2 weeks

Results GUI page does not show "to be executed" cases list

by koti

Hi, is it possible to show "Total count of test cases listed in Test Definition" to the Results GUI page. Right now it shows only executed test cases (either PASS/FAIL) but does not show to be executed (yet to be executed) cases count. Regards, Koti

9 months, 2 weeks

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users July 2023