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?
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
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
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
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.
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
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.
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
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
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
