lava-users

lava-users@lists.lavasoftware.org

954 discussions

by Milosz Wasilewski

Hi, I'm running a project which requires changes in device status in LAVA. It will request the device to be put into 'maintenance' and later on into 'good' state. Initially I was using my personal API token. Since I was a superuser it all worked. A few weeks ago I tried to move to a more permanent solution with a dedicated user. I granted all required access rights to the new user, but PUT calls to api/v0.2/devices/<device_name> were rejected. After looking at the code it seems that only superuser is allowed to make such calls. Is there a reason for that? Changes were introduced in this commit: https://git.lavasoftware.org/lava/lava/-/commit/2bdbd462d745b45308faf86dd37… Best Regards, Milosz

4 years, 11 months

using 'uuu' boot action results in KeyError: 'uuu' on v2021.09

by Davis Roman

Hello, I received an error message when using the 'uuu' boot action on v2021.09. I tried poking around through the lava source but I'm still fairly new to the repo so I'm a bit stumped. Any comments or suggestions would be greatly appreciated. Thank you, Davis Traceback (most recent call last): File "/bin/lava-run", line 240, in main job = parse_job_file(logger, options) File "/bin/lava-run", line 151, in parse_job_file env_dut=env_dut, File "/usr/lib/python3/dist-packages/lava_dispatcher/parser.py", line 163, in parse test_counts[namespace], File "/usr/lib/python3/dist-packages/lava_dispatcher/parser.py", line 47, in parse_action cls = Boot.select(device, parameters) File "/usr/lib/python3/dist-packages/lava_dispatcher/logical.py", line 276, in select res = c.accepts(device, parameters) File "/usr/lib/python3/dist-packages/lava_dispatcher/actions/boot/uuu.py", line 119, in accepts params = device["actions"]["boot"]["methods"]["uuu"]["options"] KeyError: 'uuu' LAVABug: This is probably a bug in LAVA, please report it. --------------------------------------------------------------------------------------------------------------------------- device_type: imx8m job_name: flash with uuu timeouts: job: minutes: 10 action: minutes: 10 connection: minutes: 5 visibility: public actions: - deploy: to: uuu images: boot: url: file:///home/davis/uuu/imx-boot-64.bin system : url: file:///home/davis/uuu/sd.img - boot: method: uuu commands : - uuu: -b emmc_all {boot} {system}

5 years

dispatcher docker image overwrites ENV

by Benedikt Braunger

Moin, I'm using https://git.lavasoftware.org/lava/pkg/docker-compose to build example setups with LAVA and I want to add a second remote worker. Therefore I set the URL and DC_DISPATCHER_HOSTNAME in .env and run `docker-compose up lava-dispatcher`. Sadly the dispatcher always tries to connect to "lava-server" dispite that the correct URL is passed via environment variables into the container. It looks like the value gets overwritten in https://git.lavasoftware.org/lava/lava/-/blob/master/docker/share/entrypoin… as the lava-worker file looks like this inside the container. ... # Logging level should be uppercase (DEBUG, INFO, WARN, ERROR) # LOGLEVEL="DEBUG" # Server connection URL="http://lava-server:8000/" # TOKEN="--token <token>" WS_URL="--ws-url http://lava-publisher:8001/ws/" After digging around a bit I found out, that this environment file comes from https://git.lavasoftware.org/lava/pkg/docker-compose/-/blob/master/overlays… This practically disables the possibility of configuring the worker via the .env of the docker-compose repo. The order of defaults loading in https://git.lavasoftware.org/lava/lava/-/blob/master/docker/share/entrypoin… should be changed, so that the importing from the lava-worker file happens first and the environment variable is applied afterwards. Overall there are two defaults here and two possibilities to configure the worker, which is a bit confusing and redundant. Imho the .env from the docker-compose repo is a known and established way of configuring containers and should be preferred. Regards, Beni -- Benedikt Braunger emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Goettingen, Germany Sitz der Gesellschaft: Goettingen, Amtsgericht Goettingen HR B 3160 Geschaeftsfuehrung: Heike Jordan, Dr. Uwe Kracke Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source

5 years

Parsing test result that include square brackets in interactive test

by 김서지

5 years

All device become 'Bad (Invalid device configuration)' after lava server re-install

by Kever Yang

Hi I setup a LAVA server few years ago, on Debian 9.5 Stretch(with Python 3.5), and it works correctly. Recently I update the Python to 3.6, but the lava-server not able to work correctly. eg. the HTTP server does not work. So I fall back to Python 3.5 and re-install the LAVA server at the same time, but unfortunately the device does not work this time. The device status is set to "Bad (Invalid device configuration)" by the lava-health without any real check. The device was work correctly, and only change to 'BAD' when health check job get fail. Is there any device related option was set to mandatory instead of optional which cause this issue? How can I identify this issue? I can't see any Error in the log file at /var/log/lava-server Thanks, - Kever

5 years

Can't I use ']' on bootloader_prompt and "$'\cc'" on interrupt_char?

by 김서지

5 years

How to write dummy deploy action to test already flashed and booted DUT?

by 김서지

5 years, 1 month

Re: [Lava-users] Email notifications broken in LAVA 2021.08

by Westermann, Oliver

> I actually didn?t upgrade anything myself: I am using your > docker-compose solution, on a Ubuntu 18.04 host. Just as a sidenote as I noticed this as well: We also use the docker-compose setup and while I did not investigate the reasons yet, I can confirm that our mailed notifications are broken since the recent update. I didn't care to much as we check manually either way, but I can confirm from my last e-mail that the "breaking change" was simply a rebuild of the docker compose setup with the latest updates, but no host changes. - Olli

5 years, 1 month

Re: [Lava-users] Email notifications broken in LAVA 2021.08 ?

by Remi Duraffort

Hello, Le lun. 27 sept. 2021 à 17:14, Philippe Mazet (OSS) < philippe.mazet(a)oss.nxp.com> a écrit : > I actually didn’t upgrade anything myself: I am using your docker-compose > solution, on a Ubuntu 18.04 host. > > But your image in dockerhub (lavasoftware/lava-server:2021.08) upgraded to > bullseye, yes. > Have you tried creating your own derivative of the lavasoftware/lava-server:2021.08 image and installing eventlet from pypi? Rgds > > > Thanks, > > > > Philippe > > > > > > *From:* Lava-users <lava-users-bounces(a)lists.lavasoftware.org> *On Behalf > Of *Remi Duraffort > *Sent:* Monday, September 27, 2021 5:05 PM > *To:* Philippe Mazet (OSS) <philippe.mazet(a)oss.nxp.com> > *Cc:* lava-users(a)lists.lavasoftware.org <lava-users(a)lavasoftware.org> > *Subject:* Re: [Lava-users] Email notifications broken in LAVA 2021.08 ? > > > > Hello, > > > > > > Le jeu. 23 sept. 2021 à 13:54, Philippe Mazet (OSS) < > philippe.mazet(a)oss.nxp.com> a écrit : > > Hi All, > > > > We are hitting a bug with LAVA 2021.08: email notifications seem to be > broken. > > We believe this is due to a bug between eventlet 0.26.0 and dnspython. > > Visibly, this is fixed in eventlet 0.32.0: > https://github.com/eventlet/eventlet/issues/619 > > > > Did you face the same bug? > > > > I guess you upgraded to bullseye? Because LAVA 2021.08 hasn't changed > anything regarding it's requirements. > > > > > > Any idea about how to fix that? > > > > Depending on which debian version you are using. Either ask a DD to upload > python-eventlet 0.32 and to upload it to bullseye-backports. > > > > > > > > Thanks a lot, > > > > Philippe > > > > Trace below: > > ERROR:lava_scheduler_app:[Errno -3] Lookup timed out > > Traceback (most recent call last): > > File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line > 435, in resolve > > return _proxy.query(name, rdtype, raise_on_no_answer=raises, > > File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line > 391, in query > > return end() > > File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line > 370, in end > > raise result[1] > > File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line > 351, in step > > a = fun(*args, **kwargs) > > File "/usr/lib/python3/dist-packages/dns/resolver.py", line 1089, in > query > > return self.resolve(qname, rdtype, rdclass, tcp, source, > > File "/usr/lib/python3/dist-packages/dns/resolver.py", line 1043, in > resolve > > timeout = self._compute_timeout(start, lifetime) > > File "/usr/lib/python3/dist-packages/dns/resolver.py", line 950, in > _compute_timeout > > raise Timeout(timeout=duration) > > dns.exception.Timeout: The DNS operation timed out after 5.104917526245117 > seconds > > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.lavasoftware.org > https://lists.lavasoftware.org/mailman/listinfo/lava-users > > > > > -- > > Rémi Duraffort > > TuxArchitect > > Linaro > -- Rémi Duraffort TuxArchitect Linaro

5 years, 1 month

two boot actions in single job

by Milosz Wasilewski

Hi, I'm trying to run a job which reboots the board. The reboot is controlled with interactive shell. After issuing 'reboot' I try to run a 'boot' action with download overlay. This unfortunately fails. If there is 'transfer_overlay' lava complains there is no overlay available to download. When I remove 'transfer_overlay' lava complains there are no tests to run. I guess I need to add 'deploy' action before the second boot, but I don't know how to do it properly. The DUT should be left on it's own and not reflashed. Here is my job definition: actions: - deploy: namespace: before timeout: minutes: 10 to: flasher images: image: .... - boot: namespace: before prompts: - "root@imx8mmevk" timeout: minutes: 10 auto_login: login_prompt: 'login:' username: fio password_prompt: "Password:" password: "fio" login_commands: - sudo su - fio method: minimal transfer_overlay: download_command: cd /home ; wget unpack_command: tar -C / -xzf - test: namespace: before timeout: minutes: 5 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: prepare-upgrade description: "OTA upgrade" os: - debian scope: - functional run: steps: ... from: inline name: prepare-upgrade path: inline/prepare-upgrade.yaml - test: namespace: before timeout: minutes: 1 interactive: - name: reboot prompts: ['root@imx8mmevk',] script: - command: reboot name: reboot - boot: namespace: after connection-namespace: before prompts: - "root@imx8mmevk" timeout: minutes: 10 auto_login: login_prompt: 'login:' username: fio password_prompt: "Password:" password: "fio" login_commands: - sudo su - fio method: minimal transfer_overlay: download_command: cd /home ; wget unpack_command: tar -C / -xzf - test: namespace: after connection-namespace: before timeout: minutes: 5 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: verify-rollback description: "OTA upgrade" os: - debian scope: - functional run: steps: ... from: inline name: verify-rollback path: inline/verify-rollback.yaml I removed the test steps as they're not relevant. The 'before' and 'after' namespaces are required. Without namespaces LAVA will only run last boot and test sections and ignores the ones in 'before' namespace. To conclude - does anyone know how to make this job working? Either by adding a 'dummy deploy' to the 'after' namespace or by getting rid of namespaces so all tests are executed in the defined order? Best Regards, Milosz

5 years, 1 month

← Newer
1
...
14
15
16
17
18
19
20
...
96
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users