- lava-users - op-lists.linaro.org

by George Nistor

Hi, But I do not understand exactly for example if I can use a Nexus5x; the device is in the list of supported devices Steve McIntyre sent me. Milosz Wasilewski said I cannot use it with Lava due to the lack of possibility to force power cycle on them (via serial interface - USB). To be able to use it requires hw modification of the device? What we want to have for the moment is a real device (ex, Nexus 5) on which to run Tradef with Lava. george -----Original Message----- From: Steve McIntyre <steve.mcintyre(a)linaro.org> Sent: Tuesday, August 20, 2019 8:51 PM To: George Nistor <george.n(a)l4b-software.com> Cc: lava-users(a)lists.lavasoftware.org Subject: Re: [Lava-users] real devices supported by Lava by default Hi George, On Tue, Aug 20, 2019 at 12:54:21PM +0000, George Nistor wrote: > >I have a question regarding real devices supported by Linaro Lava. > >Besides these dev boards I found here : >https://validation.linaro.org/static/ >docs/v2/standard-armmp-ramdisk-bbb.html#standard-known-devices > >Are any other real devices supported in Lava by default? (any >commercial phone for example Nexus 5)? There's a huge set of supported devices. If you don't already have LAVA installed, the easiest way to find the list is by looking at the set of device type configurations at https://git.lavasoftware.org/lava/lava/tree/master/etc/dispatcher-config/de… Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

5 years, 10 months

2
1
0 0

real devices supported by Lava by default

by George Nistor

Hello Lava users, I have a question regarding real devices supported by Linaro Lava. Besides these dev boards I found here : https://validation.linaro.org/static/docs/v2/standard-armmp-ramdisk-bbb.htm… Are any other real devices supported in Lava by default? (any commercial phone for example Nexus 5)? george

5 years, 10 months

3
2
0 0

LXC-START

by Fedusiv Ilya

Hello, LAVA Team! I'm trying to implement own device description. Run with standard fastboot singlenode with lxc. And received error: lava-dispatcher, installed at version: 2019.03+stretchstart: 0 validateStart time: 2019-08-19 15:01:03.367020+00:00 (UTC)validate duration: 0.00result: fail definition: lava case: validate <http://localhost:10080/results/testcase/8>Cleaning after the jobRoot tmp directory removed at /var/lib/lava/dispatcher/tmp/2InfrastructureError: The Infrastructure is not working correctly. Please report this error to LAVA admins.error_msg: Cannot find command 'lxc-start' in $PATH error_type: Infrastructure result: fail definition: lava case: job <http://localhost:10080/results/testcase/9> Best regards, Ilya Fedusiv

5 years, 10 months

2
1
0 0

Help on kernelci integration

by Xiaofeng Ren

Anyone can help to provide some suggestion about following kernelci integration problem: We setup one kernelci in our infrastructure and deploy LAVA master and slave as well. kernelci can support build, LAVA can also work to run automation test. We use the lava-boot-v2.sh (jenkins job in kernelci-core project ) to trigger lava test, but we found that both boot report or test report can't be synchronized to kernelci dashboard. It will report json format error, may I know whether we need follow boot schema or test schema defined in kernelci (https://api.kernelci.org/schema-boot.html and https://api.kernelci.org/schema-test.html) to create one report, then trigger LAVA callback function to post one request? Following is callback definition in https://github.com/kernelci/kernelci-core/blob/master/templates/base/kernel…. Do we need customize this callback if we want to post request for boot and test result? Any suggestion will be appreciated. {%- if callback %} notify: criteria: status: finished callback: {%- if callback_type == 'custom' %} url: {{ callback_url }} {%- else %} url: {{ callback_url }}/callback/{{ callback_name }}?lab_name={{ lab_name }}&status={STATUS}&status_string={STATUS_STRING} {%- endif %} method: POST dataset: {{ callback_dataset }} token: {{ callback }} content-type: json {% endif %}

5 years, 10 months

2
2
0 0

Adding new device

by Fedusiv Ilya

Hello LAVA Team! Found in manual about adding new device, at begin better to write to you. Device is: aarch64 Flashing via fastboot (have partition table list) Device has serial debug connection. For flashing using next commands: fastboot flash <partition name> <path> ... ... fastboot set_active a fastboot reboot To turn device into fastboot mode need to enter command in serial debug. Best regards, Ilya Fedusiv

5 years, 10 months

2
1
0 0

running CTS and VTS from lxc against an qemu target with AOSP

by George Nistor

Hi Lava Users, I am trying to create a target with qemu running android as an ISO image. The job I intend to write is to run CTS and VTS on a qemu target with android. But I receive error when submitting. Could anyone help me telling me which are my mistakes I do with the job? None of the deployment strategies accepted your deployment parameters, reasons given: qemu-nfs: "to" is not "nfs" lxc: "to" parameter is not "lxc" overlay: 'overlay' not in the device configuration deploy methods removeable: "media" was not "sata", "sd", or "usb" fastboot: "to" parameter is not "fastboot" tftp: "to" parameter is not "tftp" nfs: "to" parameter is not "nfs" images: "to" parameter is not "tmpfs" flasher: 'flasher' not in the device configuration deploy methods docker: 'docker' not in the device configuration deploy methods uboot-ums: "to" parameter is not "u-boot-ums" ssh: "ssh" is not in the device configuration deploy methods download: "to" parameter is not "download" iso: "iso" was not in the parameters recovery-mode: 'recovery' not in the device configuration deploy methods mps: "mps" was not in the device configuration deploy methods nbd: "to" parameter is not "nbd" vemsd: "to" parameter is not "vemsd" device_type: qemu job_name: george_ISO_6 timeouts: job: minutes: 120 action: minutes: 120 connection: minutes: 120 priority: medium visibility: public # CONTEXT_BLOCK context: arch: amd64 # ACTIONS_BLOCK actions: - deploy: timeout: minutes: 120 to: iso-installer images: rootfs: url: https://osdn.net/frs/redir.php?m=cznic&f=android-x86%2F69704%2Fandroid-x86-… sha256sum: 71e3cd7e7151fbc7e9bb29be10e337b2545586d3ef173c5ae8c07d13bf595732 # BOOT_BLOCK - boot: method: qemu-iso media: media=cdrom,readonly timeout: minutes: 20 connection: serial

5 years, 10 months

2
3
0 0

Re: [Lava-users] running commands locally from a Lava job

by George Nistor

Hi Lava users, I am using the sample you sent me last week to run tradefed: https://gist.github.com/mwasilew/e6e80a351d43388b1c3342098012ec Until we have a real device to run on Tradefed we decided to use it with qemu, so the question is: 1. How do we deploy android on qemu via Lava? 2. How to boot android via lava? Do you have any sample job for the above questions? george ________________________________ From: George Nistor Sent: Thursday, August 8, 2019 2:19:05 PM To: Vladut Magas <vladut.m(a)l4b-software.com>; Inon Sharony <inon.s(a)l4b-software.com>; Yair Podemasky <yair.p(a)l4b-software.com> Cc: Andreas Schl?ter <andreas.s(a)l4b-software.com>; Ilya Fedusiv <ilya.f(a)l4b-software.com> Subject: FW: [Lava-users] running commands locally from a Lava job Here is the answer I have just received from Linaro via their mail-list. They say it is not a good idea to build tradefed with lava, but it can be used in the scenario to run TF from an LXC container - they have said. Tradefed should be built from outside Lava. george -----Original Message----- From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org> Sent: Thursday, August 8, 2019 2:07 PM To: George Nistor <george.n(a)l4b-software.com> Cc: lava-users(a)lists.lavasoftware.org Subject: Re: [Lava-users] running commands locally from a Lava job On Thu, 8 Aug 2019 at 11:50, George Nistor <george.n(a)l4b-software.com> wrote: > > Thanks for the answers, > > 1. What do you mean by "with LXC container acting as a host side ". It is an LXC container on the machine where Lava runs and inside this containes runs Tradefed? yes, exactly. Here is an example job definition: https://gist.github.com/mwasilew/e6e80a351d43388b1c3342098012ec5c I can't share the actual job and logs as there are passwords included. milosz > 2. Where can I find an example of these Jobs? Could you help me with an link, or sample jobs? > > george > > -----Original Message----- > From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org> > Sent: Thursday, August 8, 2019 1:29 PM > To: George Nistor <george.n(a)l4b-software.com> > Cc: lava-users(a)lists.lavasoftware.org > Subject: Re: [Lava-users] running commands locally from a Lava job > > I would say it's a bad idea. LAVA is not meant for building stuff. It can do that but you will need to hack around quite a lot. Secondly IIUC you need to have dependency between build and run steps. If you want to implement this using LAVA this implies multi-node job. There is no other way LAVA will manage dependencies and timings between executions. So this is getting pretty complicated already. > > LAVA is already running tradefed jobs (CTS and VTS) using real hardware and it's a pretty common use case. There are 2 implementations of this. One is using single node job with LXC container acting as a host side. Other is using multinode and can shard tests between multiple devices. However tradefed packages are built outside of lava and downloaded before job starts. > > To sum up, I think what you're trying to do is not best suited for LAVA. However it might be possible given some effort spent on experimenting. > > milosz > > On Thu, 8 Aug 2019 at 11:20, George Nistor <george.n(a)l4b-software.com> wrote: > > > > Yes > > For one job to build tradefederation from inside a docker container. > > For the second job to run Google TradeFederation from the docker container. > > > > Would be that possible with Lava? > > > > george > > > > -----Original Message----- > > From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org> > > Sent: Thursday, August 8, 2019 1:16 PM > > To: George Nistor <george.n(a)l4b-software.com> > > Cc: lava-users(a)lists.lavasoftware.org > > Subject: Re: [Lava-users] running commands locally from a Lava job > > > > George, > > > > Do I understand correctly you would like to use LAVA as a building tool? > > > > milosz > > > > On Thu, 8 Aug 2019 at 10:47, George Nistor <george.n(a)l4b-software.com> wrote: > > > > > > Hi Lava users, > > > > > > > > > > > > Is it possible to run commands inside a lava job test-section, locally, from a Lava Job? > > > > > > Ex: > > > > > > cd /media/sh_shared_folders > > > > > > docker build -t tradefed . > > > > > > > > > > > > We have the following setup: > > > > > > A machine with Linux Ubuntu; > > > an Oracle Virtual Box VM on the machine with a Xubuntu distro > > > image inside the VM we have created 3 Docker containers: > > > > > > one with the Jenkins > > > second one with Lava > > > third is created for the purpose of running Google TradeFederation > > > against the Android device > > > > > > > > > > > > (The AOSP source tree is available to the VM via shared_folders > > > and the docker container has also access to it. (via docker run -v > > > dir_host:dir_container) ) > > > > > > > > > > > > What we what to achieve is to have 2 jobs in Lava : > > > > > > one for building the Docker image for the purpose of building > > > TradeFederation inside > > > > > > Ex. Running these commande locally: > > > > > > source > > > ./build/make/envsetup.sh > > > > > > lunch > > > <device-target> > > > > > > make > > > tradefed-all -j8 > > > > > > > > > > > > second using the above image, instantiate, create a container > > > which should run TradeFederation against the android device > > > connected to the machine > > > > > > > > > > > > What I need is to be able to run commands locally inside the VM (on Xubuntu distro) from a Lava job. For these we have to somehow not send the command to qemu but run them locally. > > > > > > Is this possible? If yes, how can we achieve this? > > > > > > > > > > > > George Nistor > > > > > > _______________________________________________ > > > Lava-users mailing list > > > Lava-users(a)lists.lavasoftware.org > > > https://lists.lavasoftware.org/mailman/listinfo/lava-users > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.lavasoftware.org > https://lists.lavasoftware.org/mailman/listinfo/lava-users

5 years, 10 months

1
0
0 0

running commands locally from a Lava job

by George Nistor

Hi Lava users, Is it possible to run commands inside a lava job test-section, locally, from a Lava Job? Ex: cd /media/sh_shared_folders docker build -t tradefed . We have the following setup: * A machine with Linux Ubuntu; * an Oracle Virtual Box VM on the machine with a Xubuntu distro image * inside the VM we have created 3 Docker containers: * one with the Jenkins * second one with Lava * third is created for the purpose of running Google TradeFederation against the Android device (The AOSP source tree is available to the VM via shared_folders and the docker container has also access to it. (via docker run -v dir_host:dir_container) ) What we what to achieve is to have 2 jobs in Lava : * one for building the Docker image for the purpose of building TradeFederation inside Ex. Running these commande locally: source ./build/make/envsetup.sh lunch <device-target> make tradefed-all -j8 * second using the above image, instantiate, create a container which should run TradeFederation against the android device connected to the machine What I need is to be able to run commands locally inside the VM (on Xubuntu distro) from a Lava job. For these we have to somehow not send the command to qemu but run them locally. Is this possible? If yes, how can we achieve this? George Nistor

5 years, 10 months

2
5
0 0

Re: [Lava-users] Testjob state is cancelling

by Remi Duraffort

Hello, I'm asking if the corresponding lava-slave is still working properly. You can see that on the web interface in the workers page. By the way, which version are you using? Le mar. 6 août 2019 à 16:25, Gumansingh, Smita <Smita_Gumansingh(a)mentor.com> a écrit : > Yes Remi, > > Corresponding testjob is still running on device from last 3 days after it > got canceled it from GUI. Testjob state is showing canceling > and my device state is showing Running. > > test-hardware | x86 | running | 15696 > > > Thanks & Regards, > Smita Gumansingh > ------------------------------ > *From:* Remi Duraffort <remi.duraffort(a)linaro.org> > *Sent:* Tuesday, August 6, 2019 6:26 PM > *To:* Gumansingh, Smita > *Subject:* Re: [Lava-users] Testjob state is cancelling > > Hello, > > are you sure that the corresponding lava-slave is still running? > > > Rgds > > Le mar. 6 août 2019 à 09:11, Gumansingh, Smita < > Smita_Gumansingh(a)mentor.com> a écrit : > >> Hi all, >> >> I cancelled a test job but it still running on my device and showing >> testjob state as “cancelling”. Is there any way to restart the device ,so >> that I can submit some other job . >> >> Killing the specific job id on lava-master using lava-cli also not >> solving the problem. >> >> >> >> *Regards,* >> >> *Smita Gumansingh* >> >> >> >> [image: cid:image001.jpg@01D2E5A8.A6033460] >> >> >> >> Senior test Engineer, EPS PBU Software QA/Dev Ops >> >> Mentor Graphics, >> >> Nalapad Brigade Centre, Unit No:301 & 302 >> >> Mahadevapura, Bengaluru, Karnataka 560048, India >> >> Office: +91 8067624338 |Cell: +91 9538349245 >> >> www.mentor.com >> >> >> _______________________________________________ >> Lava-users mailing list >> Lava-users(a)lists.lavasoftware.org >> https://lists.lavasoftware.org/mailman/listinfo/lava-users > > > > -- > Rémi Duraffort > LAVA Team, Linaro > -- Rémi Duraffort LAVA Team, Linaro

5 years, 10 months

2
1
0 0

usb serial not seen in LXC container

by Axel Lebourhis

Hi all, I'm running CTS tests on Android 9, with LAVA. I noticed the CTS module CtsUsbTests failed because of the error: "usb serial != adb serial expected:<[]> but was:<[a266fa0a5c85d6ee]>" This module is a hostsidetest, and checks if usb serial matches adb serial by running "lsusb -v" on the host and checking the iSerial returned by the command. ( https://android.googlesource.com/platform/cts/+/refs/heads/master/hostsidet… ) And this test fails when I run it with LAVA so I checked on my local PC and the test passes. Indeed, if I run the command "lsusb -v" I get this output for iSerial: iSerial 3 351d5a0a5c85d936 The third field is the adb serial, so it matches well. So I suspected the LXC container to not give the usb serial. So I checked directly in the container and after running "lsusb -v" I got: iSerial 3 The adb serial is missing. So, do you know a way to make the LXC see correctly the usb serial ? Regards, Axel

5 years, 10 months

2
1
0 0

uboot-ums with bmap-tools

by Diego Russo

Hello, We've been using uboot-ums deploy mechanism for quite some time but we really want to move away from dd and star using bmap-tools. I guess lava does not support it (yet) but I was wondering if there is a way where we can use uboot-ums with bmap-tools. Thanks -- Diego Russo | Staff Software Engineer | Mbed Linux OS ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - https://os.mbed.com/linux-os/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 10 months

2
1
0 0

Re: [Lava-users] uboot-ums with bmap-tools

by Diego Russo

Right, it is not the first time I ask a similar question (I did ask it last February) and a lava issue has been created: https://git.lavasoftware.org/lava/lava/issues/234 Unfortunately there are no progress on this and actually it has been removed from the milestones. Can we ask to reconsider it? ( Cheers -----Original Message----- From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> on behalf of Diego Russo <Diego.Russo(a)arm.com> Date: Tuesday, 6 August 2019 at 13:32 To: "lava-users(a)lists.lavasoftware.org" <lava-users(a)lists.lavasoftware.org> Subject: [Lava-users] uboot-ums with bmap-tools Hello, We've been using uboot-ums deploy mechanism for quite some time but we really want to move away from dd and star using bmap-tools. I guess lava does not support it (yet) but I was wondering if there is a way where we can use uboot-ums with bmap-tools. Thanks -- Diego Russo | Staff Software Engineer | Mbed Linux OS ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - https://os.mbed.com/linux-os/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Lava-users mailing list Lava-users(a)lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 10 months

1
0
0 0

Help needed with UART tests

by kingboli

Hello LAVA experts, I have a device which can boot up to android/linux. The device is connected with two USB cables. One USB cable is used for flashing images (fastboot flash) and doing some adb shell commands. Via another USB cable, I can use minicom to check uart logs and directly interact with the device (/dev/ttyUSB0). Can you share some examples (jobs, job definitions) or configurations (like ser2net conf) or any suggestion for doing below test steps on my device with LAVA? Scenario 1: 1. Flash images using fastboot 2. After android boots up or linux boots up, reboot and then stop at uboot 3. Do some tests in uboot. Scenario 2: 1. Flash images using fastboot 2. After android boots up or linux boots up, interact with the device via uart (/dev/ttyUSB0) (suppose adb is disconnected) 3. Do some tests via uart. Best regards, Kingboli

5 years, 10 months

2
1
0 0

Testjob state is cancelling

by Gumansingh, Smita

Hi all, I cancelled a test job but it still running on my device and showing testjob state as "cancelling". Is there any way to restart the device ,so that I can submit some other job . Killing the specific job id on lava-master using lava-cli also not solving the problem. Regards, Smita Gumansingh [cid:image001.jpg@01D2E5A8.A6033460] Senior test Engineer, EPS PBU Software QA/Dev Ops Mentor Graphics, Nalapad Brigade Centre, Unit No:301 & 302 Mahadevapura, Bengaluru, Karnataka 560048, India Office: +91 8067624338 |Cell: +91 9538349245 www.mentor.com<http://www.mentor.com/>

5 years, 10 months

1
0
0 0

Job template validation is buggy

by Axel Lebourhis

Hi all, Our lava instance has been upgraded from 2019.03 to 2019.07 today. Some of our teams need extra job context variables to be allowed, so I added in /etc/lava-server/settings.conf the following parameter, as described in one of your releases: EXTRA_CONTEXT_VARIABLE: ["variable_1", "variable_2", "variable_3"] It seems to work, but when I want to submit a job, sometimes I get the warning "extra key not allowed" and if I hit the button "validate" many times I finally get "valid definition". But sometimes I get "valid definition" directly. Is it a known issue? Best regards, Axel

5 years, 10 months

2
5
0 0

Lava question

by Fedusiv Ilya

Hello! I'm using lava-docker. https://github.com/kernelci/lava-docker I can deploy my image to device only with special device and flash-program, QDL. (https://git.linaro.org/landing-teams/working/qualcomm/qdl.git) Can you recommend better way how to do it with LAVA? I've tried with lxc default test jobs: https://github.com/Linaro/lava/blob/master/lava_scheduler_app/tests/sample_… and this first one : https://validation.linaro.org/static/docs/v2/deploy-lxc.html In all both cases I received similar error: lava-dispatcher, installed at version: 2019.03+stretchstart: 0 validateStart time: 2019-08-01 14:58:10.607488+00:00 (UTC)This MultiNode test job contains top level actions, in order, of: deploy, boot, test, finalizelava-lxc-mocker, installed at version: validate duration: 0.01definition: lava case: validate result: fail <http://localhost:10080/results/testcase/24>Cleaning after the jobInfrastructureError: The Infrastructure is not working correctly. Please report this error to LAVA admins.definition: lava error_msg: Cannot find command 'lxc-create' in $PATH result: fail error_type: Infrastructure case: job <http://localhost:10080/results/testcase/25> Best regards, Ilya. <https://git.lavasoftware.org/lava/lava/issues>

5 years, 10 months

2
1
0 0

Re: [Lava-users] Fwd: login prompts

by Remi Duraffort

Hello, if the prompt is "# " without more characters then in the lava job definition you have to put "# ". In fact, this won't work well because this string can be seen on other places (like kernel logs). The only solution here would be to change the prompt of the root filesystem to make it a bit more unique. Rgds Le mer. 31 juil. 2019 à 13:53, Hemanth K V <kv.hemanth.mys(a)gmail.com> a écrit : > Hello Remi, > > First of all Thanks for support.Trying for matching the string "# " > If we don't specify any escape or brackets then it is matching one of the > kernel message logs and sending the username .Following is reference of > auto_login defined in yaml. > ***** hwi path: hwi version/minor get_device_info->hwi_get_value: read > STRING value: > device name Matched prompt #4: # > > auto_login: > login_prompt: "buildroot login:" > username: root > password_prompt: "Password:" > password: root > prompts: > - '# ' > > On including escape it is waiting for > auto-login-action: Wait for prompt ['\$# \$', 'Login incorrect', 'Login > timed out'] (timeout 00:07:53). Following is reference of auto_login > defined in yaml. > > auto_login: > login_prompt: "buildroot login:" > username: root > password_prompt: "Password:" > password: root > prompts: > - '$# $' > > Thanks, > Hemanth. > > On Wed, Jul 31, 2019 at 3:25 PM Remi Duraffort <remi.duraffort(a)linaro.org> > wrote: > >> Hello, >> >> which strin are you trying to match? " #", "#", "# "? >> Just put that (without any escaping or brackets) in the list of prompts. >> >> Rgds >> >> Le mar. 30 juil. 2019 à 14:20, Hemanth K V <kv.hemanth.mys(a)gmail.com> a >> écrit : >> >>> >>> Hello Lava Users, >>> >>> The target on which I am trying to run tests from LAVA has # prompt >>> after login. >>> As specified in Documentation >>> https://lava.collabora.co.uk/static/docs/v2/actions-boot.html?highlight=pro… >>> >>> - boot: >>> prompts: >>> # escape the brackets to ensure that the prompt does not match >>> # kernel debug lines which may mention initramfs >>> - '$initramfs$' >>> >>> in the job definition I am including - >>> boot: >>> ..... >>> failure_retry: 4 >>> prompts: >>> - '$# $' >>> >>> But in the job execution log getting "*auto-login-action: Wait for prompt ['\$# \$', 'Login incorrect', 'Login timed out'] (timeout 00:07:52)*". >>> >>> Also if we want to debug while running the job which will be the best possible approach to follow. >>> In the Documentation got information on "Debugging Django issues" which states two settings are required in/etc/lava-server/settings.conf >>> >>> >>> - "DEBUG": true, >>> - "USE_DEBUG_TOOLBAR": true, >>> >>> Thanks, >>> Hemanth. >>> >>> _______________________________________________ >>> Lava-users mailing list >>> Lava-users(a)lists.lavasoftware.org >>> https://lists.lavasoftware.org/mailman/listinfo/lava-users >> >> >> >> -- >> Rémi Duraffort >> LAVA Team, Linaro >> > -- Rémi Duraffort LAVA Team, Linaro

5 years, 10 months

1
0
0 0

Fwd: login prompts

by Hemanth K V

Hello Lava Users, The target on which I am trying to run tests from LAVA has # prompt after login. As specified in Documentation https://lava.collabora.co.uk/static/docs/v2/actions-boot.html?highlight=pro… - boot: prompts: # escape the brackets to ensure that the prompt does not match # kernel debug lines which may mention initramfs - '$initramfs$' in the job definition I am including - boot: ..... failure_retry: 4 prompts: - '$# $' But in the job execution log getting "*auto-login-action: Wait for prompt ['\$# \$', 'Login incorrect', 'Login timed out'] (timeout 00:07:52)*". Also if we want to debug while running the job which will be the best possible approach to follow. In the Documentation got information on "Debugging Django issues" which states two settings are required in/etc/lava-server/settings.conf - "DEBUG": true, - "USE_DEBUG_TOOLBAR": true, Thanks, Hemanth.

5 years, 11 months

2
2
0 0

Re: [Lava-users] overlay-unpack timeout error

by Remi Duraffort

Hello Denis, in the timeouts dictionary, you can specify a connections dictionary. So something like this should work: timeouts: connections: overlay-unpack: minutes: 10 See https://docs.lavasoftware.org/lava/actions-timeout.html#connection-timeout Le mer. 24 juil. 2019 à 14:30, Denis HUMEAU <denis.humeau(a)st.com> a écrit : > Hi Rémi, > > > > Where do you set a connection timeout? In the job, in the device > description? > > I didn’t find anything explicit in LAVA help. > > > > Denis > > > > *From:* Remi Duraffort <remi.duraffort(a)linaro.org> > *Sent:* mercredi 24 juillet 2019 14:23 > *To:* Denis HUMEAU <denis.humeau(a)st.com> > *Cc:* Lava-users(a)lists.lavasoftware.org > *Subject:* Re: [Lava-users] overlay-unpack timeout error > > > > Hello Denis, > > > > have you tried settings the connection timeout? IIRC lava is expecting the > board to send something and will timeout if not receiving anything during > "connection timeout" seconds. > > > > > > Rgds > > > > Le mar. 23 juil. 2019 à 08:58, Denis HUMEAU <denis.humeau(a)st.com> a > écrit : > > Hello Rémi, > > > > Here is a plain log corresponding to the case described by Philippe. > > Let me know if you need more. > > > > Denis > > > > *From:* Lava-users <lava-users-bounces(a)lists.lavasoftware.org> *On Behalf > Of *Remi Duraffort > *Sent:* lundi 22 juillet 2019 17:42 > *To:* Philippe BEGNIC <philippe.begnic(a)st.com> > *Cc:* Lava-users(a)lists.lavasoftware.org > *Subject:* Re: [Lava-users] overlay-unpack timeout error > > > > Hello Philippe, > > > > could you send the raw logs? > > > > > > Rgds > > > > Le ven. 19 juil. 2019 à 09:34, Philippe BEGNIC <philippe.begnic(a)st.com> a > écrit : > > Hello everyone, > > > > > > I have got an error in a lava job during to overlay unpacking operations. > > > > This happen with jobs that flash the DUT before executing the tests. When the partitions are flashed on the DUT, I reboot the boards. > > > > After kernel has started, the kernel boot prompt is detected. Then the commands to downloads the tests overlay are launched. ( wget ... ) > > But in my case, these commands are not immediately executed, because the DUT is beeing resizing the root filesystem to fit available disk space > > on the SDCard. > > > > This operation take time ( depending on capacity and characteristics of the SDCard), and cause overlay-unpack <https://citools.st.com/results/testcase/2039053> to fail with a timeout error, > > because the command wget is not executed in the expected time ( 30 sec is the default time ). > > > > I have tried to add a time out settings in the transfer_overlay part of my jobs, but this has no effect. > > > > > > Is it possible to set specific "timeout trigger" for the "overlay-unpack" operation ? > > > > My Lava version: *2019.01+stretch* > > > > Best regards > > > > Philippe Begnic > > STMicroelectronics > > > > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.lavasoftware.org > https://lists.lavasoftware.org/mailman/listinfo/lava-users > > > > > -- > > Rémi Duraffort > > LAVA Team, Linaro > > > > > -- > > Rémi Duraffort > > LAVA Team, Linaro > -- Rémi Duraffort LAVA Team, Linaro

5 years, 11 months

1
0
0 0

repeat blocks

by Pete Dyer

Hi, I'm trying to write a test definition that contains a repeat block (boot / test) as described in the help section. However the repeat block gives me the syntax error: "Invalid definition: extra keys not allowed @ data['actions'][2]['repeat']" I then tried using https://git.lavasoftware.org/lava/lava/blob/master/lava_dispatcher/tests/sa… as an example and I get the same error message with the repeat. Is this something that is expected to work? I would like to use repeat blocks for some soak tests that I am writing. Pete IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 11 months

2
1
0 0

systemd-boot support

by Hemanth K V

Hello Lava-users, In lava do we have support of booting x86 target boards which has systemd-boot as bootloader. Thanks, Hemanth.

5 years, 11 months

2
1
0 0

login sent on 'prompt' reception instead of 'login_prompt'

by Jerome BESNARD

Hello, I am working with Denis HUMEAU for STMicroelectronics. I have a problem to perform several reboot with LAVA job when I am using an image with requested login. I do not understand why 'root' login is sent to device under test when the prompt is received (lines 941, 942, 943, 944 in job_43624.log file). 'root' login should be sent only when a 'login_prompt' is received (like in lines 696, 697, 698, 699, 701, 702 in job_43624.log file). Could you help me to solve this problem, please ? Regards, [Description: Description: Description: Description: Description: Description: logo_big5] Jerome BESNARD | TINA: 166 7142 | Tel: +33 (0)244027142 | Mobile: +33 (0)623392912 MDG | SW Validation Ingineer

5 years, 11 months

3
6
0 0

Accessing DUTs for hacking sessions from an external network

by Tim Jaacks

Hello everyone, I have the following LAVA setup: LAVA server - 1 LAVA worker - 16 DUTs The LAVA server and the LAVA worker are located in my company network (172.20.0.0/16). The DUTs are connected to the LAVA worker in a local network (192.168.20.0/24). Thus, the DUTs are not accessible from outside the worker. What is a good way to allow for hacking sessions to a DUT (let's say 192.168.20.247) from the company network? I can think of the following solutions: 1. Use SSH forwarding on lava-worker: ssh -g -L 50000:localhost:22 -N root(a)192.168.20.247 2. Forward the SSH port via netcat on lava-worker: nc -l -p 50000 -c "nc 192.168.20.247 22" 3. Forward the SSH port via iptables on lava-worker: iptables -t nat -A PREROUTING -p tcp --dport 50000 -j DNAT --to 192.168.20.247:22 All of these make the device accessible via "ssh -p 50000 root@lava-worker" from the company network. So far, so good. However, in an ideal world this forwarding would be active only during the hacking session, so that in normal test jobs the DUT is not accessible. Is there a way to achieve this? Does anyone have experience with such a scenario? How do you handle DUT access for hacking sessions? 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 WE MAKE IT YOURS! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun

5 years, 11 months

1
0
0 0

Help needed with gateway and sensors testing

by Diego Russo

Hello LAVA experts, I need your help for a more complex test we would need to run. We'd like to test a gateway node that talks to remote sensors. * the gateway node is a Cortex-A like (E.g.: RPi3) board * sensors might be a mixture of Cortex-M (non-Linux) and Cortex-A (Linux) devices * communication between the gateway node and sensors might happen with different protocols: bluetooth, wifi, lora, zigbee. * besides the gateway node, we need to control every sensor and be able to provision and to power cycle them. We are pretty confident on running tests on single boards (with and without interaction with LXC containers) but as the above example is more complex we need some guidance on how this can be achieved with LAVA. The main question mark we have is how LAVA interacts with Cortex-M devices, especially for their deployment. Does anyone of you have a similar scenario? What are the main challenges? How complicated and/or robust to run something similar with LAVA? Can you point us to documentation, examples? Any help is very much appreciated. Thanks! -- Diego Russo | Staff Software Engineer | Mbed Linux OS ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - https://os.mbed.com/linux-os/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 11 months

2
2
0 0

Expected failures

by Pete Dyer

Hello, We have some tests that are currently expected to fail, and should then become passes once the implementation of the feature is complete. Is this something LAVA results can support? As far as I can see the result can be pass/fail/skip (and possibly unknown). Suggestions welcome. Thanks. Pete IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 11 months

2
1
0 0

External worker devices in LXC / connection to DUTs

by Tim Jaacks

Hello, we are trying to add external interfaces on the worker to connect with the DUTs, for example a 4-port USB-to-RS232 converter. Our DUTs have multiple RS232 ports which shall be tested using this remote interface. We have already figured out how to integrate this hardware into the LAVA environment, so that it can be used within the LAVA LXC (using static_info in the device dictionary, resulting in the four /dev/ttyUSB* devices being visible there). First question: We need multiple of these converters attached to the worker. How do we integrate these into LAVA? They all have the same board_id, vendor_id and product_id. If I specify the board_id in the device dictionary multiple times, the device is still added only once. Second question: We need a way to specify to which of the /dev/ttyUSB* ports a certain RS232 port of the DUT is connected. The place where I would assume to put such information is the device dictionary. But how can we access this information within a LAVA test shell? The documentation specifies some similar mechanism for energy probes: https://validation.linaro.org/static/docs/v2/admin-lxc-deploy.html?highligh… It says "Devices which are not directly attached to the worker can also be supported, for example energy probes which communicate over the network". As far as I can tell from the code, though, this seems to be a hard-coded feature without any possibility of adding other custom hardware. Is that correct? If yes, why isn't there a generic mechanism to supply static_info from the device dictionary in the LAVA test shell? Or is there? How can we implement our scenario described above using LAVA? 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 WE MAKE IT YOURS! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun

5 years, 12 months

2
4
0 0

query to retrieve Lava errors

by Denis HUMEAU

After getting stats on my setup robustness, the step forward is have a complete view on the lava errors we meet in incomplete jobs. >From what I see in incomplete jobs, my intention is to query on test suite lava and the name "job". In the query builder, if I use test suite as condition model, I can't use the job field name. Do you have any advice on how to proceed? Denis

6 years

3
5
0 0

adb device lost during cts/vts

by Axel Lebourhis

Hi all, I'm facing a pretty frustrating issue when running CTS/VTS with LAVA. I'm using Linaro's tradefed test definition : https://git.linaro.org/qa/test-definitions.git/tree/automated/android/trade… During some runs, the adb connection is lost, leading to incomplete test job. Do you know if this behavior is known and mostly general ? Or is it a bad configuration on my side ? Maybe someone knows some way to keep a reliable adb connection to the target ? Best regards, Axel

6 years

3
3
0 0

What's the difference of lava log feedback & log output on the web page?

by Larry Shen

Sometimes, I can see the lava log feedback to repeat the the lava log output, sometimes cannot. Could you give an example simple inline test, so I can always see some log feedback? Something like: - test: timeout: minutes: 1 definitions: - from: inline name: smoke-case path: inline/test.yaml repository: metadata: format: Lava-Test Test Definition 1.0 name: smoke-case-run description: Run smoke case run: steps: - lava-test-case "Case_001" --shell 'echo "Case001 gstreamer ok";' How could I let ` Case001 gstreamer ok` also been seen in feedback log level?

6 years

2
1
0 0

lava-test-case only handles lower case results strings

by Patryk Mungai Ndungu

Hello, I have recently upgraded from 2018.11 to 2019.03 and have noticed that the results of a lot of the tests I have been running no longer got parsed correctly by LAVA. This was because I was sending the results using upper case results strings. Eg. lava-test-case <test-case> PASS opposed to lava-test-case <test-case> pass This resulted in the following logs in the lava job: Received signal: <TESTCASE> TEST_CASE_ID=ETH_T_001 RESULT=PASS Bad test result: PASS Changing my results parsing script to only send lower case results strings fixed the issue, but was this restriction intended with the upgrade? Kind Regards, Patryk

6 years

3
6
0 0

password change prompt: how to automate?

by Diego Russo

Hello, I have a system that as soon as LAVA logins, it requires the password to be changed (the password needs to be typed twice). Is there an easy way to automate it using LAVA? Cheers -- Diego Russo | Staff Software Engineer | Mbed Linux OS ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - https://os.mbed.com/linux-os/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years

2
3
0 0

Error: "deploy stage is missing" in multinode job

by Axel Lebourhis

Hi all, I'm currently trying to make a multinode job for CTS on Android 9. During this job, I need to unlock uboot so I use the "interactive" test action. But when I add it to my job definition, I get an error message during the run : "Nothing to run. Maybe the 'deploy' stage is missing, otherwise this is a bug which should be reported." If I remove the test action with the "interactive" method, I won't get that error. Maybe I'm missing something but I don't get what it could be. You will find attached a test job example which leads to this error. Best regards, Axel

6 years

2
4
0 0

timeouts for deploy vs http-download

by Kevin Hilman

Hello, I'm trying to customize the http-download timeout as documented[1], but I doesn't seem to work. The global deploy time always seems to win. Based on the doc, I did this, I added the following to my job[2] timeouts: actions: http-download: minutes: 15 However, in the job output, you can see that the http-download timeout value is set to 25 min (1500 sec) which is coming from the deploy action timeout. I got the same result when tryin to use timeouts: connections: What am I missing? Kevin [1] https://validation.linaro.org/static/docs/v2/timeouts.html?highlight=http_d… [2] https://lava.automotivelinux.org/scheduler/job/3270/definition#defline44 [3] https://lava.automotivelinux.org/scheduler/job/3270#action_1-1-1

6 years

4
8
0 0

Re: [Lava-users] Why make the decision to limit job context in lava master?

by Larry Shen

Thanks, Remi, So, looking forward to your patch which allow admins to extend the white list with a variable in the settings. Regards, Larry From: Remi Duraffort <remi.duraffort(a)linaro.org> Sent: Thursday, May 23, 2019 3:59 PM To: Larry Shen <larry.shen(a)nxp.com> Cc: lava-users(a)lists.lavasoftware.org Subject: [EXT] Re: [Lava-users] Why make the decision to limit job context in lava master? Caution: EXT Email Hello Larry, 1. We mainly have 2 kinds of situations: a) Something like "uboot_ums_flash" which already in linaro lava tree. In the past, this can be overridden by job context. And I guess a lots of other variables which spread every corner of different jinja2 files. Huge I think, I really worried how lava can add so many keys in whitelist... Why do you have to update uboot_ums_flash in the job definition and not in the device dictionary? This sounds more like a device specific information instead of a job definition one. Anyway, having a long list of keys in the white list is not really a problem. This is only a python array, nothing more. b) Something which just used in device jinja2 to control some different command in different situations. I know linaro accept upstreams for device-type, I have no idea if private lab's device jinja2 also useful for other people. Contributions are welcome. A rule of thumb for device-type integration/templates is often: is the device available for purchase by someone outside your company? If yes, then it's a good idea to upstream it. If not, then it's more a case-by-case decision. 2. Sounds you guys will not rollback this commit because security issue. So two suggestions: Sorry no :( a) I don't know how this security issue could impact for an internal lab which not exposed to external internet. Anyway, if possible to add a configure to any settings to let admin to decide if we care this security issue? More details to come later on, but I don't think this is a good idea. b) If a) not easy to do or not accept, if possible this whitelist be stored in database or other persist file, so user can free to add his own keyword to whitelist, then even we will upgrade lava to later new version, we can still remain the keyword setting in the past, meanwhile user still can free to add any keyword to whitelist without upstream again and again for this hard coded whitelist, I don't think this make sense. I'm currently writing down a patch to allow admins to extend the white list with a variable in the settings. Please consider. BTW, as Tim Jaacks said in other thread: this limit not happen in multinode job, is it a bug, so next release we will also have this backdoor closed? I'm fixing this second issue in https://git.lavasoftware.org/lava/lava/merge_requests/547<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.lavas…> Thanks for reporting it. Rgds -- Rémi Duraffort LAVA Team, Linaro

6 years, 1 month

2
1
0 0

auto_login and minimal boot

by Diego Russo

Hello, In my job definition I have a minimal boot: https://staging.validation.linaro.org/static/docs/v2/actions-boot.html?high… Documentation says "auto-login and transfer_overlay are both supported for this method." But if I add auto_login the schema validation in the submit page will raise a warning: "Valid definition with warnings: extra keys not allowed @ data['actions']['boot']['minimal']" Of course if I take the auto_login out, the validation is green. If I leave the auto_login, it will be used. I think the validation needs to reflect what documentation says. Cheers -- Diego Russo | Staff Software Engineer | Mbed Linux OS ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - https://os.mbed.com/linux-os/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 1 month

2
2
0 0

Re: [Lava-users] Why make the decision to limit job context in lava master?

by Larry Shen

Thanks, Remi, 1. We mainly have 2 kinds of situations: a) Something like "uboot_ums_flash" which already in linaro lava tree. In the past, this can be overridden by job context. And I guess a lots of other variables which spread every corner of different jinja2 files. Huge I think, I really worried how lava can add so many keys in whitelist... b) Something which just used in device jinja2 to control some different command in different situations. I know linaro accept upstreams for device-type, I have no idea if private lab's device jinja2 also useful for other people. 2. Sounds you guys will not rollback this commit because security issue. So two suggestions: a) I don't know how this security issue could impact for an internal lab which not exposed to external internet. Anyway, if possible to add a configure to any settings to let admin to decide if we care this security issue? b) If a) not easy to do or not accept, if possible this whitelist be stored in database or other persist file, so user can free to add his own keyword to whitelist, then even we will upgrade lava to later new version, we can still remain the keyword setting in the past, meanwhile user still can free to add any keyword to whitelist without upstream again and again for this hard coded whitelist, I don't think this make sense. Please consider. BTW, as Tim Jaacks said in other thread: this limit not happen in multinode job, is it a bug, so next release we will also have this backdoor closed? Regards, Larry -----Original Message----- From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> On Behalf Of lava-users-request(a)lists.lavasoftware.org Sent: Tuesday, May 21, 2019 11:13 PM To: lava-users(a)lists.lavasoftware.org Subject: [EXT] Lava-users Digest, Vol 9, Issue 19 Caution: EXT Email Send Lava-users mailing list submissions to lava-users(a)lists.lavasoftware.org To subscribe or unsubscribe via the World Wide Web, visit https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lav… or, via email, send a message with subject or body 'help' to lava-users-request(a)lists.lavasoftware.org You can reach the person managing the list at lava-users-owner(a)lists.lavasoftware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Lava-users digest..." Today's Topics: 1. Re: Why make the decision to limit job context in lava master? (Remi Duraffort) 2. Re: timeouts for deploy vs http-download (Remi Duraffort) 3. Re: Using transfer overlay (Pete Dyer) ---------------------------------------------------------------------- Message: 1 Date: Tue, 21 May 2019 17:02:35 +0200 From: Remi Duraffort <remi.duraffort(a)linaro.org> To: lava-users <lava-users(a)lists.lavasoftware.org> Subject: Re: [Lava-users] Why make the decision to limit job context in lava master? Message-ID: <CANJfhHeXiuVi02dMfmzeQ5EjnP=SqDymDNoyfwDB2XNN8ckodg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello, we had to enforce the content of the context dictionary in order to fix a security issue that we found recently. The full details of the security issue will be disclosed when a CVE is available. We know that this is annoying for many people so we tried to collect all the valid use cases before the previous release. Which variables are you setting in the context? Is the corresponding code upstreamed? Cheers Le lun. 20 mai 2019 à 10:49, cnspring2002 <cnspring2002(a)aliyun.com> a écrit : > +1, we also have same issue, had to pending new version deploy. > > Message: 1 > Date: Mon, 20 May 2019 05:39:40 +0000 > From: Larry Shen <larry.shen(a)nxp.com> > To: "lava-users(a)lists.lavasoftware.org" > <lava-users(a)lists.lavasoftware.org> > Subject: [Lava-users] Why make the decision to limit job context in > lava master? > Message-ID: > < > DBBPR04MB63291E1DC4F5F202DEDFE16699060(a)DBBPR04MB6329.eurprd04.prod.out > look.com > > > > Content-Type: text/plain; charset="utf-8" > > For 2019.04 version, we see next: > > Job context > ----------- > > > The schema validator is now checking the content of the `context` dictionary. Only the following keys are now allowed: > > > * `arch`, `boot_console`, `boot_root`, `cpu`, `extra_options`, > `guestfs_driveid`, `guestfs_interface`, `guestfs_size`, `machine`, > `memory`, `model`, `monitor`, `netdevice`, `serial`, `vga` > > * `bootloader_prompt`, `console_device`, `extra_kernel_args`, > `extra_nfsroot_args`, `kernel_loglevel`, `kernel_start_message`, > `lava_test_results_dir`, `menu_interrupt_prompt`, `mustang_menu_list`, > `test_character_delay`, `tftp_mac_address` > > Jobs using keys that are not listed in this list will be rejected. > > > We usually set an customized context in job, and in device-type jinja2, use this context to just different value to set proper parameters. > After this limit, all things break! > > So, my question is: > > > lava could be designed to as a framework to give freedom to users to do their things as in the past, why we now enhance so many limits to users? > And additional, and workaround for my scenario? > > Regards, > Larry > > > > > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.lavasoftware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.lavasoftware.org%2Fmailman%2Flistinfo%2Flava-users&data=02%7C01% > 7Clarry.shen%40nxp.com%7C2ebbb071596f41c8816208d6ddfee338%7C686ea1d3bc > 2b4c6fa92cd99c5c301635%7C0%7C0%7C636940484145033600&sdata=cpnWI8y6 > NzawoUy%2BOtunqchIyXsaHO0ryYzPyJf3Gw0%3D&reserved=0 -- Rémi Duraffort LAVA Team, Linaro

6 years, 1 month

2
1
0 0

Using transfer overlay

by Pete Dyer

Hello, I'm using transfer overlay to get a set of tests onto the target. However I want to untar it into /scratch instead of / because of storage requirements. This I can do quite easily. However the tests are going to try to run from / (e.g. /lava-10473/bin/lava-test-runner /lava-10473/1) Is there a way of running tests from /scratch/lava-10473.... ? Or a way of defining a command to run immediately after the transfer overlay that makes a link between /lava-10473 and /scratch/lava-10473 ? Thanks. Pete IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 1 month

4
7
0 0

Re: [Lava-users] Why make the decision to limit job context in lava master?

by cnspring2002

+1, we also have same issue, had to pending new version deploy. Message: 1 Date: Mon, 20 May 2019 05:39:40 +0000 From: Larry Shen <larry.shen(a)nxp.com> To: "lava-users(a)lists.lavasoftware.org" <lava-users(a)lists.lavasoftware.org> Subject: [Lava-users] Why make the decision to limit job context in lava master? Message-ID: <DBBPR04MB63291E1DC4F5F202DEDFE16699060(a)DBBPR04MB6329.eurprd04.prod.outlook.com> Content-Type: text/plain; charset="utf-8" For 2019.04 version, we see next: Job context ----------- The schema validator is now checking the content of the `context` dictionary. Only the following keys are now allowed: * `arch`, `boot_console`, `boot_root`, `cpu`, `extra_options`, `guestfs_driveid`, `guestfs_interface`, `guestfs_size`, `machine`, `memory`, `model`, `monitor`, `netdevice`, `serial`, `vga` * `bootloader_prompt`, `console_device`, `extra_kernel_args`, `extra_nfsroot_args`, `kernel_loglevel`, `kernel_start_message`, `lava_test_results_dir`, `menu_interrupt_prompt`, `mustang_menu_list`, `test_character_delay`, `tftp_mac_address` Jobs using keys that are not listed in this list will be rejected. We usually set an customized context in job, and in device-type jinja2, use this context to just different value to set proper parameters. After this limit, all things break! So, my question is: lava could be designed to as a framework to give freedom to users to do their things as in the past, why we now enhance so many limits to users? And additional, and workaround for my scenario? Regards, Larry

6 years, 1 month

2
1
0 0

Problems with email notifications

by Frank, Matthias

Hi lava-users, my Debian machine running lava-server (2019.04) sends mails via msmtp/msmtp-mta. Mails from cron or apt work fine. But I got no mails from lava. Even when I submit a test job with a notify statement. notify: criteria: status: finished recipients: - to: method: email user: default verbosity: verbose The user default uses my real mail address not a system mail address. This is the Django log: INFO 2019-05-10 07:18:15,546 notifications [1343] sending email notification to XXXXXXX(a)YYYYYY.com ERROR 2019-05-10 07:18:15,557 notifications [Errno 99] Cannot assign requested address Traceback (most recent call last): File "/usr/lib/python3/dist-packages/lava_scheduler_app/notifications.py", line 303, in send_notifications title, body, settings.SERVER_EMAIL, [recipient.email_address] File "/usr/lib/python3/dist-packages/django/core/mail/__init__.py", line 62, in send_mail return mail.send() File "/usr/lib/python3/dist-packages/django/core/mail/message.py", line 348, in send return self.get_connection(fail_silently).send_messages([self]) File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py", line 104, in send_messages new_conn_created = self.open() File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py", line 64, in open self.connection = self.connection_class(self.host, self.port, **connection_params) File "/usr/lib/python3.5/smtplib.py", line 251, in __init__ (code, msg) = self.connect(host, port) File "/usr/lib/python3.5/smtplib.py", line 335, in connect self.sock = self._get_socket(host, port, self.timeout) File "/usr/lib/python3.5/smtplib.py", line 306, in _get_socket self.source_address) File "/usr/lib/python3.5/socket.py", line 712, in create_connection raise err File "/usr/lib/python3.5/socket.py", line 703, in create_connection sock.connect(sa) OSError: [Errno 99] Cannot assign requested address WARNING 2019-05-10 07:18:15,558 notifications [1343] failed to send email notification to XXXXXXX(a)YYYYYY.com Lava has a problem with smtp. Is it necessary to have a complete smtp server on the local machine? Or is there a special smtp configuration? Greetings, Matthias

6 years, 1 month

2
3
0 0

Why make the decision to limit job context in lava master?

by Larry Shen

For 2019.04 version, we see next: Job context ----------- The schema validator is now checking the content of the `context` dictionary. Only the following keys are now allowed: * `arch`, `boot_console`, `boot_root`, `cpu`, `extra_options`, `guestfs_driveid`, `guestfs_interface`, `guestfs_size`, `machine`, `memory`, `model`, `monitor`, `netdevice`, `serial`, `vga` * `bootloader_prompt`, `console_device`, `extra_kernel_args`, `extra_nfsroot_args`, `kernel_loglevel`, `kernel_start_message`, `lava_test_results_dir`, `menu_interrupt_prompt`, `mustang_menu_list`, `test_character_delay`, `tftp_mac_address` Jobs using keys that are not listed in this list will be rejected. We usually set an customized context in job, and in device-type jinja2, use this context to just different value to set proper parameters. After this limit, all things break! So, my question is: lava could be designed to as a framework to give freedom to users to do their things as in the past, why we now enhance so many limits to users? And additional, and workaround for my scenario? Regards, Larry

6 years, 1 month

2
1
0 0

Board use rate in Lava?

by Denis HUMEAU

Dear users, I'd like to add metrics to scale my test farm. Basically I would like to check the occupation rate of the active boards in my farm, to be able to decide whether I need to add extra ones or not. Do you know if there is a simple way to do it? Best regards, Denis

6 years, 1 month

2
1
0 0

lxc test error

by jack lu

Hi, In my lava environment (debian 9.5 stretch, lava version:2019.04+stretch).When run a simple lxc test job.It happend a error: <http://192.168.101.205/scheduler/job/8#L83>Lxc container rootfs not found .. <http://192.168.101.205/scheduler/job/8#L101>LAVABug: This is probably a bug in LAVA, please report it. job definition is a simple lxc job from lava document: device_type: lxcjob_name: lxc-fedoratimeouts: job: minutes: 30 action: minutes: 5priority: mediumvisibility: public metadata: source: https://git.linaro.org/lava-team/refactoring.git path: lxc-fedora.yaml protocols: lava-lxc: name: pipeline-lxc-test distribution: fedora release: '26' arch: amd64 actions:- deploy: timeout: minutes: 30 to: lxc - boot: prompts: - '[root(a)(.*) /]#' timeout: minutes: 5 method: lxc - test: timeout: minutes: 5 definitions: - repository: http://git.linaro.org/lava-team/lava-functional-tests.git from: git path: lava-test-shell/smoke-tests-basic.yaml name: smoke-tests

6 years, 1 month

1
0
0 0

about multinode api parameter file overwritten

by jack lu

The multinode function of "pass data between devices".Note: "The message data is stored in a cache file which will be overwritten when the next synchronisation call is made. Ensure that your scripts make use of (or copy aside) any MultiNode cache data before calling any other MultiNode API helpers that may clear the cache." Does it mean follow example: roler1: .. steps: - lava-send ipv4 ip=192 - lava-send ipv4 ip=193 .. roler2: step2: - lava-wait ipv4 - ipdata=$(cat /tmp/lava_multi_node_cache.txt | cut -d = -f 2) .. After run, is content of roler2 ipdata 193?

6 years, 1 month

2
6
0 0

How to handle udev events when lava dispatcher is in a container

by Kumar Gala

In trying to run lava-dispatcher inside a docker container and connect a FRDM-K64F board ran into some issues related to the fact that udev events aren’t seen inside the container since we aren’t typically running systemd/udevd there. I came across this project that will forward udev events from the host to a container that worked pretty well: https://github.com/eiz/udevfw I’ve re-implemented this in python for easier development (added some docker awareness): https://git.lavasoftware.org/galak/docker-compose/blob/lite/contrib/udev-fo… Right now running udev-forward.py is kinda kludgy. Wanted to get input on how people think this should work, should we make a daemon out of it? Should there be some kinda of config file? Do we think we need to filter events (and if so how)? Need to look at support for multicasting (support sending to multiple dispatchers). Where should this live, in docker-compose repo? Other thoughts. - k

6 years, 1 month

1
1
0 0

lavacli device-type template set: Permission denied

by Kevin Hilman

Hello, I have a remote worker that needs to add a new device-type on the master. The remote worker has an auth token with admin/staff/superuser privileges, and lavacli configured with that token, but when I attempt to set the new template, I get permission denied: # lavacli device-types template set da850-lcdk /tmp/new-device-type.jinja2 Unable to call 'device-types.template': <Fault 400: 'Unable to write device-type configuration: Permission denied'> What permissions am I missing? Kevin

6 years, 1 month

2
1
0 0

Re: [Lava-users] [EXT] can LAVA support Python?

by White Weng

We have an internal automation framework supports Python, and would like to migrate to LAVA. can LAVA support Python? Thanks White Weng

6 years, 1 month

2
1
0 0

Issue with 2019.04 containers and static/docs/v2/

by Dan Rue

Hi! I'm seeing the following issue with lavasoftware/lava-server:2019.04: http://localhost/static/docs/v2/ gives "Forbidden". Apache log shows the following: [Mon May 06 17:57:42.206713 2019] [autoindex:error] [pid 766:tid 140404225701632] [client 172.18.0.1:46780] AH01276: Cannot serve directory /usr/share/lava-server/static/docs/v2/: No matching DirectoryIndex (index.html,index.cgi,index.pl,index.php,index.xhtml,index.htm) found, and server-generated directory index forbidden by Options directive, referer: http://localhost/ The easiest way to reproduce is to run: $ docker run --rm -p 80:80 -it lavasoftware/lava-server:2019.04 And load http://localhost/static/docs/v2/ Change 2019.04 to 2019.03 and it works fine. I didn't see anything about this mentioned in the release announcement. I guess the apache config needs some update? Thanks! Dan

6 years, 1 month

2
5
0 0

[PATCH] doc/v2/timeouts: fix http-download action name typos

by Kevin Hilman

The name of the action for http download uses a hyphen, not an underscore. Fix the typos. Signed-off-by: Kevin Hilman <khilman(a)baylibre.com> --- doc/v2/timeouts.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/v2/timeouts.rst b/doc/v2/timeouts.rst index c330f9d89548..50070766abe0 100644 --- a/doc/v2/timeouts.rst +++ b/doc/v2/timeouts.rst @@ -259,7 +259,7 @@ block override. timeouts: actions: - http_download: + http-download: minutes: 2 .. _individual_connection_timeout_overrides: @@ -275,7 +275,7 @@ specific connection timeout which can be longer or shorter than the default. timeouts: connections: - http_download: + http-download: minutes: 2 .. _action_block_timeout_overrides: -- 2.21.0

6 years, 1 month

2
4
0 0

Current LAVA version in stretch-backports

by Tim Jaacks

Hello everyone, the current LAVA version in stretch-backports is still 2018-11. Is there a reason why it has not been updated since then? Will newer releases go into buster only? Or will there be updates in stretch-backports in the future? For stretch users, do you recommend using the LAVA repositories to upgrade to the latest version? Or should production systems keep using 2018-11 at this moment? 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<http://www.garz-fricke.com/> WE MAKE IT YOURS! [cid:image001.jpg@01D4FF4A.A2ED9910] Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun

6 years, 1 month

2
1
0 0

Re: [Lava-users] Handling of a kernel panic

by Remi Duraffort

Hello, as said in the previous email, that's currently not possible to see kernel crashes outside of the boot action. That's something we want to improve. I will soon create an issue in our gitlab instance where you would be able to comment. Rgds Le jeu. 11 avr. 2019 à 14:33, Frank, Matthias <Matthias.Frank(a)tq-group.com> > a écrit : > > Hi lava users, > > > > sometimes I how in memory allocator stress tests a kernel panic. How can I > evaluate this? Is it possible to set a testcase or job to fail if a kernel > panic occurs? > > > > Matthias > > > > Sometimes a test triggers a kernel panic and the dut will reboot to U-Boot > and stuck because there is no boot process. Lava waits until timeout and > stop the job. > > > -- Rémi Duraffort LAVA Team, Linaro

6 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users