lava-users February 2018

lava-users@lists.lavasoftware.org

20 participants
30 discussions

Error while submitting a Test Definition | Standalone LAVA Master installation

by Conrad Djedjebi

Good morning everyone, I am getting in touch with you in order to show you an issue i am encountering while submitting a basic Test Definition through my LAVA web page (localhost). I am a new LAVA user. Both the two attached scripts are returning the following error in the interface : I checked the syntax of my yaml files using an online tool. Here is a description of the steps I followed while installing the Standalone Master instance of LAVA on my computer : - Installing lava-server - Setting up Apache2 server - Setting ser2net - Adding a superuser to lava system - Creating a device type (.jinja2) file and a device - Writing a Test Definition (.yaml file) - Submitting that Test Definition through the GUI of lava thank you for your help,

6 years, 10 months

Unable to get job summary for running test job in master-slave configuration

by mayuri mohite

Hello all, I am following steps mentioned in https://validation.linaro.org/static/docs/v2/pipeline-server.html#zmq-curve for installing lava dispatcher on local machine (slave which is my worker machine) and https://validation.linaro.org/static/docs/v2/installing_on_debian.html for installing lava server on another machine (master) I have added device through GUI using https://validation.linaro.org/static/docs/v2/first-devices.html#create-devi… documentation I have successfully added worker to serevr side and able to get message showing that encryption has been enabled on the both master and slave side. I am able to run test job on added target which has worker as slave machine on which my dispatcher is running. My job is started it is showing runnig state but I am not getting any console log in job summary. please help me to get debug log in job summary. Regards, Mayuri.

6 years, 10 months

[IMPORTANT - test issue #99] Issues with installing when running behind a web proxy

by Zoran S

More about proxies: Here is update on the Lava proxy business. Please, read this very carefully, since this is the solution to the problems with Lava proxies, as well as Lava DUT ones. YES, after applying what Remi advised to me, the qemu01 test: https://www.validation.linaro.org/static/docs/v2/first-job.html worked like a charm. I simply copied /etc/lava-server/env.yaml to /etc/lava-server/env.dut.yaml (and created the new file). Remi, I would like to thank you for the advise! Best Regards, Zoran Stojsavljevic ---------- Forwarded message ---------- From: Remi Duraffort <remi.duraffort(a)linaro.org> Date: Thu, Feb 15, 2018 at 4:30 PM Subject: Re: [Lava-users] [HW target questions] Pointers from Lava test suite to the HW target To: Zoran S <zoran.stojsavljevic.de(a)gmail.com> Cc: Lava Users Mailman list <lava-users(a)lists.linaro.org> Not exactly. 1/ The process that is deploying, booting and testing a DUT (Device Under test) is called lava-run. lava-run environment variables are controlled by /etc/lava-server/env.yaml By default, all environment variables are removed and only a small set of variables are added. This helps to make executions reproducible between dispatchers and instances. So if you need an environment variable to be set, then you have to add it to /etc/lava-server/env.yaml 2/ On the DUT itself, by default, we don't add or change any environment variable. Because that's the user responsibility. However, if /etc/lava-server/env.dut.yaml does exists, it will be used to add environment variables to the DUT shell. To create the list of environment variables to add to the DUT, we take the full environment from lava-run (as defined by /etc/lava-server/env.yaml) and we apply the rules from env.dut.yaml. I hope that does help you to understand how environment is setup in lava. Rgds On Wed, Feb 14, 2018 at 2:04 PM, Zoran S <zoran.stojsavljevic.de(a)gmail.com> wrote: > https://gitlab.com/cip-project/cip-testing/testing/issues/99 > > Also from: > https://lists.cip-project.org/pipermail/cip-dev/2017-July/000338.html > > At the end of test issue #99, I added the solution to this problem. > > Lava does NOT read VM's ENV variables. It ignores them. Lava reads > /etc/lava-server/env.yaml as setup proxy file! > > Included there also /etc/lava-server/env.yaml file example. > > It could be done also DIRECTLY (every time bringing up the VM) using > python, tapping into the urllib3 python code (example given): > https://stackoverflow.com/questions/31151615/how-to-handle-proxies-in-urlli… > > I've tried this, using in-line python interpreter, it worked. > > Zoran

6 years, 10 months

Test execution without creating images

by Hemanth K V

Hello Lava Users, Trying to reproduce LAVA installation in our lab.Was able to successfully test deploy boot and test through nfs metod. But having difficulty when device is booted with *preinstalled Debian or OpenEmbedded images and ** we just want to execute tests on it (no need to create images at moment).* Can have any reference documents or templates to refer when just want to execute tests on device. Thanks, Hemanth.

6 years, 10 months

[HW target questions] Pointers from Lava test suite to the HW target

by Zoran S

Hello to the Lava users, I am the new Lava user. My aim is to use Lava (for now V1) setup for my testing, from the beginning just to hook-up my Beagle Bone Black (BBB) to Lava worker, and from Lava apache to set the proper context for testing BBB HW. As I am reading Lava framework, I got the following impression about the test suite: [1] I need to prepare BBB's U-Boot for the Lava U-Boot jinja2 setup; [2] I need to hook-up my EG-PMS2-LAN (energenie) to the Lava (to PO and POFF HW platform); [3] I need to hook-up ser2net interface (which I already have working over TCP) to the Lava. so Lava can control it; [4] I need to hook-up uImage, .dtb and ramdisk images to the Lava (which will be FTPed and set in memory for board setup and testing). Question 1: Does manual have some Beagle Bone Black U-Boot default scripts, which should be provisioned to the BBB U-Boot for the correct Lava U-Boot behavior? Question 2: How do I do [1], [2], [3] and [4], does Lava manual have some explanation as working example how to do these points? Question 3: Anything else I missed for the proper Lava test setting? Thank you in advance, Zoran

6 years, 10 months

Unable to connect to mirror.bytemark.co.uk:http: [IP: 2001:41c8:20:5e6::10 80]

by Zoran S

After figuring out proxies and setting them correctly, I let run First QEMU job, described here: https://staging.validation.linaro.org/static/docs/v2/first-job.html And have the following errors: https://pastebin.com/334xHvX8 For example, there are no elements requested from this job such as: E: Failed to fetch http://mirror.bytemark.co.uk/debian/pool/main/p/python3.5/python3.5-minimal… Unable to connect to mirror.bytemark.co.uk:http: [IP: 2001:41c8:20:5e6::10 80] E: Failed to fetch http://mirror.bytemark.co.uk/debian/pool/main/p/python3-defaults/python3-mi… Unable to connect to mirror.bytemark.co.uk:http: [IP: 2001:41c8:20:5e6::10 80] But I am getting on ping mirror.bytemark.co.uk PING mirror.bytemark.co.uk (212.110.161.69)... ??? IP address seems to be IPV6 (which points that something is not correctly set)?! I also checked a routing table, everything there within VM is set correctly. Do I need to set more of the proxies?! What is the problem here??? Thank you, Zoran

6 years, 10 months

Regarding LXC Job

by Chetan Sharma

Hi Everyone, If i execute a LXC Job. If this job execution failed due to any reason, then in that case LXC-stop is not called, directly lxc-destroy is called by which LXC instance is still running on system and consumes memory and Space. How we can can make sure that this instance destroys with Job completion either Failed/Passed/Incomplete. -- Thanks & Regards Chetan Sharma

6 years, 10 months

user logins via http and https

by Kevin Hilman

Is there a way to make user logins to work whether you're connecting over HTTP or HTTPS on the same instance? I know that to get user logins to work without https, you have to add this to /etc/lava-server/settings.conf: "CSRF_COOKIE_SECURE": false, "SESSION_COOKIE_SECURE": false, But it would be nice if user logins would also work over https at the same time. The use case for this is an internal LAVA instance that doesn't have https so internal connections are all over http. The same instance is also available to the outside world via an nginx reverse proxy with TLS termination, so connections from outside are over https. Can it be made to work for both internal (http) and external (https) connections? Thanks, Kevin

6 years, 10 months

how to achieve sync among multi-node in job definition

by Liao, Guoqi

Hi Guys: When I am doing a multi-node testing, I create one job definition liking below. For example: Sub-job 1 finished booting and testing, but sub-job 2 is on-going booting. So sub-job 1 will Remove the template file like <lava_dipatcher>/tmp/overlay****, that will cause sub-job 2 could NOT download The overlay**** file, sub-job 2 failed in the end. My question is how to do sync between multi-node in the job Definition? My job definition: protocols: lava-multinode: roles: foo: tags: - board1 device_type: ********** context: grub_method: centos grub_installed_device: (hd1,gpt1) count: 1 bar: tags: - board2 device_type: ********** context: grub_method: centos grub_installed_device: (hd2,gpt1) count: 1 timeout: minutes: 6 job_name: centos openjdk test timeouts: job: minutes: 1500 action: minutes: 50 connection: minutes: 30 priority: medium visibility: public actions: - deploy: role: - foo - bar kernel: url: http://******** type: zimage os: centos timeout: minutes: 80 to: tftp - boot: timeout: minutes: 40 role: - bar method: grub commands: centos_installed auto_login: login_prompt: 'login:' username: root password_prompt: 'Password:' password: root prompts: - 'root@localhost ~' transfer_overlay: download_command: rm -f /root/overlay* ; ifconfig ; wget -S --progress=dot:giga unpack_command: tar -C / -xaf parameters: shutdown-message: "reboot: Restarting system" - boot: timeout: minutes: 40 role: - foo method: grub commands: centos_installed auto_login: login_prompt: 'login:' username: root password_prompt: 'Password:' password: root prompts: - 'root@localhost ~' transfer_overlay: download_command: rm -f /root/overlay* ; ifconfig ; wget -S --progress=dot:giga unpack_command: tar -C / -xaf parameters: shutdown-message: "reboot: Restarting system" - test: role: - foo - bar timeout: minutes: 50 definitions: - repository: ssh://**********/test-definitions from: git branch: ********** path: automated/linux/openjdk/openjdk-smoke.yaml name: openjdk-smoke Thanks B.R. Guoqi This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

6 years, 10 months

Minimal Boot: manage additional parameters

by Philippe BEGNIC

Hello Lava Team, I have created some Lava jobs that use our proprietary Flasher, based on a DFU connection. As our flasher is not a "standard" flasher, I have adapted the boot process to be able to use our flasher. I use the boot method "minimal" to achieve this. To call our flasher script, I have used the script called by the method "power_on". This is defined in the device configuration. Find below an extract of the device content : ....................................................................................... .. .. {% set hard_reset_command = '/usr/bin/pduclient --daemon localhost --hostname lava_pdu_01.lme.st.com --command reboot --port 1' %} {% set power_off_command = '/usr/bin/pduclient --daemon localhost --hostname lava_pdu_01.lme.st.com --command off --port 1' %} {% set power_on_command = '/root/git/lava-config/scripts/flash_stm32_programmer.sh -u lava_pdu_01.lme.st.com -p 1 -d usb1 -b ds378_2.lme.st.com -s 4_5_6 -f /tmp/test' %} {% set connection_command = 'telnet localhost 2001' %} .. .. ....................................................................................... This works correctly for a "static" configuration. The settings for the flasher are defined outside Lava by a script that configure the flashing parameters. The "power_on" script reads these parameters, and launch the flashing on the board. My problem now, is when I launch simultaneously jobs on several boards that requires different flashing binaries version. I am unable to indicate to each boards which binary version to be used by our flasher. The best way would be to pass parameters in the job to indicate which binary version has to be used by the flasher. This could be done in the "deploy action" and pass to the "power_on" command, but I don't know how to implement it. I don't know also if it is possible to do that easily ? Find below my job definition. ###### Job definition ############## actions: - deploy: timeout: minutes: 5 to: ssh os: oe device: - boot: method: minimal failure_retry: 2 auto_login: login_prompt: 'login:' username: root prompts: - 'root@stm32mp1' timeout: minutes: 10 transfer_overlay: download_command: sync && sleep 15 && wget unpack_command: tar -C / -xzf - test: ... ############################# Thanks to support me. BR Philippe

6 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users February 2018