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

by Ilya Fedusiv

Hi, Lava Team! Want to use user_commands as written here : https://validation.linaro.org/static/docs/v2/actions-command.html Device dictionary has : {% set user_commands = {'switch_mode' : {'do': './usr/local/scripts/switch_mode.sh'}} %} Job https://pastebin.com/hhWbC207 I have lxc and custom script to set device flash-mode. But have error error_msg: 'common' is a reserved namespace that should not be present with other namespaces To fix it I added namespace to command: - command: namespace: tlxc name: switch_to_qdl But error again in validate before submit Invalid definition: extra keys not allowed @ data['actions'][3]['command']['namespace'] I have fastboot and custom flash methods. pre_power_command in deploy I use for fastboot. Need to use somehow custom script to switch to another mode, that's why I decided to use -command action. Please help how to fix error with namespaces or suggest another solution. Best regards, Ilya Fedusiv

5 years, 3 months

2
3
0 0

Using "command" actions in multinode jobs

by Ryan Harkin

Hi LAVA folks, I'm trying to create a multinode job based on iperf.yaml: https://github.com/Linaro/test-definitions/blob/master/automated/linux/iper… (note, this iperf.sh test doesn't actually work as intended, but that's a problem I'm debugging). The full job definition is at the bottom of this email. Anyway, I'm adding my own deploy and boot sections, as per working single node jobs. However, my deploy uses "command" actions, like this: - command: role: - host - guest namespace: dfu-firmware name: set_boot_to_nand These give error messages like this: Invalid definition: extra keys not allowed @ data['actions'][1]['command']['role'] And if I remove the "role" settings, I get a different error: Valid definition with warnings: Every action of a multinode job should have roles So it seems like I'm in a loop. Any suggestions?? Thanks, Ryan. ------------------------------------------------------ JOB DEFINITION ------------------------------------------------------ job_name: lces2-iperf timeouts: job: minutes: 60 action: minutes: 3 connection: minutes: 5 priority: medium visibility: public metadata: iperf-version: v3 protocols: lava-multinode: roles: host: device_type: rzn1d count: 1 timeout: minutes: 30 guest: device_type: rzn1d count: 1 timeout: minutes: 30 actions: #################### # Deploy QSPI images #################### - deploy: role: - host - guest namespace: dfu-firmware to: tmpfs images: sf_fsbl: image_arg: --alt sf_fsbl --download {sf_fsbl} url: https://snapshots.linaro.org/openembedded/schneider/linaro-warrior-4.9/rzn1… sf_trustedfw: image_arg: --alt sf_trustedfw --download {sf_trustedfw} url: https://snapshots.linaro.org/openembedded/schneider/linaro-warrior-4.9/rzn1… sf_uboot0: image_arg: --alt sf_uboot0 --download {sf_uboot0} url: https://snapshots.linaro.org/openembedded/schneider/linaro-warrior-4.9/rzn1… sf_uboot1: image_arg: --alt sf_uboot1 --download {sf_uboot1} url: https://snapshots.linaro.org/openembedded/schneider/linaro-warrior-4.9/rzn1… - command: namespace: dfu-firmware role: - host - guest name: set_boot_to_nand - boot: namespace: dfu-firmware role: - host - guest method: dfu timeout: minutes: 10 - command: namespace: test role: - host - guest name: set_boot_to_qspi ############### # TFTP/NFS ############### - deploy: namespace: test-nfs role: - host - guest timeout: minutes: 5 to: tftp os: oe kernel: url: https://snapshots.linaro.org/openembedded/schneider/linaro-warrior-4.9/rzn1… type: zimage dtb: url: https://snapshots.linaro.org/openembedded/schneider/linaro-warrior-4.9/rzn1… nfsrootfs: url: https://snapshots.linaro.org/openembedded/schneider/linaro-warrior-4.9/rzn1… compression: bz2 - boot: namespace: test-nfs role: - host - guest connection-namespace: dfu-firmware timeout: minutes: 20 method: u-boot commands: - setenv autoload no - dhcp - dhcp - env print - setenv serverip {SERVER_IP} - tftp {KERNEL_ADDR} {KERNEL} - tftp {DTB_ADDR} {DTB} - setenv bootargs 'console=ttyS0,115200n8 root=/dev/nfs rw nfsroot={NFS_SERVER_IP}:{NFSROOTFS},tcp,hard,intr,vers=3 rootwait coherent_pool=2M ip=dhcp' - '{BOOTX}' auto_login: login_prompt: 'login:' username: root prompts: - 'root@snarc-soca9:' - 'root@rzn1-snarc:' - test: namespace: test-nfs role: - host timeout: minutes: 30 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: run-iperf3-server description: "Run iperf3 in server mode" run: steps: - apt-get -y update - apt-get -y install iperf3 - if iperf3 -s -D; then lava-test-case run-iperf3-server --result 'pass'; else lava-test-raise 'Failed to run ipef3 server'; fi - lava-send server-ready ipaddr=$(lava-echo-ipv4 eth0) - lava-wait client-done - pkill iperf3 from: inline name: run-iperf3-server path: inline/run-iperf3-server.yaml - test: namespace: test-nfs role: - guest timeout: minutes: 30 definitions: - repository: https://git.linaro.org/people/chase.qi/test-definitions.git from: git path: automated/linux/iperf/iperf.yaml name: iperf3-test parameters: SERVER: lava-host-role # The MSG ID and KEY should be the same as the ones sent by lava-send above MSG_ID: server-ready MSG_KEY: ipaddr

5 years, 3 months

2
3
0 0

Re: [Lava-users] Unable to boot target via ipxe using nfs and tftp protocol via lava-docker container

by admirer mishra

Hi, I found the solution, we have to mount dispatcher.yaml file from lava-server in lava-master container as well beacuse lava-master is the one who communicate with DUT and run the job. regards admirer mishra

5 years, 4 months

1
0
0 0

Re: [Lava-users] Unable to boot target via ipxe using nfs and tftp protocol via lava-docker container

by admirer mishra

Hi Stevan, I am using latest lava-docker containers 2020.01 so using rest api I set the dispatcher ip and post it, which creates a dispatcher.yaml file with the content dispatcher_ip: '141.64.81.191' (not my ip) I checked it's there in the directory (/etc/lava-server/dispatcher.d/lava-dispatcher/dispatcher.yaml), but still no change in SERVER_IP or NFS_SERVER_IP (everything is same) while running the job, due to which not able to do tftp. I even tried with restarting the lava-server but still no change. Thanks for your time. regards, admirer mishra

5 years, 4 months

2
1
0 0

Unable to boot target via ipxe using nfs and tftp protocol via lava-docker container

by admirer mishra

Hi there, Yesterday, while going through the mail, I found about the docker-compose file provided by lava. The script is amazing it gives even more understanding of how actual lava-server and dispatcher work. I am a complete beginner just working on lava and docker from last 20 days. So, I am trying to boot a x86 device via ipxe using nfs and tftp protocol. In normal lava server running on host everything works fine because the host ip and target ip are on same local network so tftp and nfs works fine. But docker uses internal network and target is on local network so how to configure so that it works? I also used the docker compose file but the problem still persists. Is there any other configuration in the containers that I have to do make it work? Please help I am complete newbie in this field. Thanks for your time admirer mishra

5 years, 4 months

2
1
0 0

Lava Dispatcher Docker container tftp issue

by ROSHAN KUMAR

Hi, I am using the docker-compose file provided by lava community. I don't understand why there is a separate tftpd container and also how my device who is on host local network will communicate with it. Also same things I don't understand for nfs container. Please let me know Thanks and regards ROSHAN KUMAR

5 years, 4 months

3
3
0 0

Lava Server Docker container not working as Dispatcher

by ROSHAN KUMAR

Hi, I created a lava server docker container on amd64 machine using lavasoftware/lava-server docker image present on docker hub. But after running the container I didn't find any Dispatcher online except lava-logs. Did the current version of lava server docker container doesn't work as dispatcher similar to normal lava server. Please let me know. Thanks and regards ROSHAN KUMAR

5 years, 4 months

2
1
0 0

Mix device's type

by Ilya Fedusiv

Hi! I want to mix two flashing types for device : fastboot and custom ( run custom script ) I already did both types separately using deploy methods : fastboot and flasher How I can mix both types? And in web gui in device panel what does mean that error? Configuration Error: missing or invalid template. Jobs requesting this device type (mix-type) will not be able to start until a template is available on the master. Best regards, Ilya

5 years, 4 months

2
1
0 0

Dropping apache2 from lava-server container

by Remi Duraffort

Hello everyone, if you follow the latest developments, you might have seen that LAVA is now using whitenoise to allow gunicorn to serve static files. In the current releases (2020.01 and before), apache2 is forwarding dynamic requests to gunicorn and serving static files himself. In the next release, apache2 will forward all the requests to gunicorn that will serve both dynamic and static content. If you use the debian packages, apache2 will still be installed and configured automatically. We are proposing to drop the apache2 packages from the lava-server docker container. In fact, if you use the docker container, you have anyway to setup a reverse proxy to make the container visible to the outside world and to do the SSL termination. What do you think about this? Rgds -- Rémi Duraffort LAVA Architect Linaro

5 years, 4 months

2
3
0 0

Re: [Lava-users] Upgrade LAVA

by Remi Duraffort

The slaves/worker logs are in /var/log/lava-dispatcher/lava-slave.log Le mar. 11 févr. 2020 à 12:37, dhanu msys <dhanuskd.palnati(a)gmail.com> a écrit : > Hi Remi, > > After upgrading the LAVA Package , I have seen Worker Status show > "Offline". > > As per Earlier Experience , I have check the Lava-Logs and Lava-Master > Logs under /var/log/lava-server/lava-logs.log and > /var/log/lava-server/lava-master.log , it seems both are running fine > without any error. > > And also I have checked the Encryption in the both lava-master & lava-logs > under /etc/lava-server/lava-logs & /etc/lava-server/lava-master. PFA. > > Please check the attachment logs once and let me know if any changes need > to be done specific to the latest lava package. > > Thanks & Regards, > Dhanunjaya. P > > > On Wed, Feb 5, 2020 at 6:59 PM dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > >> Hi Remi, >> >> Thanks for sharing the Information. >> >> I can able to update the LAVA Package. >> >> Please find the latest packages list in below. >> >> doclava-aosp/stable 6.0.1+r55-1 all >> klavaro/stable 3.03-2 amd64 >> lava-common/unknown,now 2020.01+10+buster all [installed] >> lava-coordinator/unknown 2020.01+10+buster all [upgradable from: 0.1.7-1] >> lava-dev/unknown 2020.01+10+buster all [upgradable from: 2019.01-5] >> lava-dispatcher-host/unknown,now 2020.01+10+buster all >> [installed,automatic] >> lava-dispatcher/unknown,now 2020.01+10+buster all [installed] >> lava-lxc-mocker/unknown 2020.01+10+buster all >> lava-server-doc/unknown 2020.01+10+buster all [upgradable from: 2019.01-5] >> lava-server/unknown,now 2020.01+10+buster all [installed] >> lava-tool/stable,now 0.25-2 all [installed] >> lava/unknown,now 2020.01+10+buster all [installed] >> lavacli/unknown 0.9.7+buster all [upgradable from: 0.9.5-1] >> lavapdu-client/stable,now 0.0.5-1 all [installed] >> lavapdu-daemon/stable,now 0.0.5-1 all [installed] >> r-cran-lava/stable 1.6.4-1 all >> r-cran-lavaan/stable 0.6.3-1 all >> >> Thanks for immediate support. >> >> Regards, >> Dhanunjaya. P >> >> >> On Wed, Feb 5, 2020 at 3:55 PM Remi Duraffort <remi.duraffort(a)linaro.org> >> wrote: >> >>> Hello, >>> >>> add the apt lavasoftware depository. >>> >>> See >>> https://lava.readthedocs.io/en/latest/admin/basic-tutorials/instance/instal… >>> This will create a new source >>> "deb https://apt.lavasoftware.org/release buster main" >>> >>> >>> Rgds >>> >>> Le mer. 5 févr. 2020 à 05:59, dhanu msys <dhanuskd.palnati(a)gmail.com> a >>> écrit : >>> >>>> Hi Team, >>>> >>>> How to get the Latest Version changes in the LAVA Package for Single >>>> Instance? >>>> >>>> What is the Latest version released ? >>>> >>>> Please let me know the "How to Upgrade the Lava package without >>>> disturbing the existing test setup. >>>> >>>> Here I have attached the Lava packages list in my current setup to run >>>> the lava for reference. PFA. >>>> >>>> Thanks & Regards, >>>> Dhanunjaya. P >>>> _______________________________________________ >>>> Lava-users mailing list >>>> Lava-users(a)lists.lavasoftware.org >>>> https://lists.lavasoftware.org/mailman/listinfo/lava-users >>>> >>> >>> >>> -- >>> Rémi Duraffort >>> LAVA Architect >>> Linaro >>> >> -- Rémi Duraffort LAVA Architect Linaro

5 years, 4 months

2
1
0 0

Upgrade LAVA

by dhanu msys

Hi Team, How to get the Latest Version changes in the LAVA Package for Single Instance? What is the Latest version released ? Please let me know the "How to Upgrade the Lava package without disturbing the existing test setup. Here I have attached the Lava packages list in my current setup to run the lava for reference. PFA. Thanks & Regards, Dhanunjaya. P

5 years, 4 months

2
2
0 0

Re: [Lava-users] [EXT] Re: Test jobs to boot the target through JLink

by dhanu msys

Hi Andrei, Thanks for suggestion, I too had a same doubt before proceeding with the upgrade. I will try to setup the latest version in new system or i will take a backup of existing setup and run the test. Thanks & Regards, Dhanunjaya. P On Mon, Jan 27, 2020 at 2:24 PM Andrei Gansari <andrei.gansari(a)nxp.com> wrote: > Hello Dhanunjaya, > > > > These are the instructions on installing lava, you have to do something > similar to this in order to upgrade: > > https://docs.lavasoftware.org/lava/installing_on_debian.html > > > > I’m not sure if it will break or not your current setup, so be cautious > when upgrading, better backup if you have a live setup that is testing > other boards. > > > > I’m not a currently maintaining a LAVA server so I don’t have experience > updating from one version to another. > > Better you search the mailing list, ask on the mailing list or tryout on a > virtual machine. > > > > > > Andrei > > > > *From:* dhanu msys <dhanuskd.palnati(a)gmail.com> > *Sent:* Friday, January 24, 2020 12:44 PM > *To:* Andrei Gansari <andrei.gansari(a)nxp.com> > *Subject:* Re: [EXT] Re: [Lava-users] Test jobs to boot the target > through JLink > > > > *Caution: *EXT Email > > Hi Andrei, > > > > Can you please share the procedure to upgrade to the latest lava version. > > > > Thanks in advance. > > > > Regards, > > Dhanunjaya. P > > > > > > On Thu, Jan 23, 2020 at 7:33 PM Andrei Gansari <andrei.gansari(a)nxp.com> > wrote: > > From the screenshot it looks like you have a version of LAVA that does not > support jlink boot method. > > JLink was added in version 2019.10-1 > > > > Andrei > > > > *From:* dhanu msys <dhanuskd.palnati(a)gmail.com> > *Sent:* Thursday, January 23, 2020 3:13 PM > *To:* Andrei Gansari <andrei.gansari(a)nxp.com> > *Cc:* Kumar Gala <kumar.gala(a)linaro.org>; Andrei Gansari < > andrei.gansari(a)linaro.org>; lava-users <lava-users(a)lists.lavasoftware.org> > *Subject:* Re: [EXT] Re: [Lava-users] Test jobs to boot the target > through JLink > > > > *Caution: *EXT Email > > Hi Andrei, > > > > I run the test job based on the references shared by you. > > > > But , facing the error , while running the test job. > > > > Here I have attached the device template & device configuration files > along with the error. > > > > Please find the attachments & please provide me the inputs. > > > > Thanks in Advance. > > > > Regards, > > Dhanunjaya. P > > > > > > On Tue, Jan 21, 2020 at 5:29 PM Andrei Gansari <andrei.gansari(a)nxp.com> > wrote: > > Hello Dhanunjaya. P, > > > > You need to create a yaml file in > lava/lava_dispatcher/tests/sample_jobs/fpga_a64-jlink.yaml … assuming you > have already created the device fpga_a64. > > > > You have an example of FRDM-K64F booting cmsis-dap here: > > > https://github.com/Linaro/lite-lava-docker-compose/blob/lite/example/lava.j… > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> > > You need to replace “method: cmsis-dap” -> “method: jlink” > > > > I didn’t run a clean lava environment, so I maybe missing something. > > > > > > Andrei G. > > > > *From:* dhanu msys <dhanuskd.palnati(a)gmail.com> > *Sent:* Tuesday, January 21, 2020 12:31 PM > *To:* Andrei Gansari <andrei.gansari(a)nxp.com> > *Cc:* Kumar Gala <kumar.gala(a)linaro.org>; Andrei Gansari < > andrei.gansari(a)linaro.org>; lava-users <lava-users(a)lists.lavasoftware.org> > *Subject:* Re: [EXT] Re: [Lava-users] Test jobs to boot the target > through JLink > > > > *Caution: *EXT Email > > Hi Andrei, > > > > Based on the information shared earlier , i have tried to configure the > device type to make use of jlink based boot method test job , but i have > faced an issue "Configuration Error: missing or invalid template*.* Jobs > requesting this device type (fpga_a64) will not be able to start until a > template is available on the master." > > > > Can you please check once and share the updated Device-Type Template also. > > > > Thanks & Regards, > > Dhanunjaya. P > > > > > > On Tue, Jan 21, 2020 at 3:28 PM dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > > Hi Andrei , > > Hi Kumar, > > > > Can you please share some of the Test Job definition references to check > the Jlink-based test jobs configurations. > > > > Thanks & Regards, > > Dhanunjaya. P > > > > > > On Tue, Nov 26, 2019 at 2:36 PM Andrei Gansari <andrei.gansari(a)nxp.com> > wrote: > > I’ve tested lava+jlink on Cortex M with both onboard debugger and external > debugger, like the one you referenced. > > You should change the following if needed: > > > > address: > > *0x00000000* > > options: > > - '-device *MK64FN1M0xxx12'* > > - '-if SWD' > > - '-speed 4000' > > > > The interface SWD is supported, not JTAG, that can be easily changed if > you need to. > > > > Regards, > > Andrei > > > > *From:* Lava-users <lava-users-bounces(a)lists.lavasoftware.org> *On Behalf > Of *dhanu msys > *Sent:* Tuesday, November 26, 2019 7:49 AM > *To:* Kumar Gala <kumar.gala(a)linaro.org> > *Cc:* Andrei Gansari <andrei.gansari(a)linaro.org>; lava-users < > lava-users(a)lists.lavasoftware.org> > *Subject:* [EXT] Re: [Lava-users] Test jobs to boot the target through > JLink > > > > *Caution: *EXT Email > > Hi Kumar, > > > > Thanks for sharing the reference. > > > > It's better to have some references for the test jobs submission also. > > > > Currently we are in initial phase to make use of LAVA , so we wants to > check the feasibility to deploy through JLink based test jobs. > > > > Here I have provided the JLink Interface , which we are going to use for > the development. > > > > > https://www.thingbits.net/products/segger-j-link-base-jtag-swd-debugger?utm… > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.thing…> > > > > > Regards, > > Dhanunjaya. P > > > > > > On Sat, Nov 23, 2019 at 9:37 PM Kumar Gala <kumar.gala(a)linaro.org> wrote: > > > > > On Nov 21, 2019, at 11:06 PM, dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > > > > Hi Team, > > > > Can you please share some reference test jobs to run the tests using > J-Link boot method. > > Here’s a reference to the board cfg side change for J-Link: > > > https://github.com/agansari/lite-lava/blob/35a5bcbc01780638e6fd5e126bdfe180… > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> > > Andrei, > > Did you have a test job example to go along with this? > > - k > >

5 years, 4 months

1
1
0 0

lava-run crash after submitting a job

by Alexander Moore

Hello, Our internal LAVA setup has been hitting this crash intermittently (it reproduces about one out of every 30 job submissions). The below log snippet is from the 2019.07 LAVA docker images, but we updated to the 2019.12 images and the crash still occurs with the same error signature. lava-master | 2019-10-22 15:37:17,539 DEBUG |--> [523] scheduling lava-master | 2019-10-22 15:37:17,854 INFO [523] START => lava-dispatcher (CY8CKIT_062-01) lava-master | 2019-10-22 15:37:17,969 INFO [523] lava-dispatcher => START_OK lava-master | 2019-10-22 15:37:22,981 INFO [523] lava-dispatcher => END (lava-run crashed, mark job as INCOMPLETE) lava-master | 2019-10-22 15:37:23,038 ERROR [523] Unable to dump 'description.yaml' lava-master | 2019-10-22 15:37:23,038 ERROR [523] Compressed data ended before the end-of-stream marker was reached lava-master | Traceback (most recent call last): lava-master | File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-master.py", line 337, in _handle_end lava-master | description = lzma.decompress(compressed_description) lava-master | File "/usr/lib/python3.5/lzma.py", line 340, in decompress lava-master | raise LZMAError("Compressed data ended before the " lava-master | _lzma.LZMAError: Compressed data ended before the end-of-stream marker was reached Please let me know if I can provide any other info to help debug. Thanks, Alex 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.

5 years, 4 months

2
9
0 0

Device node in LXC is not accessible in hacking session

by Tim Jaacks

Hey everyone, I have a problem where a physical hardware device on my worker passed through to an LXC container cannot be read from or written to when I am connected to the LXC in a hacking session via SSH. I have registered the device in my static_info: {% set static_info = [ {"board_id": "GO31472"}, ] %} LAVA starts the LXC and attaches the device to it correctly: start: 2.2 lxc-add-static (timeout 00:04:50) [remote] Adding /dev/ttyUSB16, /dev/serial/by-id/usb-GFL_M_504_G_GO31472-if00-port0, /dev/bus/usb/004/008, /dev/serial/by-path/pci-0000:00:1d.3-usb-0:1:1.0-port0 nice lxc-device -n lxc-remote-10577 add /dev/ttyUSB16 nice lxc-device -n lxc-remote-10577 add /dev/serial/by-id/usb-GFL_M_504_G_GO31472-if00-port0 nice lxc-device -n lxc-remote-10577 add /dev/bus/usb/004/008 nice lxc-device -n lxc-remote-10577 add /dev/serial/by-path/pci-0000:00:1d.3-usb-0:1:1.0-port0 end: 2.2 lxc-add-static (duration 00:00:00) [remote] When I connect to the LXC via SSH using a hacking session, the device is there, but I cannot access it: root@lxc-remote-10577:~# ls -la /dev/ttyUSB16 crw-r--r-- 1 root root 180, 0 Aug 27 11:26 /dev/ttyUSB16 root@lxc-remote-10577:~# cat /dev/ttyUSB16 cat: /dev/ttyUSB16: Operation not permitted However, when I attach to the LXC directly from the worker using "lxc-attach", I can access it: root@lxc-remote-10577:~# ls -la /dev/ttyUSB16 crw-r--r-- 1 root root 180, 0 Aug 27 11:26 /dev/ttyUSB16 root@lxc-remote-10577:~# cat /dev/ttyUSB16 ��^C root@lxc-remote-10577:/# Did anybody else encounter such a problem before? Any hints on what might be the difference between lxc-attach and the SSH connection? Mit freundlichen Grüßen / Best regards Tim Jaacks DEVELOPMENT ENGINEER Garz & Fricke GmbH Schlachthofstrasse 20 21079 Hamburg Direct: +49 40 791 899 - 183 Fax: +49 40 791899 - 39 tim.jaacks(a)garz-fricke.com www.garz-fricke.com WE MAKE IT YOURS! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun

5 years, 5 months

1
0
0 0

Test jobs to boot the target through JLink

by dhanu msys

Hi Team, Can you please share some reference test jobs to run the tests using J-Link boot method. Thanks & Regards, Dhanunjaya. P

5 years, 5 months

3
8
0 0

Creating a multinode job

by Ryan Harkin

Hi folks, I'm struggling to create a working multinode job and wondered if someone could help? Here's the sample job I've submitted to try to get a handle on how multinode works: https://validation.linaro.org/scheduler/job/1963418.1#L1745 The main problem happens when LAVA executes this command on the shell: /lava-1963419/bin/lava-test-runner /lava-1963419/1 But there is no "/lava-1963419/1" directory, so then it can't find lava-common-functions and fails like this because the path is relative to a path that doesn't exist: /lava-1963419/bin/lava-test-runner: line 18: /lava-1963419/1/../bin/lava-common-functions: No such file or directory When I run a similar definition on a single node, it uses zero for the lava sub-dir, not 1, and it works: https://validation.linaro.org/scheduler/job/1963236#L2065 I tried to work out what was running here, to see if I could debug the scripts to work out where the "1" comes from. I cloned the LAVA repo and I cannot see the script "environment", and the lava-test-runner sources lava-common-functions from line 16, not 18. So now I'm curious where LAVA gets its scripts from. Another minor point, I'm following the instructions on this link: https://docs.lavasoftware.org/lava/writing-multinode.html And there are some dead links in there, eg. https://docs.lavasoftware.org/lava/examples/test-jobs/first-multinode-job.y… https://docs.lavasoftware.org/lava/examples/test-jobs/second-multinode-job.… https://docs.lavasoftware.org/lava/examples/test-jobs/bbb-lxc-ssh-guest.yaml Thanks, Ryan.

5 years, 5 months

2
3
0 0

grub boot

by Hemanth K V

Hello Lava Users, Trying to boot a target in LAVA based on base-grub device type.The LAVA version installed is 2019.11. >From the GRUB command line when I manually enter following commands for network setting ,it is getting executed successfully. grub> insmod efinet grub> net_ls_cards efinet2 20:87:56:b6:74:cd efinet1 20:87:56:f1:cf:21 efinet0 20:87:56:f1:cf:22 grub> net_add_addr test efinet0 134.86.62.99 grub> net_ls_addr test 20:87:56:f1:cf:22 134.86.62.99 But when I am sending same thing via LAVA , *net_add_addr test efinet0 134.86.62.99* [H[J[1;1Hgrub> net_add_addr test efinet0 134.86.62.99 bootloader-commands: Wait for prompt ['grub>'] (timeout 00:09:38) [1;7Hn[1;8H[1;8He[1;9H[1;9Ht[1;10H[1;10H_[1;11H[1;11Ha[1;12H[1;12Hd[1;13H[1;13Hd[1;14H[1;14H_[1;15H[1;15Ha[1;16H[1;16Hd[1;17H[1;17Hd[1;18H[1;18Hr[1;19H[1;19H [1;20H[1;20Ht[1;21H[1;21He[1;22H[1;22Hs[1;23H[1;23Ht[1;24H[1;24H [1;25H[1;25H [1;26H *error: three arguments expected.* The above error will come when we don't pass 3 parameters to net_add_addr grub> net_add_addr test efinet0 error: three arguments expected. I am getting this error even though 3 arguments are getting passed. Attached is the screen shot of the Job execution log. Thanks, Hemanth.

5 years, 5 months

3
4
0 0

Re: [Lava-users] Job Failure-Infrastructure error for qemu arm64

by Remi Duraffort

Hello, I ran the same job on staging (debian buster) and it's working fine: https://staging.validation.linaro.org/scheduler/job/266192 Something wrong on your system. Difficult to know. Could you send the full logs. Rgds Le mar. 14 janv. 2020 à 07:35, dhanu msys <dhanuskd.palnati(a)gmail.com> a écrit : > Hi Remi, > > Can you please check the logs and let me know what was the changes i need > to make to run the LAVA QEMU arm based test jobs. > > Thanks & Regards, > Dhanunjaya. P > > > On Mon, Dec 23, 2019 at 5:47 PM dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > >> Hi Remi, >> >> Can you able to check the below mentioned the Log Files & Job related >> configurations along with the Job failure logs. >> >> Thanks & Regards, >> Dhanunjaya. P >> >> >> On Thu, Nov 28, 2019 at 6:01 PM dhanu msys <dhanuskd.palnati(a)gmail.com> >> wrote: >> >>> Hi Remi, >>> >>> Here I have attached the test job definition , test summary details & >>> qemu device configuration file along with device template for qemu arm64 >>> architecture. PFA. >>> >>> Regards, >>> Dhanunjaya. P >>> >>> >>> On Tue, Nov 26, 2019 at 5:19 PM dhanu msys <dhanuskd.palnati(a)gmail.com> >>> wrote: >>> >>>> Hi Remi, >>>> >>>> Here I have attached the Host Information. >>>> >>>> root@Dhanu:~# uname -a >>>> Linux Dhanu 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) >>>> x86_64 GNU/Linux >>>> >>>> root@Dhanu:~# lsb_release -a >>>> No LSB modules are available. >>>> Distributor ID: Debian >>>> Description: Debian GNU/Linux 10 (buster) >>>> Release: 10 >>>> Codename: buster >>>> >>>> root@Dhanu:~# df -h >>>> Filesystem Size Used Avail Use% Mounted on >>>> udev 1.9G 0 1.9G 0% /dev >>>> tmpfs 383M 18M 365M 5% /run >>>> /dev/sda1 289G 23G 252G 9% / >>>> tmpfs 1.9G 375M 1.6G 20% /dev/shm >>>> tmpfs 5.0M 4.0K 5.0M 1% /run/lock >>>> tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup >>>> tmpfs 383M 5.7M 377M 2% /run/user/1000 >>>> >>>> And also I have attached the CPU Info & MemInfo related information for >>>> your reference. >>>> >>>> Regards, >>>> Dhanunjaya. P >>>> >>>> >>>> On Tue, Nov 26, 2019 at 3:17 PM Remi Duraffort < >>>> remi.duraffort(a)linaro.org> wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>>> https://staging.validation.linaro.org/scheduler/device/staging-qemu03 >>>>>> >>>>>> >>>>>> This should work, unless your system is way too old. what host are >>>>> you using? >>>>> >>>>> >>>>> Rgds >>>>> >>>>> -- >>>>> Rémi Duraffort >>>>> LAVA Architect >>>>> Linaro >>>>> >>>> -- Rémi Duraffort LAVA Architect Linaro

5 years, 5 months

2
4
0 0

Lava dispatcher compatible question.

by David

Hello, all, Recently I heard from somebody said, lava will drop stretch support from 2020.01 release, I didn't find related information, is it true? I also want to know if I remain on stretch, but still use 2019.12 release just for slave, but maybe later just upgrade master to for example 2020.06 release on buster. Will 2019.12 slave on stretch be compatible with 2020.06(Just a example version) master on buster? Will you promise it? Best Regards, David

5 years, 5 months

2
2
0 0

Lava dispatcher compatible question.

by David

Hello, all, Recently I heard from somebody said, lava will drop stretch support from 2020.01 release, I didn't find related information, is it true? I also want to know if I remain on stretch, but still use 2019.12 release just for slave, but maybe later just upgrade master to for example 2020.06 release on buster. Will 2019.12 slave on stretch be compatible with 2020.06(Just a example version) master on buster? Will you promise it? Best Regards, David

5 years, 5 months

1
0
0 0

lavacli cannot fetch big logs.

by Larry Shen

Hi, there, We have one job to do some stress test, the final log is about 270MB. We use `lavacli -i production jobs logs --raw 30686` to fetch the log, it gives me next: ``` $ time lavacli -i production jobs logs --raw 30686 /usr/lib/python3/dist-packages/lavacli/__init__.py:101: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details. config = yaml.load(f_conf.read()) Unable to call 'jobs.logs': <ProtocolError for http://larry.shen:xxx@xxx.nxp.com/RPC2: 500 ('Connection broken: IncompleteRead(0 bytes read)', IncompleteRead(0 bytes read))> real 0m39.006s user 0m0.989s sys 0m0.191s ``` I check the gunicorn log, it give me: [2020-01-08 08:11:12 +0000] [188] [CRITICAL] WORKER TIMEOUT (pid:11506) Any suggestion?

5 years, 5 months

3
8
0 0

docker dispatcher qemu mount problem since 2019.11

by Dan Rue

I tried updating my lava-docker-compose repo to the latest but hit a problem mounting the overlay filesystem in qemu as of 2019.11 (2019.10 and earlier works, 2019.11 and later do not). To reproduce, clone https://github.com/danrue/lava-docker-compose/ and run "make"; observe the qemu health-check time out. The health check job can be found at https://github.com/danrue/lava-docker-compose/blob/master/server-overlay/et… The problem seems to occur when it tries to mount the overlay filesystem for the test job. I see in the release notes that the containers moved to buster in 2019.11 - related? Raw output below. Thanks, Dan / # mkdir /lava-2 mkdir /lava-2 mount /dev/disk/by-uuid/16786250-75bd-4703-9d57-7cfa618c725e -t ext2 /lava-2 / # mount /dev/disk/by-uuid/16786250-75bd-4703-9d57-7cfa618c725e -t ext2 /lava-2 mount /dev/disk/by-uuid/16786250-75bd-4703-9d57-7cfa618c725e -t ext2 /lava-2 mount: mounting /dev/disk/by-uuid/16786250-75bd-4703-9d57-7cfa618c725e on /lava-2 failed: No such file or directory ls -la /lava-2/bin/lava-test-runner / # ls -la /lava-2/bin/lava-test-runner ls -la /lava-2/bin/lava-test-runner ls: /lava-2/bin/lava-test-runner: No such file or directory Using /lava-2 export SHELL=/bin/sh / # export SHELL=/bin/sh export SHELL=/bin/sh . /lava-2/environment / # . /lava-2/environment . /lava-2/environment /bin/sh: .: can't open '/lava-2/environment' /lava-2/bin/lava-test-runner /lava-2/0 / # /lava-2/bin/lava-test-runner /lava-2/0 Test shell timeout: 10s (minimum of the action and connection timeout) /lava-2/bin/lava-test-runner /lava-2/0 /bin/sh: /lava-2/bin/lava-test-runner: not found

5 years, 5 months

3
2
0 0

Implement new deployment method

by Ilya Fedusiv

Hi! I'm trying to implement new method to lava. As a reference I took fastboot. Now I can job with my new implemented method. I want to work with lxc container as with fastboot. But same job as for fastboot with lxc, doesn't create lxc container and miss step with image validation. Only start methods which are described in /lava_dispatcher/actions/deploy/qdl.py What I miss? Kind regards, Ilya

5 years, 5 months

2
1
0 0

Job Failure-Infrastructure error for qemu arm64

by dhanu msys

Hi Team, I have tried to run the QEMU related jobs for arm64 with the below configurations , throwing an error. Can you please let me know the what was the Infrastructure missing on this job. Thanks & Regards, Dhanunjaya. P

5 years, 6 months

2
6
0 0

ACME Cape support in LAVA

by Milosz Wasilewski

Hi, I'm trying to change the way LAVA searches for and passes USB devices to LXC containers. Current code depends on arbitrary variables present in the static_info dictionary that is part of the device dictionary. This seems to be a problem for some users [1]. So the proposal was made to get rid of the arbitrary variables entirely and use udev variables (starting with ID_). The change was pretty simple to implement but when I started changing the docs I realized there were other classes of devices supported with static_info. Docs list ACME Cape that can be connected over LAN [2]. I'm not aware of any users of this code but I don't want to break the feature if there is anyone using it. So if you're users of LAVA who connect ACME Cape using static_info please reply to this thread. If I don't hear any replies I will remove this support. [1] https://git.lavasoftware.org/lava/lava/issues/335 [2] https://github.com/ARM-software/lisa/wiki/Energy-Meters-Requirements#user-c… Best Regards, milosz

5 years, 6 months

2
2
0 0

Re: [Lava-users] Deploy RTOS Based Application Image

by Remi Duraffort

What kind of command do you run to flash over usb? Le jeu. 28 nov. 2019 à 13:26, dhanu msys <dhanuskd.palnati(a)gmail.com> a écrit : > Hi Remi, > > We were flashing through USB otg cable. > > USB deploy method supported by lava right? > > Regards, > Dhanunjaya > > On Thu, Nov 28, 2019, 17:52 Remi Duraffort <remi.duraffort(a)linaro.org> > wrote: > >> Hello, >> >> you should give more information if you want to have a proper answer. >> >> How do you flash the board? is it fully automatic? >> Is this method already supported by LAVA? >> >> >> Rgds >> >> Le jeu. 28 nov. 2019 à 07:48, dhanu msys <dhanuskd.palnati(a)gmail.com> a >> écrit : >> >>> Hi Team, >>> >>> How can i deploy RTOS based Application Image on target. >>> >>> Notes : >>> Target HW : STM32F429I-DISC1. >>> RTOS : Open source RTOS >>> Application Image (RTOS + Application specific code). >>> >>> We are able to flash the Developed Application Firmware (.out/.bin) >>> through IAR IDE via USB, so we are in plan to make use of LAVA and run test >>> applications automatically. >>> >>> So , Can you please provide some references to deploy this test >>> scenarios in LAVA. >>> >>> Thanks & Regards, >>> Dhanunjaya. P >>> _______________________________________________ >>> Lava-users mailing list >>> Lava-users(a)lists.lavasoftware.org >>> https://lists.lavasoftware.org/mailman/listinfo/lava-users >> >> >> >> -- >> Rémi Duraffort >> LAVA Architect >> Linaro >> > -- Rémi Duraffort LAVA Architect Linaro

5 years, 6 months

3
6
0 0

RFC: when to drop stretch support?

by Remi Duraffort

Hello everyone, Summary: We would like to drop the support for stretch in the (near) future. Details: Currently lava-server and lava-dispatcher are supported on both debian stretch and debian buster. Since LAVA 2019.11, the lava-server and lava-dispatcher docker images are based on debian buster and not stretch. Unittest are still running on stretch, buster and bullseye but integration tests (lavafed and meta-lava mainly) are using the docker container so they run only on buster. Dropping the support for stretch will: * simplify testing * allow to use more recent version of python and django * remove some issues with old dependencies in stretch But before dropping the support we need to ensure that users/admins had some time to migrate to buster or to docker-based installations. In an ideal world, I would drop the support for stretch on the 1st of January 2020. But please answer to this mail so we can device of the right date all together. Thanks -- Rémi Duraffort LAVA Architect Linaro

5 years, 6 months

3
8
0 0

Value for connections lava-test-shell timeouts.

by Larry Shen

Hi, there, We can set lava-test-shell timeouts in test job like next: timeouts: connections: lava-test-shell: minutes: 1 My question is: what's the suitable value for this? Any performance consideration for this value, or in one word, what if I set it as small as possible?

5 years, 6 months

1
0
0 0

Interactive test action unreliable behavior

by Philippe Mazet

Hi All, I am experimenting with the interactive test action, but cannot get it to work reliably. I tried to replicate what is documented here: https://docs.lavasoftware.org/lava/interactive.html#writing-tests-interacti… I also took as example a job mentioned previously on this mailing list: https://validation.linaro.org/scheduler/job/1925569/definition But If I come down to the simplest uboot test job (yaml + log attached), I still see false verdicts. I first set 2 variables in uboot. Then I print them, and verify if the output contains the expected string. Only the first case behaves as expected: "fail-expected-1". All following tests go wrong: Test case "fail-expected-2" fails, but for a wrong reason: "Matched a prompt (was expecting a success): '=> '" And remaining test cases also show a wrong verdict because of this. Including the last 2 TCs which are supposed to pass, but are marked as failed. I also tested in Linux and on a different platform, and the behavior is the same. Am I missing something with the syntax? Or with serial console settings? Thanks a lot for your help, Philippe Mazet

5 years, 6 months

2
3
0 0

lxc creation fails with multiple containers

by Diego Russo

Hello, Sometimes LAVA slaves end up in a funky state where all jobs will be failing for the lxc-creation. This is an just a section of the pstree but actually the machine is not doing anything. No CPU/IO/memory usage at all. |-lxc-ubuntu,26488 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216 --name=mbl-rpi3-healthcheck-lxc-86216 --rootfs=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216/rootfs --release xenial ... | `-lxc-ubuntu,26495 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216 --name=mbl-rpi3-healthcheck-lxc-86216 --rootfs=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216/rootfs --release xenial ... | `-flock,26496 -x 9 |-lxc-ubuntu,29367 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/cellular-wifi-lxc-85573 --name=cellular-wifi-lxc-85573 --rootfs=/var/lib/lxc/cellular-wifi-lxc-85573/rootfs --release xenial --packages ... | `-lxc-ubuntu,29374 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/cellular-wifi-lxc-85573 --name=cellular-wifi-lxc-85573 --rootfs=/var/lib/lxc/cellular-wifi-lxc-85573/rootfs --release xenial --packages ... | `-rsync,29590 -Ha /var/cache/lxc/xenial/rootfs-amd64/ /var/lib/lxc/cellular-wifi-lxc-85573/rootfs/ | `-rsync,29593 -Ha /var/cache/lxc/xenial/rootfs-amd64/ /var/lib/lxc/cellular-wifi-lxc-85573/rootfs/ | `-rsync,29594 -Ha /var/cache/lxc/xenial/rootfs-amd64/ /var/lib/lxc/cellular-wifi-lxc-85573/rootfs/ |-lxc-ubuntu,30173 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-pelion-lxc-85584 --name=multi_component-image-update-pelion-lxc-85584... | `-lxc-ubuntu,30186 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-pelion-lxc-85584 --name=multi_component-image-update-pelion-lxc-85584... | `-flock,30187 -x 9 |-lxc-ubuntu,30226 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/helloworld-update-lxc-85537 --name=helloworld-update-lxc-85537 --rootfs=/var/lib/lxc/helloworld-update-lxc-85537/rootfs --release xenial --packages ... | `-lxc-ubuntu,30233 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/helloworld-update-lxc-85537 --name=helloworld-update-lxc-85537 --rootfs=/var/lib/lxc/helloworld-update-lxc-85537/rootfs --release xenial --packages ... | `-flock,30234 -x 9 |-lxc-ubuntu,30800 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588 --name=rootfs-image-update-mbl-cli-lxc-85588 --rootfs=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588/rootfs ... | `-lxc-ubuntu,30807 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588 --name=rootfs-image-update-mbl-cli-lxc-85588 --rootfs=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588/rootfs ... | `-flock,30808 -x 9 |-lxc-ubuntu,30837 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540 --name=mbl-cli-basic-commands-lxc-85540 --rootfs=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540/rootfs --release xenial ... | `-lxc-ubuntu,30844 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540 --name=mbl-cli-basic-commands-lxc-85540 --rootfs=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540/rootfs --release xenial ... | `-flock,30845 -x 9 |-lxc-ubuntu,31697 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/wifi-access-lxc-85591 --name=wifi-access-lxc-85591 --rootfs=/var/lib/lxc/wifi-access-lxc-85591/rootfs --release xenial --packages systemd,systemd-sysv | `-lxc-ubuntu,31704 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/wifi-access-lxc-85591 --name=wifi-access-lxc-85591 --rootfs=/var/lib/lxc/wifi-access-lxc-85591/rootfs --release xenial --packages systemd,systemd-sysv | `-flock,31705 -x 9 |-lxc-ubuntu,31800 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-mbl-cli-lxc-85542 --name=multi_component-image-update-mbl-cli-lxc-85542... | `-lxc-ubuntu,31807 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-mbl-cli-lxc-85542 --name=multi_component-image-update-mbl-cli-lxc-85542... | `-flock,31808 -x 9 I have tens and tens of this processes. LAVA jobs have failed but lxc processes are still there. It seems to be some sort of deadlock in the lxc world. I'm on Debian stretch 9.8. It recently started with no apparent reason. Regards -- 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/docs/mbed-linux-os/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 6 months

3
2
0 0

Deploy RTOS Based Application Image

by dhanu msys

Hi Team, How can i deploy RTOS based Application Image on target. Notes : Target HW : STM32F429I-DISC1. RTOS : Open source RTOS Application Image (RTOS + Application specific code). We are able to flash the Developed Application Firmware (.out/.bin) through IAR IDE via USB, so we are in plan to make use of LAVA and run test applications automatically. So , Can you please provide some references to deploy this test scenarios in LAVA. Thanks & Regards, Dhanunjaya. P

5 years, 6 months

2
1
0 0

Re: [Lava-users] None of the deployment strategies accepted your deployment parameters

by dhanu msys

Hi Milosz, Thanks for providing the document references. I will try my level best. Thanks & Regards, Dhanunjaya On Tue, Nov 12, 2019, 20:36 Milosz Wasilewski <milosz.wasilewski(a)linaro.org> wrote: > I'll defer you to the docs: > - boot commands: > https://master.lavasoftware.org/static/docs/v2/actions-boot.html#index-9 > - device type: > > https://master.lavasoftware.org/static/docs/v2/devicetypes.html#device-types > - u-boot bootloader: > https://master.lavasoftware.org/static/docs/v2/actions-boot.html#index-35 > > I didn't test tftp booting with this board, so I can't help. It should > work as this is supported in device type: > > https://git.lavasoftware.org/lava/lava/blob/master/etc/dispatcher-config/de… > > Good luck. > > milosz > > On Tue, 12 Nov 2019 at 13:59, dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > > > > Hi Milosz, > > > > I was running tftp on my localhost & kept those uImage & dtb files in > the "tftpboot" repository. PFA. > > > > > > Thanks & Regards, > > Dhanunjaya. P > > > > > > On Tue, Nov 12, 2019 at 7:23 PM dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > >> > >> Hi Milosz, > >> > >> Yes , I have booted my board manually using the tftp , here i have > attached those uImage & dtb images. PFA. > >> Once the device bootsup , through command prompt , i will set the > following commands. > >> > >> setenv ipaddr 192.168.1.201 > >> setenv gatewayip 192.168.1.200 > >> setenv serverip 192.168.1.200 > >> setenv netmask 255.255.255.0 > >> tftpboot 0xc2000000 uImage > >> tftpboot 0xc4000000 stm32mp157c-ev1.dtb > >> setenv bootargs 'root=/dev/mmcblk0p6 rootwait rw > console=ttySTM0,115200'bootm 0xc2000000 - 0xc4000000 > >> > >> Its basically ARM architecture based and bootloader "u-boot". > >> > >> Can you please suggest how i can deploy the tftp files through LAVA > test job ,what will be the url i need pass in the job definition ? > >> > >> Thanks & Regards, > >> Dhanunjaya. P > >> > >> > >> On Tue, Nov 12, 2019 at 7:07 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >>> > >>> Hmm, > >>> Do you know how tftp boot works? Loading 100M tarball into memory > >>> doesn't seem like a good idea. Which bootloader is running on your > >>> board? > >>> > >>> milosz > >>> > >>> On Tue, 12 Nov 2019 at 13:32, dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > >>> > > >>> > Hi Milosz, > >>> > > >>> > As per earlier email , I am trying to boot the STM32mp157c-dk2 with > the tftp deploy method , but getting failed to have proper device > configuration. > >>> > > >>> > Here I have attached the device configuration , device template & > Job definition files. PFA. > >>> > > >>> > Please let me know how to get resolve the issue. > >>> > > >>> > Regards, > >>> > Dhanunjaya. P > >>> > > >>> > > >>> > On Tue, Nov 12, 2019 at 2:45 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >>> >> > >>> >> On Tue, 12 Nov 2019 at 08:14, dhanu msys < > dhanuskd.palnati(a)gmail.com> wrote: > >>> >> > > >>> >> > Hi Milosz, > >>> >> > > >>> >> > Currently eth008 was unavailable, Is there any possibility to > make use of Raspberry pi 4 as PDU to run power control commands on > STM32mp157c-dk2 ? > >>> >> > >>> >> Sure. Anything that can drive a relay will work. You will need to > >>> >> create a script that LAVA can call. Eth008 is a good choice for a > >>> >> bigger LAB where you need a lot of relays (these boards have > >>> >> configurable MAC addresses). If you need just one, than pick any > relay > >>> >> you can get on ebay and that will do the trick. > >>> >> > >>> >> milosz > >>> >> > >>> >> > > >>> >> > Thanks in advance. > >>> >> > > >>> >> > Regards, > >>> >> > Dhanunjaya. P > >>> >> > > >>> >> > > >>> >> > On Mon, Nov 11, 2019 at 5:36 PM dhanu msys < > dhanuskd.palnati(a)gmail.com> wrote: > >>> >> >> > >>> >> >> Hi Milosz, > >>> >> >> > >>> >> >> Thanks for the reply. > >>> >> >> > >>> >> >> I will try to get the eth008 if possible , otherwise i will try > to make use of TFTP or u-boot methods to run the test job on > STM32mp157c-dk2. > >>> >> >> > >>> >> >> Thanks & Regards, > >>> >> >> Dhanunjaya. P > >>> >> >> > >>> >> >> > >>> >> >> On Mon, Nov 11, 2019 at 4:57 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >>> >> >>> > >>> >> >>> On Mon, 11 Nov 2019 at 11:07, dhanu msys < > dhanuskd.palnati(a)gmail.com> wrote: > >>> >> >>> > > >>> >> >>> > Hi Milosz, > >>> >> >>> > > >>> >> >>> > Really Thanks for sharing the Information. > >>> >> >>> > > >>> >> >>> > I have basic question, we can't able to run any test job for > the STM32 without external hardware(PDU) ? > >>> >> >>> > > >>> >> >>> > Can you please share the device configuration , which helps > to run the test jobs without "ethernet controlled relay" for the STM32. > >>> >> >>> > >>> >> >>> > https://git.linaro.org/lava/lava-lab.git/tree/shared/lab-scripts/eth008_con… > >>> >> >>> > >>> >> >>> > > >>> >> >>> > As I requested earlier , is there any possibility to run the > STM32 specific jobs with any other deployment methods(tmpfs , tftp..etc). > >>> >> >>> > >>> >> >>> Our boards use EFI for booting and I never tried tftp with > that. You > >>> >> >>> might need grub EFI application for that. Alternatively you > might use > >>> >> >>> u-boot. I didn't try that either. > >>> >> >>> > >>> >> >>> milosz > >>> >> >>> > >>> >> >>> > > >>> >> >>> > Thanks & Regards, > >>> >> >>> > Dhanunjaya. P > >>> >> >>> > > >>> >> >>> > > >>> >> >>> > On Mon, Nov 11, 2019 at 4:19 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >>> >> >>> >> > >>> >> >>> >> Well, LAVA will try to switch the device into DFU mode for > deployment > >>> >> >>> >> step. These lines in the device dict do it: > >>> >> >>> >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 1 > -s on', > >>> >> >>> >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 2 > -s on', > >>> >> >>> >> Then it will power on the board: > >>> >> >>> >> '/usr/local/lab-scripts/snmp_pdu_control --hostname lngpdu01 > --command > >>> >> >>> >> on --port 3 --delay 20', > >>> >> >>> >> After that it will try to flash it using the > STM32_Programmer_CLI: > >>> >> >>> >> '/usr/local/bin/STM32_Programmer_CLI -c port=usb1 -w > {LAYOUT} -q', > >>> >> >>> >> Lastly it will power the board down and flip the dip > switches back: > >>> >> >>> >> '/usr/local/lab-scripts/snmp_pdu_control --hostname lngpdu01 > --command > >>> >> >>> >> off --port 3', > >>> >> >>> >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 1 > -s off', > >>> >> >>> >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 2 > -s off', > >>> >> >>> >> > >>> >> >>> >> So if you don't have HW moded board, this device dict won't > work for > >>> >> >>> >> you. Sources for the scripts are here: > >>> >> >>> >> > https://git.linaro.org/lava/lava-lab.git/tree/shared/lab-scripts > >>> >> >>> >> We're using pretty expensive HW in the LAB: > >>> >> >>> >> - managed APC PDUs: > >>> >> >>> >> > https://www.apc.com/shop/uk/en/products/Rack-PDU-Switched-1U-16A-208-230V-8… > >>> >> >>> >> (I couldn't find the exact models we have, they're > discontinued) > >>> >> >>> >> - ETH008 relay board: > https://www.robot-electronics.co.uk/htm/eth008tech.htm > >>> >> >>> >> > >>> >> >>> >> milosz > >>> >> >>> >> > >>> >> >>> >> On Mon, 11 Nov 2019 at 10:42, dhanu msys < > dhanuskd.palnati(a)gmail.com> wrote: > >>> >> >>> >> > > >>> >> >>> >> > Hi Milosz, > >>> >> >>> >> > > >>> >> >>> >> > No. > >>> >> >>> >> > Through Manual Setup , we are able to switch between the > modes. > >>> >> >>> >> > > >>> >> >>> >> > Here I have attached the kernel & dtb image for your > reference. PFA. > >>> >> >>> >> > > >>> >> >>> >> > Dhanunjaya. P > >>> >> >>> >> > > >>> >> >>> >> > > >>> >> >>> >> > On Mon, Nov 11, 2019 at 3:40 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >>> >> >>> >> >> > >>> >> >>> >> >> I think I forgot to ask key question when it comes to > this device: did > >>> >> >>> >> >> you do the HW mod to be able to switch between DFU and OS > boot modes > >>> >> >>> >> >> without manual step? > >>> >> >>> >> >> > >>> >> >>> >> >> milosz > >>> >> >>> >> >> > >>> >> >>> >> >> On Mon, 11 Nov 2019 at 10:01, dhanu msys < > dhanuskd.palnati(a)gmail.com> wrote: > >>> >> >>> >> >> > > >>> >> >>> >> >> > Hi Milosz, > >>> >> >>> >> >> > > >>> >> >>> >> >> > Thanks for reply. > >>> >> >>> >> >> > > >>> >> >>> >> >> > I am new to the LAVA usage. > >>> >> >>> >> >> > > >>> >> >>> >> >> > I have taken reference from the below link. > >>> >> >>> >> >> > > https://staging.validation.linaro.org/scheduler/device/staging-stm32mp157-0… > >>> >> >>> >> >> > > >>> >> >>> >> >> > Here I have attached the device_dictionary & device > configurations files, PFA. > >>> >> >>> >> >> > > >>> >> >>> >> >> > Note : I am not able to see the "lab-scripts" to have > power controlled commands in my local repository , is there any specific > package need to install in my localhost , can you please share the > lab-scripts to have pdu control and also please share the pdu device > details if required to connect with the hardware. > >>> >> >>> >> >> > > >>> >> >>> >> >> > Can you please share some references , which i can run > some jobs through any other deploy methods like "tmpfs , tftp " for > "STM32MP157C-DK2". > >>> >> >>> >> >> > > >>> >> >>> >> >> > Thanks & Regards, > >>> >> >>> >> >> > Dhanunjaya. P > >>> >> >>> >> >> > > >>> >> >>> >> >> > > >>> >> >>> >> >> > On Mon, Nov 11, 2019 at 2:59 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >>> >> >>> >> >> >> > >>> >> >>> >> >> >> Could you share your device dictionary? You might be > missing > >>> >> >>> >> >> >> flasher_deploy_commands. > >>> >> >>> >> >> >> > >>> >> >>> >> >> >> Please check here for reference: > >>> >> >>> >> >> >> > https://ledge.validation.linaro.org/scheduler/device/lng-stm32mp157-01/devi… > >>> >> >>> >> >> >> > >>> >> >>> >> >> >> milosz > >>> >> >>> >> >> >> > >>> >> >>> >> >> >> On Thu, 7 Nov 2019 at 07:48, dhanu msys < > dhanuskd.palnati(a)gmail.com> wrote: > >>> >> >>> >> >> >> > > >>> >> >>> >> >> >> > Hi Team, > >>> >> >>> >> >> >> > > >>> >> >>> >> >> >> > I am trying to run the test_jobs on the specific > device type "stm32mp1157c-dk2" , but its throwing an error message to > deploy "flasher" method in the deployment parameters. > >>> >> >>> >> >> >> > > >>> >> >>> >> >> >> > Here I have attached the screenshots for reference. > PFA. > >>> >> >>> >> >> >> > > >>> >> >>> >> >> >> > Thanks & Regards, > >>> >> >>> >> >> >> > Dhanunjaya. P > >>> >> >>> >> >> >> > _______________________________________________ > >>> >> >>> >> >> >> > Lava-users mailing list > >>> >> >>> >> >> >> > Lava-users(a)lists.lavasoftware.org > >>> >> >>> >> >> >> > > https://lists.lavasoftware.org/mailman/listinfo/lava-users >

5 years, 7 months

2
7
0 0

Re: [Lava-users] lxc creation fails with multiple containers

by Diego Russo

An update: as soon as I kll the rsync processes, all the lxc and flock processes get terminated. Before the killing I did try to create a lxc container from the command line but it was stuck. It continued after killing the rsync processes. How can I avoid this situation? 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, 26 November 2019 at 11:17 To: "lava-users(a)lists.lavasoftware.org" <lava-users(a)lists.lavasoftware.org> Subject: [Lava-users] lxc creation fails with multiple containers Hello, Sometimes LAVA slaves end up in a funky state where all jobs will be failing for the lxc-creation. This is an just a section of the pstree but actually the machine is not doing anything. No CPU/IO/memory usage at all. |-lxc-ubuntu,26488 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216 --name=mbl-rpi3-healthcheck-lxc-86216 --rootfs=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216/rootfs --release xenial ... | `-lxc-ubuntu,26495 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216 --name=mbl-rpi3-healthcheck-lxc-86216 --rootfs=/var/lib/lxc/mbl-rpi3-healthcheck-lxc-86216/rootfs --release xenial ... | `-flock,26496 -x 9 |-lxc-ubuntu,29367 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/cellular-wifi-lxc-85573 --name=cellular-wifi-lxc-85573 --rootfs=/var/lib/lxc/cellular-wifi-lxc-85573/rootfs --release xenial --packages ... | `-lxc-ubuntu,29374 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/cellular-wifi-lxc-85573 --name=cellular-wifi-lxc-85573 --rootfs=/var/lib/lxc/cellular-wifi-lxc-85573/rootfs --release xenial --packages ... | `-rsync,29590 -Ha /var/cache/lxc/xenial/rootfs-amd64/ /var/lib/lxc/cellular-wifi-lxc-85573/rootfs/ | `-rsync,29593 -Ha /var/cache/lxc/xenial/rootfs-amd64/ /var/lib/lxc/cellular-wifi-lxc-85573/rootfs/ | `-rsync,29594 -Ha /var/cache/lxc/xenial/rootfs-amd64/ /var/lib/lxc/cellular-wifi-lxc-85573/rootfs/ |-lxc-ubuntu,30173 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-pelion-lxc-85584 --name=multi_component-image-update-pelion-lxc-85584... | `-lxc-ubuntu,30186 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-pelion-lxc-85584 --name=multi_component-image-update-pelion-lxc-85584... | `-flock,30187 -x 9 |-lxc-ubuntu,30226 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/helloworld-update-lxc-85537 --name=helloworld-update-lxc-85537 --rootfs=/var/lib/lxc/helloworld-update-lxc-85537/rootfs --release xenial --packages ... | `-lxc-ubuntu,30233 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/helloworld-update-lxc-85537 --name=helloworld-update-lxc-85537 --rootfs=/var/lib/lxc/helloworld-update-lxc-85537/rootfs --release xenial --packages ... | `-flock,30234 -x 9 |-lxc-ubuntu,30800 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588 --name=rootfs-image-update-mbl-cli-lxc-85588 --rootfs=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588/rootfs ... | `-lxc-ubuntu,30807 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588 --name=rootfs-image-update-mbl-cli-lxc-85588 --rootfs=/var/lib/lxc/rootfs-image-update-mbl-cli-lxc-85588/rootfs ... | `-flock,30808 -x 9 |-lxc-ubuntu,30837 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540 --name=mbl-cli-basic-commands-lxc-85540 --rootfs=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540/rootfs --release xenial ... | `-lxc-ubuntu,30844 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540 --name=mbl-cli-basic-commands-lxc-85540 --rootfs=/var/lib/lxc/mbl-cli-basic-commands-lxc-85540/rootfs --release xenial ... | `-flock,30845 -x 9 |-lxc-ubuntu,31697 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/wifi-access-lxc-85591 --name=wifi-access-lxc-85591 --rootfs=/var/lib/lxc/wifi-access-lxc-85591/rootfs --release xenial --packages systemd,systemd-sysv | `-lxc-ubuntu,31704 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/wifi-access-lxc-85591 --name=wifi-access-lxc-85591 --rootfs=/var/lib/lxc/wifi-access-lxc-85591/rootfs --release xenial --packages systemd,systemd-sysv | `-flock,31705 -x 9 |-lxc-ubuntu,31800 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-mbl-cli-lxc-85542 --name=multi_component-image-update-mbl-cli-lxc-85542... | `-lxc-ubuntu,31807 /usr/share/lxc/templates/lxc-ubuntu --path=/var/lib/lxc/multi_component-image-update-mbl-cli-lxc-85542 --name=multi_component-image-update-mbl-cli-lxc-85542... | `-flock,31808 -x 9 I have tens and tens of this processes. LAVA jobs have failed but lxc processes are still there. It seems to be some sort of deadlock in the lxc world. I'm on Debian stretch 9.8. It recently started with no apparent reason. Regards -- 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/docs/mbed-linux-os/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Lava-users mailing list Lava-users(a)lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 7 months

1
0
0 0

LAVA master

by 宿川

Hi all, We upgraded our LAVA master to 2019.11 (2019.11 + stretch) version , but when queried devices owned by current user , it listed all devices hooked to this master, can anybody help check it? Regards, Su Chuan

5 years, 7 months

2
3
0 0

LXC connection LTP Issue

by Ilya Fedusiv

Hi! Have some issues with recognition of ltp test end point. After receiving message of the ltp's execution finish, job is still running and waiting with line : Listened to connection for namespace 'tlxc' done until get timeout. Also sometimes job runs good without that stuck. All scripts to run ltp were taken from lava's repo, without any changes. Just edit skipfile Here is end of log with stuck ltp https://pastebin.com/1qJAbxTJ Here is end of log with successful ltp recognition. https://pastebin.com/BnFyq5dU Here is test part of the job. https://pastebin.com/m6vAWkZ9 Ilya

5 years, 7 months

3
9
0 0

LAVA Lab System Specifications

by dhanu msys

Hi Team, Now I have experienced by running some of test jobs on LAVA Setup , really lava-mailing-lists helps a lot to solve problems & providing suggestions at earliest. Now We are planning to have LAVA Lab Setup with minimum 30 to 40 devices connected to the PDU to run automation test jobs. So , at initial we wants to know the LAVA Server Specifications more in detail , like RAM etc.. to setup the LAVA Lab. Regards, Dhanunjaya. P

5 years, 7 months

2
2
0 0

LAVA Web Interface access in intranet

by dhanu msys

Hi Team, I am able to access the web interface(WEB GUI) through localhost. Is there any specific configuration required to access the web ui within the intranet. Here I have shared the server.conf & instance.conf ( /etc/lava-server/ )files, please let me know the configuration changes if required? Dhanunjaya. P

5 years, 7 months

2
4
0 0

Re: [Lava-users] [Automated-testing] ELC followup / Search for a testing framework for small distribution tests on device

by Milosz Wasilewski

On Tue, 12 Nov 2019 at 16:49, Westermann, Oliver <Oliver.Westermann(a)cognex.com> wrote: > > Hey everyone, > > I recently joined the ELC in Lyon and had a good chat with a few who may read this list. Only during the ELC I leaned about the automated testing summit and if I had not planned the next days already, I would probably have joined. During the interesting talks and some networking I also learned about this list, so I now have to ask a bunch of questions in the hope for answers ;-) > > We (as in the company I work for) moved to linux for our embedded devices quite some time ago, but our testing hasn't. We have a test system for our full product, but due to the nature of the product ("cameras with intelligence"), there is a lot of implied requirements on the state of the device, which makes testing expensive (in terms of device- and setuptime), which results in only one, but very thorough test loop a day. > > We're now trying to check our options to setup a smaller on-device test-stage before this setup. We would like to test features we would consider "distribution features": Network connectivity, IO features, updates and more. Most devs have their small scripts to do one thing or another, but we would prefer to distribute something that allows us to share all this and run it as part of the CI chain. > > So I've looked into some of the pages on the Automated_Testing page of the elinux wiki and dove into a few of the frameworks, but actually I'm even more confused by LAVA, fuego and all the other tools than before. We already have a build system, we already have a CI system controlling build system. So I'm writing to you in an attempt to get a feeling for whats there and where we can contribute, and I will try to list some of our goal and ideas so maybe someone can throw me some good links (and hopefully, we can > > What we would like: > We would like to run simple tests (execute eg python & bash script) and validate the outputs > We would like to bring devices into a certain state, eg by an upgrade (we use sth with swupdate beneath) As LAVA co-maintainer I'm obviously biased but I think this tool can do what you need. LAVA doesn't do any building it expects build artifacts to be available for download. It can deliver software to your device (aka deployment step) and drive your device to run some tests. If you could give some more details about the device (how to deploy software to it, how to connect to console, etc.) I can probably suggest next step with LAVA. milosz > > Since I assume a lot of you have a better overview about whats out there, what sounds like our needs and where you think we could contribute, let me know :-) > > Best regards and thanks to all of those who gave talks at OSS and ELC, it was a very cool (and overwhelming) time :-) > > - Olli > > > -- > _______________________________________________ > automated-testing mailing list > automated-testing(a)yoctoproject.org > https://lists.yoctoproject.org/listinfo/automated-testing

5 years, 7 months

2
1
0 0

Re: [Lava-users] dispatcher_config not parsed

by Remi Duraffort

Hello, I said "lava-master" and not "lava-server". Le mar. 19 nov. 2019 à 11:56, Klaas Schulze-Dieckhoff < K.Schulze-Dieckhoff(a)sonnen.de> a écrit : > Hello Remi, > > > > yes it is visible, the first command-line output I showed in the original > message was from inside the lava-server container. I also played around > with the ownership of the file since it is a problem for devices/* and > health-check/* files (they must be lavaserver:lavaserver). But this didn’t > help… > > > > Thanks > > Klaas > > > > *Von:* Remi Duraffort <remi.duraffort(a)linaro.org> > *Gesendet:* Dienstag, 19. November 2019 11:09 > *An:* Klaas Schulze-Dieckhoff <K.Schulze-Dieckhoff(a)sonnen.de> > *Cc:* lava-users(a)lists.lavasoftware.org > *Betreff:* Re: [Lava-users] dispatcher_config not parsed > > > > Hello, > > > > is the configuration file > (/etc/lava-server/dispatcher.d/<hostname>/dispatcher.yaml) visible from the > master container? > > > > In the docker-compose setup, each service is running in a specific > container so the configuration files should be set carefully. > > > > > > Rgds > > > > Le mar. 19 nov. 2019 à 09:25, Klaas Schulze-Dieckhoff < > K.Schulze-Dieckhoff(a)sonnen.de> a écrit : > > Hi all, > > > > I am running lava using docker-compose. Additional to the official > docker-compose.yaml I added and FTP and NFS container. For testing my setup > I am trying to test a beaglebone black. > > In order to load dtb and kernel uboot needs to know the IP of the FTP / > NFS server. I added the IP in the following two ways: > > > > server: > > root@1a010c2f736b:/# cat > /etc/lava-server/dispatcher.d/lava-dispatcher.yaml > > dispatcher_ip: <server ip addr> > > > > dispatcher: > > root@075e2deb4c34:/# cat /etc/lava-dispatcher/lava-slave > > [....] > > NFS_SERVER_IP="<server-ip-addr> " > > > > The hostname of the dispatcher is `lava-dispatcher`. But, when the > health-check is running it will always run `setenv serverip > <ip-of-docker-container>. > > I also tried various variants of setting the dispatcher configuration > (./dispatcher.d/<hostname>/dispatcher.yaml, > ./dispatcher.d/<hostname>/env.yaml). No matter what I do lava persists to > take the IP of the docker-container. > > > > According to ` server/management/commands/lava-master.py` line 465 at > least one of the variants should word, > > > > I would appreciate some hints how to fix this! > > > > Thanks > Klaas > > > > Geschäftsführer: Christoph Ostermann (CEO), Oliver Koch, Steffen > Schneider, Hermann Schweizer, Tim Ulbricht. > Amtsgericht Kempten/Allgäu, Registernummer: 10655, Steuernummer > 127/137/50792, USt.-IdNr. DE272208908 > > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.lavasoftware.org > https://lists.lavasoftware.org/mailman/listinfo/lava-users > > > > > -- > > Rémi Duraffort > > LAVA Architect > > Linaro > > Geschäftsführer: Christoph Ostermann (CEO), Oliver Koch, Steffen > Schneider, Hermann Schweizer, Tim Ulbricht. > Amtsgericht Kempten/Allgäu, Registernummer: 10655, Steuernummer > 127/137/50792, USt.-IdNr. DE272208908 > -- Rémi Duraffort LAVA Architect Linaro

5 years, 7 months

1
0
0 0

dispatcher_config not parsed

by Klaas Schulze-Dieckhoff

Hi all, I am running lava using docker-compose. Additional to the official docker-compose.yaml I added and FTP and NFS container. For testing my setup I am trying to test a beaglebone black. In order to load dtb and kernel uboot needs to know the IP of the FTP / NFS server. I added the IP in the following two ways: server: root@1a010c2f736b:/# cat /etc/lava-server/dispatcher.d/lava-dispatcher.yaml dispatcher_ip: <server ip addr> dispatcher: root@075e2deb4c34:/# cat /etc/lava-dispatcher/lava-slave [....] NFS_SERVER_IP="<server-ip-addr> " The hostname of the dispatcher is `lava-dispatcher`. But, when the health-check is running it will always run `setenv serverip <ip-of-docker-container>. I also tried various variants of setting the dispatcher configuration (./dispatcher.d/<hostname>/dispatcher.yaml, ./dispatcher.d/<hostname>/env.yaml). No matter what I do lava persists to take the IP of the docker-container. According to ` server/management/commands/lava-master.py` line 465 at least one of the variants should word, I would appreciate some hints how to fix this! Thanks Klaas Gesch?ftsf?hrer: Christoph Ostermann (CEO), Oliver Koch, Steffen Schneider, Hermann Schweizer, Tim Ulbricht. Amtsgericht Kempten/Allg?u, Registernummer: 10655, Steuernummer 127/137/50792, USt.-IdNr. DE272208908

5 years, 7 months

2
1
0 0

docker-compose: libguestfs failing

by Klaas Schulze-Dieckhoff

Hi all, I am trying to run a lava-lab with the official docker-compose.yml. When running a health-check on a qemu-device it fails because libguestfs can't find a kernel inside /boot. (There is already a discussion running on the libguestfs-mailing list). But I think the underlying problem is, that there is really no kernel inside /boot of my lava-dispatcher container: #:~/linaro_lava/docker-compose$ docker-compose exec lava-dispatcher bash root@8b5507bd355a:/# ls -al /boot total 4124 drwxr-xr-x 6 root root 129 Oct 1 10:35 . drwxr-xr-x 57 root root 4096 Nov 5 06:04 .. drwxr-xr-x 2 root root 3 Oct 1 10:34 androidboot drwxr-xr-x 2 root root 3 Apr 25 2018 efi drwxr-xr-x 2 root root 3 Oct 1 10:34 grub lrwxrwxrwx 1 root root 28 Oct 1 10:34 initrd.img-core -> initrd.img-core-0.7.43+ppa27 -rw-r--r-- 1 root root 4218483 Oct 1 10:34 initrd.img-core-0.7.43+ppa27 drwxr-xr-x 2 root root 3 Oct 1 10:34 uboot Since /boot is mounted into the docker-container inside docker-compose.yml I would expect it to have the same content the on my host, which is not the case: #:~/linaro_lava/docker-compose$ ls -al /boot total 68300 drwxr-xr-x 4 root root 4096 Oct 30 08:17 . drwxr-xr-x 24 root root 4096 Oct 30 08:14 .. -rw------- 1 root root 4064684 Oct 1 03:02 System.map-4.15.0-66-generic -rw-r--r-- 1 root root 217362 Oct 1 03:02 config-4.15.0-66-generic drwxr-xr-x 3 root root 4096 Jan 1 1970 efi drwxr-xr-x 5 root root 4096 Nov 4 15:26 grub -rw-r--r-- 1 root root 57266820 Oct 30 08:17 initrd.img-4.15.0-66-generic -rw------- 1 root root 8363672 Oct 1 03:05 vmlinuz-4.15.0-66-generic Why can these both directories be different? I would really appreciate if somebody can help me out here! Thanks Klaas Geschäftsführer: Christoph Ostermann (CEO), Oliver Koch, Steffen Schneider, Hermann Schweizer, Tim Ulbricht. Amtsgericht Kempten/Allgäu, Registernummer: 10655, Steuernummer 127/137/50792, USt.-IdNr. DE272208908

5 years, 7 months

2
1
0 0

RPi3 and uboot 2019.10

by Diego Russo

Hello, We are using RPi3 B/B+ in our infrastructure and the latest uboot changed his behaviour in case of error. In our case we have a kernel and DTB but we don’t have the ramdisk. Despite this, LAVA tries the tftp command for the RAMDISK but the 2 versions have different errors. With uboot 2019.07 this is what happens: tftp - {RAMDISK} U-Boot> tftp - {RAMDISK} bootloader-commands: Wait for prompt ['U-Boot>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'Retry time exceeded; starting again', 'ERROR: The remote end did not respond in time.', 'Bad Linux ARM64 Image magic!', 'Wrong Ramdisk Image Format', 'Ramdisk image is corrupt or invalid', 'ERROR: Failed to allocate', 'TFTP error: trying to overwrite reserved memory'] (timeout 00:04:08) tftp - {RAMDISK} lan78xx_eth Waiting for PHY auto negotiation to complete...... done Using lan78xx_eth device TFTP from server 192.168.130.111; our IP address is 192.168.130.138 Filename '{RAMDISK}'. Load address: 0x0 Loading: * TFTP error: 'File not found' (1) Not retrying... Uboot 2019.10 has a different behaviour and throws a different error: tftp - {RAMDISK} U-Boot> tftp - {RAMDISK} bootloader-commands: Wait for prompt ['U-Boot>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'Retry time exceeded; starting again', 'ERROR: The remote end did not respond in time.', 'Bad Linux ARM64 Image magic!', 'Wrong Ramdisk Image Format', 'Ramdisk image is corrupt or invalid', 'ERROR: Failed to allocate', 'TFTP error: trying to overwrite reserved memory'] (timeout 00:04:12) tftp - {RAMDISK} lan78xx_eth Waiting for PHY auto negotiation to complete...... done Using lan78xx_eth device TFTP from server 192.168.130.111; our IP address is 192.168.130.138 Filename '{RAMDISK}'. TFTP error: trying to overwrite reserved memory... matched a bootloader error message: 'TFTP error: trying to overwrite reserved memory' (11) At this point LAVA fails the job because it matches the error message. What's the best way to solve the issue. How can I tell LAVA not to deal with the RAMDISK at all? 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/docs/mbed-linux-os/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 7 months

3
8
0 0

Flasher action and pre power command

by Ilya Fedusiv

Hello! I'm trying to flash via special tool, which is not implemented in lava. I did it successfully by editing device dictionary. Next want to use pre power command. That's why I use lxc. But how trigger protocol to use it? It doesnt work: - deploy: namespace: target timeout: minutes: 20 to: flasher images: flash_dir: url: file:///opt/image.zip os: oe protocols: lava-lxc: - action: flasher-deploy request: pre-power-command Ilya

5 years, 7 months

2
3
0 0

Re: [Lava-users] None of the deployment strategies accepted your deployment parameters

by dhanu msys

Hi Milosz, Thanks for the reply. I will try to get the eth008 if possible , otherwise i will try to make use of TFTP or u-boot methods to run the test job on STM32mp157c-dk2. Thanks & Regards, Dhanunjaya. P On Mon, Nov 11, 2019 at 4:57 PM Milosz Wasilewski < milosz.wasilewski(a)linaro.org> wrote: > On Mon, 11 Nov 2019 at 11:07, dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > > > > Hi Milosz, > > > > Really Thanks for sharing the Information. > > > > I have basic question, we can't able to run any test job for the STM32 > without external hardware(PDU) ? > > > > Can you please share the device configuration , which helps to run the > test jobs without "ethernet controlled relay" for the STM32. > > > https://git.linaro.org/lava/lava-lab.git/tree/shared/lab-scripts/eth008_con… > > > > > As I requested earlier , is there any possibility to run the STM32 > specific jobs with any other deployment methods(tmpfs , tftp..etc). > > Our boards use EFI for booting and I never tried tftp with that. You > might need grub EFI application for that. Alternatively you might use > u-boot. I didn't try that either. > > milosz > > > > > Thanks & Regards, > > Dhanunjaya. P > > > > > > On Mon, Nov 11, 2019 at 4:19 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >> > >> Well, LAVA will try to switch the device into DFU mode for deployment > >> step. These lines in the device dict do it: > >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 1 -s on', > >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 2 -s on', > >> Then it will power on the board: > >> '/usr/local/lab-scripts/snmp_pdu_control --hostname lngpdu01 --command > >> on --port 3 --delay 20', > >> After that it will try to flash it using the STM32_Programmer_CLI: > >> '/usr/local/bin/STM32_Programmer_CLI -c port=usb1 -w {LAYOUT} -q', > >> Lastly it will power the board down and flip the dip switches back: > >> '/usr/local/lab-scripts/snmp_pdu_control --hostname lngpdu01 --command > >> off --port 3', > >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 1 -s off', > >> '/usr/local/lab-scripts/eth008_control -a 172.27.19.27 -r 2 -s off', > >> > >> So if you don't have HW moded board, this device dict won't work for > >> you. Sources for the scripts are here: > >> https://git.linaro.org/lava/lava-lab.git/tree/shared/lab-scripts > >> We're using pretty expensive HW in the LAB: > >> - managed APC PDUs: > >> > https://www.apc.com/shop/uk/en/products/Rack-PDU-Switched-1U-16A-208-230V-8… > >> (I couldn't find the exact models we have, they're discontinued) > >> - ETH008 relay board: > https://www.robot-electronics.co.uk/htm/eth008tech.htm > >> > >> milosz > >> > >> On Mon, 11 Nov 2019 at 10:42, dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > >> > > >> > Hi Milosz, > >> > > >> > No. > >> > Through Manual Setup , we are able to switch between the modes. > >> > > >> > Here I have attached the kernel & dtb image for your reference. PFA. > >> > > >> > Dhanunjaya. P > >> > > >> > > >> > On Mon, Nov 11, 2019 at 3:40 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >> >> > >> >> I think I forgot to ask key question when it comes to this device: > did > >> >> you do the HW mod to be able to switch between DFU and OS boot modes > >> >> without manual step? > >> >> > >> >> milosz > >> >> > >> >> On Mon, 11 Nov 2019 at 10:01, dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > >> >> > > >> >> > Hi Milosz, > >> >> > > >> >> > Thanks for reply. > >> >> > > >> >> > I am new to the LAVA usage. > >> >> > > >> >> > I have taken reference from the below link. > >> >> > > https://staging.validation.linaro.org/scheduler/device/staging-stm32mp157-0… > >> >> > > >> >> > Here I have attached the device_dictionary & device configurations > files, PFA. > >> >> > > >> >> > Note : I am not able to see the "lab-scripts" to have power > controlled commands in my local repository , is there any specific package > need to install in my localhost , can you please share the lab-scripts to > have pdu control and also please share the pdu device details if required > to connect with the hardware. > >> >> > > >> >> > Can you please share some references , which i can run some jobs > through any other deploy methods like "tmpfs , tftp " for "STM32MP157C-DK2". > >> >> > > >> >> > Thanks & Regards, > >> >> > Dhanunjaya. P > >> >> > > >> >> > > >> >> > On Mon, Nov 11, 2019 at 2:59 PM Milosz Wasilewski < > milosz.wasilewski(a)linaro.org> wrote: > >> >> >> > >> >> >> Could you share your device dictionary? You might be missing > >> >> >> flasher_deploy_commands. > >> >> >> > >> >> >> Please check here for reference: > >> >> >> > https://ledge.validation.linaro.org/scheduler/device/lng-stm32mp157-01/devi… > >> >> >> > >> >> >> milosz > >> >> >> > >> >> >> On Thu, 7 Nov 2019 at 07:48, dhanu msys < > dhanuskd.palnati(a)gmail.com> wrote: > >> >> >> > > >> >> >> > Hi Team, > >> >> >> > > >> >> >> > I am trying to run the test_jobs on the specific device type > "stm32mp1157c-dk2" , but its throwing an error message to deploy "flasher" > method in the deployment parameters. > >> >> >> > > >> >> >> > Here I have attached the screenshots for reference. PFA. > >> >> >> > > >> >> >> > Thanks & Regards, > >> >> >> > Dhanunjaya. P > >> >> >> > _______________________________________________ > >> >> >> > Lava-users mailing list > >> >> >> > Lava-users(a)lists.lavasoftware.org > >> >> >> > https://lists.lavasoftware.org/mailman/listinfo/lava-users >

5 years, 7 months

2
4
0 0

Fork option is disabled

by Suram Suram

Hi, I want to submit a change to device-type file and when I tried from the webGUI after logging in, the fork option is disabled. After clicking on the forks count number, the fork option appears to be enabled on that page. Clicked it to select namespace, when hovered the mouse over the namespace, it shows the following error "You have reached your project limit" Can some one help me on this please? Regards Suram

5 years, 7 months

2
1
0 0

None of the deployment strategies accepted your deployment parameters

by dhanu msys

Hi Team, I am trying to run the test_jobs on the specific device type "stm32mp1157c-dk2" , but its throwing an error message to deploy "flasher" method in the deployment parameters. Here I have attached the screenshots for reference. PFA. Thanks & Regards, Dhanunjaya. P

5 years, 7 months

2
3
0 0

Force prompt in lava boot issue.

by Larry Shen

Guys, We have a problem as next: [cid:image001.jpg@01D5958F.E65E7670] The story is we have kernel exception when device boot, then per next code: if index == cls.TRACE or index == cls.EXCEPTION: res = "fail" if action: action.logger.warning( "%s: %s" % (action.name, cls.MESSAGE_CHOICES[index][2]) ) # TRACE may need a newline to force a prompt connection.sendline(connection.check_char) It will send a "#" to device, but unfortunately, the exception time is too close the final login, then the "#" was sent to user login as next: Imx8qxpmek login: # Then when we send "root", it definitely cannot login, how to resolve? More, why lava send "#" to device when kernel have exception?

5 years, 7 months

2
1
0 0

Re: [Lava-users] 500 internal server error

by Remi Duraffort

Hello, could you give me the exact version? If you are admin, just ask debian to give you the package version. If you are a user, this is printed in the first line of every job logs. Rgds Le lun. 4 nov. 2019 à 07:58, dhanu msys <dhanuskd.palnati(a)gmail.com> a écrit : > Hi Remi, > > I was using LAVA Version V2, please correct me if i am quite wrong. > > Please let me know how to find out the lava version using command prompt. > > Thanks & Regards, > Dhanunjaya. P > > > On Thu, Oct 31, 2019 at 9:42 PM Remi Duraffort <remi.duraffort(a)linaro.org> > wrote: > >> Hello, >> >> which version are you using? >> >> >> Rgds >> >> Le jeu. 31 oct. 2019 à 13:19, dhanu msys <dhanuskd.palnati(a)gmail.com> a >> écrit : >> >>> Hi Team, >>> >>> While Running LAVA in localhost , facing the error while accessing the >>> UI related to Devices. >>> >>> Here I have attached the screenshot , please find the attachment. >>> >>> Please help me to solve this issue. >>> >>> Thanks & Regards, >>> Dhanunjaya. P >>> _______________________________________________ >>> Lava-users mailing list >>> Lava-users(a)lists.lavasoftware.org >>> https://lists.lavasoftware.org/mailman/listinfo/lava-users >> >> >> >> -- >> Rémi Duraffort >> LAVA Architect >> Linaro >> > -- Rémi Duraffort LAVA Architect Linaro

5 years, 7 months

2
4
0 0

Lava Test Jobs didn't scheduled

by dhanu msys

Hi Team, I have submitted some sample test jobs for qemu device type on my local lava setup. After successful submission of tests , I can't able to see the jobs running status , the state remains to "submitted". When i gone through the lava-master logs , Observed the warnings saying that can't able to schedule the jobs due to lava-logs is offline. Here I have attached the screenshots. Please find the attachments. Can you please let me know how to schedule the jobs on master by manual. Thanks & Regards, Dhanunjaya. P

5 years, 7 months

2
10
0 0

Issue with prompt matching with no output during boot

by Diego Russo

Hello, We upgrade from LAVA 2019.04 to 2019.10 and we have issues with the prompt matching when the device boots. We test 2 kinds of Linux images: * Development image * it outputs data into the serial (secure boot, uboot, kernel, systemd) * user: root, pass: empty * Production image * it doesn't output anything and *only presents the login prompt* * user: root, pass: it could be anything The workflow is the following: * spin up LXC container for recovery mode * boot the DUT waiting for the prompt. We don't need to login using the serial connection but we need to wait the prompt to understand that the board has successfully booted * run tests from the LXC container and using ssh to the DUT In LAVA 2019.04 everything was working as expected: ... start: 7.3 auto-login-action (timeout 00:05:57) [target] Using line separator: #'\n'# No login prompt set. Parsing kernel messages ['-+\\[ cut here \\]-+\\s+(.*\\s+-+\\[ end trace (\\w*) \\]-+)', '(Unhandled fault.*)\\r\\n', 'Kernel panic - (.*) end Kernel panic', 'Stack:\\s+(.*\\s+-+\\[ end trace (\\w*) \\]-+)', 'mbed-linux-os-(.*) login:', 'Login timed out', 'Login incorrect'] [auto-login-action] Waiting for messages, (timeout 00:05:57) Waiting using forced prompt support. 178.45381999015808s timeout Trying ::1... Connected to localhost. Escape character is '^]'. Mbed Linux OS mbl-warrior-dev-production_build64 mbed-linux-os-674 ttymxc5 Matched prompt #4: mbed-linux-os-(.*) login: ... While in 2019.10 the job is failing with the following: ... start: 7.3 auto-login-action (timeout 00:05:57) [target] auto-login-action: Wait for prompt ['Linux version [0-9]'] (timeout 00:06:00) Trying ::1... Connected to localhost. Escape character is '^]'. � Mbed Linux OS mbl-warrior-dev-production_build74 mbed-linux-os-1764 ttymxc5 ... Another thing we observed in LAVA 2019.10: using the dev images (hence with output data) it works without any problem. Here a snippet of our pipeline: .... - boot: namespace: recovery timeout: minutes: 5 method: recovery commands: recovery - deploy: timeout: minutes: 10 to: recovery namespace: recovery connection: lxc images: images to download..... os: debian - test: namespace: lxc connection: lxc timeout: minutes: 10 definitions: - from: inline name: flash-image path: inline/flash-image.yaml repository: metadata: format: Lava-Test Test Definition 1.0 name: flash-image description: "Flash image to board in recovery mode" os: - oe run: steps: - steps to recover the board - boot: namespace: recovery timeout: minutes: 5 method: recovery commands: exit - boot: namespace: target method: minimal failure_retry: 3 prompts: - "mbed-linux-os-(.*) login:" timeout: minutes: 6 .... Looking at the LAVA code we think the following commit changed the behaviour: https://git.lavasoftware.org/lava/lava/commit/6b5698a2d3ed23031e40aa1d86181… How are we supposed to change the pipeline to make it work again? 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/docs/mbed-linux-os/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 7 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users