lava-users

lava-users@lists.lavasoftware.org

2 participants
936 discussions

by George Nistor

Hello Lava users, Thanks to Tim Jaaks for previous problem I reported. I managed to configure default external shared folder for the lava lxc container. However, I try to run VTS from Lava but after displaying initial string with VTS I get an error saying adb server could not start. I have tried restart, no success. The adb seems to be installed in the container. Does anyone know how to solve this error? + ./vts-tradefed Android Vendor Test Suite 9.0_R2 (eng.l4b.20190906.094644) Use \"help\" or \"help all\" to get more information on running commands. 10-15 13:45:22 E/adb: ADB server didn't ACK 10-15 13:45:22 E/ddms: 'adb start-server' failed -- run manually if necessary 10-15 13:45:22 E/adb: * failed to start daemon * 10-15 13:45:22 E/adb: error: cannot connect to daemon [udev_trigger-lxc-hikey-test-214-13:45:29] device /dev/bus/usb/001/005 added The adb is put in tlcx deploy actions: - deploy: namespace: tlxc timeout: minutes: 5 to: lxc packages: - adb - fastboot - wget - unzip - default-jre os: debian george

6 years

repeat in lava not work

by cnspring2002

actions: - repeat: count: 2 I just add above in job, and web submit validator told me: Job submission error: extra keys not allowed @ data['actions'][1]['repeat'] Does it still work now?

6 years, 1 month

unable to run vts because adb-start-server

by George Nistor

6 years, 1 month

is lxc shared folder possible?

by George Nistor

Hi Lava users, For my test, instead of downloading android-vts.zip archive from git I decided it will be used from a location on a machine which hosts Lava. The question is: Is it possible to make like a shared folder for the lxc container lava has created? Or is any other way to access directly from the lxc container a folder on the host machine? If so, how should be done? george

6 years, 1 month

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

6 years, 1 month

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.

6 years, 1 month

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

6 years, 1 month

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.

6 years, 1 month

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

6 years, 1 month

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

6 years, 1 month

← Newer
1
...
36
37
38
39
40
41
42
...
94
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users