Lava-users

lava-users@lists.linaro.org

358 discussions

bootloader-commands not waiting for prompt

by Jeremy Stashluk

The bootloader-commands step breaks into u-boot and begins to issue commands, but some commands are issued prior to receiving the prompt. I've attempted changing the boot_char_delay, but it doesn't solve the issue. I'm getting symptoms much like the ones in this thread, except I'm sending space rather than a newline, so the fix is not relevant to me. https://lists.linaro.org/pipermail/lava-users/2018-May/001069.html Jeremy Stashluk Embedded Software Engineer [cid:image002.jpg@01D45B04.B75D2A40] Geophysical Survey Systems, Inc. 40 Simon Street * Nashua, NH 03060-3075 603. 893.1109 main * 603.681.2045 direct * 603.889.3984 fax stashlukj(a)geophysical.com<mailto:stashlukj@geophysical.com> * www.geophysical.com<http://www.geophysical.com/>

8 years, 1 month

REST API

by Milosz Wasilewski

Hi, I made a first attempt to add REST API for some LAVA objects (jobs, devices and device types). The API is very rudimentary but already solves some basic job filtering issues. However I'm not sure how to add dependencies. There are 2 packages required for this code to work properly. Pip packages are named 'djangorestframework' and 'djangorestframework-filters'. Former has a corresponding debian package 'python3-djangorestframework' but the later does not. Any hints how to add proper dependencies to LAVA? The code can be found here: https://git.lavasoftware.org/mwasilew/lava/tree/rest_api milosz

8 years, 1 month

Detect u-boot watchdog in Lava

by Denis HUMEAU

Dear users, I'm looking for a way to detect a possible watchdog in u-boot during a test session. It happened that on one our test platforms a watchdog was triggered, u-boot restarted, and eventually the test session started. Unless we take a look at every trace of every job, there is a big chance to leave this type of errors undetected. Do you have any idea on a possible way to handle this in Lava, maybe via device dictionary? Thanks in advance, Denis

8 years, 1 month

CSRF verification failed even after changing settings.conf

by Jorgen Peddersen

Hi, We're using LAVA 2018.5.post1 and we have not been able to log into the web interface since upgrading to this version. The system is running within a docker container. Trying to log in results in a CSRF warning. The same version of LAVA running on a dedicated debian machine does start working when adding the mentioned lines from this page: https://validation.linaro.org/static/docs/v2/installing_on_debian.html#djan… Making the same changes to /etc/lava-server/settings.conf within the docker container has no effect on the way the web interface works. It still provides the same errors. Is there anything else we should do to try to get the web interface to allow logins? I'm not even sure the settings.conf file is being read when restarting the LAVA services, would it appear in one of the logs so that I could search for it? Thanks for any help you can provide regarding this matter. Regards, Jorgen Peddersen Jorgen Peddersen Researcher t +61 2 6103 4700 m e jorgen.peddersen(a)seeingmachines.com a 80 Mildura Street, Fyshwick ACT 2609, Australia SEEINGMACHINES.COM<http://seeingmachines.com> [SEEINGMACHINES] This email may contain confidential information. If you are not the intended recipient, destroy all copies and do not disclose or use the information within. Any content that is not concerned with the business of the Seeing Machines Group reflects the views of the sender only, not those of Seeing Machines. No warranties are given that this email does not contain viruses or harmful code. [http://www.seeingmachines.com/wp-content/uploads/2018/04/sm-email-twitter-i…] <https://twitter.com/seeingmachines> [http://www.seeingmachines.com/wp-content/uploads/2018/04/sm-email-linkedin-…] <https://www.linkedin.com/company/258949/>

8 years, 1 month

Second serial port control

by Oana Ercus

Hi everyone, I'm a newbie to LAVA, so this may be a stupid question, but I have no idea how to fix this issue. I am using a device for which I enabled the usage of the second serial port as described in the example beaglebone-black job with a second serial port - it seems that the configuration works fine, I was able to enable the secondary connection. The problem is the following: the second serial port connects to a different shell, which at this moment is used for freeRTOS application, and its prompt ("SHELL>>") is different of the primary connection prompt which is used for Linux("root@imx8mqevk"). When trying to actually run some commands on freeRTOS, I get timeout error and I have no idea how to fix it. I attached to this e-mail my test job definition, together with the log and the snip from my web. Thanks in advance for your support, Oana [image: image.png] [image: image.png]

8 years, 1 month

Changing SERVER_IP in device-types/bae-uboot.jinja2

by Thomas Klaehn

Hi, As far as I could figure out - the uboot environment server ip is set in the base_uboot_dhcp_command in base-ubooy.jinja2. The value of SERVER_IP seems to be set somehow within lava. And it looks if it's not possible to overide it in the device dictionary, isn't it? Is there a way to change the value of SERVER_IP? Thanks in advance. Best regards, Thomas Klaehn Senior Software Engineer u-blox Berlin GmbH Rudower Chaussee 9 DE-12489 Berlin Phone +49 30 55573 1032 Mobile +49 151 23990904 www.u-blox.com<http://www.u-blox.com/> locate.communicate.accelerate follow us on twitter<https://twitter.com/ublox> | subscribe to our youtube channel<https://www.youtube.com/c/ublox1> | follow us on linkedin<https://www.linkedin.com/company/u-blox> | connect with us on facebook<https://www.facebook.com/ublox1> | follow us on google+<https://plus.google.com/+ublox1> u-blox Berlin GmbH CEO (Geschäftsführer): Daniel Ammann Registered: Berlin HRB 164301 B This message contains confidential information intended only for the use of the addressee(s) and may be legally privileged. If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return email and destroy all copies of the original message. All suggestions, recommendations, or other comments contained in this email are provided as a courtesy only. We do not assume any responsibility or liability for the correctness of the information contained in the email.

8 years, 1 month

Re: [Lava-users] Reset LAVA database

by Tim Jaacks

Hi Neil, thanks for your quick and direct feedback and please excuse my incautiousness. Being a software developer, I am still new to admin stuff and don't have much experience in hosting servers. The "flush" command is documented in the help text of "lava-server manage". From the information there it seemed as if "lava-server manage dumpdata" would create a dump of the database (which it did) and that I might be able to restore it with "lava-server manage loaddata" (which I couldn't) if the flush would not do what I expected. However, the database in that installation was not important at all, I spent some time experimenting with LAVA on this machine and just wanted to have a clean database for starting production use. I assumed there should be an easy way to achieve this. With your help, I was able to reset my LAVA database using the following commands: sudo apt-get purge lava-server sudo rm -rf /etc/lava-server/ sudo rm -rf /var/lib/lava-server/ sudo pg_dropcluster 9.6 main --stop sudo pg_createcluster 9.6 main --start sudo apt-get install lava-server Thanks for pointing me to the backup topic, I will address that in my next step. Cheers, Tim Mit freundlichen Grüßen / Best regards Tim Jaacks DEVELOPMENT ENGINEER Garz & Fricke GmbH Tempowerkring 2 21079 Hamburg Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 tim.jaacks(a)garz-fricke.com www.garz-fricke.com SOLUTIONS THAT COMPLETE! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz

8 years, 1 month

Reset LAVA database

by Tim Jaacks

Hello everyone, is there a way to reset the LAVA database to the state of a fresh installation? From the docs I thought that "lava-server manage flush" command would do that. However, there are some things missing afterwards, e.g. the lava-health user and the master worker. Any hints on how to repair this? Re-installing lava-server did not help. Mit freundlichen Grüßen / Best regards i.A. Tim Jaacks Software Engineering Garz & Fricke GmbH Tempowerkring 2, 21079 Hamburg - Germany Amtsgericht Hamburg HRB 60514 Geschäftsführer: Manfred Garz, Matthias Fricke Phone: +49 40 791899 - 55 Fax: +49 40 791899 – 39 tim.jaacks(a)garz-fricke.com www.garz-fricke.com

8 years, 1 month

Building Embedded Debian-based system images

by Zoran S

Hello to Linaro developers, Recently I have learned that Linaro has developed its own tool to build Embedded Debian-based system images. I am very interested in this work/this tool. So I have some questions regarding this domain. [1] Do you have published this tool on the Open Source? [2] If YES, what are the web pointers to it, and the docs I can read and get familiar with the process? [3] Does it include scripts to enhance initramfs (the technology Linaro uses to do that), and where are the locations to read about it? [4] You name it (if I miss something, please, feel free to fill the gaps)! I use (almost always) YOCTO based build tool to create initramfses to test upon them (you know this already if you read my recent emails to this list). But I would like to have alternative method, and Linaro tool seems excellent one as alternative, for many reasons. Thank you in advance, Zoran Stojsavljevic _______

8 years, 1 month

Why the lava is not designed a machnism that notify user when only a test case is complete(err..)

by john zhang

Lava xml-rpc notification machnism, criteria.status indicates which event can be notified to user (by hook callback). But the criteria.status only has such as "Complete Incomplete,Canceled,finished" events. Why the lava is not designed a machnism that notify user when only a test case is complete(err..),if so that user has more rights to control test process execution.

8 years, 1 month

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Lava-users