lava-users

lava-users@lists.lavasoftware.org

1 participants
912 discussions

Re: [Lava-users] lava job without any flashing on a real device

by George Nistor

Yes, In my case the only way I could make lava to see the fastboot device was via running pre-power-command, and I run a script (I customized device descriptor to run a this script as pre-power-command) which does: 1. Power Off Wait 5s 2.Power On Wait 30s 3. Login as root Wait 5s 4. echo reboot bootloader. # make it go in fastboot mode Immediately after this script runs, the udev rule is triggered and device id added (seen from Lava). Otherwise the reboot does not work for me. The line: nice lxc-attach -n lxc-hikey-test-186 -- fastboot -s xxxxxxx reboot gives timeout. Because the device is not seen. To make the job work without any flashing I removed the - deploy section which does flashing entirely For my case: I have added to boot this section protocols: lava-lxc: - action: fastboot-boot request: pre-power-command timeout: minutes: 5 george The full job I cannot post due to company policy with confidentiality on projects. -----Original Message----- From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org> Sent: luni, 14 octombrie 2019 15:58 To: George Nistor <george.n(a)l4b-software.com> Subject: Re: lava job without any flashing on a real device Could you send the question to ML? I don't know why adb is not enough. Maybe LAVA waits for udev event? milosz On Mon, 14 Oct 2019 at 13:51, George Nistor <george.n(a)l4b-software.com> wrote: > > I have managed after all to do it with a job like this: > My problem was to be able to run pre-power-command before boot, to make lava to see the fastboot device - trigger that python script lxc-device-add. > > > -----Original Message----- > From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org> > Sent: Monday, October 14, 2019 15:02 > To: George Nistor <george.n(a)l4b-software.com> > Subject: Re: lava job without any flashing on a real device > > There was a feature called 'dummy deploy' but I can't find it any more. Did you try simply removing 'deploy' action? This should do the trick but you will need transfer_overlay in your boot section. > > milosz > > On Mon, 14 Oct 2019 at 12:33, George Nistor <george.n(a)l4b-software.com> wrote: > > > > Hi Milosz, > > > > > > > > I have a small question: > > > > Is it possible to run a lava job without any deploy – flashing sequence on a real device? > > > > > > > > I attach the job I’m working on. > > > > > > > > george

5 years, 2 months

Comparing output within a job execution between reboots

by Diego Russo

Hello, I have a job with the following flow: 1) deploy the DUT 2) boot the DUT 3) while booting, I need to capture a string: it is the version/timestamp of BL2. For example: NOTICE: BL2: v2.1(release):v2.1-232-g89a4d26-dirty NOTICE: BL2: Built : 04:06:44, Sep 25 2019 4) perform an update of the BL2 5) reboot the device 6) while booting the second time, I need to capture again the version/timestamp 7) Compare the 2 strings: if they are different, the test passes. How can I do 3) 6) and 7) with LAVA? Thanks -- Diego Russo | Staff Software Engineer | Mbed Linux OS ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - https://os.mbed.com/linux-os/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 2 months

Lava does not do DUT login

by George Nistor

Hello Lava users, I have a Lava job, with the following section: - boot: namespace: target prompts: - 'root@xxxxx:~#' auto_login: login_prompt: 'xxxxx login:' username: root timeout: minutes: 5 method: fastboot and Lava does not complete with 'root' to do autologin. After 5 mins it give me timeout autologin. Even if I run the job and waited till the login prompt comes as output in Lava and do a echo 'root' > /dev/ttyUSB2 still Lava detects timeout autologin. (even if the devices successfully logs in - I have sent the string 'root' 2 times from the terminal). [ 25.440854] audit: type=1325 audit(1564586870.989:25): table=filter family=2 entries=8 BMW xxxxx 19w32.5-1-2 mgu22 ttyMSM0 mgu22 login: root 7[r[999;999H[6nroot@xxxxx:~# root -sh: root: not found root@mgu22:~# [ 79.848385] firmware cdsp.mdt: _request_firmware_load: firmware state wait timeout: rc = -110 [ 79.857777] subsys-pil-tz 8300000.qcom,turing: cdsp: Failed to locate cdsp.mdt(rc:-11) auto-login-action timed out after 231 seconds The complete lava job is here. https://pastebin.com/MeV1AyeR Where is the mistake I do? george

5 years, 2 months

ODROID-N2: Installation & configuration help

by Malcolm Brooks

Hi All, I am installing an ODROID-N2 board into our LAVA setup. I see that there is support for ODROID-X2 and ODROID-XU3 in the LAVA codebase, but no mention of ODROID-N2. Before I start, I wanted to know if anyone has successfully installed an ODROID-N2 in LAVA? Does it work with the existing support added for the other variants? Are there any specific bits of hardware I will need to use and/or device dictionary settings I need to ensure are set before I can get the board up and running? Regards, Malcolm 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, 2 months

lava-server-gunicorn worker crashes

by Dean Birch

Hi, We've recently had an issue with our LAVA instance (version 2019.05.post1), where a long running LAVA job which had a large log file led to instabilities when serving web content. The large job was seemingly causing lava-server-gunicorn workers to use up more memory than was available, leading to workers crashing and then restarting. This led to all the workers processing the large jobs most of the time, while other requests would only be served once the workers restarted. This led to the webpages being served extremely slowly and lavacli usage timing out (if a larger timeout was not set). We had "LOG_SIZE_LIMIT": 3 set in our /etc/lava-server/settings.conf, and we did have the message on that job page for "*This log file is too large to view"*, but it seems that some requests were still attempting to process some aspect of the job causing these worker crashes. Is there any other settings that might need to be set in order to cope with long running jobs with large log files that might help with this situation? Before we look into this any further, does anyone know if this is fixed with a newer version of LAVA? Has anyone had any similar issues with their instances? Thanks, Dean

5 years, 2 months

lava inside a VM, lxc container on host machine can't get an IP address

by George Nistor

Hi Lava users, I have a problem with the lxc container which is created on the host machine, by getting an IP address. Lava is installed in a, VM with Debian stretch. Has anyone experienced this problem before? Or anyone any idee why lxc does not get the ip? Here are the logs: lava-dispatcher, installed at version: 2019.09+stretch start: 0 validate Start time: 2019-09-24 12:29:39.318789+00:00 (UTC) lxc, installed at version: 1:2.0.7-2+deb9u2 Validating that file:///usr/mgu22/mgu22-19w32.5-1-2-bmw-image-mgu22-sa8155.rootfs.ext4 exists validate duration: 0.07 definition: lava result: pass case: validate 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 lxc-hikey-test-13 -- --release stretch --mirror http://mirror.bytemark.co.uk/debian --packages systemd,systemd-sysv Container created successfully end: 1.1 lxc-create-action (duration 00:01:22) [tlxc] level: 1.1 case: lxc-create-action definition: lava result: pass namespace: tlxc duration: 82.21 extra: ... start: 1.2 lxc-create-udev-rule-action (timeout 00:03:38) [tlxc] device info file '/var/lib/lava/dispatcher/tmp/13/lxc-create-udev-rule-action-y0_d19aq/device-info.yaml' created with: [{'board_id': '7d4452a4'}] udev rules file '/var/lib/lava/dispatcher/tmp/13/lxc-create-udev-rule-action-nj_8pzv0/100-lava-lxc-hikey-test-13.rules' created ACTION=="add", ATTR{serial}=="7d4452a4", RUN+="/usr/share/lava-dispatcher/lava_lxc_device_add.py --lxc-name lxc-hikey-test-13 --device-node $name --job-id 13 --logging-url tcp://localhost:5555" '/etc/udev/rules.d/100-lava-lxc-hikey-test-13.rules' symlinked to '/var/lib/lava/dispatcher/tmp/13/lxc-create-udev-rule-action-nj_8pzv0/100-lava-lxc-hikey-test-13.rules' nice udevadm control --reload-rules udev rules reloaded. end: 1.2 lxc-create-udev-rule-action (duration 00:00:00) [tlxc] start: 1.3 boot-lxc (timeout 00:03:38) [tlxc] nice lxc-start -n lxc-hikey-test-13 -d output: Wait until 'lxc-hikey-test-13' state becomes RUNNING nice lxc-info -sH -n lxc-hikey-test-13 output: RUNNING output: 'lxc-hikey-test-13' state is RUNNING Wait until 'lxc-hikey-test-13' gets an IP address nice lxc-info -iH -n lxc-hikey-test-13 output: nice lxc-info -iH -n lxc-hikey-test-13 output: nice lxc-info -iH -n lxc-hikey-test-13 output: nice lxc-info -iH -n lxc-hikey-test-13 output: nice lxc-info -iH -n lxc-hikey-test-13 output: nice lxc-info -iH -n lxc-hikey-test-13 output: Here is my Lava job: https://pastebin.com/kiLbnjAX

5 years, 3 months

job submit error

by veera brahmam

Hi All, i am new LAVA framework i am trying to submit my first job , but error like "Invalid definition: extra keys not allowed @ data['job_timeout']" i am attaching screen shot & file. Can someone please help me to solve this issue Thanks Veera

5 years, 3 months

Change overlay directory

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

5 years, 3 months

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

5 years, 3 months

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

5 years, 3 months

← Newer
1
...
34
35
36
37
38
39
40
...
92
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users