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

by Ilya Fedusiv

Is it possible to change directory on device of overlay and all LAVA stuff for example to /tmp/ ? By default now it is / Ilya

6 years, 7 months

2
5
0 0

Sending information containing whitespaces with lava-send

by Tim Jaacks

Hello everyone, I am trying to send some information containing whitespaces via lava-send. Obviously this is not supported. Is this a bug or by design? I tried the following command: lava-send my-message my-variable="some string with whitespaces" Which produces the following output: <LAVA_SEND_DEBUG lava_multi_node_send preparing Tue Aug 27 15:02:41 CEST 2019> <LAVA_SEND_DEBUG _lava_multi_node_send started Tue Aug 27 15:02:41 CEST 2019> <LAVA_MULTI_NODE> <LAVA_SEND my-message my-variable=some> <LAVA_SEND_DEBUG _lava_multi_node_send finished Tue Aug 27 15:02:41 CEST 2019> <LAVA_SEND_DEBUG lava_multi_node_send finished Tue Aug 27 15:02:41 CEST 2019> Received Multi_Node API <LAVA_SEND> messageID: SEND-my-message lava-multinode lava-send 1 key value pair(s) to be sent. Handling signal <LAVA_SEND {"timeout": 360, "request": "lava_send", "messageID": "my-message", "message": {"my-variable": "some"}}> So obviously the string is truncated on the first whitespace. Is there any possibility to send a string containing whitespaces to another node? 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

6 years, 7 months

2
3
0 0

Test commands

by Ilya Fedusiv

# root@device:~# # lava-test-shell: Wait for prompt ['root@device:~#'] (timeout 00:05:00) # Using /lava-133 export SHELL=/bin/bash root@device:~# export SHELL=/bin/bash export SHELL=/bin/bash . /lava-133/environment root@device:~# . /lava-133/environment . /lava-133/environment -sh: .: can't open '/lava-133/environment' Will listen to feedbacks from 'tlxc' for 1 second /lava-133/bin/lava-test-runner /lava-133/0 root@device:~# /lava-133/bin/lava-test-runner /lava-133/0 Test shell timeout: 10s (minimum of the action and connection timeout) /lava-133/bin/lava-test-runner /lava-133/0 -sh: /lava-133/bin/lava-test-runner: not found Device is successfully booted and logged in. But I cant run any commands. Why lava running this command? : . /lava-133/environment And how it downloads to device. Ilya

6 years, 7 months

2
1
0 0

Fastboot reboot-bootloader

by Ilya Fedusiv

Hi! Lava as default at beginning runs that command: nice fastboot -s 261a1c5d reboot-bootloader Is it possible to avoid this step? Dont run this command Ilya

6 years, 7 months

2
15
0 0

Re: [Lava-users] Server returning wrong job id

by Fabiano Ferronato

Hi Milosz, Please take a look at the first message of this thread. There are 2 different information for this error. First, this COMMA error happens when I'm trying to access the URL (LAVA WebU), manually inserting the job_id in a browser, and not through the code. Second, the previous code is returning: lavac.server.NoSuchJob: No such job: 68271.0 Even though this job_id is been returned by the LAVA server. Thanks Em seg, 2 de set de 2019 às 11:32, Milosz Wasilewski < milosz.wasilewski(a)linaro.org> escreveu: > On Mon, 2 Sep 2019 at 10:26, Fabiano Ferronato <fabiferro(a)hotmail.com> > wrote: > > > > Hi Milosz, > > > > I still couldn't update the server but, just to clarify, the mentioned > job pasted in URL is 68271.0 as we can see in the error message: > > > > URL : http://lava.server.net/scheduler/job/68271.0 > > > > > Trying to access LAVA WebUI using the jobid (68271.0) > > > > And then some process is translating that jobid into a comma " , " : > > > > > Reverse for 'lava.scheduler.job.detail' with arguments '('',)' not > found. 1 pattern(s) tried: ['scheduler/job/(?P<pk>[0-9]+|[0-9]+\\.[0-9]+)$'] > > > > Otherwise, a really not existent jobid in the URL, let's say 99999.9, > results in "404 Not found". > > > > Here is the job submission code: > > > > try: > > job_id = self._server.scheduler.submit_job(job_data) > > if not isinstance(job_id, list): > > job_id = [job_id] > > return job_id > > > > And than the job_id is used to get job details: > > > > try: > > return self._server.scheduler.job_details(job_id) > > scheduled.job_details expects a string: > https://master.lavasoftware.org/api/help/#scheduler.job_details > > If I understand your code correctly you're passing a list to this > function. Serialized list will contain "," character. > > milosz > > > > > Best Regards, > > Fabiano > > > > Em sex, 23 de ago de 2019 às 16:25, Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> escreveu: > >> > >> I don't think there was a problem with 2018.10 with this feature. > >> Reading the error message I think you pasted "," character in the URL > >> so the pattern didn't match. As you can see in the regex, "." is there > >> and I don't recall any issues with multinode jobs then. Anyway, even > >> if this is a bug it won't be fixed in 2018.10. When you migrate to > >> latest version and you hit the same problem something can be done. > >> > >> If you can post full script you're using I can try on latest master > >> and see what happens. > >> > >> milosz > >> > >> On Fri, 23 Aug 2019 at 13:10, Fabiano Ferronato <fabiferro(a)hotmail.com> > wrote: > >> > > >> > Hi Milosz, thanks for your answer. > >> > > >> > Yes, it is a multinode job. > >> > This is a known bug on version 2018.10? I need to install the new > version and keep pipe lines running until I get the error to answer you. > >> > > >> > Fabiano > >> > > >> > Em qui, 22 de ago de 2019 às 18:58, Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> escreveu: > >> >> > >> >> On Thu, 22 Aug 2019 at 17:30, Fabiano Ferronato < > fabiferro(a)hotmail.com> wrote: > >> >> > > >> >> > Hi, > >> >> > we have a LAVA test setup working for some time. Automated > pipelines are running tests on different devices in parallel. > >> >> > After updating to version 2018.10+stretch and changing to in-line > job definitions we started to get some sporadic errors. > >> >> > > >> >> > The error message shows up after jobs are submitted and the return > from the submission is then used to ask for server job details: > >> >> > > >> >> > res = lava_server.submit_job(lava_test_job_description) > >> >> > for entry in res: > >> >> > job_details = lavasrv.job_details(entry) > >> >> > ... > >> >> > > >> >> > Resulting in the following error: > >> >> > > >> >> > lib/python3.5/site-packages/lavac/server.py", line 272, in > job_details > >> >> > raise get_server_error(error, job_id) > >> >> > lavac.server.NoSuchJob: No such job: 68271.0 > >> >> > >> >> are you submitting a multinode job? Does this also happen in more > >> >> recent version of LAVA (like 2019.07)? > >> >> > >> >> milosz > >> >> > >> >> > > >> >> > > >> >> > Trying to access LAVA WebUI using the jobid (68271.0): > >> >> > > >> >> > 500 Internal Server Error > >> >> > Reverse for 'lava.scheduler.job.detail' with arguments '('',)' not > found. 1 pattern(s) tried: ['scheduler/job/(?P<pk>[0-9]+|[0-9]+\\.[0-9]+)$'] > >> >> > > >> >> > Can you give me a hint about this error? > >> >> > > >> >> > Thanks! > >> >> > > >> >> > _______________________________________________ > >> >> > 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 >

6 years, 7 months

2
1
0 0

Fastboot device Connection

by Ilya Fedusiv

Hi! I'm using lava from debian stretch. I try flash image by fastboot. At that step job just stuck and util timeout of 10 minutes. nice fastboot -s '261a1c5d' flash persist /var/lib/lava/dispatcher/tmp/15/fastboot-deploy-7xj200yq/persist/persist.ext4 If run command from terminal fastboot -s 261a1c5d flash persist /tmp/persist.ext4 device is flashed in 3 seconds It looks like, that LAVA doesnt see my device. Job desc : https://pastebin.com/ZNeS71Ev Device desc: https://pastebin.com/rYRyEnjy Job log : https://pastebin.com/fH0u3bUb I know, that for fastboot better to work with lxc. I also tried with lxc. And it stuck on the same place. Job log with lxc : https://pastebin.com/RnZLNfvN Ilya

6 years, 7 months

2
5
0 0

Lava job with local testcase

by Vladut Magas

Hello, I have a question regarding running a test that I have on my host machine inside a Lava job. Basically, I start Lava and try to submit a job through: Scheduler/Submit The job description looks like this: device_type: qemu job_name: qemu amd64 LTP timeouts: job: minutes: 120 action: minutes: 120 connection: minutes: 120 priority: medium visibility: public metadata: source: https://ci.linaro.org/view/lava-ci/job/lava-debian-stable-amd64-vm/ path: https://git.linaro.org/ci/job/configs.git/blob/HEAD:/lava-debian-stable-amd… build-readme: https://images.validation.linaro.org/snapshots.linaro.org/components/lava/s… build-console: https://ci.linaro.org/view/lava-ci/job/lava-debian-stable-amd64-vm/console build-log: http://images.validation.linaro.org/snapshots.linaro.org/components/lava/st… # CONTEXT_BLOCK context: arch: amd64 # ACTIONS_BLOCK actions: - deploy: timeout: minutes: 120 to: tmpfs images: rootfs: image_arg: -drive format=raw,file={rootfs} url: https://images.validation.linaro.org/snapshots.linaro.org/components/lava/s… sha256sum: 4ab50cc69fc61faa9bf48edada8bc1a317247f77ced5a815f40e75cef1d62cc7 compression: gz # BOOT_BLOCK - boot: method: qemu media: tmpfs timeout: minutes: 120 prompts: - "root@debian:" auto_login: login_prompt: "login:" username: root - test: timeout: minutes: 120 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: apache-server description: "server installation" os: - debian scope: - functional run: steps: Here I would like to have my test.Something like: - make - ./home/user/folder/mytest from: inline name: apache-server path: inline/apache-server.yaml Can you maybe give me a short example on how to do that? I tried using the "inline" keyword, but to no avail. Best regards, Emanuel-Vladut Magas L4B Software, Iasi, Romania E-mail: vladut.m(a)l4b-software.com [cid:37eb12b3-1085-46f2-8e9a-e636f5edc7d8]

6 years, 7 months

2
1
0 0

Test Job bulk canceling from admin does not work in 2019.09

by Stevan Radakovic

We've just discovered that the bulk canceling of test jobs in LAVA admin does not work. Issue in gitlab: https://git.lavasoftware.org/lava/lava/issues/310 We will fix this asap and roll it out with next release or hotfix, whichever comes first. A workaround is to either use XMLRPC API or cancel jobs one at a time. Cheers, -- Stevan Radaković | LAVA Engineer Linaro.org <www.linaro.org> │ Open source software for ARM SoCs

6 years, 7 months

1
0
0 0

Power time measurements

by Denis HUMEAU

Dear Lava users, I'm looking for a way to measure, with Lava, time measurements between some power modes. Let's say the time between two messages : - Standby exit trigger - Actual standby exit from the kernel The constraint is that we can't rely on kernel timestamps (frozen during standby) and the power process implies not only kernel but also boot stages. We can only rely on the time spent between two specific messages in the console. Basically, if it was done without Lava, we'd use a tool like grabserial. Do you have any clue on what can be done? Best regards,

6 years, 7 months

2
3
0 0

500 Internal Server Error

by Ilya Fedusiv

Hi! Problem, that I'm receiving Internal Server Error Error log of django : https://pastebin.com/9dxTi0nm Log of apache : https://pastebin.com/SSwyHymT I've started working with LAVA. I installed on VirtualBox Debian stretch, as recommended. I want lava-server lava-master lava-slave on one machine and work locally. I provided next step for installing LAVA: Add this lines to /etc/apt/sources.list deb http://deb.debian.org/debian stretch-backports main deb https://apt.lavasoftware.org/release stretch-backports main root# wget https://apt.lavasoftware.org/lavasoftware.key.asc root# apt-key add lavasoftware.key.asc root# apt-get update root# apt -t stretch-backports install lava-server root# a2dissite 000-default root# a2enmod proxy root# a2enmod proxy_http root# a2ensite lava-server.conf root# service apache2 restart After that I changed some parameters as written here : https://validation.linaro.org/static/docs/v2/installing_on_debian.html#usin… to run locally I checked variables value http://54.68.224.33/static/docs/v2/pipeline-debug.html#displaying-current-s… It is similar to what I set up. root# lava-server manage check --deploy ?: (security.W012) SESSION_COOKIE_SECURE is not set to True. Using a secure-only session cookie makes it more difficult for network traffic sniffers to hijack user sessions. ?: (security.W016) You have 'django.middleware.csrf.CsrfViewMiddleware' in your MIDDLEWARE, but you have not set CSRF_COOKIE_SECURE to True. Using a secure-only CSRF cookie makes it more difficult for network traffic sniffers to steal the CSRF token. I've read that mailing list post: https://lists.lavasoftware.org/pipermail/lava-users/2018-March/000884.html So I download http://cdn-fastly.deb.debian.org/debian/pool/main/d/django-tables/python3-d… and dpkg -i to downgrade python3-django-tables2 restart everything. This didnt helped. Ilya.

6 years, 7 months

3
3
0 0

Multinode job: how can I assure that all devices are on the same worker?

by Tim Jaacks

Hello again, I have several test cases where we use LAVA multinode to test hardware and software interfaces externally. E.g. we have an SFTP server running on our DUT. In order to test that, we submit a test using two nodes: 1. The DUT 2. An LXC container The LXC device connects to the DUT via SFTP and uploads a file. Both sides determine the MD5 sum and the DUT compares them. This works as long as both the DUT and the LXC device are in the same network (or at least can reach each other via the network). Now there are more test cases which require additional hardware connections between the worker and the DUT, e.g. a serial interface test. The serial interface on the DUT is connected via an RS232-USB converter to the worker. The LXC can access this converter and send or receive data from the serial interface. This works as long as the LXC is running on the expected worker the serial interface of the DUT is connected to. As we are growing our lab, we will add more workers to our setup. There will be LXC devices on all of the workers. When submitting such a multinode job, which relies on hardware connections between the DUT and the worker, how can I make sure that the LXC part of the job is scheduled on an LXC device on the correct worker? 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

6 years, 7 months

3
16
0 0

UART connection parameters

by Dupont, Louis [2]

Hi, I'm looking into LAVA and I figured I'd give it a try by flashing a frdm-k64f MCU board and parse its output (the board behaves as a USB to UART adapter through /dev/ttyACM0 at 115200bps). I created the board instance as: {% extends 'frdm-k64f.jinja2' %} {% set board_id = '0240000048824e45004a700add89001a8761000097969900' %} {% set usb_mass_device = '/dev/disk/by-id/usb-MBED_VFS_0240000048824e45004a700add89001a8761000097969900-0:0' %} I'm able to launch a job (frdm-k64f.job) but LAVA complains and returns: Invalid job data: ["Invalid device configuration - missing 'commands'"] So I went looking for an example and found this<https://git.lavasoftware.org/fabo/lava/blob/bc44750733f57de09909f45ba7e65fa…> which defines something called connection_commands as: {% set connection_commands = {'usb0': 'telnet lab-slave-0 7115'} %} Based on the documentation<https://docs.lavasoftware.org/lava/connections.html> I'm under the impression that the slave/dispatcher is expected to momentarily open a telnet server on port 7115 and forward the output of the serial port through that server to be retrieved by a client implemented by the master. If I match the example the dispatcher flashes the board, but a telnet server is never launched on the slave. It's not surprising as at no point did I specify a tty or a baud rate for the dispatcher to connect to the board in order and launch something like: socat TCP-LISTEN:7115,fork,reuseaddr FILE:/dev/ttyACM0,b115200,raw When I sit on the slave and manually launch the command the master successfully connects to TCP port 7115. Problem is it does so after the board outputted its results (and obviously it's not the right way to do it). So I have 3 questions: * How should a UART connection be specified (/dev/ttyACM0, 115200bps) to LAVA? * Once the UART connection specified, will the dispatcher buffer the board's output until it is retrieved by the master? * Why does LAVA rely on a telnet channel instead of the existing zmq channel to forward the output of the board from the slave to the master? Thanks

6 years, 7 months

3
2
0 0

DUT in recovery mode under LAVA

by Diego Russo

Hello, We have few device types in our LAVA instance that use ums mechanism to be deployed. This has worked well so far but we have now the need to test secure boot flow (BL1, BL2...) and we cannot rely anymore in u-boot for deploying them. Assuming we have the HW in place to put the DUT in recovery mode, how can we achieve this via LAVA? Do you have an existent example where you automate the recovery mode of a board? 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.

6 years, 7 months

2
4
0 0

Accessing physical worker devices from LXC

by Tim Jaacks

Hello everyone, I have the following entry in my lxc device dictionary: {% set static_info = [ {'board_id': 'FTXTBHMA'}, ] %} This adds my USB-serial converter installed on the worker machine to the LXC. It appears correctly in the LXC: root@lxc-generic-remote-5937:~# ls -la /dev/ttyUSB* crw-r----- 1 root root 188, 0 Jul 30 13:15 /dev/ttyUSB0 crw-r----- 1 root root 188, 1 Jul 30 13:15 /dev/ttyUSB1 crw-r----- 1 root root 188, 2 Jul 30 13:15 /dev/ttyUSB2 crw-r----- 1 root root 188, 3 Jul 30 13:15 /dev/ttyUSB3 I cannot read from or write to it, though: root@lxc-generic-remote-5937:~# cat /dev/ttyUSB0 cat: /dev/ttyUSB0: Operation not permitted This does not seem to be a permission issue in the LXC, it fails even if I set all permissions: root@lxc-generic-remote-5937:~# chmod a+rwx /dev/ttyUSB0 root@lxc-generic-remote-5937:~# cat /dev/ttyUSB0 cat: /dev/ttyUSB0: Operation not permitted Does anybody have an idea what is missing here? 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

6 years, 7 months

3
5
0 0

device_description

by Fedusiv Ilya

Hello, LAVA Team! I have question about device description. I have problems with *pre_power_command* If I don't use requests : pre_power_command in my job description, i get error, that no request implementation. So in my case, I need to switch device to fastboot mode by sending command via serial connection. And I decided, that pre_power_command is better solution for me. Cause before fastboot deploying by setting up this command I will switch device's mode. And here I stuck, cause I received error message: no pre_power_command implementation. Device description: https://pastebin.com/FLhGUnyH Job description: https://pastebin.com/Ts6VUXZe Error log: https://pastebin.com/9jXvjxZb best regards, Ilya

6 years, 7 months

1
0
0 0

Adding device

by Fedusiv Ilya

Hi, LAVA Team! I'm trying to add my new device. It must be flashed by fastboot. To turn device into fastboot mode, I need to write "reboot bootloader" via serial connection. I have tried set soft_reboot_command = ['reboot bootloader'] and received error message lava-lxc protocol: FAILED executing 'lxc-attach -n lxc-hikey-test-4 -- adb reboot bootloader' Ilya

6 years, 7 months

1
0
0 0

Server returning wrong job id

by Fabiano Ferronato

Hi, we have a LAVA test setup working for some time. Automated pipelines are running tests on different devices in parallel. After updating to version 2018.10+stretch and changing to in-line job definitions we started to get some sporadic errors. The error message shows up after jobs are submitted and the return from the submission is then used to ask for server job details: res = lava_server.submit_job(lava_test_job_description) for entry in res: job_details = lavasrv.job_details(entry) ... Resulting in the following error: lib/python3.5/site-packages/lavac/server.py", line 272, in job_details raise get_server_error(error, job_id) lavac.server.NoSuchJob: No such job: 68271.0 Trying to access LAVA WebUI using the jobid (68271.0): 500 Internal Server Error Reverse for 'lava.scheduler.job.detail' with arguments '('',)' not found. 1 pattern(s) tried: ['scheduler/job/(?P<pk>[0-9]+|[0-9]+\\.[0-9]+)$'] Can you give me a hint about this error? Thanks!

6 years, 7 months

3
4
0 0

access target board with adb from LAN tu run CTS

by George Nistor

Hi Milosz, I am using the Raspberry Pi 3 B+ board as a real target. It has AOSP Pie 9 on it and runs. I would be interested now, to see like you said if I could run CTS,VTS on the board and omit deploy section. What should I put in the boot section as method: Would be the same fastboot or another method? I ask because the board is connected to LAN (and not over USB). Is it ok just to omit deploy section? In other words how would Lava know to access the board on ADB over its IP. Where should I set this info? Example section (Milosz CTS&VTS example): https://pastebin.com/hBn0pq6U

6 years, 7 months

2
1
0 0

to: iso-installer and flash with adb using wifi

by George Nistor

Hi Lava Users, I have decided to continue using a real device: a Raspberry Pi 3 B+. Because I have an iso with Android 9 Pie, to flash the board I want to use deploy: to: iso-installer The question I'm having is: Is it possible to use this mode to flash the board with ADB via Wifi? (The board, I connected wifi to our router and I am able to connect with adb using wifi) (The board does not have USB/OTG interface so the only option is to use ADB on wifi.) What I try to achieve is deploy the image I have - iso one (flash), with adb using wifi, and run as tests CTS and VTS. george -----Original Message----- From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org> Sent: Wednesday, August 21, 2019 11:27 AM To: George Nistor <george.n(a)l4b-software.com> Cc: lava-users(a)lists.lavasoftware.org Subject: Re: [Lava-users] old comercial phones supported by Lava On Wed, 21 Aug 2019 at 08:00, George Nistor <george.n(a)l4b-software.com> wrote: > > 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). > our current use case doesn't require power cycling the device. It uses the same OS build and tests are executed in chroot environment. This is pretty specific setup for the use case (doesn't require changing kernel). > To be able to use it requires hw modification of the device? yes, you need to be able to forcibly power cycle the device. With battery inside the phone this isn't possible, so you have to remove battery and replace it with power supply you can turn off. > > What we want to have for the moment is a real device (ex, Nexus 5) on which to run Tradef with Lava. What is your use case? Are you testing tradefed (ex CTS) changes and stick with the same Android build or do you test Android (kernel, libraries, etc) changes? If it's the former you might be lucky and use existing nexus5 support. If you want to test android using CTS, HW modification is necessary. milosz > > 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-conf > ig/device-types > > Cheers, > -- > Steve McIntyre steve.mcintyre(a)linaro.org > <http://www.linaro.org/> Linaro.org | Open source software for ARM > SoCs > > > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.lavasoftware.org > https://lists.lavasoftware.org/mailman/listinfo/lava-users

6 years, 7 months

2
2
0 0

lxc problem

by Fedusiv Ilya

It appears always, right from the start of the job. lxc is installed on my dispatcher. Job description https://pastebin.com/5g15YrWy DUT description: https://pastebin.com/bTKdaM5i I know dut description is not full, but I want do step by step, firstly run lxc on device. Maybe you can give some advice about DUT desc. I'm using fastboot flash for few partitions after that fastboot reboot flash_cmds_order - it is order of flashing partition fastboot_sequence - what is it? Do you have some manual about this parameters description, cause have not found it on your website. And one more question, lxc deployed on dispatcher, right? Best regards, Ilya Fedusiv

6 years, 8 months

2
8
0 0

old comercial phones supported by Lava

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

6 years, 8 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

6 years, 8 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

6 years, 8 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 %}

6 years, 8 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

6 years, 8 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

6 years, 8 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

6 years, 8 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

6 years, 8 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

6 years, 8 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

6 years, 8 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.

6 years, 8 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.

6 years, 8 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

6 years, 8 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/>

6 years, 8 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

6 years, 8 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>

6 years, 8 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

6 years, 8 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.

6 years, 8 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

6 years, 8 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.

6 years, 8 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.

6 years, 8 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

6 years, 9 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

6 years, 9 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.

6 years, 9 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.

6 years, 9 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

6 years, 9 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, 10 months

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, 10 months

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, 10 months

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, 10 months

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, 10 months

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, 10 months

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, 10 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

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, 11 months

1
0
0 0

What's the difference between kernel ci's docker and official docker?

by Larry Shen

Hi, I'd like to know is this site official? https://github.com/kernelci/lava-docker Does this project same as the one in dockerhub, lavasoftware/lava-server?

6 years, 11 months

3
2
0 0

Correct way to make device not affect others.

by cnspring2002

I attach a tag on one of my device, and when submit job I will add "tags:" to my job, it's ok. But, when others submit their job with same device-type which same as my device, as they did not specify "tags", they will have chance to run their job on my device. How to avoid it? I want the job not be scheduled to the device which have a tag if the job did not specify any tag. I tried to set the device as private, but then only me can use this device, I have other guys in groupA which want to use the device, while I hae another some guys in groupB which didid not want to use these devices as some modules on the device is not same.

6 years, 11 months

3
2
0 0

device type alias redesign

by Milosz Wasilewski

Hi, There is an idea of device type 'alias' in LAVA. I don't quite understand what the use case for the current implementation was [1]. I tried using it but it wasn't very useful. My use case is that I need to submit jobs to a device type with different device type name. This is used to align device type naming between different labs in a bigger project (kernelci.org in this case). So the questions I have about current implementation: - is there anyone using current implementation? - if current implementation is used, how much trouble would it cause to change the behaviour? Change in behaviour is quite intrusive and will require database migration. [1] https://master.lavasoftware.org/static/docs/v2/glossary.html#term-alias Regards, milosz

6 years, 11 months

4
4
0 0

Handling of a kernel panic

by Frank, Matthias

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

7 years

2
1
0 0

[PATCH] Set systemd test data directory

by Khouloud Touil

In case that 'systemd' is one of the ptest to run and to avoid some test cases failure in the systemd ptest, we need to export the proper directory that contains the needed systemd test data. This patch exports the needed test data directory. Signed-off-by: Khouloud Touil <ktouil(a)baylibre.com> --- automated/linux/ptest/ptest.yaml | 1 + automated/linux/ptest/set-systemd-test-data.sh | 18 ++++++++++++++++++ 2 files changed, 19 insertions(+) create mode 100755 automated/linux/ptest/set-systemd-test-data.sh diff --git a/automated/linux/ptest/ptest.yaml b/automated/linux/ptest/ptest.yaml index 6205c11..85f6893 100644 --- a/automated/linux/ptest/ptest.yaml +++ b/automated/linux/ptest/ptest.yaml @@ -21,5 +21,6 @@ params: run: steps: - cd ./automated/linux/ptest + - ./set-systemd-test-data.sh $TESTS - PYTHONIOENCODING=UTF-8 ./ptest.py -o ./result.txt -t ${TESTS} -e ${EXCLUDE} - ../../utils/send-to-lava.sh ./result.txt diff --git a/automated/linux/ptest/set-systemd-test-data.sh b/automated/linux/ptest/set-systemd-test-data.sh new file mode 100755 index 0000000..0a26b4b --- /dev/null +++ b/automated/linux/ptest/set-systemd-test-data.sh @@ -0,0 +1,18 @@ +#!/bin/bash +#------------------------ +# Some systemd tests needs systemd test data +# to pass. +# This script test when there is systemd tests +# and set the systemd test data +#------------------------ +tests="$*" +test_dirs=['/usr/lib/systemd/ptest/tests/test', '/usr/lib64/systemd/ptest/tests/test', '/usr/lib32/systemd/ptest/tests/test'] +for t in $tests; do + if [ "$t" == "systemd" ]; then + for dir in test_dirs ; do + if [ -e "$dir" ]; then + export SYSTEMD_TEST_DATA=$dir + fi + done + fi +done \ No newline at end of file -- 2.17.1

7 years

2
1
0 0

lava-os-build

by Frank, Matthias

Hi lava users, I have tested lava-os-build on my ptxdist root images and I got this output: root@MBa6x:/lava-557/bin ./lava-os-build _____ ___ ____ _ |_ _/ _ \\ / ___| _ _ ___| |_ ___ _ __ ___root@MBa6x:/lava-557/bin Maybe it's better to look for other files first, like /etc/os-release (or /usr/lib/os-release) for systemd systems. This file is (more) standardized way to detect with os/build is running by evaluating the keys NAME,PRETTY_NAME etc. What is the exact function of lava-os-build? Only diagnostic purpose to find out with os is running? Does something else rely on lava-os-build? What could break if I change that script? Matthias [0] https://www.freedesktop.org/software/systemd/man/os-release.html

7 years

2
1
0 0

lxc job error: Lxc container rootfs not found

by jack lu

Hi,according https://validation.linaro.org/static/docs/v2/deploy-lxc.html?highlight=lxc. I run a sample lxc Job Definition as above.. the error msg : Lxc container rootfs not found

7 years

2
3
0 0

LAVA Ansible playbooks

by Karsten Tausche

Hi, Are the Ansible playbook for setting up LAVA available somewhere? There is an old migrated issue on GitLab [1] which is closed, but the link to an implementation in there is dead. Is that playbook only internally available for Linaro? Is there anything you could share? It looks like many people are moving to Docker in the moment, but that's not an option for us (at least not for dispatchers), as we need LXC for Android testing. Cheers, Karsten [1] https://git.lavasoftware.org/lava/lava/issues/27

7 years

3
4
0 0

LAVA Django template caching

by Karsten Tausche

Hi all, The LAVA docs mention that it's possible to enable template caching via settings.conf [1]. However, doing so leads to a key error when starting the LAVA gunicorn server and in `lava-server manage check --deploy`: ... File "/usr/lib/python3/dist-packages/lava_server/settings/distro.py", line 185, in <module> ("django.template.loaders.cached.Loader", TEMPLATES[0]["OPTIONS"]["loaders"]) KeyError: 'loaders' The LAVA git history shows that this dictionary key was removed in commit 6705ec870[2], "Refresh the setting files". Is this just a bug in LAVA, is Django template caching not supported anymore with LAVA, or are other Debian/pip packages required to be installed to enable to cache? I'm currently testing that on Debian buster, which ships Django version 1.11. Cheers, Karsten [1] https://validation.linaro.org/static/docs/v2/advanced-installation.html?hig… [2] https://git.lavasoftware.org/lava/lava/commit/6705ec870c1f30ea0b7f78f05a322…

7 years

2
1
0 0

simple multinode job

by Frank, Matthias

Hi lava users, I want to try the simple client/server multi node job [0]. My job yaml is below. I get following error during job submission via webui: Job submission error: 'dict_keys' object does not support indexing What is wrong? The error message (a python error?) gives me no hint. The log files had have no entries for that issue. Greetings, Matthias job_name: simple multinode timeouts: job: minutes: 90 action: minutes: 10 connection: minutes: 2 priority: medium visibility: public protocols: lava-multinode: roles: server: device_type: tqma6s-mba6x count: 1 client: device_type: tqma6d-mba6x count: 1 timeout: minutes: 6 actions: - deploy: role: - server timeout: minutes: 10 to: tftp kernel: url: <url linuximage> type: zimage nfsrootfs: url: <url rootfs> compression: gz dtb: url: <url dtb> - deploy: role: - client timeout: minutes: 10 to: tftp kernel: url: <url linuximage> type: zimage nfsrootfs: url: <url rootfs> compression: gz dtb: url: <url dtb> - boot: role: - server method: u-boot commands: nfs auto_login: login_prompt: 'MBa6x login:' username: root prompts: - 'root@MBa6x:~' - boot: role: - client method: u-boot commands: nfs auto_login: login_prompt: 'MBa6x login:' username: root prompts: - 'root@MBa6x:~' - test: timeout: minutes: 120 definitions: - repository: <url git> from: git path: simple_multinode.yaml name: simple_multinode [0] https://validation.linaro.org/static/docs/v2/multinodeapi.html#example-1-si…

7 years

3
4
0 0

lava-server upgrade to 2019-03

by Frank, Matthias

Hi lava-users, I upgrade my lava-server package (from backports) to 2019-03 on debian stretch. After this is get an django error: ERROR 2019-04-04 08:24:16,694 exception Invalid HTTP_HOST header: '<my-host-name>'. You may need to add '<my-host-name>' to ALLOWED_HOSTS. The browser reports a Bad Request (400) So I added <my-host-name> and "*" to ALLOWED_HOSTS in /usr/lib/python3/dist-packages/lava_scheduler_app/settings.py and /usr/lib/python3/dist-packages/django/conf/global_settings.py but the error is still present. Are these the wrong file or what could be the problem? Matthias

7 years

3
2
0 0

Lava Issue: API-Error-server.scheduler.all_devices

by Chenchun (coston)

Job definition & Detailed log in attachment 发件人: Xiaomingwang (Steve) 发送时间: 2019年4月4日 10:29 收件人: lava-users(a)lists.lavasoftware.org 抄送: Yewenzhong (jackyewenzhong) <jack.yewenzhong(a)huawei.com>; Chenchun (coston) <chenchun7(a)huawei.com>; liucaili (A) <liucaili2(a)huawei.com> 主题: 转发: Lava Issue: API-Error-server.scheduler.all_devices 发件人: liucaili (A) 发送时间: 2019年4月4日 10:24 收件人: Xiaomingwang (Steve) <xiaomingwang1(a)huawei.com<mailto:xiaomingwang1@huawei.com>> 主题: Lava Issue: API-Error-server.scheduler.all_devices Dear Sir/Madam, If possible could you please help us analyze the problems encountered in recent Lava tests? Job definition & Detailed log in the attachment. lava-dispatcher version: 2018.11+stretch. The key information is as follows: python /usr/local/bin/module_deploy.py --DUT cloudgame4_01 Traceback (most recent call last): File "/usr/local/bin/module_deploy.py", line 37, in <module> main(args) File "/usr/local/bin/module_deploy.py", line 30, in main module = get_module(dut) File "/usr/local/bin/module_deploy.py", line 14, in get_module devices_list = server.scheduler.all_devices() File "/usr/lib/python2.7/xmlrpclib.py", line 1243, in __call__ return self.__send(self.__name, args) File "/usr/lib/python2.7/xmlrpclib.py", line 1602, in __request verbose=self.__verbose File "/usr/lib/python2.7/xmlrpclib.py", line 1283, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib/python2.7/xmlrpclib.py", line 1316, in single_request return self.parse_response(response) File "/usr/lib/python2.7/xmlrpclib.py", line 1493, in parse_response return u.close() File "/usr/lib/python2.7/xmlrpclib.py", line 800, in close raise Fault(**self._stack[0]) xmlrpclib.Fault: <Fault -32603: "Internal Server Error (contact server administrator for details): 'NoneType' object has no attribute 'pk'"> Is it a lava bug? We look forward to your reply. Thank you for your assistance. Best Regards, Caili Liu

7 years

2
1
0 0

Override method param per device?

by Kumar Gala

Guys, Is it possible for one board/device instance to override a methods param? Specifically if I want to set ‘resets_after_flash’ to ’true’ for one disco-l475-iot1 board instance. Here’s the device type definition: https://git.lavasoftware.org/lava/lava/blob/master/lava_scheduler_app/tests… thanks - k

7 years

2
1
0 0

record measurement

by Frank, Matthias

Hi, I want to measure some output values of test cases. I have a shell script which run stress-ng, parse it's output and exports some measurement variables. How can I record theses variables? I tried to use lava-test-case -shell myscript.sh -result pass -measurement $VAR1 -unit unit but no values are recorded. Maybe this is the wrong approach, but how can I do this in the correct way? Matthias

7 years

2
3
0 0

Using Fuego with LAVA MultiNode API

by Chase Qi

Hi, In case it is any help for other LAVA and Fuego users, here is another option to run Fuego tests with LAVA MultiNode API. https://github.com/Linaro/test-definitions/blob/master/automated/linux/fueg… Thanks, Chase

7 years

1
0
0 0

Running MultiNode job on specific devices

by Frank, Matthias

Hello lava users, how can I run a multinode job on specific devices instead of (a possible set) of device_types? I plan to run CAN or RS485 communication tests which requires a wired connection between duts. Is is possible to submit a job to theses special duts or should is have device_types with only on device instance? Greetings, Matthias

7 years

3
2
0 0

Deploying and maintaining a LAVA Lab

by Dave Pigott

Hi all, We’ve started a collaborate page on how to deploy and maintain devices and instances of LAVA Labs. https://collaborate.linaro.org/display/CTT/LAB+Device+Deployment+Guide <https://collaborate.linaro.org/display/CTT/LAB+Device+Deployment+Guide> Please understand that this is a work in progress. All suggestions for changes and additions are more than welcome. email lava-lab-team(a)linaro.org with questions and suggestions. Dave ---------------- Dave Pigott LAVA Lab Lead Linaro Ltd t: (+44) (0) 1223 400063

7 years

2
2
0 0

What happened if different worker link to different coordinator in one lava instance?

by cnspring2002

As title: What happened if different worker link to different coordinator in one lava instance for multinode job?

7 years

3
2
0 0

query about lava usage for MCU like solution

by Hake Huang

Hi Sirs, Does LAVA support MCU like system? Which usually using a debugger to download image to a MCU internal flash, and get uart result? Regards, Hake

7 years

3
5
0 0

jobs using notify with tokens, resubmit as different user

by Kevin Hilman

How can you have more than one LAVA user have the same token secret (e.g. for a notify callback.)? Example use case: - LAVA job with notify callbacks using token names - submited as user "bob", token names of "bob" map to actual token secrets - job fails - user "lab-admin" fixes some lab issues, re-submits job - job passes, but callbacks fail because tokens are associated with user "bob" Since the re-submitted job runs as user "lab-admin", the same token names and corresponding secrets don't exist. Naively, user "lab-admin" tries to copy the token secrets from user "bob" keeping the same token names, but this fails saying that "secret already exists". Why can't different users have the same secrets? I haven't looked at the code, but this limitation kind of suggests that the secret itself is the key in the db, which would prevent multiple secrets of the same. Kevin

7 years

3
5
0 0

kexec boot mechanism

by Hemanth K V

Hello Lava-users, Do we have any sample reference yaml job definition which has booting the target with kexec method. Thanks, Hemanth.

7 years

4
7
0 0

Build information in metadata

by Frank, Matthias

Hello lava users, I use in a test job linuximage, rootfs and dtb from file server location retrieved via http. These files are nightly build from Jenkins. The file links are static so I can use new images within the same test job definition. Jenkins generates also a build information text file with commit IDs an so on. How can I integrate the content of this file in the job metadata or job result log? Using metadata: build-readme: <link> in the job definition is not possible because the link is stable over different build, but the file content is changing. The DUT has no access to the file location because it is in an isolated network. Is there a way to cat the file content on the worker to metadata or job result? Greetings, Matthias

7 years, 1 month

2
1
0 0

Invalid device configuration

by Frank, Matthias

Hello lava users, my lava 2019.01 shows me a device with Health == Bad. The Transitions log give that message: March11, 3:02p.m. lava-health Good → Bad (Invalid device configuration) Where can I found information about a misconfigured device? The log files did not provide (in my eyes) sufficient information. As Health checks I use the smoke-tests. Kinds Regards, Matthias

7 years, 1 month

2
5
0 0

apt get install hang

by cnspring2002

I use lxc-mocker in docker container, everything is ok. Just if the package did not install in advance, then next command will hang in web: lxc-create -t ubuntu -n test_lava -- --release xenial --mirror http://mirror.bytemark.co.uk/debian --packages systemd,systemd-sysv --arch amd64 I enter the container, see: root@df67cf292479:/# ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 17:20 pts/0 00:00:00 /usr/bin/python3 /usr/bin/lava-slave --level DEBUG --log-file - --master tcp://192.168.1.10:5556 --socket-a root 8 0 0 17:20 pts/1 00:00:00 /bin/bash root 13 1 0 17:20 pts/0 00:00:00 lava-run [job: 837] root 19 13 0 17:20 pts/0 00:00:00 /bin/bash /usr/bin/lxc-create -q -t ubuntu -n test_lava -- --release xenial --mirror http://mirror.bytemark.c root 261 19 1 17:20 pts/0 00:00:00 apt-get -q install -y systemd systemd-sysv root 473 8 0 17:21 pts/1 00:00:00 ps -ef Seems "apt-get install" hang, but if I pre-install the systemd,etc, then everything will ok, the lxc-create will not hang. The same for lxc-attach mocker etc, all will hang if do "apt-get install" & no pakcage preinstall. Please suggest, thanks.

7 years, 1 month

2
4
0 0

docker-compose with lava

by Dan Rue

I started playing with the official lava images today and wanted to share my work in progress, in case others are doing something similar or have feedback. My goal is to deploy a lava lab locally. My architecture is a single host (for now) that will host both the lava server and one dispatcher. Once it's all working, I'll start deploying a qemu worker followed by some actual boards (hopefully). So far, I have the following docker-compose.yml: version: '3' services: database: image: postgres:9.6 environment: POSTGRES_USER: lavaserver POSTGRES_PASSWORD: mysecretpassword PGDATA: /var/lib/postgresql/data/pgdata volumes: - ${PWD}/pgdata:/var/lib/postgresql/data/pgdata server: image: lavasoftware/amd64-lava-server:2018.11 ports: - 80:80 volumes: - ${PWD}/etc/lava-server/settings.conf:/etc/lava-server/settings.conf - ${PWD}/etc/lava-server/instance.conf:/etc/lava-server/instance.conf depends_on: - database dispatcher: image: lavasoftware/amd64-lava-dispatcher:2018.11 environment: - "DISPATCHER_HOSTNAME=--hostname=dispatcher.lava.therub.org" - "LOGGER_URL=tcp://server:5555" - "MASTER_URL=tcp://server:5556" With that file, settings.conf, and instance.conf in place, I run 'mkdir pgdata; docker-compose up' and the 3 containers come up and start talking to each other. The only thing exposed to the outside world is lava-server's port 80 at the host's IP, which gives the lava homepage as expected. The first time they come up, the database isn't up fast enough (it has to initialize the first time) and lava-server fails to connect. If you cancel and run again it will connect the second time. A few things to note here. First, it doesn't seem like a persistent DB volume is possible with the existing lava-server container, because the DB is initialized at container build time rather than run-time, so there's not really a way to mount in a volume for the data. Anyway, postgres already solves this. In fact, I found their container documentation and entrypoint interface to be well done, so it may be a nice model to follow: https://hub.docker.com/_/postgres/ The server mostly works as listed above. I copied settings.conf and instance.conf out of the original container and into ./etc/lava-server/ and modified as needed. The dispatcher then runs and points to the server. It's notable that docker-compose by default sets up a docker network, allowing references to "database", "server", "dispatcher" to resolve within the containers. Once up, I ran the following to create my superuser: docker-compose exec server lava-server manage users add --staff --superuser --email dan.rue(a)linaro.org --passwd foo drue Now, for things I've run into and surprises: - When I used a local database, I could log in. With the database in a separate container, I can't. Not sure why yet. - I have the dreaded CSRF problem, which is unlikely to be related to docker, but the two vars in settings.conf didn't seem to help. (I'm terminating https outside of the container context, and then proxying into the container over http) - I was surprised there were no :latest containers published - I was surprised the containers were renamed to include the architecture name was in the container name. My understanding is that's the 'old' way to do it. The better way is to transparently detect arch using manifests. Again, see postgres/ as an example. - my pgdata/ directory gets chown'd when I run postgres container. I see the container has some support for running under a different uid, which I might try. - If the entrypoint of server supported some variables like LAVA_DB_PASSWORD, LAVA_DB_SERVER, SESSION_COOKIE_SECURE, etc, I wouldn't need to mount in things like instance.conf, settings.conf. I pushed my config used here to https://github.com/danrue/lava.home.therub.org. Git clone and then run 'docker-compose up' should just work. Anyway, thanks for the official images! They're a great start and will hopefully really simplify deploying lava. My next step is to debug some of the issues I mentioned above, and then start looking at dispatcher config (hopefully it's just a local volume mount). Dan

7 years, 1 month

4
23
0 0

AOSP multiple node job

by Chase Qi

Hi, In most cases, we don't need multiple node job as we can control AOSP DUT from lxc via adb over USB. However, here is the use case. CTS/VTS tradefed-shell --shards option supports to split tests and run them on multiple devices in parallel. To leverage the feature in LAVA, we need multinode job, right? And in multinode job, master-node lxc needs access to DUTs from salve nodes via adb over tcpip, right? Karsten shared a job example here[1]. This probably is the most advanced usage of LAVA, and probably also not encouraged? To make it more clear, the connectivity should look like this. master.lxc <----adb over usb----> master.dut master.lxc <----adb over tcpip ---> slave1.dut master.lxc <----adb over tcpip ---> slave2.dut .... I see two options for adb over tcpip. Option #1: WiFi. adb over wifi can be enabled easily by issuing adb cmds from lxc. I am not using it for two reasons. * WiFi isn't reliable for long cts/vts test run. * In Cambridge lab, WiFi sub-network isn't accessible from lxc network. Because of security concerns, there is no plan to change that. Option #2: Wired Ethernet. On devices like hikey, we need to run 'pre-os-command' in boot action to power off OTG port so that USB Ethernet dongle works. Once OTG port is off, lxc has no access to the DUT, then test definition should be executed on DUT, right? I am also having the following problems to do this. * Without context overriding, overlay tarball will be applied to '/system' directory and test job reported "/system/bin/sh: /lava-247856/bin/lava-test-runner: not found"[2]. * With the following job context, LAVA still runs '/lava-24/bin/lava-test-runner /lava-24/0' and it hangs there. It is tested in my local LAVA instance, test job definition and test log attached. Maybe my understanding on the context overriding is wrong, I thought LAVA should execute '/system/lava-24/bin/lava-test-runner /system/lava-24/0' instead. Any suggestions would be appreciated. context: lava_test_sh_cmd: '/system/bin/sh' lava_test_results_dir: '/system/lava-%s' I checked on the DUT directly, '/system/lava-%s' exist, but I cannot really run lava-test-runner. The shebang line seems problematic. --- hacking --- hikey:/system/lava-24/bin # ./lava-test-runner /system/bin/sh: ./lava-test-runner: No such file or directory hikey:/system/lava-24/bin # cat lava-test-runner #!/bin/bash #!/bin/sh .... # /system/bin/sh lava-test-runner lava-test-runner[18]: .: /lava/../bin/lava-common-functions: No such file or directory --- ends --- I had a discussion with Milosz. He proposed the third option which probably will be the most reliable one, but it is not supported in LAVA yet. Here is the idea. Milosz, feel free to explain more. **Option #3**: Add support for accessing to multiple DUTs in single node job. * Physically, we need the DUTs connected via USB cable to the same dispatcher. * In single node job, LAVA needs to add the DUTs specified(somehow) or assigned randomly(lets say both device type and numbers defined) to the same lxc container. Test definitions can take over from here. Is this can be done in LAVA? Can I require the feature? Any suggestions on the possible implementations? Thanks, Chase [1] https://review.linaro.org/#/c/qa/test-definitions/+/29417/4/automated/andro… [2] https://staging.validation.linaro.org/scheduler/job/247856#L1888

7 years, 1 month

3
6
0 0

How to full validate PSCI

by Lionel DEBIEVE

Dear All, I'm currently trying to check and implement a complete validation of my PSCI solution. The standard behavior for PSCI is to manage shutdown, reset and low power mode. I'm wondering to find the best way to manage it through LAVA. So two questions: - Is there a proper way to check the reboot behavior on a target (soft reboot)? Using shell command is not possible as the is no return from reboot. - Shutdown? I'm wondering to test the shutdown command and trig an automatic wake up after x seconds. My wish is to check that no watchdog occurred during that time (which is the only way to know if the shutdown was properly working). So it will be a similar behavior that the reboot command. Thanks for your support, BR Lionel

7 years, 1 month

2
2
0 0

撤回: Abnormal interruption during Lava test execution

by Chenchun (coston)

Chenchun (coston) 将撤回邮件“[Lava-users] Abnormal interruption during Lava test execution”。

7 years, 1 month

1
0
0 0

Abnormal interruption during Lava test execution

by Chenchun (coston)

Hi Remi Thanks for the quick reply. Attached please find the document(the raw job log and the job definition). Hello, that's in fact maybe a bug in LAVA. To help me reproduce the error, could you send: * the raw job log (click on "actions / plain logs" in the job page) * the job definition Thanks Le jeu. 21 févr. 2019 à 04:05, Chenchun (coston) <chenchun7(a)huawei.com<mailto:chenchun7@huawei.com>> a écrit : Dear Sir/Madam, could you please help us analyze the problems encountered in recent Lava tests? Detailed log in the attachment. lava-dispatcher version: 2018.11+stretch. The key information is as follows: Bug error: argument of type 'NoneType' is not iterable Chase Qi preliminary positioning is a lava bug. We look forward to your reply. Thank you for your assistance. Best Regards, Caili Liu _______________________________________________ Lava-users mailing list Lava-users(a)lists.lavasoftware.org<mailto:Lava-users@lists.lavasoftware.org> https://lists.lavasoftware.org/mailman/listinfo/lava-users -- Rémi Duraffort LAVA Team, Linaro

7 years, 1 month

2
2
0 0

Specifying metadata for test cases

by Tim Jaacks

Hello everyone, I know from the LAVA documentation how to add metadata to jobs and test suites. When I look at test results, I see that test cases have metadata, too. E.g. https://validation.linaro.org/results/testcase/9759970 shows the following metadata: case: linux-linaro-ubuntu-lscpu definition: 0_smoke-tests-lxc result: pass Is there a possibility to add custom metadata to test cases? 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

7 years, 1 month

2
3
0 0

Changing lava job status

by tomato

Hi. To make customized performance regression test job, I need to change Lava job status as I want. When I run test like kselftest, Lava dispatcher run test program under DUT. And after finishing lava test job, Job state is always 'Complete' whatever result(pass/fail) each test return. Attached image file is about kselftest result from lava test job. I want to make lava job status as 'Fail' or 'Canceled' when certain test return fail. I would like to ask your advice. Best regards Seoji Kim

7 years, 1 month

2
1
0 0

Abnormal interruption during Lava test execution

by Chenchun (coston)

Dear Sir/Madam, could you please help us analyze the problems encountered in recent Lava tests? Detailed log in the attachment. lava-dispatcher version: 2018.11+stretch. The key information is as follows: Bug error: argument of type 'NoneType' is not iterable Chase Qi preliminary positioning is a lava bug. We look forward to your reply. Thank you for your assistance. Best Regards, Caili Liu

7 years, 1 month

2
1
0 0

lava-master crashed by a job

by Axel Lebourhis

Hi all, Yesterday, we faced a weird issue with LAVA. A job was running and returned an error saying "metadata is too long". Right after that, the worker that was running the job went offline, and the lava-master raised an "unknown exception", making it crash. In attachement, you will find the full job error saying metadata is too long, the full job log, and the lava-master.log when the exception occured. Hope this helps. Axel

7 years, 1 month

2
1
0 0

lava in docker.

by cnspring2002

I use next command to start lavadispatcher: docker run -idt --net=host --privileged -v /dev:/dev -v /var/lib/lava/dispatcher/tmp:/var/lib/lava/dispatcher/tmp -e "DISPATCHER_HOSTNAME=--hostname=myname" -e "LOGGER_URL=tcp://master_ip:5555" -e "MASTER_URL=tcp://master_ip:5556" --name test_lava lavasoftware/lava-dispatcher:2019.01 In container, I start tftp and nfs. But the nfs always cannot be start successfully. I use "service nfs-kernel-server start" to start it, also before that I did "rpcbind". The start shows below seems ok: # service nfs-kernel-server start [ ok ] Exporting directories for NFS kernel daemon.... [ ok ] Starting NFS kernel daemon: nfsd mountd. But if do next we can see the nfs still not start. # service nfs-kernel-server status nfsd not running Any suggestion?

7 years, 1 month

2
3
0 0

uboot ums flakiness

by Diego Russo

Hello, We've been using uboot-ums for WaRP7 but we've been having intermittent failures when it tried to run dd to flash the image. Provided we need to look better into the root cause of this issue, we'd like to make the flashing phase a little more reliable. I have few questions, coming from different angles: * LAVA uses dd command to flash the image. Is there a way to specify the usage of bmap-tools? * let's say dd times out (this is what usually happen). Is there a mechanism to restart the actions (deploy and boot) in case of timeout? If you have any other suggestion, let me know! 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.

7 years, 1 month

3
4
0 0

Interactive Test steps with user input

by Pete Dyer

Hi, I have a test step that requires user input to a defined prompt. Is there a way I can automate this in LAVA ? I can see how we do this for Boot Actions and I've looked at interactive jobs that communicate to U-boot but these don't seem to fit my use case. 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.

7 years, 1 month

3
4
0 0

[Lava-Users] How to do Android testing on existing images

by ankit gupta

Hi All, I am new to Android testing, I am using standard board *i.mx6/rpi3* and flashed Android on it, I can connect with these board using "adb" tool. I want to do some system test using LAVA framework, and I don't want to reflash image every time(wants to test on the existing system). Can someone please let me know how I can do Android testing on existing flashed image? Thanks, Ankit

7 years, 1 month

2
1
0 0

Boot selection in u-boot from Lava?

by Denis HUMEAU

Dear Lava users, Our embedded SW offers 3 boot modes, selectable from u-boot. When booting, u-boot offers the possibility to select the boot mode: Select the boot mode 1: <boot mode 1> 2: <boot mode 2> 3: <boot mode 3> Enter choice: 1: <boot mode 1> <boot mode 1> is a default value, used after a counter has expired. All this is done using the extlinux feature. We have scripts that allow to select the boot mode, using Kermit. Now, we'd like to integrate this boot mode selection in a Lava job, and our current solution is not compatible. In Lava we may boot the kernel, modify the extlinux configuration and reboot, but do you know a direct way (with interactive mode maybe) to select the boot mode from u-boot? Best regards, Denis

7 years, 2 months

2
1
0 0

Multinode pipeline synchronisation / timeouts

by Tim Jaacks

Hello everyone, I am having problems with timeouts when using the LAVA multinode protocol. Assume the following minimal pipeline with two nodes (device = DUT, remote = some kind of external hardware interfacing with the DUT): - deploy: role: device - boot: role: device - deploy: role: remote - boot: role: remote - test: role: remote - test: role: device What I would expect: The device is booted first, then the remote is booted. Afterwards, the tests run on both nodes, being able to interact with each other. The pipeline model seems to be implemented in a way that each node has its own pipeline. This kind of makes sense, because the tests of course have to run simultaneously. However, in my case booting the device takes a lot more time than booting the remote. This makes the 'test' stage on the remote run a lot earlier than the 'test' stage on the device. My problem: How do I define a useful timeout value for the 'test' stage on the remote? Obviously I have to take the boot time difference between the two nodes into account. This seems counter-intuitive to me, since the timeout value should affect the actual test only. What happens if I use an image on the device which takes even a lot more time to boot? Or if I insert more testcases on the device which do not need the remote before? In both cases I would have to adjust the timeout value for the remote 'test' stage. Is this a design compromise? Or are there any possibilities of synchronizing pipeline stages on different nodes? I am thinking of some mechanism like "do not start 'test' stage on remote before 'boot' stage on device has finished". 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

7 years, 2 months

2
8
0 0

defining device specific values in device dictionary

by Milosz Wasilewski

Hi, Is there a way to specify an arbitrary parameter, that is board specific, in device dictionary? The parameter should be available from test shell. The use case is as follows: DUT is connected to test supporting hardware (chamelium board in this case). Tests access supporting hardware using IP address. IP address is 'static' and the supporting hw is assumed to be always turned on. Supporting hardware is dedicated to specific DUT and can't be shared (because of HW connections) between other boards of the same type (similar to energy probes). Tests run directly on DUT and access supporting hardware from there. I found 'exported parameters' in device dictionary docs: https://master.lavasoftware.org/static/docs/v2/lava-scheduler-device-dictio…. But they only list device_ip, device_mac and storage_info. Is there a way to extend this list? If not, is there any other way to provide device specific information to test shells? milosz

7 years, 2 months

2
2
0 0

Functional test for imx8m

by Axel Lebourhis

Hi everyone, I'm writing this email after discussion with Neil. I'm working at NXP and he told me Linaro wanted to run functional tests on imx8m with the new u-boot support. He told me it requires full open access, no license click-through or passwords. Philippe Mazet is more qualified to answer this type of question as I only use Android atm. He will follow up the discussion. Here you have the Yocto source code : https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-l… You can get the latest GA release with this : repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-sumo -m imx-4.14.78-1.0.0_ga.xml You can build these sources like this : DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source ./fsl-setup-release.sh -b build But, this will redirect you to a license click-through. However, you can bypass the license click-through, like "auto accept it" with this command : EULA=1 DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source ./fsl-setup-release.sh -b build We use this bypass to automate builds. So, let us know if this would be suitable for Linaro's needs. Best regards, Axel

7 years, 2 months

3
3
0 0

Creating lxc container inside docker container issue

by tomato

Hi. I encountered a problem running android apk test. I tried to run Antutu apk-automation test on android device. (https://github.com/Linaro/test-definitions/tree/master/automated/android/ap…) This is my job yaml file except device boot action. device_type: s5p4418-navi-ref-type job_name: s5p4418-navi-ref-all-pass tags: - s5p4418-navi-ref timeouts: job: minutes: 60 action: minutes: 30 connection: minutes: 20 priority: medium visibility: public protocols: lava-lxc: name: s5p4418-test template: debian distribution: debian release: jessie arch: amd64 actions: - deploy: failure_retry: 3 namespace: tlxc timeout: minutes: 5 to: lxc packages: - wget - zip - unzip - apt os: debian - boot: namespace: tlxc timeout: minutes: 10 method: lxc prompts: - 'root@(.*):/#' - 'console:/' - ':/' - test: namespace: tlxc timeout: minutes: 3 failure_retry: 3 definitions: - from: inline name: install-google-fastboot path: inline/install-google-fastboot.yaml repository: metadata: format: Lava-Test Test Definition 1.0 name: install-fastboot description: "Install fastboot provided by google" run: steps: - wget https://dl.google.com/android/repository/platform-tools_r26.0.0-linux.zip - unzip platform-tools_r26.0.0-linux.zip - ln -s `pwd`/platform-tools/fastboot /usr/bin/fastboot - ln -s `pwd`/platform-tools/adb /usr/bin/adb - fastboot --version - test: namespace: tlxc timeout: minutes: 10 failure_retry: 3 definitions: - repository: https://github.com/Linaro/test-definitions.git from: git path: automated/android/apk-automation/apk-automation.yaml name: antutu6 params: TEST_NAME: antutu6 This is log created when test job create and run lxc container. |start: 1 lxc-deploy (timeout 00:05:00) [tlxc]||start: 1.1 lxc-create-action (timeout 00:05:00) [tlxc]||nice lxc-create -q -t debian -n s5p4418-test-46 -- --release jessie --packages systemd,systemd-sysv --arch amd64||Container created successfully||end: 1.1 lxc-create-action (duration 00:00:30) [tlxc]||case: lxc-create-action case_id: 541 definition: lava duration: 29.74 extra: ... level: 1.1 namespace: tlxc result: pass <http://192.168.1.44/results/testcase/541>||start: 1.2 lxc-create-udev-rule-action (timeout 00:04:30) [tlxc]||device info file '/var/lib/lava/dispatcher/tmp/46/lxc-create-udev-rule-action-ymvjdkgm/device-info.yaml' created with: [{'board_id': 's5p4418-navi-ref'}]||udev rules file '/var/lib/lava/dispatcher/tmp/46/lxc-create-udev-rule-action-muvnvu7f/100-lava-s5p4418-test-46.rules' created||ACTION=="add", ATTR{serial}=="s5p4418-navi-ref", RUN+="/usr/share/lava-dispatcher/lava_lxc_device_add.py --lxc-name s5p4418-test-46 --device-node $name --job-id 46 --logging-url tcp://192.168.1.44:5557" ||'/etc/udev/rules.d/100-lava-s5p4418-test-46.rules' symlinked to '/var/lib/lava/dispatcher/tmp/46/lxc-create-udev-rule-action-muvnvu7f/100-lava-s5p4418-test-46.rules'||nice udevadm control --reload-rules||action: lxc-create-udev-rule-action command: ['nice', 'udevadm', 'control', '--reload-rules'] message: Command '['nice', 'udevadm', 'control', '--reload-rules']' returned non-zero exit status 2 output: Command '['nice', 'udevadm', 'control', '--reload-rules']' returned non-zero exit status 2 ||udev rules reloaded.||end: 1.2 lxc-create-udev-rule-action (duration 00:00:00) [tlxc]||start: 1.3 boot-lxc (timeout 00:04:30) [tlxc]||nice lxc-start -n s5p4418-test-46 -d||action: boot-lxc command: ['nice', 'lxc-start', '-n', 's5p4418-test-46', '-d'] message: Command '['nice', 'lxc-start', '-n', 's5p4418-test-46', '-d']' returned non-zero exit status 1 output: lxc-start: tools/lxc_start.c: main: 366 The container failed to start. lxc-start: tools/lxc_start.c: main: 368 To get more details, run the container in foreground mode. lxc-start: tools/lxc_start.c: main: 370 Additional information can be obtained by setting the --logfile and --logpriority options. ||Wait until 's5p4418-test-46' state becomes RUNNING||nice lxc-info -sH -n s5p4418-test-46||output: STOPPED||output: ||nice lxc-info -sH -n s5p4418-test-46||output: STOPPED||output: | I wonder if it is okay to create and run lxc container in docker container. I wrote job yaml file by reference this job definition. (https://validation.linaro.org/scheduler/job/1656201/definition) Best regards Seoji Kim

7 years, 2 months

3
2
0 0

swupdate image deployment

by Hemanth K V

Hello Lava-users, Do we have support in LAVA for deploying to target the SWUpdate images directly if target supports the swupdate image deployment( http://sbabic.github.io/swupdate/). Thanks, Hemanth.

7 years, 2 months

2
1
0 0

Device-type support for TI AM4378 IDK

by Olli Vainola

Hi all, We're planning to use TI AM4378 IDK in the board farm for testing (http://www.ti.com/tool/TMDSIDK437X) but it seems there is not device-type for this board. I tried to search from these links: - https://git.lavasoftware.org/lava/lava/tree/master/lava_scheduler_app/tests… - https://git.linaro.org/lava/lava-lab.git/tree/shared/device-types Did I just miss it, or is it missing from the device-types? If it is missing, are there any templates available / what template could be used as a base for the device Br Olli Väinölä 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.

7 years, 2 months

2
1
0 0

[Lava-Users] Android testing on Rpi3 board

by ankit gupta

Hi All, I have a Rpi3 board with android install on it, it can be accessed using adb from my Linux PC. I am successfully able to use Lava-LXC for testing a device. Can someone please share the steps how I can use LAVA to test an android device and how the setup will look like. If anyone can share a test job with some basic android tests would be very helpful. Thanks, Ankit

7 years, 2 months

2
1
0 0

Query to get jobs between two dates

by Denis HUMEAU

Hello Lava users, I'm trying to build a query to monitor all the test jobs done in a given period. Let's say all the jobs done in January, just to check the robustness of my setup (incomplete jobs rate). In the query interface, I can add a condition on start_time of a job, but only with a "greater than" operator, when I want to add also a condition on start_time "less than". Do you have any hint to do this? Best regards, Denis

7 years, 2 months

3
3
0 0

USB-network gadget and LXC container

by Diego Russo

Hello, I have the following setup: a WaRP7 which exposes a network connection over USB gadget driver (http://trac.gateworks.com/wiki/linux/OTG#g_etherGadget) A possible test case is to have some process running on the LAVA dispatcher (within a LXC container) which targets the WaRP7 over this network interface. Through LXC I'm able to passtrhough this interface from the host to the container and use it within the container (via /etc/lxc/default.conf) If a test requires the reboot of the WaRP7, the usb0 interface disappears from the container. When the WaRP7 boots again the usb0 interface is available on the host (but not in the container). Things I tried or thought about: * I tried synchronizing boots both of the WaRP7 and LXC container but it seems not possible to "reboot" (restart) a container within the same job execution. * Is it possible to "restart" a container during a job execution? * Outside LAVA it is possible to run a command (lxc-device --name diegor-test -- add usb0) which re-passthrough the interface from Linux to LXC container. * Is it possible to run the above command ad job execution time on the lava dispatcher? How can I solve this situation? Cheers -- Diego Russo Staff Software Engineer - diego.russo(a)arm.com Direct Tel. no: +44 1223 405920 Main Tel. no: +44 1223 400400 ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - http://twitter.com/diegor http://www.linkedin.com/in/diegor 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.

7 years, 2 months

2
10
0 0

LAVA LMP still active?

by Tim Jaacks

Hello, while searching for possibilities of testing external interfaces of my DUTs I found this presentation: https://wiki.linaro.org/Internal/lava/Lava-lmp?action=AttachFile&do=get&tar… Is the LAVA LMP project still active? If yes, how can I find information on this? 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@01D4B71E.962E36E0] Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun

7 years, 2 months

3
4
0 0

u-boot one-too-many prompt problem

by Dan Rue

I'm sorry, as surely this is an FAQ but I've spent quite a bit of time troubleshooting and reading. This is very similar to Kevin's thread from May subject 'u-boot devices broken after 2018.4 upgrade, strange u-boot interaction'. In that thread's case, the issue was that interrupt_char was being set to "\n". My symptoms are the same, but interrupt_char is set to " " or "d". I'm running LAVA from the latest released containers (2018.11), and trying to use a beaglebone-black with a more recent u-boot than exists in validation.l.o. qemu works fine. The problem seems to be that LAVA thinks there's a prompt when there isn't, and so it sends commands too quickly. Here's example output from the serial console (job link[2]): U-Boot 2017.07 (Aug 31 2017 - 15:35:58 +0000) CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Net: cpsw, usb_ether Press SPACE to abort autoboot in 10 seconds => => setenv autoload no => setenv initrd_high 0xffffffff => setenv fdt_high 0xffffffff => dhcp link up on port 0, speed 100, full duplex BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 DHCP client bound to address 10.100.0.55 (1006 ms) => 172.28.0.4 Unknown command '172.28.0.4' - try 'help' => tftp 0x82000000 57/tftp-deploy-t7xus3ey/kernel/vmlinuz link up on port 0, speed 100, full duplex *** ERROR: `serverip' not set ... When I u-boot manually, after I hit SPACE (or 'd', both work), u-boot *deletes* the character and then prints '=> ' (is that delete the root cause?). When LAVA runs, it shows an extra => and starts typing as seen above. dhcp takes a second or two, and so the subsequent command starts to get lost (in the above log we see an IP, because 'setenv serverip' got lost). If I set boot_character_delay to like 1000, it works because it gives enough time for dhcp to finish before typing the next character, but obviously makes the job very slow, and still not reliable. I'm out of ideas.. help? P.S. Two interesting things I've learned recently: 1) boot_character_delay must be specified in device_types file. it's ignored when specified in the device file (surprising, as I see it listed in some people's device files[3]). 2) If you install ser2net from sid, you can set max-connections and do some _very handy_ voyeurism on the serial console while lava does its thing (hat tip Kevin Hilman for that one). Thanks, Dan [1] https://lists.lavasoftware.org/pipermail/lava-users/2018-May/001064.html [2] https://lava.therub.org/scheduler/job/57 [3] https://git.linaro.org/lava/lava-lab.git/tree/lkft.validation.linaro.org/ma… -- Linaro - Kernel Validation

7 years, 2 months

2
7
0 0

Re: [Lava-users] reboot during test

by cnspring2002

100 testcases, submit to lava before leave the office, expect to get all the results next morning. If everything is ok, get 100 results next morning, and check every issues. Then, e.g. the 10th cases OOM, I wish from 11st case to 100th cases can continue run during the night, so I want to reboot the device after 10th case which I find it OOM. Then after reboot, continue 11st case to 100 the cases. I know OOM not automation related, but if I do not resume the 11st ~ 100th cases during this night. I had to resubmit these cases tomorrow morning after I back to office, maybe the 100th case also have some bug, I wish it could send a result, then that morning I could assign other guy to fix it quickly, not wait I back to office then remove the 10th issue case, resubmit it, wait another 8 hours, finally execute the 100th case. 8 hours passed, we do not want the process's efficiency so low! This is our aim. ------------------------------------------------------------------ 发件人：lava-users-request <lava-users-request(a)lists.lavasoftware.org> 发送时间：2019年1月25日(星期五) 16:55 收件人：lava-users <lava-users(a)lists.lavasoftware.org> 主　题：Lava-users Digest, Vol 5, Issue 37 Send Lava-users mailing list submissions to lava-users(a)lists.lavasoftware.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.lavasoftware.org/mailman/listinfo/lava-users 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. reboot during test (cnspring2002) 2. Re: AOSP multiple node job (Neil Williams) 3. Re: reboot during test (Neil Williams) 4. Re: AOSP multiple node job (Chase Qi) ---------------------------------------------------------------------- Message: 1 Date: Thu, 24 Jan 2019 20:11:39 +0800 From: cnspring2002 <cnspring2002(a)aliyun.com> To: lava-users(a)lists.lavasoftware.org Subject: [Lava-users] reboot during test Message-ID: <C0C4B61B-7B5A-4DAB-B644-849E77F0119B(a)aliyun.com> Content-Type: text/plain; charset=us-ascii Dear all, In test stage, I have a case, when it run, one firmware OOM. So I trigger the device to reboot, Then all left case cannot run . I can not use multiple boot when define job in advance because I can not predict which case will make OOM, what you suggest doing? ------------------------------ Message: 2 Date: Thu, 24 Jan 2019 15:06:56 +0000 From: Neil Williams <neil.williams(a)linaro.org> To: Chase Qi <chase.qi(a)linaro.org> Cc: lava-users(a)lists.lavasoftware.org Subject: Re: [Lava-users] AOSP multiple node job Message-ID: <CAC6CAR3v_i-vOv4BVe56RHR4PahMihexpNa6v4w44UNb+_PVuw(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" On Thu, 24 Jan 2019 at 11:41, Chase Qi <chase.qi(a)linaro.org> wrote: > > Hi, > > In most cases, we don't need multiple node job as we can control AOSP > DUT from lxc via adb over USB. However, here is the use case. > > CTS/VTS tradefed-shell --shards option supports to split tests and run > them on multiple devices in parallel. To leverage the feature in LAVA, > we need multinode job, right? If more than one device needs to have images deployed and booted specifically for this test job, then yes. MultiNode is required. To be sure that each device is at the same stage (as deploy and boot timings can vary), the test job will need to wait for all test jobs to be synchronised to the same point in each test job - synchronisation is currently restricted to POSIX shells. > And in multinode job, master-node lxc > needs access to DUTs from salve nodes via adb over tcpip, right? Not necessarily. From the LXC, the device can be controlled using USB. There is no need for devices to have a direct connection to each other just to use MultiNode. The shards implementation may require that though. > Karsten shared a job example here[1]. This probably is the most > advanced usage of LAVA All MultiNode is a complex usage of LAVA but VLANd used by the networking teams is more complex than your use case. >, and probably also not encouraged? To make it > more clear, the connectivity should look like this. There is a problem in this model: Every DUT will have it's own LXC and that device will be connected to the LXC using USB. > master.lxc <----adb over usb----> master.dut > master.lxc <----adb over tcpip ---> slave1.dut > master.lxc <----adb over tcpip ---> slave2.dut Do not separate the LXC from the DUT - the LXC and it's DUT are a single node. Master DUT has a master LXC. Slave1 DUT has a Slave1 LXC Slave2 DUT has a Slave2 LXC. Depending on the boards in use, you may be able to configure each DUT, including the master DUT, to have TCP/IP networking. That then allows the processes running in the Master node to access the slave nodes. (The following model is based on a theoretical device which doesn't have the crippling USB OTG problem of the hikey - but the hikey can work in this model if the IP addresses are determined statically and therefore are available to each slave LXC.) 0: A program executing in the Master LXC which uses USB to send commands to the master DUT which allow the Master LXC to retrieve the IP address of the master DUT. 1: That program in the Master LXC then uses the MultiNode API (lava-send) to declare that IP address to all the slave nodes. This is equivalent to how existing jobs declare the IP address of the device when using secondary connections. 2: Each slave node waits for the master-ip-addr message and sets that value in a program executing in the slave LXC. The slave LXC is connected to the slave DUT directly using USB so can use this to set the master IP address, if that is required. 3: Each slave node now runs a program in each slave LXC to connect to the slave DUT over USB and extract the slave DUT IP address 4: Each slave node then broadcasts that slave-<ID>-ip-addr message, so the first slave sends slave-1-ip-addr containing an IP address, slave 2 sends slave-2-ip-addr containing a different IP address. 5: The master node is waiting for all of these messages to be sent and retrieves the values in turn. This information is now available to a program executing inside the master LXC. This program could use USB to set these values in the master DUT, if that is required. 6: During this time, all the slave nodes are waiting for the master node to broadcast another message saying that the work on the master is complete. 7: Once the master sends the complete message, each slave node picks up this message from the MultiNode API and the script executing in the slave LXC then ends the Lava Test Definition and the slave test job completes. 8: The master can then do some other stuff and then complete. https://staging.validation.linaro.org/scheduler/job/246447/multinode_defini… https://staging.validation.linaro.org/scheduler/job/246230/multinode_defini… Don't obsess about the LXC either. With upcoming changes for docker support, we could remove the presence of the LXC entirely. The LXC with android devices only exists as a unit of isolation for the benefit of the dispatcher. It has useful side effects but the reason for the LXC to exist is to separate the fastboot operations from the dispatcher operations. For hikey and it's broken USB OTG support: 0: Each slave test job turns off the USB OTG support once the slave LXC has deployed all the test image files and determined that the slave DUT has booted correctly. If not, use lava-test-raise. 1: Next, each slave LXC uses the IP address of it's own slave DUT to check connectivity. If this fails, use lava-test-raise. 2: Each slave LXC uses the MultiNode API to declare the IP address of the slave DUT (because the slave node has determined that this IP is working). 3: The master node is waiting for these messages and these are picked up by the master LXC test definition. 4: The master LXC test definition issues commands to the master DUT - now depending on how the sharding works, this could be over USB (turn the USB OTG off later) or over TCP/IP (turn off the master USB OTG at the start of this test definition). 5: The master DUT has enough information to drive the sharding across the slave DUTs. The slave LXCs are waiting for the master to finish the sharding. (lava-wait) 6: When the master LXC determines that the master DUT has finished the sharding, then the master LXC sends a message to all the slave nodes that the test is complete. 7: Each slave node picks up the completion message in the slave LXC and the test definition finishes. 8: The master node can continue to do other tasks or can also complete it's test definition. > .... > > I see two options for adb over tcpip. > > Option #1: WiFi. adb over wifi can be enabled easily by issuing adb > cmds from lxc. I am not using it for two reasons. Agreed, this doesn't need to rely on WiFi. > > * WiFi isn't reliable for long cts/vts test run. > * In Cambridge lab, WiFi sub-network isn't accessible from lxc > network. Because of security concerns, there is no plan to change > that. > > Option #2: Wired Ethernet. On devices like hikey, we need to run > 'pre-os-command' in boot action to power off OTG port so that USB > Ethernet dongle works. Once OTG port is off, lxc has no access to the > DUT, then test definition should be executed on DUT, right? I am also > having the following problems to do this. Before the OTG is switched, all data from the DUT needs to be retrieved (and set) using the USB connection. What information you need to set depends on how the sharding works. The problem, as I see it, is that the slave DUTs have no way to declare their IP address to the slave LXC once the OTG port is switched. Therefore, you will need to put in a request for the boards to have static IP addresses declared in the device dictionary. Then the OTG can be switched and things become easier because the LXC knows the IP address and can simply declare that to the MultiNode API so that the master LXC can know which IP matches which node. There are already a number of hikey devices with the static_ip device tag and you can specify this device tag in your MultiNode test definition. > > * Without context overriding, overlay tarball will be applied to > '/system' directory and test job reported "/system/bin/sh: Why are you talking about /system ??? MultiNode only operates in a POSIX shell - the POSIX shell is in the LXC and each DUT has a dedicated LXC. In this use case, MultiNode API calls are only going to be made from each LXC. The master LXC sends some information and then receives information from test definitions running in each of the slave LXCs. The overlay is to be deployed to the LXC, not the DUT because this is an Android system. What the android system does is determined either by commands run inside the slave LXC to deploy files (before the OTG switch) or commands run inside the master LXC (with knowledge of the IP address from the MultiNode API) to execute commands on the DUT over TCP/IP. Use the LXC to deploy the files and boot the device, then to declare information about each particular node. Once that is done, whatever thing is controlling the test needs to just use TCP/IP to communicate and use the MultiNode API to send messages and allow some nodes to wait for other nodes whilst the test proceeds. > /lava-247856/bin/lava-test-runner: not found"[2]. > * With the following job context, LAVA still runs > '/lava-24/bin/lava-test-runner /lava-24/0' and it hangs there. It is > tested in my local LAVA instance, test job definition and test log > attached. Maybe my understanding on the context overriding is wrong, I > thought LAVA should execute '/system/lava-24/bin/lava-test-runner > /system/lava-24/0' instead. Any suggestions would be appreciated. > > context: > lava_test_sh_cmd: '/system/bin/sh' > lava_test_results_dir: '/system/lava-%s' > > I checked on the DUT directly, '/system/lava-%s' exist, but I cannot > really run lava-test-runner. The shebang line seems problematic. > > --- hacking --- > hikey:/system/lava-24/bin # ./lava-test-runner > /system/bin/sh: ./lava-test-runner: No such file or directory > hikey:/system/lava-24/bin # cat lava-test-runner > #!/bin/bash > > #!/bin/sh > > .... > # /system/bin/sh lava-test-runner > lava-test-runner[18]: .: /lava/../bin/lava-common-functions: No such > file or directory > --- ends --- > > I had a discussion with Milosz. He proposed the third option which > probably will be the most reliable one, but it is not supported in > LAVA yet. Here is the idea. Milosz, feel free to explain more. > > **Option #3**: Add support for accessing to multiple DUTs in single node job. > > * Physically, we need the DUTs connected via USB cable to the same dispatcher. I don't see that this solves anything and it adds a lot of unnecessary lab configuration - entirely duplicating the point of having ethernet connections to the boards. Assign static IP addresses to each board and when the test job starts, each dedicated LXC can declare the static information according to whichever board was assigned to whichever node. The DUTs only need to be visible to programs running on the master node and that can be done by declaring static IP addresses using the MultiNode API. > * In single node job, LAVA needs to add the DUTs specified(somehow) or > assigned randomly(lets say both device type and numbers defined) to > the same lxc container. Test definitions can take over from here. No - the LXC is used to issue commands to deploy test images to the DUT. The LXC is a transparent part of the dispatcher, it is not just for test definitions. The LXC cannot be used for multiple test jobs, it is part of the one dispatcher. > > Is this can be done in LAVA? Can I require the feature? Any > suggestions on the possible implementations? > > > Thanks, > Chase > > [1] https://review.linaro.org/#/c/qa/test-definitions/+/29417/4/automated/andro… > [2] https://staging.validation.linaro.org/scheduler/job/247856#L1888 > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.lavasoftware.org > https://lists.lavasoftware.org/mailman/listinfo/lava-users -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/ ------------------------------ Message: 3 Date: Thu, 24 Jan 2019 15:09:58 +0000 From: Neil Williams <neil.williams(a)linaro.org> To: cnspring2002 <cnspring2002(a)aliyun.com> Cc: lava-users(a)lists.lavasoftware.org Subject: Re: [Lava-users] reboot during test Message-ID: <CAC6CAR3fV+b1p5T2EVxUCPP7d=Erno-20MNVxPaZPVf3tbK3Yg(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" On Thu, 24 Jan 2019 at 12:13, cnspring2002 <cnspring2002(a)aliyun.com> wrote: > > Dear all, > > In test stage, I have a case, when it run, one firmware OOM. So I trigger the device to reboot, Then all left case cannot run . I can not use multiple boot when define job in advance because I can not predict which case will make OOM, what you suggest doing? The out of memory killer is a fatal device error. The test job is not going to be able to continue because the failure mode is unpredictable. The cause of the OOM needs to be determined through standard triage, not automation. (Although automation may help create a data matrix of working and failing combinations and test operations.) -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/ ------------------------------ Message: 4 Date: Fri, 25 Jan 2019 15:45:56 +0800 From: Chase Qi <chase.qi(a)linaro.org> To: Neil Williams <neil.williams(a)linaro.org> Cc: lava-users(a)lists.lavasoftware.org Subject: Re: [Lava-users] AOSP multiple node job Message-ID: <CADzYPRFJiX8qKt_NyHZCi0qs5iotx0wg0OMN9o7SOi84sYYTow(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Neil, Thanks a lot for your guidance. It is really good to see you back :) On Thu, Jan 24, 2019 at 11:07 PM Neil Williams <neil.williams(a)linaro.org> wrote: > > On Thu, 24 Jan 2019 at 11:41, Chase Qi <chase.qi(a)linaro.org> wrote: > > > > Hi, > > > > In most cases, we don't need multiple node job as we can control AOSP > > DUT from lxc via adb over USB. However, here is the use case. > > > > CTS/VTS tradefed-shell --shards option supports to split tests and run > > them on multiple devices in parallel. To leverage the feature in LAVA, > > we need multinode job, right? > > If more than one device needs to have images deployed and booted > specifically for this test job, then yes. MultiNode is required. To be > sure that each device is at the same stage (as deploy and boot timings > can vary), the test job will need to wait for all test jobs to be > synchronised to the same point in each test job - synchronisation is > currently restricted to POSIX shells. > > > And in multinode job, master-node lxc > > needs access to DUTs from salve nodes via adb over tcpip, right? > > Not necessarily. From the LXC, the device can be controlled using USB. > There is no need for devices to have a direct connection to each other > just to use MultiNode. The shards implementation may require that > though. CTS/VTS sharding shards a run into given number of independent chunks, to run on multiple devices that connected to the same host. The host will be the master lxc in our case. > > > Karsten shared a job example here[1]. This probably is the most > > advanced usage of LAVA > > All MultiNode is a complex usage of LAVA but VLANd used by the > networking teams is more complex than your use case. > > >, and probably also not encouraged? To make it > > more clear, the connectivity should look like this. > > There is a problem in this model: Every DUT will have it's own LXC and > that device will be connected to the LXC using USB. > > > master.lxc <----adb over usb----> master.dut > > master.lxc <----adb over tcpip ---> slave1.dut > > master.lxc <----adb over tcpip ---> slave2.dut > > Do not separate the LXC from the DUT - the LXC and it's DUT are a single node. > > Master DUT has a master LXC. > Slave1 DUT has a Slave1 LXC > Slave2 DUT has a Slave2 LXC. > > Depending on the boards in use, you may be able to configure each DUT, > including the master DUT, to have TCP/IP networking. That then allows > the processes running in the Master node to access the slave nodes. > Yes, that is what I am trying to do. The above connectivity topology I wrote is the goal not the initial state with LAVA design. Master lxc needs access to all the DUT nodes, either via USB or tcpip. > (The following model is based on a theoretical device which doesn't > have the crippling USB OTG problem of the hikey - but the hikey can > work in this model if the IP addresses are determined statically and > therefore are available to each slave LXC.) > > 0: A program executing in the Master LXC which uses USB to send > commands to the master DUT which allow the Master LXC to retrieve the > IP address of the master DUT. > > 1: That program in the Master LXC then uses the MultiNode API > (lava-send) to declare that IP address to all the slave nodes. This is > equivalent to how existing jobs declare the IP address of the device > when using secondary connections. > > 2: Each slave node waits for the master-ip-addr message and sets that > value in a program executing in the slave LXC. The slave LXC is > connected to the slave DUT directly using USB so can use this to set > the master IP address, if that is required. > > 3: Each slave node now runs a program in each slave LXC to connect to > the slave DUT over USB and extract the slave DUT IP address > > 4: Each slave node then broadcasts that slave-<ID>-ip-addr message, so > the first slave sends slave-1-ip-addr containing an IP address, slave > 2 sends slave-2-ip-addr containing a different IP address. > > 5: The master node is waiting for all of these messages to be sent and > retrieves the values in turn. This information is now available to a > program executing inside the master LXC. This program could use USB to > set these values in the master DUT, if that is required. > > 6: During this time, all the slave nodes are waiting for the master > node to broadcast another message saying that the work on the master > is complete. > > 7: Once the master sends the complete message, each slave node picks > up this message from the MultiNode API and the script executing in the > slave LXC then ends the Lava Test Definition and the slave test job > completes. > > 8: The master can then do some other stuff and then complete. > > https://staging.validation.linaro.org/scheduler/job/246447/multinode_defini… > > https://staging.validation.linaro.org/scheduler/job/246230/multinode_defini… > > Don't obsess about the LXC either. With upcoming changes for docker > support, we could remove the presence of the LXC entirely. The LXC > with android devices only exists as a unit of isolation for the > benefit of the dispatcher. It has useful side effects but the reason > for the LXC to exist is to separate the fastboot operations from the > dispatcher operations. > > For hikey and it's broken USB OTG support: > > 0: Each slave test job turns off the USB OTG support once the slave > LXC has deployed all the test image files and determined that the > slave DUT has booted correctly. If not, use lava-test-raise. > > 1: Next, each slave LXC uses the IP address of it's own slave DUT to > check connectivity. If this fails, use lava-test-raise. > > 2: Each slave LXC uses the MultiNode API to declare the IP address of > the slave DUT (because the slave node has determined that this IP is > working). > > 3: The master node is waiting for these messages and these are picked > up by the master LXC test definition. > > 4: The master LXC test definition issues commands to the master DUT - > now depending on how the sharding works, this could be over USB (turn > the USB OTG off later) or over TCP/IP (turn off the master USB OTG at > the start of this test definition). > > 5: The master DUT has enough information to drive the sharding across > the slave DUTs. The slave LXCs are waiting for the master to finish > the sharding. (lava-wait) > > 6: When the master LXC determines that the master DUT has finished the > sharding, then the master LXC sends a message to all the slave nodes > that the test is complete. > > 7: Each slave node picks up the completion message in the slave LXC > and the test definition finishes. > > 8: The master node can continue to do other tasks or can also complete > it's test definition. > > > > .... > > > > I see two options for adb over tcpip. > > > > Option #1: WiFi. adb over wifi can be enabled easily by issuing adb > > cmds from lxc. I am not using it for two reasons. > > Agreed, this doesn't need to rely on WiFi. > > > > > * WiFi isn't reliable for long cts/vts test run. > > * In Cambridge lab, WiFi sub-network isn't accessible from lxc > > network. Because of security concerns, there is no plan to change > > that. > > > > Option #2: Wired Ethernet. On devices like hikey, we need to run > > 'pre-os-command' in boot action to power off OTG port so that USB > > Ethernet dongle works. Once OTG port is off, lxc has no access to the > > DUT, then test definition should be executed on DUT, right? I am also > > having the following problems to do this. > > Before the OTG is switched, all data from the DUT needs to be > retrieved (and set) using the USB connection. > > What information you need to set depends on how the sharding works. > > The problem, as I see it, is that the slave DUTs have no way to > declare their IP address to the slave LXC once the OTG port is > switched. Therefore, you will need to put in a request for the boards That is the problem I had. And that is why I was trying to run test definition on Android DUT directly to enable adb over tcpip and declare IP address. As you mentioned below, it is the wrong direction. > to have static IP addresses declared in the device dictionary. Then > the OTG can be switched and things become easier because the LXC knows > the IP address and can simply declare that to the MultiNode API so > that the master LXC can know which IP matches which node. There are > already a number of hikey devices with the static_ip device tag and > you can specify this device tag in your MultiNode test definition. Brilliant and brand new idea to me. I didn't realize static-ip tag is the solution. I have managed to enable and test adb over tcpip in this way(In my local instance). I have attached my test job definition here in case it is any help for other LAVA users. The following definitions are essential. tags: - static-ip reboot_to_fastboot: false - test: namespace: tlxc timeout: minutes: 10 protocols: lava-lxc: - action: lava-test-shell request: pre-os-command timeout: minutes: 2 Thanks, Chase > > > > > * Without context overriding, overlay tarball will be applied to > > '/system' directory and test job reported "/system/bin/sh: > > Why are you talking about /system ??? MultiNode only operates in a > POSIX shell - the POSIX shell is in the LXC and each DUT has a > dedicated LXC. In this use case, MultiNode API calls are only going to > be made from each LXC. The master LXC sends some information and then > receives information from test definitions running in each of the > slave LXCs. > > The overlay is to be deployed to the LXC, not the DUT because this is > an Android system. What the android system does is determined either > by commands run inside the slave LXC to deploy files (before the OTG > switch) or commands run inside the master LXC (with knowledge of the > IP address from the MultiNode API) to execute commands on the DUT over > TCP/IP. > > Use the LXC to deploy the files and boot the device, then to declare > information about each particular node. Once that is done, whatever > thing is controlling the test needs to just use TCP/IP to communicate > and use the MultiNode API to send messages and allow some nodes to > wait for other nodes whilst the test proceeds. > > > /lava-247856/bin/lava-test-runner: not found"[2]. > > * With the following job context, LAVA still runs > > '/lava-24/bin/lava-test-runner /lava-24/0' and it hangs there. It is > > tested in my local LAVA instance, test job definition and test log > > attached. Maybe my understanding on the context overriding is wrong, I > > thought LAVA should execute '/system/lava-24/bin/lava-test-runner > > /system/lava-24/0' instead. Any suggestions would be appreciated. > > > > context: > > lava_test_sh_cmd: '/system/bin/sh' > > lava_test_results_dir: '/system/lava-%s' > > > > I checked on the DUT directly, '/system/lava-%s' exist, but I cannot > > really run lava-test-runner. The shebang line seems problematic. > > > > --- hacking --- > > hikey:/system/lava-24/bin # ./lava-test-runner > > /system/bin/sh: ./lava-test-runner: No such file or directory > > hikey:/system/lava-24/bin # cat lava-test-runner > > #!/bin/bash > > > > #!/bin/sh > > > > .... > > # /system/bin/sh lava-test-runner > > lava-test-runner[18]: .: /lava/../bin/lava-common-functions: No such > > file or directory > > --- ends --- > > > > I had a discussion with Milosz. He proposed the third option which > > probably will be the most reliable one, but it is not supported in > > LAVA yet. Here is the idea. Milosz, feel free to explain more. > > > > **Option #3**: Add support for accessing to multiple DUTs in single node job. > > > > * Physically, we need the DUTs connected via USB cable to the same dispatcher. > > I don't see that this solves anything and it adds a lot of unnecessary > lab configuration - entirely duplicating the point of having ethernet > connections to the boards. Assign static IP addresses to each board > and when the test job starts, each dedicated LXC can declare the > static information according to whichever board was assigned to > whichever node. > > The DUTs only need to be visible to programs running on the master > node and that can be done by declaring static IP addresses using the > MultiNode API. > > > * In single node job, LAVA needs to add the DUTs specified(somehow) or > > assigned randomly(lets say both device type and numbers defined) to > > the same lxc container. Test definitions can take over from here. > > No - the LXC is used to issue commands to deploy test images to the > DUT. The LXC is a transparent part of the dispatcher, it is not just > for test definitions. The LXC cannot be used for multiple test jobs, > it is part of the one dispatcher. > > > > > Is this can be done in LAVA? Can I require the feature? Any > > suggestions on the possible implementations? > > > > > > Thanks, > > Chase > > > > [1] https://review.linaro.org/#/c/qa/test-definitions/+/29417/4/automated/andro… > > [2] https://staging.validation.linaro.org/scheduler/job/247856#L1888 > > _______________________________________________ > > Lava-users mailing list > > Lava-users(a)lists.lavasoftware.org > > https://lists.lavasoftware.org/mailman/listinfo/lava-users > > > > -- > > Neil Williams > ============= > neil.williams(a)linaro.org > http://www.linux.codehelp.co.uk/

7 years, 2 months

2
1
0 0

reboot during test

by cnspring2002

Dear all, In test stage, I have a case, when it run, one firmware OOM. So I trigger the device to reboot, Then all left case cannot run . I can not use multiple boot when define job in advance because I can not predict which case will make OOM, what you suggest doing?

7 years, 2 months

2
1
0 0

Import junit data into LAVA

by Diego Russo

Hello list, Apologies if this question has been asked already. I have a test framework which spits out a junit file. What’s the best way to import data from the junit file into 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.

7 years, 2 months

3
2
0 0

Reboot DUT during job execution

by Diego Russo

Hello, we have the need to perform tests that require reboots of the DUT between their executions. Few examples are to check rootfs upgrades or to check configurations changes to persist . I have few questions: * Does LAVA support those cases? * If yes, does LAVA support multiple reboots? * If yes, how can I write tests in order to run different sets of tests at any boot. * Example: 1) do an upgrade 2) reboot the device 3) Check if the upgrade was successful * How can I structure my pipeline? 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.

7 years, 2 months

2
4
0 0

Re: [Lava-users] How can I run lava-publisher service in docker container?

by Remi Duraffort

> > > When Lava start test or finish the test job, squad zmq SUB socket seems > not receive log message from lava-server. > > It just print out '[2019-01-22 08:26:24 +0000] [DEBUG] > nexell.lava.server2: connected to tcp://192.168.1.20:2222:5500'. > The url is really strange as two port numbers are specified. Should be "tcp://192.168.1.20:5500" Rgds -- Rémi Duraffort LAVA Team, Linaro

7 years, 2 months

1
0
0 0

Reboot DUT during job execution

by Diego Russo

Hello, we have the need to perform tests that require reboots of the DUT between their executions. Few examples are to check rootfs upgrades or to check configurations changes to persist . I have few questions: * Does LAVA support those cases? * If yes, does LAVA support multiple reboots? * If yes, how can I write tests in order to run different sets of tests at any boot. * Example: 1) do an upgrade 2) reboot the device 3) Check if the upgrade was successful * How can I structure my pipeline? 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.

7 years, 2 months

1
0
0 0

Piece of advice to combine interactive boot and Linux testing

by Denis HUMEAU

Dear Lava users, I'm trying to create a job that performs the following steps : Deploy to flasher our custom tool (OK) Boot in bootloader mode - u-boot (OK) Test in interactive mode (OK) From interactive mode start kernel (OK) Launch a test from kernel (KO) The last part fails because I don't know where to check the kernel prompt. I cannot add a boot stage and declare an additional prompt because I don't want to reboot, that would reset the configuration done in interactive mode. Do you have any piece of advice or example of job showing how to proceed to manage the kernel prompt & autologin in such a job? Best regards, Denis

7 years, 2 months

4
18
0 0

check boot stages versions in a Lava job

by Denis HUMEAU

Hello, A request from some Lava users internally. We have 3 boot stages, TF-A, U-boot, and kernel. Is there a way, in a Lava job, to test that these components' versions are the expected ones? That would mean, as far as I understand, not testing the embedded software itself, but the Lava job log... Best regards, Denis

7 years, 2 months

3
3
0 0

How to upgrade lava without data loss?

by Larry Shen

Two questions here: 1. If a master-only instance here, how to upgrade without data loss? 2. If a slave-only instance here, how to upgrade without data loss? Please suggest, thanks.

7 years, 2 months

3
3
0 0

Loading LAVA specific kernel modules fails

by Tim Jaacks

Hello, the lava-dispatcher package installs a file in /etc/modules-load.d/lava-modules.conf, containing the following lines: install ipv6 modprobe ipv6 install brltty /bin/false On my debian 9.3 system, this file leads to failures when the systemd-modules-load service starts: Job for systemd-modules-load.service failed because the control process exited with error code. See "systemctl status systemd-modules-load.service" and "journalctl -xe" for details. The details in journalctl say: Jan 07 15:08:30 a048 systemd[1]: Starting Load Kernel Modules... -- Subject: Unit systemd-modules-load.service has begun start-up -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit systemd-modules-load.service has begun starting up. Jan 07 15:08:30 a048 systemd-modules-load[2088]: Failed to find module 'install ipv6 modprobe ipv6' Jan 07 15:08:30 a048 systemd-modules-load[2088]: Failed to find module 'install brltty /bin/false' Jan 07 15:08:30 a048 systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE Jan 07 15:08:30 a048 systemd[1]: Failed to start Load Kernel Modules. Obviously the "install" syntax is supported only in /etc/modprobe.d: https://manpages.debian.org/stretch/kmod/modprobe.d.5.en.html But not in /etc/modules-load.d: https://manpages.debian.org/stretch/systemd/modules-load.d.5.en.html Is this a known issue? 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

7 years, 2 months

2
4
0 0

How to run off DUT tests?

by Diego Russo

Folks, We have the need to run some tests which requires a process off DUT to be executed. Examples are: * port scan like process against the DUT * cli tests which interact with the DUT The workflow could be like: * Deploy the DUT * Boot the DUT * Run a process off DUT (actual test) * Collect test results In our setup we assume there is always a network connection between the DUT and the LAVA dispatcher. How can we achieve such workflow with 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.

7 years, 3 months

2
2
0 0

Lavacli : configuration to get lava jobs logs

by Philippe BEGNIC

Dear all, I need to get "jobs logs" using lavacli. To do that, I use the following command : lavacli jobs logs <job_id> I can perform this operation with a user that has a profile "superuser". We have also users with restricted permissions ( they can only submit jobs using lavacli ), and I would like them to get logs using lavacli. So, I have consulted in the Lava django administration page, the users permission that can be set, but I could not find which option could allow a "basic user" to get log jobs using lavacli. Is it possible to allow a user with "basic profile" to do that ? If yes, with user permission have to be set ? Best regards Philippe Begnic

7 years, 3 months

2
2
0 0

zmq example not work

by cnspring2002

Just use the sample command "python zmq_client.py -j 357 --hostname tcp://127.0.0.1:5500 -t 1200" Get the error: Traceback (most recent call last): File "zmq_client_1.py", line 155, in <module> main() File "zmq_client_1.py", line 139, in main publisher = lookup_publisher(options.hostname, options.https) File "zmq_client_1.py", line 109, in lookup_publisher socket = server.scheduler.get_publisher_event_socket() File "/usr/lib/python3.5/xmlrpc/client.py", line 1092, in __call__ return self.__send(self.__name, args) File "/usr/lib/python3.5/xmlrpc/client.py", line 1432, in __request verbose=self.__verbose File "/usr/lib/python3.5/xmlrpc/client.py", line 1134, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib/python3.5/xmlrpc/client.py", line 1146, in single_request http_conn = self.send_request(host, handler, request_body, verbose) File "/usr/lib/python3.5/xmlrpc/client.py", line 1259, in send_request self.send_content(connection, request_body) File "/usr/lib/python3.5/xmlrpc/client.py", line 1289, in send_content connection.endheaders(request_body) File "/usr/lib/python3.5/http/client.py", line 1103, in endheaders self._send_output(message_body) File "/usr/lib/python3.5/http/client.py", line 934, in _send_output self.send(msg) File "/usr/lib/python3.5/http/client.py", line 877, in send self.connect() File "/usr/lib/python3.5/http/client.py", line 849, in connect (self.host,self.port), self.timeout, self.source_address) File "/usr/lib/python3.5/socket.py", line 694, in create_connection for res in getaddrinfo(host, port, 0, SOCK_STREAM): File "/usr/lib/python3.5/socket.py", line 733, in getaddrinfo for res in _socket.getaddrinfo(host, port, family, type, proto, flags): socket.gaierror: [Errno -2] Name or service not known I wonder for following code, why http://tcp://127.0.0.1:5500/RPC2 will finally be passed to ServerProxy? If I remove http, just tcp://127.0.0.1:5500/RPC2, it will say "OSError: unsupported XML-RPC protocol" If I remove tcp, just http://127.0.0.1:5500/RPC2, it will hang in get_publisher_event_socket I use 2018.11 version, please suggest!!! xmlrpc_url = "http://%s/RPC2" % (hostname) if https: xmlrpc_url = "https://%s/RPC2" % (hostname) server = xmlrpc.client.ServerProxy(xmlrpc_url) try: socket = server.scheduler.get_publisher_event_socket()

7 years, 3 months

2
1
0 0

How can I run lava-publisher service in docker container?

by tomato

I am trying to submit test job using squad. When squad fetch the result of lava, the interval is too long. It takes at least 1 hour. I want to reduce fetch time as short as possible. This is what Squad team answer. Alternatively you can turn on ZMQ notifications in LAVA and run squad listener. This will cause test results to be fetched immediately after the test job finishes in LAVA. Enabling ZMQ publisher: https://master.lavasoftware.org/static/docs/v2/advanced-installation.html#c…. SQUAD listener is a separate process. It doesn't need any additional settings on top of what you already have. So I want to try restart lava-publisher service. I am running lava-server and dispatcher using Linaro lava docker image. On docker container, there is no service named lava-publisher. How can I manage this? Thanks.

7 years, 3 months

2
1
0 0

Differentiate RPi3 B and B+ on LAVA

by Diego Russo

Hello, Our LAVA deployment has both RPi3 B and B+ and we are interested only on the 32bit version. The device type to use looks like: https://git.lavasoftware.org/lava/lava/blob/master/lava_scheduler_app/tests… Does this device type cover both B and B+? I mean, can we use it for B+ as well? If yes, what's the best way to differentiate those on LAVA? Creating a new device type for B+ (which is the same of the above) or using tags? 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.

7 years, 3 months

2
1
0 0

Splitting the lava-server docker image

by Olli Vainola

Hi, I've been using the lava-server docker image (hub.lavasoftware.org/lava/lava/lava-server:2018.10) for a couple of weeks and I had some problems on making the data persistent for the postgres (mapping the volume from host to container). Anyways I decided to take postgres out from the startup by modifying the entrypoint.sh file: ++++++++++++++ Added these lines after start_lava_server_gunicorn -function ++++++++++++++++++++++++++ if [[ ! -z $DJANGO_POSTGRES_SERVER ]]; then txt="s/LAVA_DB_SERVER=\"localhost\"/LAVA_DB_SERVER=\"$DJANGO_POSTGRES_SERVER\"/g" sed -i $txt /etc/lava-server/instance.conf fi if [[ ! -z $DJANGO_POSTGRES_PORT ]]; then txt="s/LAVA_DB_PORT=\"5432\"/LAVA_DB_PORT=\"$DJANGO_POSTGRES_PORT\"/g" sed -i $txt /etc/lava-server/instance.conf fi ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ---------------------------- Commented out these lines ----------------------------- # Start all services #echo "Starting postgresql" #/etc/init.d/postgresql start #echo "done" #echo #echo "Waiting for postgresql" #wait_postgresql #echo "[done]" #echo -------------------------------------------- ---------------------------------------------------- After that I created a new Dockerfile and built a new image: +++++++++++++++++++++++++ Dockerfile +++++++++++++++++++++++ FROM hub.lavasoftware.org/lava/lava/lava-server:2018.10 COPY ./entrypoint.sh /root/ RUN chmod 755 /root/entrypoint.sh ENTRYPOINT ["/root/entrypoint.sh"] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> sudo docker build -t lava-server:mod . Just to get all up and running I made a docker-compose.yml file to kick postgres and lava-server up +++++++++++++++++++++++++++ docker-compose.yml +++++++++++++++++++++++++ version: '3' services: postgres: image: postgres:11 restart: always environment: POSTGRES_DB: lavaserver POSTGRES_USER: lavaserver POSTGRES_PASSWORD: d3e5d13fa15f lava-server: depends_on: - postgres image: lava-server:mod environment: DJANGO_POSTGRES_PORT: 5432 DJANGO_POSTGRES_SERVER: postgres ports: - "80:80" +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I still feel that there is too much going on inside that lava-server:mod image, since it has following softwares running: * Lavamaster * Gunicorn * Logger * Publisher What do you think, should I still break it into smaller pieces? Pros on this would be that softwares wouldn't die silently (started by using '&' and docker could try to restart them), logs would be in their own logs windows' (docker log CONTAINER) and containers themselves would be more configurable via environment variables. Br Olli Väinölä 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.

7 years, 3 months

4
4
0 0

Re: [Lava-users] [Lava-announce] Regular LAVA team design discussions open to developers

by Milosz Wasilewski

On Wed, 16 Jan 2019 at 17:33, Steve McIntyre <steve.mcintyre(a)linaro.org> wrote: > > Hi, > > In founding the LAVA Software Community Project, the team planned to > open up LAVA development more. As already announced by Neil in > September, we have already moved our infrastructure to a GitLab > instance and LAVA developers and users can collaborate there. [1] > > The next step in our process is to also open our regular development > design meetings to interested developers. The LAVA design meeting is > where the team gets together to work out deep technical issues, and to > agree on future development goals and ideas. We run these as a weekly > video conference using Google Hangouts Meet [2], We now wish to > welcome other interested developers to join us there too, to help us > develop LAVA. Steve, the only missing bit is which day and what time? :) milosz > > Summaries of the meetings will be posted regularly to the lava-devel > mailing list [3], and we encourage interested people to subscribe and > discuss LAVA development there. > > [1] https://git.lavasoftware.org/ > [2] https://meet.google.com/qre-rgen-zwc > [3] https://lists.lavasoftware.org/mailman/listinfo/lava-devel > > Cheers, > -- > Steve McIntyre steve.mcintyre(a)linaro.org > <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs > _______________________________________________ > Lava-announce mailing list > Lava-announce(a)lists.lavasoftware.org > https://lists.lavasoftware.org/mailman/listinfo/lava-announce

7 years, 3 months

2
1
0 0

Change archive and media path

by Axel Lebourhis

Hi everyone, I want to change the default path of MEDIA_ROOT and ARCHIVE_ROOT. So in /etc/lava-server-settings.conf I wrote this : "MEDIA_ROOT": "/data/lava/var/lib/lava-server/default/media", "ARCHIVE_ROOT": "/data/lava/var/lib/lava-server/default/archive", This seems to work but the web UI doesn't display the job output and when I try to download the plain log, it returns an error saying it can't be found. Could you tell me what should I do to make the web ui find the job outputs ? Best regards, Axel

7 years, 3 months

1
1
0 0

Git authentication

by Pete Dyer

In the thread about Git Authentication a solution was proposed using git credentials and the fact that the dispatcher is running as root. See: https://lists.lavasoftware.org/pipermail/lava-users/2018-December/001455.ht… I've worked out that even though the dispatcher is running as root, the environment is purged based upon env.yaml that is sent over from the master. I found that I had to add HOME=/root into env.yaml on the master for the git clone to pick up the files in the /root folder. Hope this helps anyone else trying to do this. 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.

7 years, 3 months

1
0
0 0

Re: [Lava-users] Change site issue

by Chuan Su

Dear Remi, I ran those commands you suggested in lava shell and it printed as below : Python 3.5.3 (default, Jan 19 2017, 14:11:04) [GCC 6.3.0 20170118] on linux Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from django.contrib.sites.models import Site >>> Site.objects.all() <QuerySet [<Site: 192.168.100.103>]> >>> Site.objects.count() 1 >>>

7 years, 3 months

2
4
0 0

Login issue

by Chuan Su

Dear all, I was encountered with a login in issue . I've changed domain name and display name to IP , but when I relogin now, I can't reach login page , and it reports as below : 500 Internal Server ErrorSite matching query does not exist. Oops, something has gone wrong! And I set 'DEBUG = True' in settings.conf , and it reported like below : DoesNotExist at /accounts/login/ Site matching query does not exist. | Request Method: | GET | | Request URL: | http://127.0.0.1:8000/accounts/login/?next=/scheduler/job/42 | | Django Version: | 1.11.14 | | Exception Type: | DoesNotExist | | Exception Value: | Site matching query does not exist. | | Exception Location: | /usr/lib/python3/dist-packages/django/db/models/query.py in get, line 380 | | Python Executable: | /usr/bin/python3 | | Python Version: | 3.5.3 | | Python Path: | ['/', '/usr/bin', '/usr/lib/python35.zip', '/usr/lib/python3.5', '/usr/lib/python3.5/plat-x86_64-linux-gnu', '/usr/lib/python3.5/lib-dynload', '/usr/local/lib/python3.5/dist-packages', '/usr/local/lib/python3.5/dist-packages/icsectl-0.2-py3.5.egg', '/usr/lib/python3/dist-packages'] | So I just wanna know how can I set it back? Yours , sincerely Su Chuan

7 years, 3 months

1
0
0 0

RPI3 and disk image

by Diego Russo

Hello LAVA mailing list, I see RPI3 is supported by LAVA but unfortunately it doesn't fit Mbed Linux OS (MBL) case. Our build system produces a WIC image which can be written on the SD card directly (instructions here: https://os.mbed.com/docs/linux-os/v0.5/getting-started/writing-and-booting-…). This is needed for two main reasons: * MBL has its own booting flow * MBL expects a partition layout (not only the rootfs) with multiple partitions in order to work. What's the best way to automate the deployment on MBL on RPI3 via LAVA in order to run our tests? 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.

7 years, 3 months

4
6
0 0

How can I use multiple devices under one device type?

by tomato

Hi, I have trouble with using multiple devices under one device type. https://validation.linaro.org/scheduler/device_type/beaglebone-black I want to test devices using same device type like above. To do this, I did below steps. 1) Add device type $ lava-server manage device-types s5p4418-navi-type 2) Add device type $ lava-server manage devices add --device-types s5p4418-navi-type --worker new_lava_slave s5p4418-navi-ref-qt $ lava-server manage devices add --device-types s5p4418-navi-type --worker new_lava_slave s5p4418-navi-ref-ref 3) Add device dictionary import xmlrpc.client import sys username = "admin" token = "bpexdhlth2sckkst1pslnklklw9enis92oe0ncqc4n7yby6mb5bxapof9ll503gqcqaq3rbq6o1765njgtydwozsjudur9bee8escj4zblqmbds0el0ud10qclbbn2hs" hostname = "192.168.1.20:9099" server = xmlrpc.client.ServerProxy("http://%s:%s@%s/RPC2" % (username, token, hostname), allow_none=True) # s5p4418-navi-ref-qt file = open('/home/lava/bin/nexell-device-dic/s5p4418-navi-ref-qt.jinja2','r') jinja_string = file.read() file.close() server.scheduler.import_device_dictionary("s5p4418-navi-ref-qt", jinja_string) # s5p4418-navi-ref file = open('/home/lava/bin/nexell-device-dic/s5p4418-navi-ref.jinja2','r') jinja_string = file.read() file.close() server.scheduler.import_device_dictionary("s5p4418-navi-ref", jinja_string) updated device dictionary using above python code. 4) Submit job import xmlrpc.client import sys import argparse username = "admin" token = "bpexdhlth2sckkst1pslnklklw9enis92oe0ncqc4n7yby6mb5bxapof9ll503gqcqaq3rbq6o1765njgtydwozsjudur9bee8escj4zblqmbds0el0ud10qclbbn2hs" hostname = "192.168.1.20:9099" def args_parser(): """ args parser. """ parser = argparse.ArgumentParser() parser.add_argument('job_file', help="job_file", type=argparse.FileType('r')) return parser.parse_args() def loadJob(): return args.job_file.read() def process(): print ("Submitting test job to LAVA server") global args args = args_parser() server = xmlrpc.client.ServerProxy("http://%s:%s@%s/RPC2" % (username, token, hostname), allow_none=True) yamlfile = loadJob() #print(yamlfile) server.scheduler.submit_job(yamlfile) process() $ python3 submit.py test.yaml When I submitted test job using above python code, lava server did test on device named s5p4418-navi-ref. I wanted test device named 's5p4418-navi-ref-qt'. But test is run under the device named 's5p4418-navi-ref'. This is test yaml file I submitted. device_type: s5p4418-navi-type job_name: s5p4418-navi-ref-qt-deploy-test timeouts: job: minutes: 60 action: minutes: 30 connection: minutes: 20 priority: medium visibility: public protocols: lava-lxc: name: s5p4418-test template: debian distribution: debian release: jessie arch: amd64 actions: - deploy: failure_retry: 3 namespace: s5p4418-deploy timeout: minutes: 10 to: fastboot images: nexell_ext: url: /home/lava-slave/LAVA-TEST/ dir_name: result-s5p4418-navi-ref-qt deploy_script: /home/lava/bin/nexell-lava-commands.sh deploy_command1: reboot-bootloader deploy_command2: fastboot-download #deploy_command1: test1 #deploy_command2: test2 device_path: '/dev/ttyUSB0' afterdeploy_command1: 'False' afterdeploy_command2: 'False' test: nothing os: oe - boot: namespace: s5p4418-deploy method: fastboot prompts: - 'root@s5p4418-navi-ref:~#' auto_login: login_prompt: 's5p4418-navi-ref login:' username: root parameters: shutdown-message: "reboot: Restarting system" timeout: minutes: 10 nexell_ext: command: /home/lava/bin/nexell-lava-commands.sh dir_name: result-s5p4418-navi-ref-qt command_param: boot command_param2: enter device_path: '/dev/ttyUSB0' - test: namespace: s5p4418-deploy connection: serial timeout: minutes: 3 failure_retry: 3 name: s5p4418-navi-qt-test 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

7 years, 3 months

2
1
0 0

Project qa/test-definitions moved to Github Linaro/test-definitions

by Chase Qi

Hi, We are seeing more and more contributor from outside of Linaro on the project, then we decided to move it to https://github.com/Linaro/test-definitions to make contributing easier. https://git.linaro.org/qa/test-definitions.git is a read-only mirror of the Github repo now. New changes in the Github repo will be pushed to the mirror every 10 minutes. https://review.linaro.org/#/admin/projects/qa/test-definitions also has been set to read-only. Please use Github for pull requests: https://github.com/Linaro/test-definitions/pulls Thanks, Chase

7 years, 3 months

1
0
0 0

Linaro & LAVA at FOSDEM 2019

by Neil Williams

https://fosdem.org/2019/ (No registration is necessary for FOSDEM - if you can get to Brussels, you are welcome to just turn up on site. Avoid trying to park near the site unless you get there very early, use public transport.) https://fosdem.org/2019/practical/ https://fosdem.org/2019/stands/ If you haven't been to FOSDEM before, note that there will be a huge number of people attending FOSDEM (well over 8,000 are expected), so the only real chance of meeting up is to have a known meeting point. Hopefully, you'll have a chance to get to some of the 700 sessions which have been arranged over the 2 days. Linaro will have a stand at FOSDEM 2019 in the AW building. The stand will be on the ground floor, along the corridor from AW120 near MicroPython and PINE64. Various Linaro and LAVA people will be around the stand during the event, so this can act as a focal point for anyone wanting to talk about Linaro and or LAVA during FOSDEM. https://fosdem.org/2019/schedule/room/aw1120/ The AW building is near the car park, across from Janson and the H building. Various Linaro and LAVA people have been routinely attending FOSDEM for a number of years. If you are able to get there, we will be happy to see you. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 3 months

1
0
0 0

change overlay deploy destination via ssh

by Krutz, Christoph

Hi lava team, I want to use lava for running shell scripts on several devices which are connected to the lava server via ssh. Is there a way to deploy the overlay to another directory than "/"? Example: The overlay is downloaded to /lava-123.tar.gz and extracted to /lava-123 by default. What if my rootfs "/" is read-only and I want to download and extract the overlay to /tmp or /data, which are read-write mounted? Best regards, Christoph

7 years, 3 months

2
1
0 0

Test Definition to specify somewhere other than GIT

by Pete Dyer

Hi, I have some test files stored in a private GIT repository. As I understand it there is no easy way to get the authentication passed through to the Test Definition, so I am looking for other options. Is there a way that I can write the Test Definition to reference the files elsewhere? I can bundle them into a tarball or zipfile and have them served via http without the need for authentication, but I cannot figure out how to describe this in the Test Definition. 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.

7 years, 3 months

2
1
0 0

health check and lava-test-case result

by Andrei Narkevitch

Hello, What is the rationale to ignore individual lava-test-case results when running a health check jobs? For example, the following job failed one case: https://validation.linaro.org/scheduler/job/1902316 A failing test case can be an indication of device malfunction (e.g. out of disk space, hw issues). Is it possible to force LAVA to fail a health check and thus put device in a "bad" state if one of the test cases is not successful? Thanks, Andrei Narkevitch Cypress Semiconductors This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

7 years, 3 months

3
2
0 0

General question on how to debug lava master scheduler.

by Larry Shen

After setup a master & a worker, I add this worker to this master, also add device to this worker. Then submit this job, the web page just show the task is in the status "Submit". The same configures seems work on my local machine(with master & worker on the same machine) I cannot find the root cause as job's device-type which the device have is idle & the health is good. For such kind of issue, any way to debug? I mean if any log I can find for why lava cannot dispatch the task with its 20 seconds poll?

7 years, 3 months

2
2
0 0

Re: [Lava-users] Change site issue

by Remi Duraffort

Hello, please keep the mailing-list in copy when replying. thanks for your help . I will discuss two questions (1. Change site > issue ; 2 secure boot mode ; ) in this reply. > 1) Change site issue : We changed both 'display name' and > 'display name' (example.com ) to IP address , and now we found that we > couldn't login in , when we pressed login in link on home page , it > reported as below: > > > *500 Internal Server Error**Site matching query does not exist.* > > *Oops, something has gone wrong! * > That's really strange. Could you update /etc/lava-server/settings.conf to set "DEBUG" to true, restart lava-server-gunicorn, refresh the page and send back the stack trace. Keep in mind that settings.conf is a json file, so check that the syntax is valid json. > 2) secure boot mode : at present , we solved it by utilizing > ''ramdisk" key words and forcing it not to decompress utee file , but we > don't know if we will utilize this key words in the future , so maybe it's > not a good solution. If we find any better solution after we reviews all > source codes ,we will submit it ! > Right. Rgds -- Rémi Duraffort

7 years, 3 months

1
0
0 0

Secure boot mode

by Chuan Su

Dear all, I'm trying booting my devices under test in a secure boot mode , which means i have to download dtb、kernel 、uTee files and set nfs serverip to mount rootfs in uboot , so there's an extra uTee file . And i checked key words in deploy steps and there was none extra for this action . And we only found 'image' 、’ramdisk‘、'dtb'、'rootfs' in job_templates.py under lava_server directionary . So what should i do to add this action in deploy？

7 years, 3 months

2
1
0 0

Change site issue

by Chuan Su

Dear all, I'm bothered with lava site changing function( at http://10.193.101.30/admin/sites/site/1/change/ , pls change IP address here to yours). When i changed default domain name to IP address and set notification email in my job as below: notify: recipients: - to: method: email email: temp(a)163.com criteria: status: complete verbosity: verbose and then i received messy code as below: Job details and log file: http://???/scheduler/job/19 So I just don't know what's wrong!

7 years, 3 months

2
1
0 0

change overlay deploy destination via ssh

by Krutz, Christoph

Hi lava team, I want to use lava for running shell scripts on several devices which are connected to the lava server via ssh. Is there a way to deploy the overlay to another directory than "/"? Example: The overlay is downloaded to /lava-123.tar.gz and extracted to /lava-123 by default. What if my rootfs "/" is read-only and I want to download and extract the overlay to /tmp or /data, which are read-write mounted? Best regards, Christoph

7 years, 3 months

1
0
0 0

Result app report test case regressions

by Axel Lebourhis

Hi all, At NXP, we would like the result app to report regressions/progressions between 2 tests. We run CTS/VTS job on Android 9, and as we add some features to the OS (DRM for example), we want to make sure we get the expected behavior. For that, we need to know exactly which test cases results are different between the two last jobs. CTS runs about 400 000-500 000 test cases, it's kind of heavy to process manually. For example, the result table could show 2 tables, one would be the same it is atm, and the other would show the list of test cases results that are different from the previous job. What do you think about this ? I think this could be useful to everyone. Should I submit an issue to https://git.lavasoftware.org/lava/lava/ ? Best regards, Axel

7 years, 3 months

3
7
0 0

Docker recommended volume mounts?

by Chris Sauer

Im deploying lava using the docker container and I am looking at the correct paths to mount as volumes as to not lose data between cluster rollovers. (and to have to backups) If I change the instance.conf to point to a database that is outside of the container that gets backed up and includes these paths in my volume mounts is that all I need to do? Or is there additional paths/files that should be included. https://master.lavasoftware.org/static/docs/v2/admin-backups.html If anyone knows anything about this thanks!

7 years, 3 months

4
11
0 0

Best way to run LTP tests on yocto

by Philippe Mazet

Hi all, I am running LTP tests through LAVA on a Yocto based system. If I run a LTP test suite (like syscalls) by directly calling runltp, LAVA will display it as a single TC, with a single PASS/FAIL verdict. I think the test definition here solves this problem: https://git.linaro.org/qa/test-definitions.git/tree/automated/linux/ltp/ltp… But couldn't find a job template that makes use of it. Could you please let me know: * If this could run on yocto? * Where to find an example job that makes use of this? Thanks and regards, Philippe

7 years, 3 months

3
4
0 0

Have health-check job to be registered before submitting test job?

by tomato

Hi, I have a problem for Installing LAVA server and dispatcher using docker images that Linaro offer. I installed both two images(server and dispatcher) on my local pc. When I submit job, submitted job is listed on Lava server. But it remain the status as 'Submitted' and not change. When i visit server {local ip address:port number}/scheduler/device/qemu01, I can see message like below. Is this mean that health-check job have to be registered before submitting test job? If then, how to do? I have looked for the way to figure out this problem, but I couldn't. Although I tried to disable health check on this device and forced to change Health as 'Good', Health status soon change like Good → Bad (Invalid device configuration). Below is what I did for installing LAVA server and dispatcher. - LAVA Server 1) Pull docker image and run. $ |docker pull lavasoftware/lava-server||:2018.11| ||$ docker run -itd --name new_lava_server --cap-add=NET_ADMIN \|| || -p 9099:80 -p 5557:5555 -p 5558:5556 -h new_lava_server \ || || lavasoftware/lava-server||||:2018.11|| ||2) Create superuser|| ||Create id as admin, pw as admin.|| |||| ||$ ||||lava-server manage createsuperuser|| ||3) Create token|| ||Create token for admin account on server web ui.|| 4) Add device type and device $ lava-server manage device-types add qemu 5) Add device dictionary $ lava-server manage devices add --device-type qemu --worker new_lava_slave qemu01 - LAVA dispatcher 1) Pull docker image and run. $ |docker pull lavasoftware/lava-dispatcher||:2018.11| |$ ||docker run -it --name new_lava_slave \| |||-||v||/boot||:||/boot||-||v||/lib/modules||:||/lib/modules||-||v||/home/lava-slave/LAVA-TEST||:||/opt/share||\| |||-||v||/dev/bus/usb||:||/dev/bus/usb||-||v||~/.||ssh||/id_rsa_lava||.pub:||/home/lava/||.||ssh||/authorized_keys||:ro -||v||/sys/fs/cgroup||:||/sys/fs/cgroup||\| |||--device=||/dev/ttyUSB0||\| |||-p 2022:22 -p 5555:5555 -p 5556:5556 \| |||-h new_lava_slave \| |||--privileged \| |||-e LAVA_SERVER_IP=||"192.168.1.44"||\| |||-e||"LOGGER_URL=tcp://192.168.1.44:5557"||\| |||-e||"MASTER_URL=tcp://192.168.1.44:5558"||\| |||-e||"DISPATCHER_HOSTNAME=--hostname=new_lava_slave"||\| |||lavasoftware||/lava-dispatcher||:2018.11| |2) Submit job file| || $ ./submityaml.py -p -k apikey.txt qemu01.yaml |Below is submityaml.py python code.| |apikey.txt file is token created on server. | || #!/usr/bin/python import argparse import os.path import sys import time import xmlrpclib SLEEP = 5 __version__ = 0.5 LAVA_SERVER_IP = "192.168.1.44" def is_valid_file(parser, arg, flag): if not os.path.exists(arg): parser.error("The file %s does not exist!" % arg) else: return open(arg, flag) # return an open file handle def setup_args_parser(): """Setup the argument parsing. :return The parsed arguments. """ description = "Submit job file" parser = argparse.ArgumentParser(version=__version__, description=description) parser.add_argument("yamlfile", help="specify target job file", metavar="FILE", type=lambda x: is_valid_file(parser, x, 'r')) parser.add_argument("-d", "--debug", action="store_true", help="Display verbose debug details") parser.add_argument("-p", "--poll", action="store_true", help="poll job status until job completes") parser.add_argument("-k", "--apikey", default="apikey.txt", help="File containing the LAVA api key") parser.add_argument("--port", default="9099", help="LAVA/Apache default port number") return parser.parse_args() def loadConfiguration(): global args args = setup_args_parser() def loadJob(server_str): """loadJob - read the JSON job file and fix it up for future submission """ return args.yamlfile.read() def submitJob(yamlfile, server): """submitJob - XMLRPC call to submit a JSON file returns jobid of the submitted job """ # When making the call to submit_job, you have to send a string jobid = server.scheduler.submit_job(yamlfile) return jobid def monitorJob(jobid, server, server_str): """monitorJob - added to poll for a job to complete """ if args.poll: sys.stdout.write("Job polling enabled\n") # wcount = number of times we loop while the job is running wcount = 0 # count = number of times we loop waiting for the job to start count = 0 f = open("job_status.txt", "w+") while True: status = server.scheduler.job_status(jobid) if status['job_status'] == 'Complete': f.write("Complete\n") break elif status['job_status'] == 'Canceled': f.write("Canceled\n") print '\nJob Canceled' exit(0) elif status['job_status'] == 'Submitted': sys.stdout.write("Job waiting to run for % 2d seconds\n" % (wcount * SLEEP)) sys.stdout.flush() wcount += 1 elif status['job_status'] == 'Running': sys.stdout.write("Job Running for % 2d seconds\n" % (count * SLEEP)) sys.stdout.flush() count += 1 else: f.write("unkonwn status\n") print "unknown status" exit(0) time.sleep(SLEEP) print '\n\nJob Completed: ' + str(count * SLEEP) + ' s (' + str(wcount * SLEEP) + ' s in queue)' def process(): print "Submitting test job to LAVA server" loadConfiguration() user = "admin" with open(args.apikey) as f: line = f.readline() apikey = line.rstrip('\n') server_str = 'http://' + LAVA_SERVER_IP + ":" + args.port xmlrpc_str = 'http://' + user + ":" + apikey + "@" + LAVA_SERVER_IP + ":" + args.port + '/RPC2/' print server_str print xmlrpc_str server = xmlrpclib.ServerProxy(xmlrpc_str) server.system.listMethods() yamlfile = loadJob(server_str) jobid = submitJob(yamlfile, server) monitorJob(jobid, server, server_str) if __name__ == '__main__': process() |The job file named qemu01.yaml is below.| || |# Your first LAVA JOB definition for an x86_64 QEMU device_type: qemu job_name: QEMU pipeline, first job timeouts: job: minutes: 15 action: minutes: 5 connection: minutes: 2 priority: medium visibility: public # context allows specific values to be overridden or included context: # tell the qemu template which architecture is being tested # the template uses that to ensure that qemu-system-x86_64 is executed. arch: amd64 metadata: # please change these fields when modifying this job for your own tests. docs-source: first-job docs-filename: qemu-pipeline-first-job.yaml # ACTION_BLOCK actions: - deploy: timeout: minutes: 5 to: tmpfs images: rootfs: image_arg: -drive format=raw,file={rootfs} url: https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz compression: gz # BOOT_BLOCK - boot: timeout: minutes: 2 method: qemu media: tmpfs prompts: ["root@debian:"] auto_login: login_prompt: "login:" username: root - 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| | | ||

7 years, 4 months

2
1
0 0

FW: Timeouts in LAVA failing

by Patryk Mungai Ndungu

Hello, I have noticed sometimes when I run healthchecks, LAVA gets stuck when doing a http download of the kernel and ramdisk to run a healthcheck. For example in [1] there seems to be a 3 min timeout for the deploy images section, but LAVA didn’t pick this up, and was stuck there for 17 hours. After the job was cancelled and the device health was manually set to unknown again, the healthcheck succeeds (eg. job 25 on the same lava instance). I am running LAVA 2018.7. [1] https://lava.ciplatform.org/scheduler/job/20 Thanks, Patryk Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

7 years, 4 months

2
1
0 0

Dependencies between master and worker when restoring from backups

by Tim Jaacks

Hello everyone, I have written a backup script for my LAVA instance. While testing the restore process I stumbled upon issues. Are there any dependencies between the master and workers concerning backups? When the master crashes, but the worker does not, is it safe to restore the master only and keep the worker as it is? Or do I have to keep master and worker backups in sync and always restore both at the same time? Restoring my master as described in the LAVA docs generally works. The web interface is back online, all the jobs and devices are in consistent states. Restoring the worker is relatively easy, according to the docs. I installed the LAVA packages in their previous versions on a fresh (virtual) machine, restored /etc/lava-dispatcher/lava-slave and /etc/lava-coordinator/lava-coordinator.conf. The worker has status "online" in the LAVA web interface afterwards, so the communication seems to work. However, starting a multinode job does not work. The job log says: lava-dispatcher, installed at version: 2018.5.post1-2~bpo9+1 start: 0 validate Start time: 2018-12-18 12:25:14.335215+00:00 (UTC) This MultiNode test job contains top level actions, in order, of: deploy, boot, test, finalize lxc, installed at version: 1:2.0.7-2+deb9u2 validate duration: 0.01 case: validate case_id: 112 definition: lava result: pass Initialising group b6eb846d-689f-40c5-b193-8afce41883ee Connecting to LAVA Coordinator on lava-server-vm:3079 timeout=90 seconds. This comes out in a loop, until the job times out. The lava-slave logfile says: 2018-12-18 12:27:15,114 INFO master => START(12) 2018-12-18 12:27:15,117 INFO [12] Starting job [...] 2018-12-18 12:27:15,124 DEBUG [12] dispatch: 2018-12-18 12:27:15,124 DEBUG [12] env : {'overrides': {'LC_ALL': 'C.UTF-8', 'LANG': 'C', 'PATH': '/usr/local/bin:/usr/local/sbin:/bin:/usr/bin:/usr/sbin:/sbin'}, 'purge': True} 2018-12-18 12:27:15,124 DEBUG [12] env-dut : 2018-12-18 12:27:15,129 ERROR [EXIT] 'NoneType' object has no attribute 'send_start_ok' 2018-12-18 12:27:15,129 ERROR 'NoneType' object has no attribute 'send_start_ok' It is the "job = jobs.create()" call in lava-slave's handle_start() routine which fails. Obviously there is a separate database on the worker (of which I did not know until now), which fails to be filled with values. Does this database have to be backup'ed and restored? What is the purpose of this database? Is there anything I need to know about it concerning backups? 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

7 years, 4 months

2
5
0 0

Re: [Lava-users] Lava job always exits when running a long duration test case without outputs

by Neil Williams

Please make sure you include the mailing list in all replies so that others know when a problem has been fixed (and how it was fixed) On Tue, 18 Dec 2018 at 12:00, Chuan Su <lavanxp(a)126.com> wrote: > > According to your comments , we checked our setups and we found that we utilized ser2net & telnet to communicate with DUT , however , ser2net set default timeout parameter as 600 seconds . When DUT runs a long duration case (more than 600 seconds ) without any log outputting , the connection is usually dropped by ser2net , and telnet program always prints logs as 'Connection closed by foreign host ' . Anyway thanks for your help ! See https://git.linaro.org/lava/lava-lab.git/tree/shared/server-configs/ser2net… The Linaro lab in Cambridge sets all the ser2net configs to have a zero timeout. > Sincerely, > Chuan Su > > > > > > At 2018-12-18 15:59:00, "Neil Williams" <neil.williams(a)linaro.org> wrote: > >On Tue, 18 Dec 2018 at 06:16, Chuan Su <lavanxp(a)126.com> wrote: > >> > >> Dear all, > >> We are encountered with an issue that our job always exits halfway when running a long duration test case (around 20 minutes) which outputs nothing , and lava server reports an InfrastructureError error and prints as below : > >> Connection closed by foreign host.Marking unfinished test run as failed > > > >Connection closed by foreign host means that the serial connection > >failed at the DUT - this is not a problem in the LAVA test job, this > >is an infrastructure failure at your end. The foreign host (the DUT) > >closed the serial connection. There is nothing LAVA can do about that. > >The serial connection to the DUT has simply failed. > > > >If the serial connection is USB, check for logs on the worker like > >/var/log/messages and /var/log/syslog for events related to the serial > >connection. Check that the DUT didn't simply kill the serial > >connection - maybe the DUT went into some kind of suspend mode. > > > >> definition: lava > >> result: fail > >> case: 0_apache-servers1 > >> uuid: 597_1.4.2.4.1 > >> duration: 603.53 > >> lava_test_shell connection dropped.end: 3.1 lava-test-shell (duration 00:10:05) [ns_s1] > >> namespace: ns_s1 > >> extra: ... > >> definition: lava > >> level: 3.1 > >> result: fail > >> case: lava-test-shell > >> duration: 604.55 > >> lava-test-retry failed: 1 of 1 attempts. 'lava_test_shell connection dropped.'lava_test_shell connection dropped. > >> > >> And we just test it with a very simple python script as below: > >> #!/usr/bin/env python3 > >> import time > >> print('Hello,world!') > >> time.sleep(1200) > >> print("Hello,Lava!") > >> We can see 'Hello,world!' string outputs , but there's no more output of this program found on webUI! > >> We just don't know what's wrong , so we have to mail to you for help! > >> Sincerely, > >> Chuan Su > >> > >> > >> > >> > >> _______________________________________________ > >> Lava-users mailing list > >> Lava-users(a)lists.lavasoftware.org > >> https://lists.lavasoftware.org/mailman/listinfo/lava-users > > > > > > > >-- > > > >Neil Williams > >============= > >neil.williams(a)linaro.org > >http://www.linux.codehelp.co.uk/ > > > > -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 4 months

1
0
0 0

Default patterns and fixup dicts in Lava-Test Test Definition 1.0

by Neil Williams

https://git.lavasoftware.org/lava/lava/issues/179 If your Lava-Test Test Definition 1.0 YAML files explicitly use a parse: block (like: https://git.linaro.org/qa/test-definitions.git/tree/automated/linux/ltp/ltp…) then this will remain supported in Definition 1.0. If you use the monitors or interactive test actions, this does not affect you at all. If you rely on LAVA to create a TestCase based on a command in the Lava-Test Test Definition just echoing "pass" or "fail", then this is the Default Pattern and this change will directly affect those test jobs. The current Default Pattern and Fixup are lifted directly from V1 (https://git.lavasoftware.org/lava/lava/blob/master/lava_common/constants.py…): # V1 compatibility DEFAULT_V1_PATTERN = "(?P<test_case_id>.*-*)\\s+:\\s+(?P<result>(PASS|pass|FAIL|fail|SKIP|skip|UNKNOWN|unknown))" DEFAULT_V1_FIXUP = { "PASS": "pass", "FAIL": "fail", "SKIP": "skip", "UNKNOWN": "unknown", } We've recently updated the documentation to drop mention of the default pattern support for the following reasons: * It has always been problematic to encode a Python regular expression in YAML. Failures are difficult to debug and patterns are global for the entire test operation. * The move towards more portable test definitions puts the emphasis on parsing the test output locally on the DUT using a customised parser. This has further advantages: * The pattern does not have to be mangled into YAML * The pattern can be implemented by a language other than Python * The pattern can change during the operation of the test shell, e.g. a different pattern may be required for setup than for the test itself. We are now starting to plan for Lava-Test Test Definition 2.0 with an emphasis on requiring portable test scripts and removing more of the lava_test_shell Test Helper scripts. Full information on 2.0 will be available early in 2019. As a first step, the generally unhelpful Default Pattern and Default Fixup dict are likely to be removed. If you need this support, the pattern can be added to your Lava-Test Test Definition 1.0 YAML files. In the next release, it is proposed that unless an explicit pattern is specified in the Lava-Test Test Definition 1.0 YAML file, then no pattern will be implemented. Processes which echo "pass" or "fail" would be ignored and no TestCase would be created. Let us know if there are any thoughts or problems on this proposal. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 4 months

1
0
0 0

Lava job always exits when running a long duration test case without outputs

by Chuan Su

Dear all, We are encountered with an issue that our job always exits halfway when running a long duration test case (around 20 minutes) which outputs nothing , and lava server reports an InfrastructureError error and prints as below : Connection closed by foreign host.Marking unfinished test run as failed definition: lava result: fail case: 0_apache-servers1 uuid: 597_1.4.2.4.1 duration: 603.53 lava_test_shell connection dropped.end: 3.1 lava-test-shell (duration 00:10:05) [ns_s1] namespace: ns_s1 extra: ... definition: lava level: 3.1 result: fail case: lava-test-shell duration: 604.55 lava-test-retry failed: 1 of 1 attempts. 'lava_test_shell connection dropped.'lava_test_shell connection dropped. And we just test it with a very simple python script as below: #!/usr/bin/env python3 import time print('Hello,world!') time.sleep(1200) print("Hello,Lava!") We can see 'Hello,world!' string outputs , but there's no more output of this program found on webUI! We just don't know what's wrong , so we have to mail to you for help! Sincerely, Chuan Su

7 years, 4 months

2
1
0 0

Git authentication

by Axel Lebourhis

Hi everyone, Is it possible to handle git authentication in a test job ? I need LAVA to clone a repo that can't be set to public, and obviously it won't work because of the authentication step. So is it possible to specify a password or a token ? Best regards, Axel

7 years, 4 months

5
12
0 0

LAVA webUI hangs when test case outputs long string in a line

by Chuan Su

Dear , all We found that when lava executed a script which may output a long string (more than 30000 bytes) in a line (only one line break), lava web UI always hung and there was no more lava log outputting and devices under test (short for DUT) were still powered until Lava Job time-out function triggered , however, after checked the whole log file we found that cases behind the hanging case were executed (there's new files generated) . So the problem is that when lava encountered those cases lava web UI always hangs and DUTs may not be powered off when all the cases are completed ! best wishes, Chuan Su

7 years, 4 months

2
2
0 0

LAVA webUI hangs when test case outputs long string in a line

by Chuan Su

Dear , all We found that when lava executed a script which may output a long string (more than 30000 bytes) in a line (only one line break), lava web UI always hung and there was no more lava log outputting and devices under test (short for DUT) were still powered until Lava Job time-out function triggered , however, after checked the whole log file we found that cases behind the hanging case were executed (there's new files generated) . So the problem is that when lava encountered those cases lava web UI always hangs and DUTs may not be powered off when all the cases are completed ! best wishes, Chuan Su

7 years, 4 months

1
0
0 0

Re: [Lava-users] Steps for restoring a backup

by Tim Jaacks

On Mon, 11 Dec 2018 at 11:30, Neil Williams <neil.williams at linaro.org> wrote: > On Tue, 11 Dec 2018 at 11:28, Tim Jaacks <tim.jaacks(a)garz-fricke.com> wrote: > > > > Thanks, the CLI operations are very helpful for automating the process. > > However, the docs say that all devices in "Reserved" state have to > > have their "current job" cleared. I can use "lava-server manage devices details" > > to check whether this field is actually set. There is no command to > > modify it, though. Seems like using the Python API is the only way to > > go here, right? The same applies to setting "Running" jobs to "Cancelled". > > https://git.lavasoftware.org/lava/lava/merge_requests/273 > > This should get into the upcoming 2018.12 release. Thank you very much for your quick help. The "lava-server manage jobs fail" command takes care of clearing the "current job" field of the associated device, do I understand that right? 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

7 years, 4 months

2
4
0 0

MultiNode Tradefed-runner with session retry

by Karsten Tausche

Hi folks, We at Fairphone have developed a variant of the Tradefed-runner in LAVA test-definitions that is meant to run complete Tradefed test suites on multiple devices by making use of the shards feature in Tradefed. The runner is currently in “staging” state. We still want to share now what we are using and developing to see if there are more people with interest in it. Feedback on the general approach taken would also be much appreciated. On the higher level, our setup works as follows: • Use MultiNode to allocate multiple devices for one test submission. • One “master” runs the Tradefed shell, similarly as in the existing runner. • The master connects to the workers’ DUTs via adb TCP/IP. These DUTs are transparently available to Tradefed just in the same way as USB-attached devices. • Workers ensure that their respective DUTs remain accessible to the master, especially in case of WLAN disconnects, reboots, crashes, etc. Major features of our runner: • Support for Android CTS, GTS and STS. • Test run split into “shards” in Tradefed to run tests in parallel on multiple devices. This allows for a major speedup when running large test suites. • Tradefed retry: Rerun test suites until the failure count stabilizes. • No adb root required. • Based on the original Tradefed runner, having at least parts of the common code moved to python libraries. Current limitations: • Test executions are not always stable. This needs further investigation. • Test executions produce more false positives than local test runs. This needs further investigation but is at least partially due to using adb TCP/IP instead of a local USB connection. • Android VTS not implemented (would require only minor changes) Our current changes have been pushed to the tradefed_shards_with_retry topic on Gerrit[1]. Besides the two major changes to add MultiNode adb support and then Tradefed support on top of that, a couple of smaller changes that could be useful on their own have also been pushed. We are looking forward to your feedback and to joint efforts in automating and speeding up Tradefed test executions! Best regards, Karsten for the Fairphone Software Team [1] https://review.linaro.org/q/topic:%22tradefed_shards_with_retry%22+(status:…

7 years, 4 months

2
1
0 0

Re: [Lava-users] Steps for restoring a backup

by Tim Jaacks

On Mon, 10 Dec 2018 at 20:16, Neil Williams <neil.williams at linaro.org> wrote: > Yes, there is a problem there - thanks for catching it. I think the > bulk of the page dates from the last stages of the migration when V1 > data was still around. I'll look at an update of the page tomorrow. > Step 7 is a sanity check that the install of the empty instance has > gone well, Step 9 is to ensure that the newly restored database is put > into maintenance as soon as possible to prevent any queued test jobs > from attempting to start. The critical element of Step 9 is to ensure > that the lava-master service is stopped. > > The emphasis of the section is on ensuring that the instance only > serves a "Maintenance" page, e.g. the default Debian "It works!" > apache page, to prevent access to the instance during the restore. Thanks for pointing that out, Neil. I got the point, that the Apache server has to serve a static site during the restore process. > Accessing the UI would involve having an alternative way to serve the > pages. If that can be arranged, just for admins, (e.g. by changing the > external routing to the box or redirecting DNS temporarily) then the > UI on the instance can be used with the change that the > lava-server-gunicorn service does not need to be stopped (because > access has been redirected). Other services would be stopped. However, > this would involve a fair number of apache config changes, so is best > left to those admins who have such config already on hand. > > The operations can be done from the command line and that's probably > best for these docs. > > Step 7 can be replaced by: > > lava-server manage check --deploy > > Step 9 can be replaced by looping over: > > lava-server manage devices update --health MAINTENANCE --hostname ${HOSTNAME} > > or, if there are a lot of devices: > > lava-server manage maintenance --force > > (This maintenance helper has been fixed in master - soon to be 2018.12 > - so older versions would use the first command & loop.) Thanks, the CLI operations are very helpful for automating the process. However, the docs say that all devices in "Reserved" state have to have their "current job" cleared. I can use "lava-server manage devices details" to check whether this field is actually set. There is no command to modify it, though. Seems like using the Python API is the only way to go here, right? The same applies to setting "Running" jobs to "Cancelled". > I'll look at changing the page to use CLI operations for steps 7 and > 9. Some labs can do the http redirect / routing method but the detail > of that is probably not in scope for this page in the LAVA docs. I'll > add a note that admins have that choice but leave it for those admins > to implement. 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

7 years, 4 months

2
1
0 0

Steps for restoring a backup

by Tim Jaacks

Hello everyone, I am trying to implement a backup and restore routine for our LAVA server, based on the documentation: https://validation.linaro.org/static/docs/v2/admin-backups.html#restoring-a… The creation of the backup is straight-forward. I have problems with the order of the proposed restore steps, though. Step 6 is "Stop all LAVA services". However, afterwards in step 7 it says "Make sure that this instance actually works by browsing a few (empty) instance pages." This should obviously be done before, right? The actual problem is that step 9 says "In the Django administration interface, take all devices which are not Retired into Offline". This cannot be an ordering issue, because the LAVA services actually must not be available during these modifications. How do I use the Django admin interface, while all LAVA services are stopped? 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

7 years, 4 months

2
1
0 0

How to switch device-type base jinja with only one device?

by Larry Shen

Dear all, I have a question when use lava. Background: 1. I have only one hardware device with android. 2. I have a device-type jinja2 file start with "{% extends 'base-fastboot.jinja2' %}" Here, I use "adb reboot bootloader" to enter in to fastboot. 3. I have another device-type jinja2 file start with "{% extends 'base-uboot.jinja2' %}" Here, I use "fastboot 0" in uboot to enter in to fastboot. Now, we have a scenario which need to test with above both methods, but we just have one device, if possible user can define some parameter in job.yaml, then can switch between the two methods just for one device? Any suggestion? Thanks, Larry

7 years, 4 months

2
4
0 0

lava-logs crash in 2018.11

by Corentin Labbe

Hello I got the following crash with 2018.11 on debian stretch dpkg -l|grep lava ii lava 2018.11-1~bpo9+1 all Linaro Automated Validation Architecture metapackage ii lava-common 2018.11-1~bpo9+1 all Linaro Automated Validation Architecture common ii lava-coordinator 0.1.7-1 all LAVA Coordinator daemon ii lava-dev 2018.11-1~bpo9+1 all Linaro Automated Validation Architecture developer support ii lava-dispatcher 2018.11-1~bpo9+1 amd64 Linaro Automated Validation Architecture dispatcher ii lava-server 2018.11-1~bpo9+1 all Linaro Automated Validation Architecture server ii lava-server-doc 2018.11-1~bpo9+1 all Linaro Automated Validation Architecture documentation ii lavacli 0.9.3-1~bpo9+1 all LAVA XML-RPC command line interface ii lavapdu-client 0.0.5-1 all LAVA PDU client ii lavapdu-daemon 0.0.5-1 all LAVA PDU control daemon 2018-12-04 14:14:40,187 ERROR [EXIT] Unknown exception raised, leaving! 2018-12-04 14:14:40,187 ERROR string index out of range Traceback (most recent call last): File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py", line 193, in handle self.main_loop() File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py", line 253, in main_loop while self.wait_for_messages(False): File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py", line 287, in wait_for_messages self.logging_socket() File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py", line 433, in logging_socket job.save() File "/usr/lib/python3/dist-packages/django_restricted_resource/models.py", line 71, in save return super(RestrictedResource, self).save(*args, **kwargs) File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 796, in save force_update=force_update, update_fields=update_fields) File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 820, in save_base update_fields=update_fields) File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py", line 191, in send response = receiver(signal=self, sender=sender, **named) File "/usr/lib/python3/dist-packages/lava_scheduler_app/signals.py", line 139, in testjob_notifications send_notifications(job) File "/usr/lib/python3/dist-packages/lava_scheduler_app/notifications.py", line 305, 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 342, in send return self.get_connection(fail_silently).send_messages([self]) File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py", line 107, in send_messages sent = self._send(message) File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py", line 120, in _send recipients = [sanitize_address(addr, encoding) for addr in email_message.recipients()] File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py", line 120, in <listcomp> recipients = [sanitize_address(addr, encoding) for addr in email_message.recipients()] File "/usr/lib/python3/dist-packages/django/core/mail/message.py", line 161, in sanitize_address address = Address(nm, addr_spec=addr) File "/usr/lib/python3.5/email/headerregistry.py", line 42, in __init__ a_s, rest = parser.get_addr_spec(addr_spec) File "/usr/lib/python3.5/email/_header_value_parser.py", line 1988, in get_addr_spec token, value = get_local_part(value) File "/usr/lib/python3.5/email/_header_value_parser.py", line 1800, in get_local_part if value[0] in CFWS_LEADER: IndexError: string index out of range 2018-12-04 14:14:40,211 INFO [EXIT] Disconnect logging socket and process messages 2018-12-04 14:14:40,211 DEBUG [EXIT] unbinding from 'tcp://0.0.0.0:5555' 2018-12-04 14:14:50,221 INFO [EXIT] Closing the logging socket: the queue is empty Regards

7 years, 4 months

3
6
0 0

non-posix (interactive) shell testing

by Milosz Wasilewski

Hi, I'm trying to experiment with 'interactive' test shell. The docs are here: https://master.lavasoftware.org/static/docs/v2/actions-test.html#index-1 As I understand the feature should work in the following way (the docs aren't very clear): 1. wait for one of the prompts 2. send command 3. match the result to regex (pass or fail) However when I try it out, there is no wait for prompt. LAVA immediately sends the command and adds value from prompts to list of expressions to match. Is this correct? Example job: https://staging.validation.linaro.org/scheduler/job/245886#L53 LAVA sends the command even before the board starts booting. Any help is appreciated. milosz

7 years, 4 months

3
4
0 0

U-Boot command sequence ignores prompt waiting

by Andrejs Cainikovs

Hi everyone, I’m facing an issue when U-Boot commands are sent one after another without waiting for a prompt. Obviously, device is not able to boot. Excerpt from logs: dhcp => dhcp bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:56) setenv serverip 172.17.1.189 setenv serverip 172.17.1.189 bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:56) tftp 0x80000000 60/tftp-deploy-46_3_i9j/kernel/zImage-am335x-vcu.bin tftp 0x80000000 60/tftp-deploy-46_3_i9j/kernel/zImage-am335x-vcu.bin bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:56) tftp 0x83000000 60/tftp-deploy-46_3_i9j/ramdisk/ramdisk.cpio.gz.uboot tftp 0x83000000 60/tftp-deploy-46_3_i9j/ramdisk/ramdisk.cpio.gz.uboot bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:55) setenv initrd_size ${filesize} setenv initrd_size ${filesize} bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:55) tftp 0x82000000 60/tftp-deploy-46_3_i9j/dtb/am335x-vcu-prod1.dtb tftp 0x82000000 60/tftp-deploy-46_3_i9j/dtb/am335x-vcu-prod1.dtb bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:55) dhcp dhcp link up on port 0, speed 10, half duplex BOOTP broadcast 1 setenv serverip 172.17.1.189 tftp 0x80000000 60/tftp-deploy-46_3_i9j/kernel/zImage-am335x-vcu.bin BOOTP broadcast 2 tftp 0x83000000 60/tftp-deploy-46_3_i9j/ramdisk/ramdisk.cpio.gz.uboot setenv initrd_size ${filesize} tftp 0x82000000 60/tftp-deploy-46_3_i9j/dtb/am335x-vcu-prod1.dtb BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 Retry time exceeded setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp' => setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp' bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:50) setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp' setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp' => bootz 0x80000000 0x83000000 0x82000000 => bootz 0x80000000 0x83000000 0x82000000 bootloader-commands: Wait for prompt Starting kernel (timeout 00:04:50) bootz 0x80000000 0x83000000 0x82000000 bootz 0x80000000 0x83000000 0x82000000 Bad Linux ARM zImage magic! => Bad Linux ARM zImage magic! As you see, all commands that were sent between `dhcp` command and until it was able to complete or fail are simply dropped. Device type config: {% extends 'base-uboot.jinja2' %} {% set device_type = "vcu" %} {% set console_device = 'ttyS2' %} {% set baud_rate = 115200 %} {% set interrupt_prompt = 'Press s to abort autoboot' %} {% set interrupt_char = 's' %} {% set bootloader_prompt = '=>' %} {% set uboot_mkimage_arch = 'arm' %} {% set bootz_kernel_addr = '0x80000000' %} {% set bootz_ramdisk_addr = '0x83000000' %} {% set bootz_dtb_addr = '0x82000000' %} {% set extra_kernel_args = 'ti_cpsw.rx_packet_max=1526' %} {% set kernel_start_message = 'Welcome to' %} Device config: {% extends 'vcu.jinja2' %} {% set connection_command = 'telnet lava-disp-1.local 7000' %} {% set power_on_command = 'relay-ctrl --relay 1 --state on' %} {% set power_off_command = 'relay-ctrl --relay 1 --state off' %} {% set hard_reset_command = 'relay-ctrl --relay 1 --toggle' %} Boot action block from job definition: - boot: timeout: minutes: 5 method: u-boot commands: ramdisk auto_login: login_prompt: 'am335x-nmhw21 login: ' username: root prompts: - 'fct@am335x-nmhw21:~# ' Have I misconfigured something? What I’m missing? Thanks! Best regards, Andrejs Cainikovs.

7 years, 4 months

2
9
0 0

timeouts for test action not working

by Kevin Hilman

Hello, I have a LAVA job with long running test, so I put a timeout of 180 minutes in the test action itself[1]. However, but the job times out after 3989 seconds (~ 66 min)[2]. Looking closer at the "Timing" section of the job, I see that lava-test-shell indeed has a timeout of ~3989 seconds, but I have no idea where that number comes from. That's neither the 10 minutes in the default "timeouts" section, nor the 180 minutes I put in the "test" action. Hmm, after almost pushing send on this, I now seeing that in the "timeouts" sections, the whole job has a timeout of 70 minutes. So, I assume that means an absolute max, even if one of the actions puts a higher timeout? So I guess this email now turns into a feature request rather than a bug report. Maybe LAVA should show a warning at the top of the job if any of the actions has a timeout that's longer than the job timeout. Kevin [1] http://lava.baylibre.com:10080/scheduler/job/60374/definition#defline89 [2] http://lava.baylibre.com:10080/scheduler/job/60374#results_694663

7 years, 4 months

3
3
0 0

LAVA hacking session not starting

by Manoj Tiwary

Hi all, When I try to run a test in lava , hacking session is not starting . it is exiting by showing: Using /lava-18 export SHELL=/bin/sh # export SHELL=/bin/sh /lava-18/bin/lava-test-runner /lava-18/0 /lava-18/bin/lava-test-runner /lava-18/0 Test shell timeout: 10s (minimum of the action and connection timeout) export SHELL=/bin/sh # /lava-18/bin/lava-test-runner /lava-18/0 Illegal instruction <LAVA_TEST_RUNNER EXIT> ok: lava_test_shell seems to have completed end: 3.1 lava-test-shell (duration 00:00:01) [common] end: 3 lava-test-retry (duration 00:00:01) [common] start: 4 finalize (timeout 00:10:00) [common] start: 4.1 power-off (timeout 00:00:05) [common] end: 4.1 power-off (duration 00:00:00) [common] my board linux has busybox init system Please help me resolve the issue. I've attached the job log below. Thanks & Regards, Manoj

7 years, 4 months

2
1
0 0

Tradefed test definition modification

by Axel Lebourhis

Hi everyone, I'm currently running CTS tests on imx8mq on Android 9. My test job is based on Linaro's test definition located here : https://git.linaro.org/qa/test-definitions.git/tree/automated/android/trade… I had issue concerning the Java heap size, causing the test to abort and skip a lot of tests. So, I cloned this git tree and made modifications in "tradefed.sh" : export _JAVA_OPTIONS="-Xmx350M" replaced by : export _JAVA_OPTIONS="-Xmx700M" Since this modification, I'm able to run the full CTS 9. So, I think you should consider modify this script, so other users can benefit from it. Best regards, Axel

7 years, 4 months

2
8
0 0

setting u-boot bootargs

by Manoj Tiwary

Hi all, In Tftp deploy , How to give new set of u-boot bootargs by modifying device configuration file? I've tried by giving: {% set base_kernel_args = "setenv bootargs console=serial1,115200 console=tty1 root=/dev/ram0 ip=dhcp rootwait" %} But it is not taking these args. Please suggest the modifications I have to make. Thanks and regards, Manoj

7 years, 4 months

2
3
0 0

A question of LAVA's dead container.

by Li, Xiaoming

Hi Neil, When LAVA start container from image for the first time(usually docker run ), if failed, it will bring a zoobie container. And I found that LAVA did not check whether LAVA run is OK, and has no dead container cleanup method.(maybe I was wrong). Does LAVA have some method to prevent it or do you think it is necessary? Best Regards Li Xiaoming

7 years, 4 months

2
1
0 0

Reboot keyword mismatch

by Manoj Tiwary

Hi all, During send-reboot-commands phase in Health check on my raspberry pi 3 board, LAVA is trying to match the keyword "The system is going down for reboot NOW" after sending the reset command "reboot -n" to the DUT. But the problem is when my board starts Reboot it shows "Started Show Plymouth Reboot Screen .." , not the same as what LAVA want. So is there any way to specify the keywords to what it should be("Started Show Plymouth Reboot Screen" or something) in the corresponding DUTs jinja2 file? I've attached the reslult log of my test below. Regards, Manoj

7 years, 5 months

2
1
0 0

Problem with login in Web UI

by Axel Lebourhis

Hi everyone, I have some troubles to log in my Web UI. I type the good password and username and then the website sends me back to the home page. If I type a wrong password, I get an error message. It does the same thing for all user accounts. Tried to restart lava services, apache2 but it's still doing the same thing. No error messages returned in logs. Best regards, Axel Le Bourhis

7 years, 5 months

2
13
0 0

default Soft reboot command

by Manoj Tiwary

Hi all, When health check is running on my raspberry pi 3 board , in boot phase it is taking default soft reboot commands like reboot , reboot -n , reboot -nf. which is not working with U-boot boot type. It is showing unknown command ' reboot' . How to set soft reboot command manually in test job definition? Thanks & regards, Manoj

7 years, 5 months

2
4
0 0

lava-server won't start

by Axel Lebourhis

Hi everyone, I got an issue using LAVA today. After trying to load a job page, LAVA crashed returning PROXY ERROR. I tried to restart lava-master, lava-slave and lava-server-gunicorn services without success. The django.log returns an error about django tables2, saying it can't find the module. I'm running LAVA 2018.10. See attached log for more precision. Best regards, Axel Le Bourhis

7 years, 5 months

2
2
0 0

Re: [Lava-users] Default LXC directory for LAVA

by Axel Lebourhis

Ok i'll keep that in mind. To mailing list : I confirm this solution fixed the issue. Kind regards, Axel On Tue, 6 Nov 2018 at 16:55, Neil Williams <neil.williams(a)linaro.org> wrote: > Yes, please always include the mailing list in replies. When people do > search for help in the list archives, it is frustrating to find the > question without the solution - or even just a confirmation that the > reply worked. > On Tue, 6 Nov 2018 at 15:47, Axel Lebourhis <axel.lebourhis(a)linaro.org> > wrote: > > > > Thank you for the clarification. I've been able to fix the problem > thanks to your help. > > > > Just a quick question : should I reply including the mailing list ? > > > > Regards, > > Axel > > > > On Tue, 6 Nov 2018 at 16:08, Neil Williams <neil.williams(a)linaro.org> > wrote: > >> > >> On Tue, 6 Nov 2018 at 14:59, Axel Lebourhis <axel.lebourhis(a)linaro.org> > wrote: > >> > > >> > Hi everyone, > >> > > >> > I just upgraded NXP's installation for DRM team from 2018.4 to > 2018.10. > >> > I changed my default LXC folder for storage purpose and when I was at > 2018.4, there was a constant.py file in > /usr/lib/python3/dist-packages/lava_dispatcher/utils in order to make LAVA > know where are located LXC containers. > >> > >> Avoid making code changes for these kinds of settings. Constants and > >> settings can be modified in configuration files. There is no need to > >> alter anything in /usr/lib/python3/dist-packages/lava* - any change > >> there will always be undone at the next package upgrade. > >> > >> > https://git.lavasoftware.org/lava/lava/blob/master/etc/dispatcher.yaml#L13 > >> > >> So on a per-worker basis, you can set the LXC_PATH > >> > >> This support is covered under simple administration in the LAVA help: > >> > https://master.lavasoftware.org/static/docs/v2/simple-admin.html#lava-server > >> > >> In 2018.10 release, this file doesn't exist anymore, so I'd like to > >> know how I can specify to LAVA the correct path to LXC containers. > >> > > >> > Best regards, > >> > Axel Le Bourhis > >> > > >> > _______________________________________________ > >> > Lava-users mailing list > >> > Lava-users(a)lists.lavasoftware.org > >> > https://lists.lavasoftware.org/mailman/listinfo/lava-users > >> > >> > >> > >> -- > >> > >> Neil Williams > >> ============= > >> neil.williams(a)linaro.org > >> http://www.linux.codehelp.co.uk/ > > > > -- > > Neil Williams > ============= > neil.williams(a)linaro.org > http://www.linux.codehelp.co.uk/ >

7 years, 5 months

1
0
0 0

Default LXC directory for LAVA

by Axel Lebourhis

Hi everyone, I just upgraded NXP's installation for DRM team from 2018.4 to 2018.10. I changed my default LXC folder for storage purpose and when I was at 2018.4, there was a constant.py file in /usr/lib/python3/dist-packages/lava_dispatcher/utils in order to make LAVA know where are located LXC containers. In 2018.10 release, this file doesn't exist anymore, so I'd like to know how I can specify to LAVA the correct path to LXC containers. Best regards, Axel Le Bourhis

7 years, 5 months

2
1
0 0

LAVA API add health-check issue

by Patryk Mungai Ndungu

Hello, I am having an issue adding a health-check job for a device-type using the API. I have tried doing so using both lavacli and through a python script using the xml-rpc client, but both times I get the following error: With lavacli: Unable to call 'device-types.health-check': <Fault 400: 'Unable to write health-check: Permission denied'> With the python script: Traceback (most recent call last): File "./API.py", line 9, in <module> server.scheduler.device_types.set_health_check("r8a7743-iwg20d-q7-dbcm-ca","r8a7743-iwg20d-q7-dbcm-ca.yaml") File "/usr/lib/python3.5/xmlrpc/client.py", line 1092, in __call__ return self.__send(self.__name, args) File "/usr/lib/python3.5/xmlrpc/client.py", line 1432, in __request verbose=self.__verbose File "/usr/lib/python3.5/xmlrpc/client.py", line 1134, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib/python3.5/xmlrpc/client.py", line 1150, in single_request return self.parse_response(resp) File "/usr/lib/python3.5/xmlrpc/client.py", line 1322, in parse_response return u.close() File "/usr/lib/python3.5/xmlrpc/client.py", line 655, in close raise Fault(**self._stack[0]) xmlrpc.client.Fault: <Fault 400: 'Unable to write health-check: Permission denied'> The user I use to authenticate the xml-rpc client has superuser privileges and I have tried using a number of different API functions (including ones which require superuser privileges like device-types add and devices add), all of which have worked with both lavacli and the python script. I have also made sure that the name of the healthcheck file matches the device-type. Has anyone else encountered this issue? Thanks, Patryk Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

7 years, 5 months

3
5
0 0

adding devices in LAVA docker

by Manoj Tiwary

Hi all, I've installed lava-docker from https://github.com/kernelci/lava-docker but I'm little confused about adding devices and device-types to it . As described in the link above , i've edited boards.yaml file and added the board name as follows masters: - name: master1 host: local users: - name: admin token: longrandomtokenadmin password: admin superuser: yes staff: yes tokens: - username: admin token: dfjdfkfkdjfkdsjfsl description: no description slaves: - name: lab-slave-0 host: local remote_master: master1 remote_user: admin boards: - name: bcm2837-rpi-3-b-01 type: bcm2837-rpi-3-b uart: idvendor: 0x0403 idproduct: 0x6001 serial: A904MHLH after I built docker image and ran it. i'm getting following error while loading docker images Removing local_lab-slave-0_1 local_master1_1 is up-to-date Recreating 5b8d2c91c519_local_lab-slave-0_1 ... error ERROR: for 5b8d2c91c519_local_lab-slave-0_1 Cannot start service lab-slave-0: linux runtime spec devices: error gathering device information while adding custom device "/dev/bcm2837-rpi-3-b-01": lstat /dev/bcm2837-rpi-3-b-01: no such file or directory ERROR: for lab-slave-0 Cannot start service lab-slave-0: linux runtime spec devices: error gathering device information while adding custom device "/dev/bcm2837-rpi-3-b-01": lstat /dev/bcm2837-rpi-3-b-01: no such file or directory help me resolve this issue. Thanks, Manoj

7 years, 5 months

2
3
0 0

Fwd: regarding test suites

by Hemanth K V

Hello Lava-users, I am trying to run some test suites in LAVA and my test suite is organized as below -single script with multiple test cases -want to have report the results from LAVA of all test cases -don't want to depend on the return value of script which will make as test case as PASS or FAIL Developing test suites in shell script and using sh-test-lib and attached is sample test script for reference. Want to report the result of iptable_packageCheck_test and iptable_kernel_config_test separately in LAVA framework and will be having single script for both the test cases. Based on above criteria which is best method of running the test script in LAVA.Referred https://validation.linaro.org/static/docs/v2/developing-tests.html Following is the content of LAVA Test Shell Definition I am using metadata: name: applications format: "Lava-Test-Shell Test Definition 1.0" description: "Application tests." os: - debian scope: - Functional environment: - lava-test-shell run: steps: - cd /opt/applications - ./cron.sh - ./iptable.sh - . ../utils/send-to-lava.sh output/result.txt Thanks, Hemanth.

7 years, 5 months

3
2
0 0

Fwd: Issue in adding Device type

by Manoj Tiwary

---------- Forwarded message --------- From: Manoj Tiwary <manojtiwary22(a)gmail.com> Date: Thu 25 Oct, 2018, 6:46 PM Subject: Issue in adding Device type To: <lava-users(a)lists.linaro.org> Hi all, I've installed lava on Ubuntu 14.04 by following below steps : *deb [arch=amd64] http://images.validation.linaro.org/trusty-repo <http://images.validation.linaro.org/trusty-repo> trusty main$ wget http://images.validation.linaro.org/trusty-repo/trusty-repo.key.asc <http://images.validation.linaro.org/trusty-repo/trusty-repo.key.asc>$ sudo apt-key add trusty-repo.key.asc$ sudo apt-get update$ sudo apt-get install lava-server$ sudo a2dissite 000-default$ sudo a2ensite lava-server.conf$ sudo service apache2 restart* Now when i'm trying to add device-type using following command *$ sudo lava-server manage add-device-type qemu* I'm getting command not found error. so , I checked subcommands available using *$ sudo lava-server manage help * I got following output Available subcommands: [auth] changepassword createsuperuser [dashboard_app] addldapuser authorize_superuser linaro_ldapuserlist mergeldapuser [django] check cleanup compilemessages createcachetable dbshell diffsettings dumpdata flush inspectdb loaddata makemessages runfcgi shell sql sqlall sqlclear sqlcustom sqldropindexes sqlflush sqlindexes sqlinitialdata sqlsequencereset startapp startproject validate [django_extensions] clean_pyc compile_pyc create_app create_command create_jobs describe_form dumpscript export_emails find_template generate_secret_key graph_models mail_debug notes passwd pipchecker print_settings print_user_for_session reset_db runjob runjobs runprofileserver runscript runserver_plus set_fake_emails set_fake_passwords shell_plus show_templatetags show_urls sqlcreate sqldiff sync_media_s3 sync_s3 syncdata unreferenced_files update_permissions validate_templates [django_openid_auth] openid_cleanup [lava_scheduler_app] crowd device-dictionary dispatcher-master migrate-users-to-crowd scheduler schedulermonitor testjobmigrate [sessions] clearsessions [south] convert_to_south datamigration graphmigrations migrate migrationcheck schemamigration startmigration syncdb test testserver [staticfiles] collectstatic findstatic runserver add-device-type subcommand is not there. Help me resolve this issue. Thanks & Regards, Manoj

7 years, 5 months

2
1
0 0

Re: [Lava-users] Overwriting SERVER_IP

by Patryk Mungai Ndungu

Hello, Is there a way to overwrite the SERVER_IP variable either in the LAVA environment or in the device-types template/device dictionary? https://lava.ciplatform.org/static/docs/v2/migrating-admin-example.html?hig… No matter what I do, it remains in the rendered yaml file for a device. Unfortunately, the IP it picks up for the environment I'm working is wrong, as I'm running LAVA within a docker-container and it picks up the IP of the container, but the tftp server (within docker) is proxified to the host, meaning that the IP address it needs to pick up is the host's IP. Hence my question, is there a way to overwrite it so that the desired IP appears in the rendered job submission yaml? Thanks, Patryk Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

7 years, 5 months

2
2
0 0

lavacli: adding remote worker requires superuser

by Kevin Hilman

Hello, When trying to use lavacli to add a remote worker, it works fine if the user is a superuser. However, if I drop the superuser privileges and add just the privileges for adding workers, it fails with: Unable to call 'workers.add': <Fault 403: "User 'testuser' is not superuser." we even tried enabling all the permissions for that user, but leaving the superuser flag off, and it still fails. Why does this require superuser and the specific permissions related to workers don't work? Kevin

7 years, 5 months

4
8
0 0

job stuck after disconnection

by Corentin Labbe

Hello We got a job (number 332) stuck in running state. After 23h of inaction, the only way to stop it was to cancel+fail it. According to the logs, a small disconnection happen between the slave and master. The slave seems to try to update the final status of the job but the master "ignore" it. Regards This is the slave logs: 2018-09-21 21:45:57,197 INFO [332] Starting job2018-09-21 21:45:57,226 DEBUG [332] device : actions: 2018-09-21 21:45:57,227 DEBUG [332] env-dut : 2018-09-21 21:45:57,241 DEBUG START_OK(332) => master 2018-09-21 21:46:17,260 DEBUG PING => master (last message 20s ago) 2018-09-21 21:46:17,453 DEBUG master => PONG(20) 2018-09-21 21:46:37,475 DEBUG PING => master (last message 20s ago) 2018-09-21 21:46:37,684 DEBUG master => PONG(20) 2018-09-21 21:46:57,708 DEBUG PING => master (last message 20s ago) 2018-09-21 21:47:03,603 DEBUG master => PONG(20) 2018-09-21 21:47:23,625 DEBUG PING => master (last message 20s ago) 2018-09-21 21:47:41,199 DEBUG master => PONG(20) 2018-09-21 21:48:01,222 DEBUG PING => master (last message 20s ago) 2018-09-21 21:48:19,372 DEBUG master => PONG(20) ## 2018-09-21 21:48:39,395 DEBUG PING => master (last message 20s ago) ## 2018-09-21 21:48:59,418 DEBUG PING => master (last message 40s ago) ## 2018-09-21 21:49:19,441 DEBUG PING => master (last message 60s ago) 2018-09-21 21:49:34,458 INFO [332] Job END ## 2018-09-21 21:49:34,487 DEBUG END(332) => master 2018-09-21 21:49:39,496 WARNING Master goes OFFLINE 2018-09-21 21:49:39,496 DEBUG PING => master (last message 80s ago) 2018-09-21 21:49:39,501 INFO [332] Job END (resend) 2018-09-21 21:49:39,515 DEBUG END(332) => master 2018-09-21 21:49:44,521 INFO [332] Job END (resend) 2018-09-21 21:49:44,538 DEBUG END(332) => master 2018-09-21 21:49:49,544 INFO [332] Job END (resend) 2018-09-21 21:49:49,559 DEBUG END(332) => master 2018-09-21 21:49:54,565 INFO [332] Job END (resend) 2018-09-21 21:49:54,588 DEBUG END(332) => master 2018-09-21 21:49:59,594 DEBUG PING => master (last message 100s ago) 2018-09-21 21:49:59,594 INFO [332] Job END (resend) 2018-09-21 21:49:59,612 DEBUG END(332) => master 2018-09-21 21:50:04,618 INFO [332] Job END (resend) 2018-09-21 21:50:04,639 DEBUG END(332) => master 2018-09-21 21:50:09,645 INFO [332] Job END (resend) 2018-09-21 21:50:09,659 DEBUG END(332) => master 2018-09-21 21:50:14,665 INFO [332] Job END (resend) 2018-09-21 21:50:14,685 DEBUG END(332) => master 2018-09-21 21:50:19,690 DEBUG PING => master (last message 120s ago) 2018-09-21 21:50:19,691 INFO [332] Job END (resend) 2018-09-21 21:50:19,708 DEBUG END(332) => master 2018-09-21 21:50:24,714 INFO [332] Job END (resend) 2018-09-21 21:50:24,735 DEBUG END(332) => master 2018-09-21 21:50:29,741 INFO [332] Job END (resend) 2018-09-21 21:50:29,755 DEBUG END(332) => master 2018-09-21 21:50:34,761 INFO [332] Job END (resend) 2018-09-21 21:50:34,776 DEBUG END(332) => master 2018-09-21 21:50:39,781 DEBUG PING => master (last message 140s ago) 2018-09-21 21:50:39,782 INFO [332] Job END (resend) 2018-09-21 21:50:39,800 DEBUG END(332) => master 2018-09-21 21:50:44,806 INFO [332] Job END (resend) 2018-09-21 21:50:44,823 DEBUG END(332) => master 2018-09-21 21:50:49,829 INFO [332] Job END (resend) 2018-09-21 21:50:49,850 DEBUG END(332) => master 2018-09-21 21:50:54,856 INFO [332] Job END (resend) 2018-09-21 21:50:54,876 DEBUG END(332) => master 2018-09-21 21:50:59,882 DEBUG PING => master (last message 160s ago) 2018-09-21 21:50:59,883 INFO [332] Job END (resend) 2018-09-21 21:50:59,901 DEBUG END(332) => master 2018-09-21 21:51:04,907 INFO [332] Job END (resend) 2018-09-21 21:51:04,920 DEBUG END(332) => master 2018-09-21 21:51:09,926 INFO [332] Job END (resend) 2018-09-21 21:51:09,939 DEBUG END(332) => master 2018-09-21 21:51:14,945 INFO [332] Job END (resend) 2018-09-21 21:51:14,967 DEBUG END(332) => master 2018-09-21 21:51:19,973 DEBUG PING => master (last message 180s ago) 2018-09-21 21:51:19,974 INFO [332] Job END (resend) 2018-09-21 21:51:19,994 DEBUG END(332) => master 2018-09-21 21:51:25,000 INFO [332] Job END (resend) 2018-09-21 21:51:25,020 DEBUG END(332) => master 2018-09-21 21:51:30,026 INFO [332] Job END (resend) 2018-09-21 21:51:30,047 DEBUG END(332) => master 2018-09-21 21:51:35,053 INFO [332] Job END (resend) 2018-09-21 21:51:35,071 DEBUG END(332) => master 2018-09-21 21:51:40,077 DEBUG PING => master (last message 200s ago) 2018-09-21 21:51:40,077 INFO [332] Job END (resend) 2018-09-21 21:51:40,095 DEBUG END(332) => master 2018-09-21 21:51:45,101 INFO [332] Job END (resend) 2018-09-21 21:51:45,123 DEBUG END(332) => master 2018-09-21 21:51:50,129 INFO [332] Job END (resend) 2018-09-21 21:51:50,149 DEBUG END(332) => master 2018-09-21 21:51:55,154 INFO [332] Job END (resend) 2018-09-21 21:51:55,175 DEBUG END(332) => master 2018-09-21 21:51:58,639 DEBUG master => PONG(20) 2018-09-21 21:51:58,640 INFO Master is ONLINE 2018-09-21 21:51:58,831 DEBUG master => PONG(20) 2018-09-21 21:51:58,833 DEBUG master => PONG(20) 2018-09-21 21:52:00,053 INFO master => END_OK(332) 2018-09-21 21:52:00,054 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,062 DEBUG master => PONG(20) 2018-09-21 21:52:00,062 INFO master => END_OK(332) 2018-09-21 21:52:00,063 DEBUG [332] Unknown job 2018-09-21 21:52:00,063 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,242 INFO master => END_OK(332) 2018-09-21 21:52:00,242 DEBUG [332] Unknown job 2018-09-21 21:52:00,243 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,243 INFO master => END_OK(332) 2018-09-21 21:52:00,244 DEBUG [332] Unknown job 2018-09-21 21:52:00,244 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,244 INFO master => END_OK(332) 2018-09-21 21:52:00,245 DEBUG [332] Unknown job 2018-09-21 21:52:00,245 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,246 DEBUG master => PONG(20) 2018-09-21 21:52:00,246 INFO master => END_OK(332) 2018-09-21 21:52:00,246 DEBUG [332] Unknown job 2018-09-21 21:52:00,246 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,381 INFO master => END_OK(332) 2018-09-21 21:52:00,382 DEBUG [332] Unknown job 2018-09-21 21:52:00,382 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,436 INFO master => END_OK(332) 2018-09-21 21:52:00,436 DEBUG [332] Unknown job 2018-09-21 21:52:00,436 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,592 INFO master => END_OK(332) 2018-09-21 21:52:00,593 DEBUG [332] Unknown job 2018-09-21 21:52:00,593 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,610 DEBUG master => PONG(20) 2018-09-21 21:52:00,770 INFO master => END_OK(332) 2018-09-21 21:52:00,771 DEBUG [332] Unknown job 2018-09-21 21:52:00,771 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,892 INFO master => END_OK(332) 2018-09-21 21:52:00,892 DEBUG [332] Unknown job 2018-09-21 21:52:00,892 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:00,976 INFO master => END_OK(332) 2018-09-21 21:52:00,977 DEBUG [332] Unknown job 2018-09-21 21:52:00,977 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,156 INFO master => END_OK(332) 2018-09-21 21:52:01,157 DEBUG [332] Unknown job 2018-09-21 21:52:01,157 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,164 DEBUG master => PONG(20) 2018-09-21 21:52:01,170 INFO master => END_OK(332) 2018-09-21 21:52:01,171 DEBUG [332] Unknown job 2018-09-21 21:52:01,171 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,353 INFO master => END_OK(332) 2018-09-21 21:52:01,353 DEBUG [332] Unknown job 2018-09-21 21:52:01,353 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,493 INFO master => END_OK(332) 2018-09-21 21:52:01,493 DEBUG [332] Unknown job 2018-09-21 21:52:01,493 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,550 INFO master => END_OK(332) 2018-09-21 21:52:01,551 DEBUG [332] Unknown job 2018-09-21 21:52:01,551 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,552 DEBUG master => PONG(20) 2018-09-21 21:52:01,700 INFO master => END_OK(332) 2018-09-21 21:52:01,700 DEBUG [332] Unknown job 2018-09-21 21:52:01,700 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,745 INFO master => END_OK(332) 2018-09-21 21:52:01,745 DEBUG [332] Unknown job 2018-09-21 21:52:01,745 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,819 INFO master => END_OK(332) 2018-09-21 21:52:01,819 DEBUG [332] Unknown job 2018-09-21 21:52:01,820 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,936 INFO master => END_OK(332) 2018-09-21 21:52:01,936 DEBUG [332] Unknown job 2018-09-21 21:52:01,936 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:01,938 DEBUG master => PONG(20) 2018-09-21 21:52:02,048 INFO master => END_OK(332) 2018-09-21 21:52:02,048 DEBUG [332] Unknown job 2018-09-21 21:52:02,049 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:02,138 INFO master => END_OK(332) 2018-09-21 21:52:02,138 DEBUG [332] Unknown job 2018-09-21 21:52:02,138 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:22,160 DEBUG PING => master (last message 20s ago) 2018-09-21 21:52:37,178 INFO master => END_OK(332) 2018-09-21 21:52:37,179 DEBUG [332] Unknown job 2018-09-21 21:52:37,179 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:37,180 INFO master => END_OK(332) 2018-09-21 21:52:37,180 DEBUG [332] Unknown job 2018-09-21 21:52:37,180 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:37,181 DEBUG master => PONG(20) 2018-09-21 21:52:37,181 INFO master => END_OK(332) 2018-09-21 21:52:37,181 DEBUG [332] Unknown job 2018-09-21 21:52:37,182 DEBUG [332] Removing /var/lib/lava/dispatcher/slave/tmp/332 2018-09-21 21:52:37,374 DEBUG master => PONG(20) 2018-09-21 21:52:57,396 DEBUG PING => master (last message 20s ago) 2018-09-21 21:53:17,418 DEBUG PING => master (last message 40s ago) 2018-09-21 21:53:21,421 DEBUG master => PONG(20) 2018-09-21 21:53:21,610 DEBUG master => PONG(20) 2018-09-21 21:53:41,632 DEBUG PING => master (last message 20s ago) 2018-09-21 21:54:01,653 DEBUG PING => master (last message 40s ago) 2018-09-21 21:54:05,695 DEBUG master => PONG(20) 2018-09-21 21:54:05,893 DEBUG master => PONG(20) 2018-09-21 21:54:25,911 DEBUG PING => master (last message 20s ago) 2018-09-21 21:54:45,933 DEBUG PING => master (last message 40s ago) 2018-09-21 21:54:51,497 DEBUG master => PONG(20) 2018-09-21 21:54:51,692 DEBUG master => PONG(20) 2018-09-21 21:55:11,713 DEBUG PING => master (last message 20s ago) 2018-09-21 21:55:31,733 DEBUG PING => master (last message 40s ago) 2018-09-21 21:55:38,958 DEBUG master => PONG(20) 2018-09-21 21:55:39,147 DEBUG master => PONG(20) 2018-09-21 21:55:59,169 DEBUG PING => master (last message 20s ago) 2018-09-21 21:56:19,191 DEBUG PING => master (last message 40s ago) 2018-09-21 21:56:23,724 DEBUG master => PONG(20) 2018-09-21 21:56:23,927 DEBUG master => PONG(20) 2018-09-21 21:56:43,950 DEBUG PING => master (last message 20s ago) 2018-09-21 21:56:44,137 DEBUG master => PONG(20) 2018-09-21 21:57:04,159 DEBUG PING => master (last message 20s ago) 2018-09-21 21:57:04,351 DEBUG master => PONG(20) And this is the master logs: 2018-09-21 21:45:56,427 INFO scheduling jobs: 2018-09-21 21:45:56,428 DEBUG - bcm2837-rpi-3-b-32 2018-09-21 21:45:56,453 DEBUG -> rpi3-corelab-01 (Idle, Good) 2018-09-21 21:45:56,453 DEBUG |--> [332] scheduling 2018-09-21 21:45:56,459 DEBUG - dra7-evm 2018-09-21 21:45:56,464 DEBUG - qemu 2018-09-21 21:45:56,660 INFO [332] START => agl-core-lab-1 (rpi3-corelab-01) 2018-09-21 21:45:57,341 INFO [332] agl-core-lab-1 => START_OK 2018-09-21 21:45:57,773 DEBUG lava-logs => PING(20) 2018-09-21 21:46:16,711 INFO scheduling health checks: 2018-09-21 21:46:16,724 INFO scheduling jobs: 2018-09-21 21:46:16,725 DEBUG - dra7-evm 2018-09-21 21:46:16,729 DEBUG - qemu 2018-09-21 21:46:17,351 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:46:18,980 DEBUG lava-logs => PING(20) 2018-09-21 21:46:36,744 INFO scheduling health checks: 2018-09-21 21:46:36,757 INFO scheduling jobs: 2018-09-21 21:46:36,758 DEBUG - dra7-evm 2018-09-21 21:46:36,762 DEBUG - qemu 2018-09-21 21:46:37,566 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:46:48,466 DEBUG lava-logs => PING(20) 2018-09-21 21:46:56,776 INFO scheduling health checks: 2018-09-21 21:46:56,790 INFO scheduling jobs: 2018-09-21 21:46:56,791 DEBUG - dra7-evm 2018-09-21 21:46:56,795 DEBUG - qemu 2018-09-21 21:46:57,797 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:47:08,482 DEBUG lava-logs => PING(20) 2018-09-21 21:47:16,809 INFO scheduling health checks: 2018-09-21 21:47:16,822 INFO scheduling jobs: 2018-09-21 21:47:16,823 DEBUG - dra7-evm 2018-09-21 21:47:16,827 DEBUG - qemu 2018-09-21 21:47:23,718 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:47:31,521 DEBUG lava-logs => PING(20) 2018-09-21 21:47:36,841 INFO scheduling health checks: 2018-09-21 21:47:36,854 INFO scheduling jobs: 2018-09-21 21:47:36,855 DEBUG - dra7-evm 2018-09-21 21:47:36,859 DEBUG - qemu 2018-09-21 21:47:54,275 DEBUG lava-logs => PING(20) 2018-09-21 21:47:56,872 INFO scheduling health checks: 2018-09-21 21:47:56,885 INFO scheduling jobs: 2018-09-21 21:47:56,886 DEBUG - dra7-evm 2018-09-21 21:47:56,891 DEBUG - qemu 2018-09-21 21:48:01,321 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:48:14,292 DEBUG lava-logs => PING(20) 2018-09-21 21:48:16,903 INFO scheduling health checks: 2018-09-21 21:48:16,917 INFO scheduling jobs: 2018-09-21 21:48:16,918 DEBUG - dra7-evm 2018-09-21 21:48:16,922 DEBUG - qemu 2018-09-21 21:48:35,995 DEBUG lava-logs => PING(20) 2018-09-21 21:48:36,933 INFO scheduling health checks: 2018-09-21 21:48:36,946 INFO scheduling jobs: 2018-09-21 21:48:36,947 DEBUG - dra7-evm 2018-09-21 21:48:36,951 DEBUG - qemu 2018-09-21 21:48:39,486 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:48:56,011 DEBUG lava-logs => PING(20) 2018-09-21 21:48:56,962 INFO scheduling health checks: 2018-09-21 21:48:56,975 INFO scheduling jobs: 2018-09-21 21:48:56,976 DEBUG - dra7-evm 2018-09-21 21:48:56,981 DEBUG - qemu 2018-09-21 21:49:16,995 INFO scheduling health checks: 2018-09-21 21:49:17,009 INFO scheduling jobs: 2018-09-21 21:49:17,010 DEBUG - dra7-evm 2018-09-21 21:49:17,014 DEBUG - qemu 2018-09-21 21:49:21,406 DEBUG lava-logs => PING(20) 2018-09-21 21:49:37,026 INFO scheduling health checks: 2018-09-21 21:49:37,040 INFO scheduling jobs: 2018-09-21 21:49:37,041 DEBUG - dra7-evm 2018-09-21 21:49:37,046 DEBUG - qemu 2018-09-21 21:49:41,419 DEBUG lava-logs => PING(20) 2018-09-21 21:49:52,363 ERROR [STATE] Dispatcher <agl-core-lab-1> goes OFFLINE 2018-09-21 21:49:57,059 INFO scheduling health checks: 2018-09-21 21:49:57,067 INFO scheduling jobs: 2018-09-21 21:50:01,440 DEBUG lava-logs => PING(20) 2018-09-21 21:50:17,078 INFO scheduling health checks: 2018-09-21 21:50:17,086 INFO scheduling jobs: 2018-09-21 21:50:21,462 DEBUG lava-logs => PING(20) 2018-09-21 21:50:37,097 INFO scheduling health checks: 2018-09-21 21:50:37,105 INFO scheduling jobs: 2018-09-21 21:50:41,484 DEBUG lava-logs => PING(20) 2018-09-21 21:50:57,117 INFO scheduling health checks: 2018-09-21 21:50:57,125 INFO scheduling jobs: 2018-09-21 21:51:01,502 DEBUG lava-logs => PING(20) 2018-09-21 21:51:17,135 INFO scheduling health checks: 2018-09-21 21:51:17,144 INFO scheduling jobs: 2018-09-21 21:51:21,524 DEBUG lava-logs => PING(20) 2018-09-21 21:51:37,154 INFO scheduling health checks: 2018-09-21 21:51:37,162 INFO scheduling jobs: 2018-09-21 21:51:41,546 DEBUG lava-logs => PING(20) 2018-09-21 21:51:57,170 INFO scheduling health checks: 2018-09-21 21:51:57,178 INFO scheduling jobs: 2018-09-21 21:51:58,734 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:51:58,737 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:51:59,125 INFO [332] agl-core-lab-1 => END 2018-09-21 21:51:59,954 DEBUG get_type_name: skipping finalize 2018-09-21 21:51:59,954 DEBUG type_name failed for finalize metatype finalize 2018-09-21 21:51:59,954 DEBUG get_type_name: skipping finalize 2018-09-21 21:51:59,954 DEBUG type_name failed for finalize metatype finalize 2018-09-21 21:51:59,954 DEBUG get_type_name: skipping finalize 2018-09-21 21:51:59,954 DEBUG type_name failed for finalize metatype finalize 2018-09-21 21:51:59,960 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:51:59,964 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:51:59,968 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:51:59,971 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:51:59,974 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:51:59,977 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:52:00,093 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:00,287 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:00,341 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:00,493 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:00,496 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:52:00,674 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:00,795 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:00,881 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,061 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,063 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:52:01,075 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,256 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,397 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,453 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,456 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:52:01,568 DEBUG lava-logs => PING(20) 2018-09-21 21:52:01,603 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,646 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,722 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,840 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,842 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:52:01,884 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:01,985 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:02,040 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:02,106 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:02,109 DEBUG agl-core-lab-1 => PING(20) 2018-09-21 21:52:02,220 INFO [332] agl-core-lab-1 => END (duplicated), skipping 2018-09-21 21:52:17,187 INFO scheduling health checks: 2018-09-21 21:52:17,201 INFO scheduling jobs: 2018-09-21 21:52:17,202 DEBUG - dra7-evm 2018-09-21 21:52:17,207 DEBUG - qemu 2018-09-21 21:52:21,585 DEBUG lava-logs => PING(20)

7 years, 6 months

4
4
0 0

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

7 years, 6 months

2
12
0 0

Integrate auxiliary device in LAVA test job definition

by Oana Ercus

Hello, I am looking for a suitable method for the following use-case: during test, I need to access the connection to the workstation that runs my LAVA worker and use it as a second namespace in order to be able to issue some commands on the the workstation (like playing an audio file). In other words I need to integrate the workstation as an auxiliary device needed for testing in the test job definition (like ssh <user>@<ws_ip_addr> and send some commands). Using LXC is not an option at this moment. At a first sight, the Multinode support would have the most of the needed features, but I did not find an example of such an usage, if there is any example you can point me to, I will be grateful. Thank you in advance, Oana Ercus

7 years, 6 months

2
1
0 0

Setting tags for existing devices via command line

by Tim Jaacks

Hello everyone, is there a way of setting tags for existing devices via the command line? The "lava-server manage devices update" command does not have a "--tags" parameter, as the "lava-server manage devices add" has. 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

7 years, 6 months

2
3
0 0

Does deploy action have such as "deploy-namespace" to indicate to use previous deploy images?

by john zhang

In lava job definition, boot action can use "connection-namespace" to indicate use previous namespace's connection.Does deploy action have such as "deploy-namespace" to indicate to use previous deploy image? For example in an application scenario, it need to sequential execution two phases pipeline(deploy,boot,test), it can be solved by define two namespace in job definiton. When run it executed in serial as : phase1(namespace1) deploy->boot->test -> phase2(namespace2) deploy->boot->test. If phase2 deploy images(kernel,dtb,rootfs) are exactly same as phase2 deploy images,how to speed up phase2 deploy execution? I guess if deploy action have such as "deploy-namespace" to indicate previous deploy,then phase2 deploy process can be pass.

7 years, 6 months

2
7
0 0

In job defintion file the description of the related device is only the "device_type", why is not "device"?

by john zhang

Before test job,we need to add a "device_type" .jinja2 file to directory /etc/lava-server/dispatcher-config/device-types/,and add a "device" .jinja2 file to /etc/lava-server/dispatcher-config/devices/. The "device_type" .jinja2 file defines device type(for example different hardware) ,and "device" .jinja2 file(at: /etc/lava-server/dispatcher-config/devices/) defines a concrete device. When the dispatcher submits job, a job should be submited to a concrete device.But In job defintion file,the description of the related device is only the "device_type" but no "device", why is not "device"? for example: # Your first LAVA JOB definition for arm device_type: arm job_name: arm pipeline, first job ## why not as: # Your first LAVA JOB definition for arm device: arm01 job_name: arm pipeline, first job

7 years, 6 months

3
6
0 0

does LXC devices mean LXC can emulate various arm devices peripheral interfaces?

by chao yang

https://validation.linaro.org/static/docs/v2/admin-lxc-deploy.html#lxc-depl… , It say that LXC devices can run lava tests within a container without disturbing the dispatcher host. Does LXC support the arm device? Although LXC may supports to run the arm virtual machine in PC server,but how does it support the completed arm device(Including various peripheral interfaces eg ethernet,usb.. ) ? Because the test job often test various peripheral interfaces,Is LXC emulating these interfaces?

7 years, 6 months

2
4
0 0

Getting tests on DUT: other solutions?

by Diego Russo

Hello, Currently I'm testing a board type which deploys OE via u-boot-ums. Before flashing the image into the device, LAVA slave modifies the image copying tests definition onto it. Once the image is modified with all the tests, this is dd'ed into the device, booted and tests will be running. This is OK so far but as soon as we enable signed images (roofs will be R/O but we will be having other R/W partitions) this won't work anymore as we are changing the image and it needs to be resigned. Moreover, this is very board specific. I'm here to investigate alternative solutions which have a more "generic" approach which also a developer (without LAVA) can run. The only assumption is that *the DUT has always wired network connectivity with the SLAVE*. The workflow I have in mind is something like: 1) I have a signed image which I deploy onto the DUT 2) Boot the DUT 3) Instruct the device to get tests from somewhere (either from the SLAVE or internet) 4) Run those tests The step I'd like to solve is 3). I was thinking something like that: * download/compile all I need on the SLAVE (it is not possible to do it on the DUT due to limited resources/libraries/tooling) * setup some sort of server http on the SLAVE in order to serve those files * wget those files onto the DUT * setup and execute the tests. The above approach should work WITHOUT LAVA as well. Basically, replace SLAVE with "developer computer" Is it something I can architect with LAVA? Does LAVA give me this flexibility? Thanks for your help Regards -- Diego Russo Staff Software Engineer - diego.russo(a)arm.com Direct Tel. no: +44 1223 405920 Main Tel. no: +44 1223 400400 ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - http://twitter.com/diegor http://www.linkedin.com/in/diegor 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.

7 years, 6 months

2
4
0 0

Re: [Lava-users] Description of LAVA's user permissions

by Tim Jaacks

>On Mon, 8 Oct 2018 at 10:19, Tim Jaacks <tim.jaacks at garz-fricke.com> wrote: > >> Hello everyone, >> >> is there a detailed description for all the user permissions defined by >> LAVA? Or where do I find them in the source code? >> > >LAVA currently only has one level of permissions - superuser or not. > >There is on custom permission - cancel or resubmit test job. > >Everything else comes from Django and is ignored. > At least the "Can add test job" permission seems to be evaluated as well. The UI element "Scheduler -> Submit" is available only if this permission is set. > >> >> There are lots of permissions of which I have no idea what they mean, e.g. >> "Can [add|change|delete] action data". How is this permission used? >> >> 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 at 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 >> >> _______________________________________________ >> Lava-users mailing list >> Lava-users at lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lava-users >> > > >-- > >Neil Williams >============= >neil.williams at linaro.org >http://www.linux.codehelp.co.uk/ >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: <http://lists.linaro.org/pipermail/lava-users/attachments/20181008/bf5abb68/…> 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

7 years, 6 months

1
0
0 0

Re: [Lava-users] Description of LAVA's user permissions

by Tim Jaacks

>On Mon, 8 Oct 2018 at 10:19, Tim Jaacks <tim.jaacks at garz-fricke.com> wrote: > >> Hello everyone, >> >> is there a detailed description for all the user permissions defined by >> LAVA? Or where do I find them in the source code? >> > >LAVA currently only has one level of permissions - superuser or not. > >There is on custom permission - cancel or resubmit test job. > >Everything else comes from Django and is ignored. > Oh thanks, I didn't know that. Is this noted anywhere in the docs? > >> >> There are lots of permissions of which I have no idea what they mean, e.g. >> "Can [add|change|delete] action data". How is this permission used? >> >> 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 at 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 >> >> _______________________________________________ >> Lava-users mailing list >> Lava-users at lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lava-users >> > > >-- > >Neil Williams >============= >neil.williams at linaro.org >http://www.linux.codehelp.co.uk/ >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: <http://lists.linaro.org/pipermail/lava-users/attachments/20181008/bf5abb68/…> 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

7 years, 6 months

1
0
0 0

Description of LAVA's user permissions

by Tim Jaacks

Hello everyone, is there a detailed description for all the user permissions defined by LAVA? Or where do I find them in the source code? There are lots of permissions of which I have no idea what they mean, e.g. "Can [add|change|delete] action data". How is this permission used? 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

7 years, 6 months

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users