Hello Lava users,
I have a question regarding real devices supported by Linaro Lava.
Besides these dev boards I found here : https://validation.linaro.org/static/docs/v2/standard-armmp-ramdisk-bbb.htm…
Are any other real devices supported in Lava by default? (any commercial phone for example Nexus 5)?
george
Hello, LAVA Team!
I'm trying to implement own device description. Run with standard fastboot
singlenode with lxc.
And received error:
lava-dispatcher, installed at version: 2019.03+stretchstart: 0 validateStart
time: 2019-08-19 15:01:03.367020+00:00 (UTC)validate duration: 0.00result:
fail
definition: lava
case: validate
<http://localhost:10080/results/testcase/8>Cleaning after the jobRoot tmp
directory removed at /var/lib/lava/dispatcher/tmp/2InfrastructureError: The
Infrastructure is not working correctly. Please report this error to LAVA
admins.error_msg: Cannot find command 'lxc-start' in $PATH
error_type: Infrastructure
result: fail
definition: lava
case: job <http://localhost:10080/results/testcase/9>
Best regards, Ilya Fedusiv
Anyone can help to provide some suggestion about following kernelci
integration problem:
We setup one kernelci in our infrastructure and deploy LAVA master and
slave as well. kernelci can support build, LAVA can also work to run
automation test. We use the lava-boot-v2.sh (jenkins job in kernelci-core
project ) to trigger lava test, but we found that both boot report or test
report can't be synchronized to kernelci dashboard. It will report json
format error, may I know whether we need follow boot schema or test schema
defined in kernelci (https://api.kernelci.org/schema-boot.html and
https://api.kernelci.org/schema-test.html) to create one report, then
trigger LAVA callback function to post one request?
Following is callback definition in
https://github.com/kernelci/kernelci-core/blob/master/templates/base/kernel….
Do we need customize this callback if we want to post request for boot and
test result? Any suggestion will be appreciated.
{%- if callback %}
notify:
criteria:
status: finished
callback:
{%- if callback_type == 'custom' %}
url: {{ callback_url }}
{%- else %}
url: {{ callback_url }}/callback/{{ callback_name }}?lab_name={{ lab_name
}}&status={STATUS}&status_string={STATUS_STRING}
{%- endif %}
method: POST
dataset: {{ callback_dataset }}
token: {{ callback }}
content-type: json
{% endif %}
Hello LAVA Team!
Found in manual about adding new device, at begin better to write to you.
Device is: aarch64
Flashing via fastboot (have partition table list)
Device has serial debug connection.
For flashing using next commands:
fastboot flash <partition name> <path>
...
...
fastboot set_active a
fastboot reboot
To turn device into fastboot mode need to enter command in serial debug.
Best regards,
Ilya Fedusiv
Hi Lava Users,
I am trying to create a target with qemu running android as an ISO image.
The job I intend to write is to run CTS and VTS on a qemu target with android.
But I receive error when submitting.
Could anyone help me telling me
which are my mistakes I do with the job?
None of the deployment strategies accepted your deployment parameters, reasons given: qemu-nfs: "to" is not "nfs" lxc: "to" parameter is not "lxc" overlay: 'overlay' not in the device configuration deploy methods removeable: "media" was not "sata", "sd", or "usb" fastboot: "to" parameter is not "fastboot" tftp: "to" parameter is not "tftp" nfs: "to" parameter is not "nfs" images: "to" parameter is not "tmpfs" flasher: 'flasher' not in the device configuration deploy methods docker: 'docker' not in the device configuration deploy methods uboot-ums: "to" parameter is not "u-boot-ums" ssh: "ssh" is not in the device configuration deploy methods download: "to" parameter is not "download" iso: "iso" was not in the parameters recovery-mode: 'recovery' not in the device configuration deploy methods mps: "mps" was not in the device configuration deploy methods nbd: "to" parameter is not "nbd" vemsd: "to" parameter is not "vemsd"
device_type: qemu
job_name: george_ISO_6
timeouts:
job:
minutes: 120
action:
minutes: 120
connection:
minutes: 120
priority: medium
visibility: public
# CONTEXT_BLOCK
context:
arch: amd64
# ACTIONS_BLOCK
actions:
- deploy:
timeout:
minutes: 120
to: iso-installer
images:
rootfs:
url: https://osdn.net/frs/redir.php?m=cznic&f=android-x86%2F69704%2Fandroid-x86-…
sha256sum: 71e3cd7e7151fbc7e9bb29be10e337b2545586d3ef173c5ae8c07d13bf595732
# BOOT_BLOCK
- boot:
method: qemu-iso
media: media=cdrom,readonly
timeout:
minutes: 20
connection: serial
Hi Lava users,
I am using the sample you sent me last week to run tradefed: https://gist.github.com/mwasilew/e6e80a351d43388b1c3342098012ec
Until we have a real device to run on Tradefed we decided to use it with qemu, so the question is:
1. How do we deploy android on qemu via Lava?
2. How to boot android via lava?
Do you have any sample job for the above questions?
george
________________________________
From: George Nistor
Sent: Thursday, August 8, 2019 2:19:05 PM
To: Vladut Magas <vladut.m(a)l4b-software.com>; Inon Sharony <inon.s(a)l4b-software.com>; Yair Podemasky <yair.p(a)l4b-software.com>
Cc: Andreas Schl?ter <andreas.s(a)l4b-software.com>; Ilya Fedusiv <ilya.f(a)l4b-software.com>
Subject: FW: [Lava-users] running commands locally from a Lava job
Here is the answer I have just received from Linaro via their mail-list.
They say it is not a good idea to build tradefed with lava, but it can be used in the scenario to run TF from an LXC container - they have said.
Tradefed should be built from outside Lava.
george
-----Original Message-----
From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org>
Sent: Thursday, August 8, 2019 2:07 PM
To: George Nistor <george.n(a)l4b-software.com>
Cc: lava-users(a)lists.lavasoftware.org
Subject: Re: [Lava-users] running commands locally from a Lava job
On Thu, 8 Aug 2019 at 11:50, George Nistor <george.n(a)l4b-software.com> wrote:
>
> Thanks for the answers,
>
> 1. What do you mean by "with LXC container acting as a host side ". It is an LXC container on the machine where Lava runs and inside this containes runs Tradefed?
yes, exactly. Here is an example job definition:
https://gist.github.com/mwasilew/e6e80a351d43388b1c3342098012ec5c
I can't share the actual job and logs as there are passwords included.
milosz
> 2. Where can I find an example of these Jobs? Could you help me with an link, or sample jobs?
>
> george
>
> -----Original Message-----
> From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org>
> Sent: Thursday, August 8, 2019 1:29 PM
> To: George Nistor <george.n(a)l4b-software.com>
> Cc: lava-users(a)lists.lavasoftware.org
> Subject: Re: [Lava-users] running commands locally from a Lava job
>
> I would say it's a bad idea. LAVA is not meant for building stuff. It can do that but you will need to hack around quite a lot. Secondly IIUC you need to have dependency between build and run steps. If you want to implement this using LAVA this implies multi-node job. There is no other way LAVA will manage dependencies and timings between executions. So this is getting pretty complicated already.
>
> LAVA is already running tradefed jobs (CTS and VTS) using real hardware and it's a pretty common use case. There are 2 implementations of this. One is using single node job with LXC container acting as a host side. Other is using multinode and can shard tests between multiple devices. However tradefed packages are built outside of lava and downloaded before job starts.
>
> To sum up, I think what you're trying to do is not best suited for LAVA. However it might be possible given some effort spent on experimenting.
>
> milosz
>
> On Thu, 8 Aug 2019 at 11:20, George Nistor <george.n(a)l4b-software.com> wrote:
> >
> > Yes
> > For one job to build tradefederation from inside a docker container.
> > For the second job to run Google TradeFederation from the docker container.
> >
> > Would be that possible with Lava?
> >
> > george
> >
> > -----Original Message-----
> > From: Milosz Wasilewski <milosz.wasilewski(a)linaro.org>
> > Sent: Thursday, August 8, 2019 1:16 PM
> > To: George Nistor <george.n(a)l4b-software.com>
> > Cc: lava-users(a)lists.lavasoftware.org
> > Subject: Re: [Lava-users] running commands locally from a Lava job
> >
> > George,
> >
> > Do I understand correctly you would like to use LAVA as a building tool?
> >
> > milosz
> >
> > On Thu, 8 Aug 2019 at 10:47, George Nistor <george.n(a)l4b-software.com> wrote:
> > >
> > > Hi Lava users,
> > >
> > >
> > >
> > > Is it possible to run commands inside a lava job test-section, locally, from a Lava Job?
> > >
> > > Ex:
> > >
> > > cd /media/sh_shared_folders
> > >
> > > docker build -t tradefed .
> > >
> > >
> > >
> > > We have the following setup:
> > >
> > > A machine with Linux Ubuntu;
> > > an Oracle Virtual Box VM on the machine with a Xubuntu distro
> > > image inside the VM we have created 3 Docker containers:
> > >
> > > one with the Jenkins
> > > second one with Lava
> > > third is created for the purpose of running Google TradeFederation
> > > against the Android device
> > >
> > >
> > >
> > > (The AOSP source tree is available to the VM via shared_folders
> > > and the docker container has also access to it. (via docker run -v
> > > dir_host:dir_container) )
> > >
> > >
> > >
> > > What we what to achieve is to have 2 jobs in Lava :
> > >
> > > one for building the Docker image for the purpose of building
> > > TradeFederation inside
> > >
> > > Ex. Running these commande locally:
> > >
> > > source
> > > ./build/make/envsetup.sh
> > >
> > > lunch
> > > <device-target>
> > >
> > > make
> > > tradefed-all -j8
> > >
> > >
> > >
> > > second using the above image, instantiate, create a container
> > > which should run TradeFederation against the android device
> > > connected to the machine
> > >
> > >
> > >
> > > What I need is to be able to run commands locally inside the VM (on Xubuntu distro) from a Lava job. For these we have to somehow not send the command to qemu but run them locally.
> > >
> > > Is this possible? If yes, how can we achieve this?
> > >
> > >
> > >
> > > George Nistor
> > >
> > > _______________________________________________
> > > Lava-users mailing list
> > > Lava-users(a)lists.lavasoftware.org
> > > https://lists.lavasoftware.org/mailman/listinfo/lava-users
> _______________________________________________
> Lava-users mailing list
> Lava-users(a)lists.lavasoftware.org
> https://lists.lavasoftware.org/mailman/listinfo/lava-users
Hi Lava users,
Is it possible to run commands inside a lava job test-section, locally, from a Lava Job?
Ex:
cd /media/sh_shared_folders
docker build -t tradefed .
We have the following setup:
* A machine with Linux Ubuntu;
* an Oracle Virtual Box VM on the machine with a Xubuntu distro image
* inside the VM we have created 3 Docker containers:
* one with the Jenkins
* second one with Lava
* third is created for the purpose of running Google TradeFederation against the Android device
(The AOSP source tree is available to the VM via shared_folders and the docker container has also access to it. (via docker run -v dir_host:dir_container) )
What we what to achieve is to have 2 jobs in Lava :
* one for building the Docker image for the purpose of building TradeFederation inside
Ex. Running these commande locally:
source ./build/make/envsetup.sh
lunch <device-target>
make tradefed-all -j8
* second using the above image, instantiate, create a container which should run TradeFederation against the android device connected to the machine
What I need is to be able to run commands locally inside the VM (on Xubuntu distro) from a Lava job. For these we have to somehow not send the command to qemu but run them locally.
Is this possible? If yes, how can we achieve this?
George Nistor
Hello,
I'm asking if the corresponding lava-slave is still working properly. You
can see that on the web interface in the workers page.
By the way, which version are you using?
Le mar. 6 août 2019 à 16:25, Gumansingh, Smita <Smita_Gumansingh(a)mentor.com>
a écrit :
> Yes Remi,
>
> Corresponding testjob is still running on device from last 3 days after it
> got canceled it from GUI. Testjob state is showing canceling
> and my device state is showing Running.
>
> test-hardware | x86 | running | 15696
>
>
> Thanks & Regards,
> Smita Gumansingh
> ------------------------------
> *From:* Remi Duraffort <remi.duraffort(a)linaro.org>
> *Sent:* Tuesday, August 6, 2019 6:26 PM
> *To:* Gumansingh, Smita
> *Subject:* Re: [Lava-users] Testjob state is cancelling
>
> Hello,
>
> are you sure that the corresponding lava-slave is still running?
>
>
> Rgds
>
> Le mar. 6 août 2019 à 09:11, Gumansingh, Smita <
> Smita_Gumansingh(a)mentor.com> a écrit :
>
>> Hi all,
>>
>> I cancelled a test job but it still running on my device and showing
>> testjob state as “cancelling”. Is there any way to restart the device ,so
>> that I can submit some other job .
>>
>> Killing the specific job id on lava-master using lava-cli also not
>> solving the problem.
>>
>>
>>
>> *Regards,*
>>
>> *Smita Gumansingh*
>>
>>
>>
>> [image: cid:image001.jpg@01D2E5A8.A6033460]
>>
>>
>>
>> Senior test Engineer, EPS PBU Software QA/Dev Ops
>>
>> Mentor Graphics,
>>
>> Nalapad Brigade Centre, Unit No:301 & 302
>>
>> Mahadevapura, Bengaluru, Karnataka 560048, India
>>
>> Office: +91 8067624338 |Cell: +91 9538349245
>>
>> www.mentor.com
>>
>>
>> _______________________________________________
>> Lava-users mailing list
>> Lava-users(a)lists.lavasoftware.org
>> https://lists.lavasoftware.org/mailman/listinfo/lava-users
>
>
>
> --
> Rémi Duraffort
> LAVA Team, Linaro
>
--
Rémi Duraffort
LAVA Team, Linaro
Hi all,
I'm running CTS tests on Android 9, with LAVA.
I noticed the CTS module CtsUsbTests failed because of the error:
"usb serial != adb serial expected:<[]> but was:<[a266fa0a5c85d6ee]>"
This module is a hostsidetest, and checks if usb serial matches adb serial
by running "lsusb -v" on the host and checking the iSerial returned by the
command. (
https://android.googlesource.com/platform/cts/+/refs/heads/master/hostsidet…
)
And this test fails when I run it with LAVA so I checked on my local PC and
the test passes. Indeed, if I run the command "lsusb -v" I get this output
for iSerial:
iSerial 3 351d5a0a5c85d936
The third field is the adb serial, so it matches well.
So I suspected the LXC container to not give the usb serial. So I checked
directly in the container and after running "lsusb -v" I got:
iSerial 3
The adb serial is missing.
So, do you know a way to make the LXC see correctly the usb serial ?
Regards,
Axel
Hello,
We've been using uboot-ums deploy mechanism for quite some time but we really want to move away from dd and star using bmap-tools.
I guess lava does not support it (yet) but I was wondering if there is a way where we can use uboot-ums with bmap-tools.
Thanks
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Right, it is not the first time I ask a similar question (I did ask it last February) and a lava issue has been created: https://git.lavasoftware.org/lava/lava/issues/234
Unfortunately there are no progress on this and actually it has been removed from the milestones.
Can we ask to reconsider it? (
Cheers
-----Original Message-----
From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> on behalf of Diego Russo <Diego.Russo(a)arm.com>
Date: Tuesday, 6 August 2019 at 13:32
To: "lava-users(a)lists.lavasoftware.org" <lava-users(a)lists.lavasoftware.org>
Subject: [Lava-users] uboot-ums with bmap-tools
Hello,
We've been using uboot-ums deploy mechanism for quite some time but we really want to move away from dd and star using bmap-tools.
I guess lava does not support it (yet) but I was wondering if there is a way where we can use uboot-ums with bmap-tools.
Thanks
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
Lava-users mailing list
Lava-users(a)lists.lavasoftware.org
https://lists.lavasoftware.org/mailman/listinfo/lava-users
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello LAVA experts,
I have a device which can boot up to android/linux.
The device is connected with two USB cables.
One USB cable is used for flashing images (fastboot flash) and doing some adb shell commands. Via another USB cable, I can use minicom to check uart logs and directly interact with the device (/dev/ttyUSB0).
Can you share some examples (jobs, job definitions) or configurations (like ser2net conf) or any suggestion for doing below test steps on my device with LAVA?
Scenario 1:
1. Flash images using fastboot
2. After android boots up or linux boots up, reboot and then stop at uboot
3. Do some tests in uboot.
Scenario 2:
1. Flash images using fastboot
2. After android boots up or linux boots up, interact with the device via uart (/dev/ttyUSB0) (suppose adb is disconnected)
3. Do some tests via uart.
Best regards,
Kingboli
Hi all,
I cancelled a test job but it still running on my device and showing testjob state as "cancelling". Is there any way to restart the device ,so that I can submit some other job .
Killing the specific job id on lava-master using lava-cli also not solving the problem.
Regards,
Smita Gumansingh
[cid:image001.jpg@01D2E5A8.A6033460]
Senior test Engineer, EPS PBU Software QA/Dev Ops
Mentor Graphics,
Nalapad Brigade Centre, Unit No:301 & 302
Mahadevapura, Bengaluru, Karnataka 560048, India
Office: +91 8067624338 |Cell: +91 9538349245
www.mentor.com<http://www.mentor.com/>
Hi all,
Our lava instance has been upgraded from 2019.03 to 2019.07 today.
Some of our teams need extra job context variables to be allowed, so I
added in /etc/lava-server/settings.conf the following parameter, as
described in one of your releases:
EXTRA_CONTEXT_VARIABLE: ["variable_1", "variable_2", "variable_3"]
It seems to work, but when I want to submit a job, sometimes I get the
warning "extra key not allowed" and if I hit the button "validate" many
times I finally get "valid definition". But sometimes I get "valid
definition" directly.
Is it a known issue?
Best regards,
Axel
Hello,
if the prompt is "# " without more characters then in the lava job
definition you have to put "# ".
In fact, this won't work well because this string can be seen on other
places (like kernel logs).
The only solution here would be to change the prompt of the root filesystem
to make it a bit more unique.
Rgds
Le mer. 31 juil. 2019 à 13:53, Hemanth K V <kv.hemanth.mys(a)gmail.com> a
écrit :
> Hello Remi,
>
> First of all Thanks for support.Trying for matching the string "# "
> If we don't specify any escape or brackets then it is matching one of the
> kernel message logs and sending the username .Following is reference of
> auto_login defined in yaml.
> ***** hwi path: hwi version/minor get_device_info->hwi_get_value: read
> STRING value:
> device name Matched prompt #4: #
>
> auto_login:
> login_prompt: "buildroot login:"
> username: root
> password_prompt: "Password:"
> password: root
> prompts:
> - '# '
>
> On including escape it is waiting for
> auto-login-action: Wait for prompt ['\\(# \\)', 'Login incorrect', 'Login
> timed out'] (timeout 00:07:53). Following is reference of auto_login
> defined in yaml.
>
> auto_login:
> login_prompt: "buildroot login:"
> username: root
> password_prompt: "Password:"
> password: root
> prompts:
> - '\(# \)'
>
> Thanks,
> Hemanth.
>
> On Wed, Jul 31, 2019 at 3:25 PM Remi Duraffort <remi.duraffort(a)linaro.org>
> wrote:
>
>> Hello,
>>
>> which strin are you trying to match? " #", "#", "# "?
>> Just put that (without any escaping or brackets) in the list of prompts.
>>
>> Rgds
>>
>> Le mar. 30 juil. 2019 à 14:20, Hemanth K V <kv.hemanth.mys(a)gmail.com> a
>> écrit :
>>
>>>
>>> Hello Lava Users,
>>>
>>> The target on which I am trying to run tests from LAVA has # prompt
>>> after login.
>>> As specified in Documentation
>>> https://lava.collabora.co.uk/static/docs/v2/actions-boot.html?highlight=pro…
>>>
>>> - boot:
>>> prompts:
>>> # escape the brackets to ensure that the prompt does not match
>>> # kernel debug lines which may mention initramfs
>>> - '\(initramfs\)'
>>>
>>> in the job definition I am including -
>>> boot:
>>> .....
>>> failure_retry: 4
>>> prompts:
>>> - '\(# \)'
>>>
>>> But in the job execution log getting "*auto-login-action: Wait for prompt ['\\(# \\)', 'Login incorrect', 'Login timed out'] (timeout 00:07:52)*".
>>>
>>> Also if we want to debug while running the job which will be the best possible approach to follow.
>>> In the Documentation got information on "Debugging Django issues" which states two settings are required in/etc/lava-server/settings.conf
>>>
>>>
>>> - "DEBUG": true,
>>> - "USE_DEBUG_TOOLBAR": true,
>>>
>>> Thanks,
>>> Hemanth.
>>>
>>> _______________________________________________
>>> Lava-users mailing list
>>> Lava-users(a)lists.lavasoftware.org
>>> https://lists.lavasoftware.org/mailman/listinfo/lava-users
>>
>>
>>
>> --
>> Rémi Duraffort
>> LAVA Team, Linaro
>>
>
--
Rémi Duraffort
LAVA Team, Linaro
Hello Lava Users,
The target on which I am trying to run tests from LAVA has # prompt after
login.
As specified in Documentation
https://lava.collabora.co.uk/static/docs/v2/actions-boot.html?highlight=pro…
- boot:
prompts:
# escape the brackets to ensure that the prompt does not match
# kernel debug lines which may mention initramfs
- '\(initramfs\)'
in the job definition I am including -
boot:
.....
failure_retry: 4
prompts:
- '\(# \)'
But in the job execution log getting "*auto-login-action: Wait for
prompt ['\\(# \\)', 'Login incorrect', 'Login timed out'] (timeout
00:07:52)*".
Also if we want to debug while running the job which will be the best
possible approach to follow.
In the Documentation got information on "Debugging Django issues"
which states two settings are required
in/etc/lava-server/settings.conf
- "DEBUG": true,
- "USE_DEBUG_TOOLBAR": true,
Thanks,
Hemanth.
Hello Denis,
in the timeouts dictionary, you can specify a connections dictionary.
So something like this should work:
timeouts:
connections:
overlay-unpack:
minutes: 10
See
https://docs.lavasoftware.org/lava/actions-timeout.html#connection-timeout
Le mer. 24 juil. 2019 à 14:30, Denis HUMEAU <denis.humeau(a)st.com> a écrit :
> Hi Rémi,
>
>
>
> Where do you set a connection timeout? In the job, in the device
> description?
>
> I didn’t find anything explicit in LAVA help.
>
>
>
> Denis
>
>
>
> *From:* Remi Duraffort <remi.duraffort(a)linaro.org>
> *Sent:* mercredi 24 juillet 2019 14:23
> *To:* Denis HUMEAU <denis.humeau(a)st.com>
> *Cc:* Lava-users(a)lists.lavasoftware.org
> *Subject:* Re: [Lava-users] overlay-unpack timeout error
>
>
>
> Hello Denis,
>
>
>
> have you tried settings the connection timeout? IIRC lava is expecting the
> board to send something and will timeout if not receiving anything during
> "connection timeout" seconds.
>
>
>
>
>
> Rgds
>
>
>
> Le mar. 23 juil. 2019 à 08:58, Denis HUMEAU <denis.humeau(a)st.com> a
> écrit :
>
> Hello Rémi,
>
>
>
> Here is a plain log corresponding to the case described by Philippe.
>
> Let me know if you need more.
>
>
>
> Denis
>
>
>
> *From:* Lava-users <lava-users-bounces(a)lists.lavasoftware.org> *On Behalf
> Of *Remi Duraffort
> *Sent:* lundi 22 juillet 2019 17:42
> *To:* Philippe BEGNIC <philippe.begnic(a)st.com>
> *Cc:* Lava-users(a)lists.lavasoftware.org
> *Subject:* Re: [Lava-users] overlay-unpack timeout error
>
>
>
> Hello Philippe,
>
>
>
> could you send the raw logs?
>
>
>
>
>
> Rgds
>
>
>
> Le ven. 19 juil. 2019 à 09:34, Philippe BEGNIC <philippe.begnic(a)st.com> a
> écrit :
>
> Hello everyone,
>
>
>
>
>
> I have got an error in a lava job during to overlay unpacking operations.
>
>
>
> This happen with jobs that flash the DUT before executing the tests. When the partitions are flashed on the DUT, I reboot the boards.
>
>
>
> After kernel has started, the kernel boot prompt is detected. Then the commands to downloads the tests overlay are launched. ( wget ... )
>
> But in my case, these commands are not immediately executed, because the DUT is beeing resizing the root filesystem to fit available disk space
>
> on the SDCard.
>
>
>
> This operation take time ( depending on capacity and characteristics of the SDCard), and cause overlay-unpack <https://citools.st.com/results/testcase/2039053> to fail with a timeout error,
>
> because the command wget is not executed in the expected time ( 30 sec is the default time ).
>
>
>
> I have tried to add a time out settings in the transfer_overlay part of my jobs, but this has no effect.
>
>
>
>
>
> Is it possible to set specific "timeout trigger" for the "overlay-unpack" operation ?
>
>
>
> My Lava version: *2019.01+stretch*
>
>
>
> Best regards
>
>
>
> Philippe Begnic
>
> STMicroelectronics
>
>
>
> _______________________________________________
> Lava-users mailing list
> Lava-users(a)lists.lavasoftware.org
> https://lists.lavasoftware.org/mailman/listinfo/lava-users
>
>
>
>
> --
>
> Rémi Duraffort
>
> LAVA Team, Linaro
>
>
>
>
> --
>
> Rémi Duraffort
>
> LAVA Team, Linaro
>
--
Rémi Duraffort
LAVA Team, Linaro
Hi,
I'm trying to write a test definition that contains a repeat block (boot / test) as described in the help section.
However the repeat block gives me the syntax error:
"Invalid definition: extra keys not allowed @ data['actions'][2]['repeat']"
I then tried using https://git.lavasoftware.org/lava/lava/blob/master/lava_dispatcher/tests/sa… as an example and I get the same error message with the repeat.
Is this something that is expected to work? I would like to use repeat blocks for some soak tests that I am writing.
Pete
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
I am working with Denis HUMEAU for STMicroelectronics.
I have a problem to perform several reboot with LAVA job when I am using an image with requested login.
I do not understand why 'root' login is sent to device under test when the prompt is received (lines 941, 942, 943, 944 in job_43624.log file). 'root' login should be sent only when a 'login_prompt' is received (like in lines 696, 697, 698, 699, 701, 702 in job_43624.log file).
Could you help me to solve this problem, please ?
Regards,
[Description: Description: Description: Description: Description: Description: logo_big5]
Jerome BESNARD | TINA: 166 7142 | Tel: +33 (0)244027142 | Mobile: +33 (0)623392912
MDG | SW Validation Ingineer
Hello everyone,
I have the following LAVA setup:
LAVA server - 1 LAVA worker - 16 DUTs
The LAVA server and the LAVA worker are located in my company network (172.20.0.0/16).
The DUTs are connected to the LAVA worker in a local network (192.168.20.0/24).
Thus, the DUTs are not accessible from outside the worker.
What is a good way to allow for hacking sessions to a DUT (let's say 192.168.20.247) from the company network?
I can think of the following solutions:
1. Use SSH forwarding on lava-worker:
ssh -g -L 50000:localhost:22 -N root(a)192.168.20.247
2. Forward the SSH port via netcat on lava-worker:
nc -l -p 50000 -c "nc 192.168.20.247 22"
3. Forward the SSH port via iptables on lava-worker:
iptables -t nat -A PREROUTING -p tcp --dport 50000 -j DNAT --to 192.168.20.247:22
All of these make the device accessible via "ssh -p 50000 root@lava-worker" from the company network. So far, so good.
However, in an ideal world this forwarding would be active only during the hacking session, so that in normal test jobs the DUT is not accessible.
Is there a way to achieve this? Does anyone have experience with such a scenario? How do you handle DUT access for hacking sessions?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hello LAVA experts,
I need your help for a more complex test we would need to run.
We'd like to test a gateway node that talks to remote sensors.
* the gateway node is a Cortex-A like (E.g.: RPi3) board
* sensors might be a mixture of Cortex-M (non-Linux) and Cortex-A (Linux) devices
* communication between the gateway node and sensors might happen with different protocols: bluetooth, wifi, lora, zigbee.
* besides the gateway node, we need to control every sensor and be able to provision and to power cycle them.
We are pretty confident on running tests on single boards (with and without interaction with LXC containers) but as the above example is more complex we need some guidance on how this can be achieved with LAVA.
The main question mark we have is how LAVA interacts with Cortex-M devices, especially for their deployment.
Does anyone of you have a similar scenario? What are the main challenges? How complicated and/or robust to run something similar with LAVA?
Can you point us to documentation, examples?
Any help is very much appreciated.
Thanks!
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
We have some tests that are currently expected to fail, and should then become passes once the implementation of the feature is complete.
Is this something LAVA results can support? As far as I can see the result can be pass/fail/skip (and possibly unknown).
Suggestions welcome.
Thanks.
Pete
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
we are trying to add external interfaces on the worker to connect with the DUTs, for example a 4-port USB-to-RS232 converter. Our DUTs have multiple RS232 ports which shall be tested using this remote interface.
We have already figured out how to integrate this hardware into the LAVA environment, so that it can be used within the LAVA LXC (using static_info in the device dictionary, resulting in the four /dev/ttyUSB* devices being visible there).
First question: We need multiple of these converters attached to the worker. How do we integrate these into LAVA? They all have the same board_id, vendor_id and product_id. If I specify the board_id in the device dictionary multiple times, the device is still added only once.
Second question: We need a way to specify to which of the /dev/ttyUSB* ports a certain RS232 port of the DUT is connected. The place where I would assume to put such information is the device dictionary. But how can we access this information within a LAVA test shell?
The documentation specifies some similar mechanism for energy probes:
https://validation.linaro.org/static/docs/v2/admin-lxc-deploy.html?highligh…
It says "Devices which are not directly attached to the worker can also be supported, for example energy probes which communicate over the network".
As far as I can tell from the code, though, this seems to be a hard-coded feature without any possibility of adding other custom hardware. Is that correct?
If yes, why isn't there a generic mechanism to supply static_info from the device dictionary in the LAVA test shell? Or is there?
How can we implement our scenario described above using LAVA?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
After getting stats on my setup robustness, the step forward is have a complete view on the lava errors we meet in incomplete jobs.
>From what I see in incomplete jobs, my intention is to query on test suite lava and the name "job".
In the query builder, if I use test suite as condition model, I can't use the job field name.
Do you have any advice on how to proceed?
Denis
Hi all,
I'm facing a pretty frustrating issue when running CTS/VTS with LAVA.
I'm using Linaro's tradefed test definition :
https://git.linaro.org/qa/test-definitions.git/tree/automated/android/trade…
During some runs, the adb connection is lost, leading to incomplete test
job.
Do you know if this behavior is known and mostly general ? Or is it a bad
configuration on my side ?
Maybe someone knows some way to keep a reliable adb connection to the
target ?
Best regards,
Axel
Sometimes, I can see the lava log feedback to repeat the the lava log output, sometimes cannot.
Could you give an example simple inline test, so I can always see some log feedback?
Something like:
- test:
timeout:
minutes: 1
definitions:
- from: inline
name: smoke-case
path: inline/test.yaml
repository:
metadata:
format: Lava-Test Test Definition 1.0
name: smoke-case-run
description: Run smoke case
run:
steps:
- lava-test-case "Case_001" --shell 'echo "Case001 gstreamer ok";'
How could I let ` Case001 gstreamer ok` also been seen in feedback log level?
Hello,
I have recently upgraded from 2018.11 to 2019.03 and have noticed that the results of a lot of the tests I have been running no longer got parsed correctly by LAVA. This was because I was sending the results using upper case results strings.
Eg. lava-test-case <test-case> PASS opposed to lava-test-case <test-case> pass
This resulted in the following logs in the lava job:
Received signal: <TESTCASE> TEST_CASE_ID=ETH_T_001 RESULT=PASS
Bad test result: PASS
Changing my results parsing script to only send lower case results strings fixed the issue, but was this restriction intended with the upgrade?
Kind Regards,
Patryk
Hello,
I have a system that as soon as LAVA logins, it requires the password to be changed (the password needs to be typed twice).
Is there an easy way to automate it using LAVA?
Cheers
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi all,
I'm currently trying to make a multinode job for CTS on Android 9.
During this job, I need to unlock uboot so I use the "interactive" test
action.
But when I add it to my job definition, I get an error message during the
run :
"Nothing to run. Maybe the 'deploy' stage is missing, otherwise this is a
bug which should be reported."
If I remove the test action with the "interactive" method, I won't get that
error.
Maybe I'm missing something but I don't get what it could be.
You will find attached a test job example which leads to this error.
Best regards,
Axel
Thanks, Remi,
So, looking forward to your patch which allow admins to extend the white list with a variable in the settings.
Regards,
Larry
From: Remi Duraffort <remi.duraffort(a)linaro.org>
Sent: Thursday, May 23, 2019 3:59 PM
To: Larry Shen <larry.shen(a)nxp.com>
Cc: lava-users(a)lists.lavasoftware.org
Subject: [EXT] Re: [Lava-users] Why make the decision to limit job context in lava master?
Caution: EXT Email
Hello Larry,
1. We mainly have 2 kinds of situations:
a) Something like "uboot_ums_flash" which already in linaro lava tree. In the past, this can be overridden by job context. And I guess a lots of other variables which spread every corner of different jinja2 files. Huge I think, I really worried how lava can add so many keys in whitelist...
Why do you have to update uboot_ums_flash in the job definition and not in the device dictionary? This sounds more like a device specific information instead of a job definition one.
Anyway, having a long list of keys in the white list is not really a problem. This is only a python array, nothing more.
b) Something which just used in device jinja2 to control some different command in different situations. I know linaro accept upstreams for device-type, I have no idea if private lab's device jinja2 also useful for other people.
Contributions are welcome. A rule of thumb for device-type integration/templates is often: is the device available for purchase by someone outside your company?
If yes, then it's a good idea to upstream it. If not, then it's more a case-by-case decision.
2. Sounds you guys will not rollback this commit because security issue. So two suggestions:
Sorry no :(
a) I don't know how this security issue could impact for an internal lab which not exposed to external internet. Anyway, if possible to add a configure to any settings to let admin to decide if we care this security issue?
More details to come later on, but I don't think this is a good idea.
b) If a) not easy to do or not accept, if possible this whitelist be stored in database or other persist file, so user can free to add his own keyword to whitelist, then even we will upgrade lava to later new version, we can still remain the keyword setting in the past, meanwhile user still can free to add any keyword to whitelist without upstream again and again for this hard coded whitelist, I don't think this make sense.
I'm currently writing down a patch to allow admins to extend the white list with a variable in the settings.
Please consider. BTW, as Tim Jaacks said in other thread: this limit not happen in multinode job, is it a bug, so next release we will also have this backdoor closed?
I'm fixing this second issue in https://git.lavasoftware.org/lava/lava/merge_requests/547<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.lavas…>
Thanks for reporting it.
Rgds
--
Rémi Duraffort
LAVA Team, Linaro
Hello,
In my job definition I have a minimal boot: https://staging.validation.linaro.org/static/docs/v2/actions-boot.html?high…
Documentation says "auto-login and transfer_overlay are both supported for this method." But if I add auto_login the schema validation in the submit page will raise a warning: "Valid definition with warnings: extra keys not allowed @ data['actions']['boot']['minimal']"
Of course if I take the auto_login out, the validation is green.
If I leave the auto_login, it will be used.
I think the validation needs to reflect what documentation says.
Cheers
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Thanks, Remi,
1. We mainly have 2 kinds of situations:
a) Something like "uboot_ums_flash" which already in linaro lava tree. In the past, this can be overridden by job context. And I guess a lots of other variables which spread every corner of different jinja2 files. Huge I think, I really worried how lava can add so many keys in whitelist...
b) Something which just used in device jinja2 to control some different command in different situations. I know linaro accept upstreams for device-type, I have no idea if private lab's device jinja2 also useful for other people.
2. Sounds you guys will not rollback this commit because security issue. So two suggestions:
a) I don't know how this security issue could impact for an internal lab which not exposed to external internet. Anyway, if possible to add a configure to any settings to let admin to decide if we care this security issue?
b) If a) not easy to do or not accept, if possible this whitelist be stored in database or other persist file, so user can free to add his own keyword to whitelist, then even we will upgrade lava to later new version, we can still remain the keyword setting in the past, meanwhile user still can free to add any keyword to whitelist without upstream again and again for this hard coded whitelist, I don't think this make sense.
Please consider. BTW, as Tim Jaacks said in other thread: this limit not happen in multinode job, is it a bug, so next release we will also have this backdoor closed?
Regards,
Larry
-----Original Message-----
From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> On Behalf Of lava-users-request(a)lists.lavasoftware.org
Sent: Tuesday, May 21, 2019 11:13 PM
To: lava-users(a)lists.lavasoftware.org
Subject: [EXT] Lava-users Digest, Vol 9, Issue 19
Caution: EXT Email
Send Lava-users mailing list submissions to
lava-users(a)lists.lavasoftware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lav…
or, via email, send a message with subject or body 'help' to
lava-users-request(a)lists.lavasoftware.org
You can reach the person managing the list at
lava-users-owner(a)lists.lavasoftware.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Lava-users digest..."
Today's Topics:
1. Re: Why make the decision to limit job context in lava
master? (Remi Duraffort)
2. Re: timeouts for deploy vs http-download (Remi Duraffort)
3. Re: Using transfer overlay (Pete Dyer)
----------------------------------------------------------------------
Message: 1
Date: Tue, 21 May 2019 17:02:35 +0200
From: Remi Duraffort <remi.duraffort(a)linaro.org>
To: lava-users <lava-users(a)lists.lavasoftware.org>
Subject: Re: [Lava-users] Why make the decision to limit job context
in lava master?
Message-ID:
<CANJfhHeXiuVi02dMfmzeQ5EjnP=SqDymDNoyfwDB2XNN8ckodg(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
we had to enforce the content of the context dictionary in order to fix a security issue that we found recently. The full details of the security issue will be disclosed when a CVE is available.
We know that this is annoying for many people so we tried to collect all the valid use cases before the previous release.
Which variables are you setting in the context? Is the corresponding code upstreamed?
Cheers
Le lun. 20 mai 2019 à 10:49, cnspring2002 <cnspring2002(a)aliyun.com> a écrit :
> +1, we also have same issue, had to pending new version deploy.
>
> Message: 1
> Date: Mon, 20 May 2019 05:39:40 +0000
> From: Larry Shen <larry.shen(a)nxp.com>
> To: "lava-users(a)lists.lavasoftware.org"
> <lava-users(a)lists.lavasoftware.org>
> Subject: [Lava-users] Why make the decision to limit job context in
> lava master?
> Message-ID:
> <
> DBBPR04MB63291E1DC4F5F202DEDFE16699060(a)DBBPR04MB6329.eurprd04.prod.out
> look.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> For 2019.04 version, we see next:
>
> Job context
> -----------
>
>
> The schema validator is now checking the content of the `context` dictionary. Only the following keys are now allowed:
>
>
> * `arch`, `boot_console`, `boot_root`, `cpu`, `extra_options`,
> `guestfs_driveid`, `guestfs_interface`, `guestfs_size`, `machine`,
> `memory`, `model`, `monitor`, `netdevice`, `serial`, `vga`
>
> * `bootloader_prompt`, `console_device`, `extra_kernel_args`,
> `extra_nfsroot_args`, `kernel_loglevel`, `kernel_start_message`,
> `lava_test_results_dir`, `menu_interrupt_prompt`, `mustang_menu_list`,
> `test_character_delay`, `tftp_mac_address`
>
> Jobs using keys that are not listed in this list will be rejected.
>
>
> We usually set an customized context in job, and in device-type jinja2, use this context to just different value to set proper parameters.
> After this limit, all things break!
>
> So, my question is:
>
>
> lava could be designed to as a framework to give freedom to users to do their things as in the past, why we now enhance so many limits to users?
> And additional, and workaround for my scenario?
>
> Regards,
> Larry
>
>
>
>
> _______________________________________________
> Lava-users mailing list
> Lava-users(a)lists.lavasoftware.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.lavasoftware.org%2Fmailman%2Flistinfo%2Flava-users&data=02%7C01%
> 7Clarry.shen%40nxp.com%7C2ebbb071596f41c8816208d6ddfee338%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C636940484145033600&sdata=cpnWI8y6
> NzawoUy%2BOtunqchIyXsaHO0ryYzPyJf3Gw0%3D&reserved=0
--
Rémi Duraffort
LAVA Team, Linaro
Hello,
I'm using transfer overlay to get a set of tests onto the target.
However I want to untar it into /scratch instead of / because of storage requirements.
This I can do quite easily.
However the tests are going to try to run from / (e.g. /lava-10473/bin/lava-test-runner /lava-10473/1)
Is there a way of running tests from /scratch/lava-10473.... ?
Or a way of defining a command to run immediately after the transfer overlay that makes a link between /lava-10473 and /scratch/lava-10473 ?
Thanks.
Pete
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
+1, we also have same issue, had to pending new version deploy.
Message: 1
Date: Mon, 20 May 2019 05:39:40 +0000
From: Larry Shen <larry.shen(a)nxp.com>
To: "lava-users(a)lists.lavasoftware.org"
<lava-users(a)lists.lavasoftware.org>
Subject: [Lava-users] Why make the decision to limit job context in
lava master?
Message-ID:
<DBBPR04MB63291E1DC4F5F202DEDFE16699060(a)DBBPR04MB6329.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
For 2019.04 version, we see next:
Job context
-----------
The schema validator is now checking the content of the `context` dictionary. Only the following keys are now allowed:
* `arch`, `boot_console`, `boot_root`, `cpu`, `extra_options`, `guestfs_driveid`, `guestfs_interface`, `guestfs_size`, `machine`, `memory`, `model`, `monitor`, `netdevice`, `serial`, `vga`
* `bootloader_prompt`, `console_device`, `extra_kernel_args`, `extra_nfsroot_args`, `kernel_loglevel`, `kernel_start_message`, `lava_test_results_dir`, `menu_interrupt_prompt`, `mustang_menu_list`, `test_character_delay`, `tftp_mac_address`
Jobs using keys that are not listed in this list will be rejected.
We usually set an customized context in job, and in device-type jinja2, use this context to just different value to set proper parameters.
After this limit, all things break!
So, my question is:
lava could be designed to as a framework to give freedom to users to do their things as in the past, why we now enhance so many limits to users?
And additional, and workaround for my scenario?
Regards,
Larry
Hi lava-users,
my Debian machine running lava-server (2019.04) sends mails via msmtp/msmtp-mta. Mails from cron or apt work fine. But I got no mails from lava. Even when I submit a test job with a notify statement.
notify:
criteria:
status: finished
recipients:
- to:
method: email
user: default
verbosity: verbose
The user default uses my real mail address not a system mail address.
This is the Django log:
INFO 2019-05-10 07:18:15,546 notifications [1343] sending email notification to XXXXXXX(a)YYYYYY.com
ERROR 2019-05-10 07:18:15,557 notifications [Errno 99] Cannot assign requested address
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/lava_scheduler_app/notifications.py", line 303, in send_notifications
title, body, settings.SERVER_EMAIL, [recipient.email_address]
File "/usr/lib/python3/dist-packages/django/core/mail/__init__.py", line 62, in send_mail
return mail.send()
File "/usr/lib/python3/dist-packages/django/core/mail/message.py", line 348, in send
return self.get_connection(fail_silently).send_messages([self])
File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py", line 104, in send_messages
new_conn_created = self.open()
File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py", line 64, in open
self.connection = self.connection_class(self.host, self.port, **connection_params)
File "/usr/lib/python3.5/smtplib.py", line 251, in __init__
(code, msg) = self.connect(host, port)
File "/usr/lib/python3.5/smtplib.py", line 335, in connect
self.sock = self._get_socket(host, port, self.timeout)
File "/usr/lib/python3.5/smtplib.py", line 306, in _get_socket
self.source_address)
File "/usr/lib/python3.5/socket.py", line 712, in create_connection
raise err
File "/usr/lib/python3.5/socket.py", line 703, in create_connection
sock.connect(sa)
OSError: [Errno 99] Cannot assign requested address
WARNING 2019-05-10 07:18:15,558 notifications [1343] failed to send email notification to XXXXXXX(a)YYYYYY.com
Lava has a problem with smtp. Is it necessary to have a complete smtp server on the local machine? Or is there a special smtp configuration?
Greetings,
Matthias
For 2019.04 version, we see next:
Job context
-----------
The schema validator is now checking the content of the `context` dictionary. Only the following keys are now allowed:
* `arch`, `boot_console`, `boot_root`, `cpu`, `extra_options`, `guestfs_driveid`, `guestfs_interface`, `guestfs_size`, `machine`, `memory`, `model`, `monitor`, `netdevice`, `serial`, `vga`
* `bootloader_prompt`, `console_device`, `extra_kernel_args`, `extra_nfsroot_args`, `kernel_loglevel`, `kernel_start_message`, `lava_test_results_dir`, `menu_interrupt_prompt`, `mustang_menu_list`, `test_character_delay`, `tftp_mac_address`
Jobs using keys that are not listed in this list will be rejected.
We usually set an customized context in job, and in device-type jinja2, use this context to just different value to set proper parameters.
After this limit, all things break!
So, my question is:
lava could be designed to as a framework to give freedom to users to do their things as in the past, why we now enhance so many limits to users?
And additional, and workaround for my scenario?
Regards,
Larry
Dear users,
I'd like to add metrics to scale my test farm. Basically I would like to check the occupation rate of the active boards in my farm, to be able to decide whether I need to add extra ones or not.
Do you know if there is a simple way to do it?
Best regards,
Denis
The multinode function of "pass data between devices".Note:
"The message data is stored in a cache file which will be overwritten when
the next synchronisation call is made. Ensure that your scripts make use of
(or copy aside) any MultiNode cache data before calling any other MultiNode
API helpers that may clear the cache."
Does it mean follow example:
roler1:
..
steps:
- lava-send ipv4 ip=192
- lava-send ipv4 ip=193
..
roler2:
step2:
- lava-wait ipv4
- ipdata=$(cat /tmp/lava_multi_node_cache.txt | cut -d = -f 2)
..
After run, is content of roler2 ipdata 193?
In trying to run lava-dispatcher inside a docker container and connect a FRDM-K64F board ran into some issues related to the fact that udev events aren’t seen inside the container since we aren’t typically running systemd/udevd there.
I came across this project that will forward udev events from the host to a container that worked pretty well:
https://github.com/eiz/udevfw
I’ve re-implemented this in python for easier development (added some docker awareness):
https://git.lavasoftware.org/galak/docker-compose/blob/lite/contrib/udev-fo…
Right now running udev-forward.py is kinda kludgy. Wanted to get input on how people think this should work, should we make a daemon out of it? Should there be some kinda of config file? Do we think we need to filter events (and if so how)? Need to look at support for multicasting (support sending to multiple dispatchers). Where should this live, in docker-compose repo?
Other thoughts.
- k
Hello,
I have a remote worker that needs to add a new device-type on the
master.
The remote worker has an auth token with admin/staff/superuser
privileges, and lavacli configured with that token, but when I attempt
to set the new template, I get permission denied:
# lavacli device-types template set da850-lcdk /tmp/new-device-type.jinja2
Unable to call 'device-types.template': <Fault 400: 'Unable to write device-type configuration: Permission denied'>
What permissions am I missing?
Kevin
Hi!
I'm seeing the following issue with lavasoftware/lava-server:2019.04:
http://localhost/static/docs/v2/ gives "Forbidden". Apache log shows the
following:
[Mon May 06 17:57:42.206713 2019] [autoindex:error] [pid 766:tid 140404225701632] [client 172.18.0.1:46780] AH01276: Cannot serve directory /usr/share/lava-server/static/docs/v2/: No matching DirectoryIndex (index.html,index.cgi,index.pl,index.php,index.xhtml,index.htm) found, and server-generated directory index forbidden by Options directive, referer: http://localhost/
The easiest way to reproduce is to run:
$ docker run --rm -p 80:80 -it lavasoftware/lava-server:2019.04
And load http://localhost/static/docs/v2/
Change 2019.04 to 2019.03 and it works fine.
I didn't see anything about this mentioned in the release announcement.
I guess the apache config needs some update?
Thanks!
Dan
The name of the action for http download uses a hyphen, not an
underscore. Fix the typos.
Signed-off-by: Kevin Hilman <khilman(a)baylibre.com>
---
doc/v2/timeouts.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/v2/timeouts.rst b/doc/v2/timeouts.rst
index c330f9d89548..50070766abe0 100644
--- a/doc/v2/timeouts.rst
+++ b/doc/v2/timeouts.rst
@@ -259,7 +259,7 @@ block override.
timeouts:
actions:
- http_download:
+ http-download:
minutes: 2
.. _individual_connection_timeout_overrides:
@@ -275,7 +275,7 @@ specific connection timeout which can be longer or shorter than the default.
timeouts:
connections:
- http_download:
+ http-download:
minutes: 2
.. _action_block_timeout_overrides:
--
2.21.0
Hello everyone,
the current LAVA version in stretch-backports is still 2018-11. Is there a reason why it has not been updated since then?
Will newer releases go into buster only? Or will there be updates in stretch-backports in the future?
For stretch users, do you recommend using the LAVA repositories to upgrade to the latest version?
Or should production systems keep using 2018-11 at this moment?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com<http://www.garz-fricke.com/>
WE MAKE IT YOURS!
[cid:image001.jpg@01D4FF4A.A2ED9910]
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hello,
as said in the previous email, that's currently not possible to see kernel
crashes outside of the boot action.
That's something we want to improve. I will soon create an issue in our
gitlab instance where you would be able to comment.
Rgds
Le jeu. 11 avr. 2019 à 14:33, Frank, Matthias <Matthias.Frank(a)tq-group.com>
> a écrit :
>
> Hi lava users,
>
>
>
> sometimes I how in memory allocator stress tests a kernel panic. How can I
> evaluate this? Is it possible to set a testcase or job to fail if a kernel
> panic occurs?
>
>
>
> Matthias
>
>
>
> Sometimes a test triggers a kernel panic and the dut will reboot to U-Boot
> and stuck because there is no boot process. Lava waits until timeout and
> stop the job.
>
>
>
--
Rémi Duraffort
LAVA Team, Linaro
Hi,
I'd like to know is this site official? https://github.com/kernelci/lava-docker
Does this project same as the one in dockerhub, lavasoftware/lava-server?
I attach a tag on one of my device, and when submit job I will add "tags:" to my job, it's ok.
But, when others submit their job with same device-type which same as my device, as they did not specify "tags", they will have chance to run their job on my device.
How to avoid it? I want the job not be scheduled to the device which have a tag if the job did not specify any tag.
I tried to set the device as private, but then only me can use this device, I have other guys in groupA which want to use the device, while I hae another some guys in groupB which didid not want to use these devices as some modules on the device is not same.
Hi,
There is an idea of device type 'alias' in LAVA. I don't quite
understand what the use case for the current implementation was [1]. I
tried using it but it wasn't very useful. My use case is that I need
to submit jobs to a device type with different device type name. This
is used to align device type naming between different labs in a bigger
project (kernelci.org in this case). So the questions I have about
current implementation:
- is there anyone using current implementation?
- if current implementation is used, how much trouble would it cause
to change the behaviour?
Change in behaviour is quite intrusive and will require database migration.
[1] https://master.lavasoftware.org/static/docs/v2/glossary.html#term-alias
Regards,
milosz
Hi lava users,
sometimes I how in memory allocator stress tests a kernel panic. How can I evaluate this? Is it possible to set a testcase or job to fail if a kernel panic occurs?
Matthias
In case that 'systemd' is one of the ptest to run and to avoid some
test cases failure in the systemd ptest, we need to export the proper
directory that contains the needed systemd test data.
This patch exports the needed test data directory.
Signed-off-by: Khouloud Touil <ktouil(a)baylibre.com>
---
automated/linux/ptest/ptest.yaml | 1 +
automated/linux/ptest/set-systemd-test-data.sh | 18 ++++++++++++++++++
2 files changed, 19 insertions(+)
create mode 100755 automated/linux/ptest/set-systemd-test-data.sh
diff --git a/automated/linux/ptest/ptest.yaml b/automated/linux/ptest/ptest.yaml
index 6205c11..85f6893 100644
--- a/automated/linux/ptest/ptest.yaml
+++ b/automated/linux/ptest/ptest.yaml
@@ -21,5 +21,6 @@ params:
run:
steps:
- cd ./automated/linux/ptest
+ - ./set-systemd-test-data.sh $TESTS
- PYTHONIOENCODING=UTF-8 ./ptest.py -o ./result.txt -t ${TESTS} -e ${EXCLUDE}
- ../../utils/send-to-lava.sh ./result.txt
diff --git a/automated/linux/ptest/set-systemd-test-data.sh b/automated/linux/ptest/set-systemd-test-data.sh
new file mode 100755
index 0000000..0a26b4b
--- /dev/null
+++ b/automated/linux/ptest/set-systemd-test-data.sh
@@ -0,0 +1,18 @@
+#!/bin/bash
+#------------------------
+# Some systemd tests needs systemd test data
+# to pass.
+# This script test when there is systemd tests
+# and set the systemd test data
+#------------------------
+tests="$*"
+test_dirs=['/usr/lib/systemd/ptest/tests/test', '/usr/lib64/systemd/ptest/tests/test', '/usr/lib32/systemd/ptest/tests/test']
+for t in $tests; do
+ if [ "$t" == "systemd" ]; then
+ for dir in test_dirs ; do
+ if [ -e "$dir" ]; then
+ export SYSTEMD_TEST_DATA=$dir
+ fi
+ done
+ fi
+done
\ No newline at end of file
--
2.17.1
Hi lava users,
I have tested lava-os-build on my ptxdist root images and I got this output:
root@MBa6x:/lava-557/bin ./lava-os-build
_____ ___ ____ _
|_ _/ _ \\ / ___| _ _ ___| |_ ___ _ __ ___root@MBa6x:/lava-557/bin
Maybe it's better to look for other files first, like /etc/os-release (or /usr/lib/os-release) for systemd systems.
This file is (more) standardized way to detect with os/build is running by evaluating the keys NAME,PRETTY_NAME etc.
What is the exact function of lava-os-build? Only diagnostic purpose to find out with os is running? Does something else rely on lava-os-build? What could break if I change that script?
Matthias
[0] https://www.freedesktop.org/software/systemd/man/os-release.html
Hi,
Are the Ansible playbook for setting up LAVA available somewhere? There is
an old migrated issue on GitLab [1] which is closed, but the link to an
implementation in there is dead. Is that playbook only internally available
for Linaro? Is there anything you could share?
It looks like many people are moving to Docker in the moment, but that's
not an option for us (at least not for dispatchers), as we need LXC for
Android testing.
Cheers,
Karsten
[1] https://git.lavasoftware.org/lava/lava/issues/27
Hi all,
The LAVA docs mention that it's possible to enable template caching via
settings.conf [1]. However, doing so leads to a key error when starting the
LAVA gunicorn server and in `lava-server manage check --deploy`:
...
File "/usr/lib/python3/dist-packages/lava_server/settings/distro.py",
line 185, in <module>
("django.template.loaders.cached.Loader",
TEMPLATES[0]["OPTIONS"]["loaders"])
KeyError: 'loaders'
The LAVA git history shows that this dictionary key was removed in commit
6705ec870[2], "Refresh the setting files".
Is this just a bug in LAVA, is Django template caching not supported
anymore with LAVA, or are other Debian/pip packages required to be
installed to enable to cache?
I'm currently testing that on Debian buster, which ships Django version
1.11.
Cheers,
Karsten
[1]
https://validation.linaro.org/static/docs/v2/advanced-installation.html?hig…
[2]
https://git.lavasoftware.org/lava/lava/commit/6705ec870c1f30ea0b7f78f05a322…
Hi lava-users,
I upgrade my lava-server package (from backports) to 2019-03 on debian stretch. After this is get an django error:
ERROR 2019-04-04 08:24:16,694 exception Invalid HTTP_HOST header: '<my-host-name>'. You may need to add '<my-host-name>' to ALLOWED_HOSTS.
The browser reports a Bad Request (400)
So I added <my-host-name> and "*" to ALLOWED_HOSTS in /usr/lib/python3/dist-packages/lava_scheduler_app/settings.py and /usr/lib/python3/dist-packages/django/conf/global_settings.py but the error is still present. Are these the wrong file or what could be the problem?
Matthias
Job definition & Detailed log in attachment
发件人: Xiaomingwang (Steve)
发送时间: 2019年4月4日 10:29
收件人: lava-users(a)lists.lavasoftware.org
抄送: Yewenzhong (jackyewenzhong) <jack.yewenzhong(a)huawei.com>; Chenchun (coston) <chenchun7(a)huawei.com>; liucaili (A) <liucaili2(a)huawei.com>
主题: 转发: Lava Issue: API-Error-server.scheduler.all_devices
发件人: liucaili (A)
发送时间: 2019年4月4日 10:24
收件人: Xiaomingwang (Steve) <xiaomingwang1(a)huawei.com<mailto:xiaomingwang1@huawei.com>>
主题: Lava Issue: API-Error-server.scheduler.all_devices
Dear Sir/Madam,
If possible could you please help us analyze the problems encountered in recent Lava tests?
Job definition & Detailed log in the attachment.
lava-dispatcher version: 2018.11+stretch.
The key information is as follows:
python /usr/local/bin/module_deploy.py --DUT cloudgame4_01
Traceback (most recent call last):
File "/usr/local/bin/module_deploy.py", line 37, in <module>
main(args)
File "/usr/local/bin/module_deploy.py", line 30, in main
module = get_module(dut)
File "/usr/local/bin/module_deploy.py", line 14, in get_module
devices_list = server.scheduler.all_devices()
File "/usr/lib/python2.7/xmlrpclib.py", line 1243, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python2.7/xmlrpclib.py", line 1602, in __request
verbose=self.__verbose
File "/usr/lib/python2.7/xmlrpclib.py", line 1283, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib/python2.7/xmlrpclib.py", line 1316, in single_request
return self.parse_response(response)
File "/usr/lib/python2.7/xmlrpclib.py", line 1493, in parse_response
return u.close()
File "/usr/lib/python2.7/xmlrpclib.py", line 800, in close
raise Fault(**self._stack[0])
xmlrpclib.Fault: <Fault -32603: "Internal Server Error (contact server administrator for details): 'NoneType' object has no attribute 'pk'">
Is it a lava bug? We look forward to your reply. Thank you for your assistance.
Best Regards,
Caili Liu
Hi,
I want to measure some output values of test cases. I have a shell script which run stress-ng, parse it's output and exports some measurement variables.
How can I record theses variables? I tried to use lava-test-case -shell myscript.sh -result pass -measurement $VAR1 -unit unit but no values are recorded. Maybe this is the wrong approach, but how can I do this in the correct way?
Matthias
Hello lava users,
how can I run a multinode job on specific devices instead of (a possible set) of device_types? I plan to run CAN or RS485 communication tests which requires a wired connection between duts. Is is possible to submit a job to theses special duts or should is have device_types with only on device instance?
Greetings,
Matthias
Hi Sirs,
Does LAVA support MCU like system? Which usually using a debugger to download image to a MCU internal flash, and get uart result?
Regards,
Hake
How can you have more than one LAVA user have the same token secret
(e.g. for a notify callback.)?
Example use case:
- LAVA job with notify callbacks using token names
- submited as user "bob", token names of "bob" map to actual token secrets
- job fails
- user "lab-admin" fixes some lab issues, re-submits job
- job passes, but callbacks fail because tokens are associated with user "bob"
Since the re-submitted job runs as user "lab-admin", the same token
names and corresponding secrets don't exist.
Naively, user "lab-admin" tries to copy the token secrets from user
"bob" keeping the same token names, but this fails saying that "secret
already exists".
Why can't different users have the same secrets?
I haven't looked at the code, but this limitation kind of suggests that
the secret itself is the key in the db, which would prevent multiple
secrets of the same.
Kevin
Hello lava users,
I use in a test job linuximage, rootfs and dtb from file server location retrieved via http. These files are nightly build from Jenkins. The file links are static so I can use new images within the same test job definition.
Jenkins generates also a build information text file with commit IDs an so on.
How can I integrate the content of this file in the job metadata or job result log? Using metadata: build-readme: <link> in the job definition is not possible because the link is stable over different build, but the file content is changing.
The DUT has no access to the file location because it is in an isolated network. Is there a way to cat the file content on the worker to metadata or job result?
Greetings,
Matthias
Hello lava users,
my lava 2019.01 shows me a device with Health == Bad. The Transitions log give that message:
March11, 3:02p.m.
lava-health
Good → Bad (Invalid device configuration)
Where can I found information about a misconfigured device? The log files did not provide (in my eyes) sufficient information.
As Health checks I use the smoke-tests.
Kinds Regards,
Matthias
I use lxc-mocker in docker container, everything is ok.
Just if the package did not install in advance, then next command will hang in web:
lxc-create -t ubuntu -n test_lava -- --release xenial --mirror http://mirror.bytemark.co.uk/debian --packages systemd,systemd-sysv --arch amd64
I enter the container, see:
root@df67cf292479:/# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 17:20 pts/0 00:00:00 /usr/bin/python3 /usr/bin/lava-slave --level DEBUG --log-file - --master tcp://192.168.1.10:5556 --socket-a
root 8 0 0 17:20 pts/1 00:00:00 /bin/bash
root 13 1 0 17:20 pts/0 00:00:00 lava-run [job: 837]
root 19 13 0 17:20 pts/0 00:00:00 /bin/bash /usr/bin/lxc-create -q -t ubuntu -n test_lava -- --release xenial --mirror http://mirror.bytemark.c
root 261 19 1 17:20 pts/0 00:00:00 apt-get -q install -y systemd systemd-sysv
root 473 8 0 17:21 pts/1 00:00:00 ps -ef
Seems "apt-get install" hang, but if I pre-install the systemd,etc, then everything will ok, the lxc-create will not hang. The same for lxc-attach mocker etc, all will hang if do "apt-get install" & no pakcage preinstall.
Please suggest, thanks.
I started playing with the official lava images today and wanted to
share my work in progress, in case others are doing something similar or
have feedback. My goal is to deploy a lava lab locally. My architecture
is a single host (for now) that will host both the lava server and one
dispatcher. Once it's all working, I'll start deploying a qemu worker
followed by some actual boards (hopefully).
So far, I have the following docker-compose.yml:
version: '3'
services:
database:
image: postgres:9.6
environment:
POSTGRES_USER: lavaserver
POSTGRES_PASSWORD: mysecretpassword
PGDATA: /var/lib/postgresql/data/pgdata
volumes:
- ${PWD}/pgdata:/var/lib/postgresql/data/pgdata
server:
image: lavasoftware/amd64-lava-server:2018.11
ports:
- 80:80
volumes:
- ${PWD}/etc/lava-server/settings.conf:/etc/lava-server/settings.conf
- ${PWD}/etc/lava-server/instance.conf:/etc/lava-server/instance.conf
depends_on:
- database
dispatcher:
image: lavasoftware/amd64-lava-dispatcher:2018.11
environment:
- "DISPATCHER_HOSTNAME=--hostname=dispatcher.lava.therub.org"
- "LOGGER_URL=tcp://server:5555"
- "MASTER_URL=tcp://server:5556"
With that file, settings.conf, and instance.conf in place, I run 'mkdir
pgdata; docker-compose up' and the 3 containers come up and start
talking to each other. The only thing exposed to the outside world is
lava-server's port 80 at the host's IP, which gives the lava homepage as
expected. The first time they come up, the database isn't up fast enough
(it has to initialize the first time) and lava-server fails to connect.
If you cancel and run again it will connect the second time.
A few things to note here. First, it doesn't seem like a persistent DB
volume is possible with the existing lava-server container, because the
DB is initialized at container build time rather than run-time, so
there's not really a way to mount in a volume for the data. Anyway,
postgres already solves this. In fact, I found their container
documentation and entrypoint interface to be well done, so it may be a
nice model to follow: https://hub.docker.com/_/postgres/
The server mostly works as listed above. I copied settings.conf and
instance.conf out of the original container and into ./etc/lava-server/ and
modified as needed.
The dispatcher then runs and points to the server.
It's notable that docker-compose by default sets up a docker network, allowing
references to "database", "server", "dispatcher" to resolve within the
containers.
Once up, I ran the following to create my superuser:
docker-compose exec server lava-server manage users add --staff --superuser --email dan.rue(a)linaro.org --passwd foo drue
Now, for things I've run into and surprises:
- When I used a local database, I could log in. With the database in a
separate container, I can't. Not sure why yet.
- I have the dreaded CSRF problem, which is unlikely to be related to
docker, but the two vars in settings.conf didn't seem to help. (I'm
terminating https outside of the container context, and then proxying
into the container over http)
- I was surprised there were no :latest containers published
- I was surprised the containers were renamed to include the
architecture name was in the container name. My understanding is
that's the 'old' way to do it. The better way is to transparently
detect arch using manifests. Again, see postgres/ as an example.
- my pgdata/ directory gets chown'd when I run postgres container. I see
the container has some support for running under a different uid,
which I might try.
- If the entrypoint of server supported some variables like
LAVA_DB_PASSWORD, LAVA_DB_SERVER, SESSION_COOKIE_SECURE, etc, I
wouldn't need to mount in things like instance.conf, settings.conf.
I pushed my config used here to
https://github.com/danrue/lava.home.therub.org. Git clone and then run
'docker-compose up' should just work.
Anyway, thanks for the official images! They're a great start and will
hopefully really simplify deploying lava. My next step is to debug some
of the issues I mentioned above, and then start looking at dispatcher
config (hopefully it's just a local volume mount).
Dan
Hi,
In most cases, we don't need multiple node job as we can control AOSP
DUT from lxc via adb over USB. However, here is the use case.
CTS/VTS tradefed-shell --shards option supports to split tests and run
them on multiple devices in parallel. To leverage the feature in LAVA,
we need multinode job, right? And in multinode job, master-node lxc
needs access to DUTs from salve nodes via adb over tcpip, right?
Karsten shared a job example here[1]. This probably is the most
advanced usage of LAVA, and probably also not encouraged? To make it
more clear, the connectivity should look like this.
master.lxc <----adb over usb----> master.dut
master.lxc <----adb over tcpip ---> slave1.dut
master.lxc <----adb over tcpip ---> slave2.dut
....
I see two options for adb over tcpip.
Option #1: WiFi. adb over wifi can be enabled easily by issuing adb
cmds from lxc. I am not using it for two reasons.
* WiFi isn't reliable for long cts/vts test run.
* In Cambridge lab, WiFi sub-network isn't accessible from lxc
network. Because of security concerns, there is no plan to change
that.
Option #2: Wired Ethernet. On devices like hikey, we need to run
'pre-os-command' in boot action to power off OTG port so that USB
Ethernet dongle works. Once OTG port is off, lxc has no access to the
DUT, then test definition should be executed on DUT, right? I am also
having the following problems to do this.
* Without context overriding, overlay tarball will be applied to
'/system' directory and test job reported "/system/bin/sh:
/lava-247856/bin/lava-test-runner: not found"[2].
* With the following job context, LAVA still runs
'/lava-24/bin/lava-test-runner /lava-24/0' and it hangs there. It is
tested in my local LAVA instance, test job definition and test log
attached. Maybe my understanding on the context overriding is wrong, I
thought LAVA should execute '/system/lava-24/bin/lava-test-runner
/system/lava-24/0' instead. Any suggestions would be appreciated.
context:
lava_test_sh_cmd: '/system/bin/sh'
lava_test_results_dir: '/system/lava-%s'
I checked on the DUT directly, '/system/lava-%s' exist, but I cannot
really run lava-test-runner. The shebang line seems problematic.
--- hacking ---
hikey:/system/lava-24/bin # ./lava-test-runner
/system/bin/sh: ./lava-test-runner: No such file or directory
hikey:/system/lava-24/bin # cat lava-test-runner
#!/bin/bash
#!/bin/sh
....
# /system/bin/sh lava-test-runner
lava-test-runner[18]: .: /lava/../bin/lava-common-functions: No such
file or directory
--- ends ---
I had a discussion with Milosz. He proposed the third option which
probably will be the most reliable one, but it is not supported in
LAVA yet. Here is the idea. Milosz, feel free to explain more.
**Option #3**: Add support for accessing to multiple DUTs in single node job.
* Physically, we need the DUTs connected via USB cable to the same dispatcher.
* In single node job, LAVA needs to add the DUTs specified(somehow) or
assigned randomly(lets say both device type and numbers defined) to
the same lxc container. Test definitions can take over from here.
Is this can be done in LAVA? Can I require the feature? Any
suggestions on the possible implementations?
Thanks,
Chase
[1] https://review.linaro.org/#/c/qa/test-definitions/+/29417/4/automated/andro…
[2] https://staging.validation.linaro.org/scheduler/job/247856#L1888
Dear All,
I'm currently trying to check and implement a complete validation of my
PSCI solution.
The standard behavior for PSCI is to manage shutdown, reset and low
power mode.
I'm wondering to find the best way to manage it through LAVA.
So two questions:
- Is there a proper way to check the reboot behavior on a target (soft
reboot)? Using shell command is not possible as the is no return from
reboot.
- Shutdown? I'm wondering to test the shutdown command and trig an
automatic wake up after x seconds. My wish is to check that no watchdog
occurred during that time (which is the only way to know if the shutdown
was properly working). So it will be a similar behavior that the reboot
command.
Thanks for your support,
BR
Lionel
Hi Remi
Thanks for the quick reply. Attached please find the document(the raw job log and the job definition).
Hello,
that's in fact maybe a bug in LAVA. To help me reproduce the error, could you send:
* the raw job log (click on "actions / plain logs" in the job page)
* the job definition
Thanks
Le jeu. 21 févr. 2019 à 04:05, Chenchun (coston) <chenchun7(a)huawei.com<mailto:chenchun7@huawei.com>> a écrit :
Dear Sir/Madam,
could you please help us analyze the problems encountered in recent Lava tests?
Detailed log in the attachment.
lava-dispatcher version: 2018.11+stretch.
The key information is as follows: Bug error: argument of type 'NoneType' is not iterable
Chase Qi preliminary positioning is a lava bug. We look forward to your reply.
Thank you for your assistance.
Best Regards,
Caili Liu
_______________________________________________
Lava-users mailing list
Lava-users(a)lists.lavasoftware.org<mailto:Lava-users@lists.lavasoftware.org>
https://lists.lavasoftware.org/mailman/listinfo/lava-users
--
Rémi Duraffort
LAVA Team, Linaro
Hello everyone,
I know from the LAVA documentation how to add metadata to jobs and test suites. When I look at test results, I see that test cases have metadata, too. E.g. https://validation.linaro.org/results/testcase/9759970 shows the following metadata:
case: linux-linaro-ubuntu-lscpu
definition: 0_smoke-tests-lxc
result: pass
Is there a possibility to add custom metadata to test cases?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz
Hi.
To make customized performance regression test job, I need to change
Lava job status as I want.
When I run test like kselftest, Lava dispatcher run test program under DUT.
And after finishing lava test job, Job state is always 'Complete'
whatever result(pass/fail) each test return.
Attached image file is about kselftest result from lava test job.
I want to make lava job status as 'Fail' or 'Canceled' when certain test
return fail.
I would like to ask your advice.
Best regards
Seoji Kim
Dear Sir/Madam,
could you please help us analyze the problems encountered in recent Lava tests?
Detailed log in the attachment.
lava-dispatcher version: 2018.11+stretch.
The key information is as follows: Bug error: argument of type 'NoneType' is not iterable
Chase Qi preliminary positioning is a lava bug. We look forward to your reply.
Thank you for your assistance.
Best Regards,
Caili Liu
Hi all,
Yesterday, we faced a weird issue with LAVA.
A job was running and returned an error saying "metadata is too long".
Right after that, the worker that was running the job went offline, and the
lava-master
raised an "unknown exception", making it crash.
In attachement, you will find the full job error saying metadata is too
long,
the full job log, and the lava-master.log when the exception occured.
Hope this helps.
Axel
I use next command to start lavadispatcher:
docker run -idt --net=host --privileged -v /dev:/dev -v /var/lib/lava/dispatcher/tmp:/var/lib/lava/dispatcher/tmp -e "DISPATCHER_HOSTNAME=--hostname=myname" -e "LOGGER_URL=tcp://master_ip:5555" -e "MASTER_URL=tcp://master_ip:5556" --name test_lava lavasoftware/lava-dispatcher:2019.01
In container, I start tftp and nfs. But the nfs always cannot be start successfully. I use "service nfs-kernel-server start" to start it, also before that I did "rpcbind".
The start shows below seems ok:
# service nfs-kernel-server start
[ ok ] Exporting directories for NFS kernel daemon....
[ ok ] Starting NFS kernel daemon: nfsd mountd.
But if do next we can see the nfs still not start.
# service nfs-kernel-server status
nfsd not running
Any suggestion?
Hello,
We've been using uboot-ums for WaRP7 but we've been having intermittent failures when it tried to run dd to flash the image.
Provided we need to look better into the root cause of this issue, we'd like to make the flashing phase a little more reliable.
I have few questions, coming from different angles:
* LAVA uses dd command to flash the image. Is there a way to specify the usage of bmap-tools?
* let's say dd times out (this is what usually happen). Is there a mechanism to restart the actions (deploy and boot) in case of timeout?
If you have any other suggestion, let me know!
Cheers
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi,
I have a test step that requires user input to a defined prompt.
Is there a way I can automate this in LAVA ?
I can see how we do this for Boot Actions and I've looked at interactive jobs that communicate to U-boot but these don't seem to fit my use case.
Thanks.
Pete
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi All,
I am new to Android testing, I am using standard board *i.mx6/rpi3* and
flashed Android on it, I can connect with these board using "adb" tool.
I want to do some system test using LAVA framework, and I don't want to
reflash image every time(wants to test on the existing system). Can someone
please let me know how I can do Android testing on existing flashed image?
Thanks,
Ankit
Dear Lava users,
Our embedded SW offers 3 boot modes, selectable from u-boot.
When booting, u-boot offers the possibility to select the boot mode:
Select the boot mode
1: <boot mode 1>
2: <boot mode 2>
3: <boot mode 3>
Enter choice: 1: <boot mode 1>
<boot mode 1> is a default value, used after a counter has expired.
All this is done using the extlinux feature.
We have scripts that allow to select the boot mode, using Kermit. Now, we'd like to integrate this boot mode selection in a Lava job, and our current solution is not compatible.
In Lava we may boot the kernel, modify the extlinux configuration and reboot, but do you know a direct way (with interactive mode maybe) to select the boot mode from u-boot?
Best regards,
Denis
Hello everyone,
I am having problems with timeouts when using the LAVA multinode protocol. Assume the following minimal pipeline with two nodes (device = DUT, remote = some kind of external hardware interfacing with the DUT):
- deploy:
role: device
- boot:
role: device
- deploy:
role: remote
- boot:
role: remote
- test:
role: remote
- test:
role: device
What I would expect: The device is booted first, then the remote is booted. Afterwards, the tests run on both nodes, being able to interact with each other.
The pipeline model seems to be implemented in a way that each node has its own pipeline. This kind of makes sense, because the tests of course have to run simultaneously.
However, in my case booting the device takes a lot more time than booting the remote. This makes the 'test' stage on the remote run a lot earlier than the 'test' stage on the device.
My problem: How do I define a useful timeout value for the 'test' stage on the remote? Obviously I have to take the boot time difference between the two nodes into account. This seems counter-intuitive to me, since the timeout value should affect the actual test only. What happens if I use an image on the device which takes even a lot more time to boot? Or if I insert more testcases on the device which do not need the remote before? In both cases I would have to adjust the timeout value for the remote 'test' stage.
Is this a design compromise? Or are there any possibilities of synchronizing pipeline stages on different nodes? I am thinking of some mechanism like "do not start 'test' stage on remote before 'boot' stage on device has finished".
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hi,
Is there a way to specify an arbitrary parameter, that is board
specific, in device dictionary? The parameter should be available from
test shell. The use case is as follows: DUT is connected to test
supporting hardware (chamelium board in this case). Tests access
supporting hardware using IP address. IP address is 'static' and the
supporting hw is assumed to be always turned on. Supporting hardware
is dedicated to specific DUT and can't be shared (because of HW
connections) between other boards of the same type (similar to energy
probes). Tests run directly on DUT and access supporting hardware from
there.
I found 'exported parameters' in device dictionary docs:
https://master.lavasoftware.org/static/docs/v2/lava-scheduler-device-dictio….
But they only list device_ip, device_mac and storage_info. Is there a
way to extend this list? If not, is there any other way to provide
device specific information to test shells?
milosz
Hi everyone,
I'm writing this email after discussion with Neil.
I'm working at NXP and he told me Linaro wanted to run functional tests on
imx8m
with the new u-boot support.
He told me it requires full open access, no license click-through or
passwords.
Philippe Mazet is more qualified to answer this type of question as I only
use Android atm. He will follow up the discussion.
Here you have the Yocto source code :
https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-l…
You can get the latest GA release with this :
repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b
imx-linux-sumo -m imx-4.14.78-1.0.0_ga.xml
You can build these sources like this :
DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source ./fsl-setup-release.sh -b
build
But, this will redirect you to a license click-through.
However, you can bypass the license click-through, like "auto accept it"
with this command :
EULA=1 DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source
./fsl-setup-release.sh -b build
We use this bypass to automate builds.
So, let us know if this would be suitable for Linaro's needs.
Best regards,
Axel
Hello Lava-users,
Do we have support in LAVA for deploying to target the SWUpdate images
directly if target supports the swupdate image deployment(
http://sbabic.github.io/swupdate/).
Thanks,
Hemanth.
Hi all,
We're planning to use TI AM4378 IDK in the board farm for testing (http://www.ti.com/tool/TMDSIDK437X) but it seems there is not device-type for this board. I tried to search from these links:
- https://git.lavasoftware.org/lava/lava/tree/master/lava_scheduler_app/tests…
- https://git.linaro.org/lava/lava-lab.git/tree/shared/device-types
Did I just miss it, or is it missing from the device-types? If it is missing, are there any templates available / what template could be used as a base for the device
Br
Olli Väinölä
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi All,
I have a Rpi3 board with android install on it, it can be accessed using
adb from my Linux PC.
I am successfully able to use Lava-LXC for testing a device.
Can someone please share the steps how I can use LAVA to test an android
device and how the setup will look like. If anyone can share a test job
with some basic android tests would be very helpful.
Thanks,
Ankit
Hello Lava users,
I'm trying to build a query to monitor all the test jobs done in a given period. Let's say all the jobs done in January, just to check the robustness of my setup (incomplete jobs rate).
In the query interface, I can add a condition on start_time of a job, but only with a "greater than" operator, when I want to add also a condition on start_time "less than".
Do you have any hint to do this?
Best regards,
Denis
Hello,
I have the following setup: a WaRP7 which exposes a network connection over USB gadget driver (http://trac.gateworks.com/wiki/linux/OTG#g_etherGadget)
A possible test case is to have some process running on the LAVA dispatcher (within a LXC container) which targets the WaRP7 over this network interface.
Through LXC I'm able to passtrhough this interface from the host to the container and use it within the container (via /etc/lxc/default.conf)
If a test requires the reboot of the WaRP7, the usb0 interface disappears from the container. When the WaRP7 boots again the usb0 interface is available on the host (but not in the container).
Things I tried or thought about:
* I tried synchronizing boots both of the WaRP7 and LXC container but it seems not possible to "reboot" (restart) a container within the same job execution.
* Is it possible to "restart" a container during a job execution?
* Outside LAVA it is possible to run a command (lxc-device --name diegor-test -- add usb0) which re-passthrough the interface from Linux to LXC container.
* Is it possible to run the above command ad job execution time on the lava dispatcher?
How can I solve this situation?
Cheers
--
Diego Russo
Staff Software Engineer - diego.russo(a)arm.com
Direct Tel. no: +44 1223 405920
Main Tel. no: +44 1223 400400
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - http://twitter.com/diegorhttp://www.linkedin.com/in/diegor
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
while searching for possibilities of testing external interfaces of my DUTs I found this presentation:
https://wiki.linaro.org/Internal/lava/Lava-lmp?action=AttachFile&do=get&tar…
Is the LAVA LMP project still active? If yes, how can I find information on this?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com<http://www.garz-fricke.com/>
WE MAKE IT YOURS!
[cid:image001.jpg@01D4B71E.962E36E0]
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
I'm sorry, as surely this is an FAQ but I've spent quite a bit of time
troubleshooting and reading. This is very similar to Kevin's thread from
May subject 'u-boot devices broken after 2018.4 upgrade, strange u-boot
interaction'. In that thread's case, the issue was that interrupt_char
was being set to "\n". My symptoms are the same, but interrupt_char is
set to " " or "d".
I'm running LAVA from the latest released containers (2018.11), and
trying to use a beaglebone-black with a more recent u-boot than exists
in validation.l.o. qemu works fine.
The problem seems to be that LAVA thinks there's a prompt when there
isn't, and so it sends commands too quickly. Here's example output from
the serial console (job link[2]):
U-Boot 2017.07 (Aug 31 2017 - 15:35:58 +0000)
CPU : AM335X-GP rev 2.1
I2C: ready
DRAM: 512 MiB
No match for driver 'omap_hsmmc'
No match for driver 'omap_hsmmc'
Some drivers were not found
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Net: cpsw, usb_ether
Press SPACE to abort autoboot in 10 seconds
=>
=> setenv autoload no
=> setenv initrd_high 0xffffffff
=> setenv fdt_high 0xffffffff
=> dhcp
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 10.100.0.55 (1006 ms)
=> 172.28.0.4
Unknown command '172.28.0.4' - try 'help'
=> tftp 0x82000000 57/tftp-deploy-t7xus3ey/kernel/vmlinuz
link up on port 0, speed 100, full duplex
*** ERROR: `serverip' not set
...
When I u-boot manually, after I hit SPACE (or 'd', both work), u-boot
*deletes* the character and then prints '=> ' (is that delete the root
cause?). When LAVA runs, it shows an extra => and starts typing as seen
above. dhcp takes a second or two, and so the subsequent command starts
to get lost (in the above log we see an IP, because 'setenv serverip'
got lost).
If I set boot_character_delay to like 1000, it works because it gives
enough time for dhcp to finish before typing the next character, but
obviously makes the job very slow, and still not reliable.
I'm out of ideas.. help?
P.S. Two interesting things I've learned recently:
1) boot_character_delay must be specified in device_types file. it's
ignored when specified in the device file (surprising, as I see it
listed in some people's device files[3]).
2) If you install ser2net from sid, you can set max-connections and do
some _very handy_ voyeurism on the serial console while lava does its
thing (hat tip Kevin Hilman for that one).
Thanks,
Dan
[1] https://lists.lavasoftware.org/pipermail/lava-users/2018-May/001064.html
[2] https://lava.therub.org/scheduler/job/57
[3] https://git.linaro.org/lava/lava-lab.git/tree/lkft.validation.linaro.org/ma…
--
Linaro - Kernel Validation
100 testcases, submit to lava before leave the office, expect to get all the results next morning.
If everything is ok, get 100 results next morning, and check every issues.
Then, e.g. the 10th cases OOM, I wish from 11st case to 100th cases can continue run during the night, so I want to reboot the device after 10th case which I find it OOM. Then after reboot, continue 11st case to 100 the cases.
I know OOM not automation related, but if I do not resume the 11st ~ 100th cases during this night. I had to resubmit these cases tomorrow morning after I back to office, maybe the 100th case also have some bug, I wish it could send a result, then that morning I could assign other guy to fix it quickly, not wait I back to office then remove the 10th issue case, resubmit it, wait another 8 hours, finally execute the 100th case. 8 hours passed, we do not want the process's efficiency so low! This is our aim.
------------------------------------------------------------------
发件人:lava-users-request <lava-users-request(a)lists.lavasoftware.org>
发送时间:2019年1月25日(星期五) 16:55
收件人:lava-users <lava-users(a)lists.lavasoftware.org>
主 题:Lava-users Digest, Vol 5, Issue 37
Send Lava-users mailing list submissions to
lava-users(a)lists.lavasoftware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.lavasoftware.org/mailman/listinfo/lava-users
or, via email, send a message with subject or body 'help' to
lava-users-request(a)lists.lavasoftware.org
You can reach the person managing the list at
lava-users-owner(a)lists.lavasoftware.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Lava-users digest..."
Today's Topics:
1. reboot during test (cnspring2002)
2. Re: AOSP multiple node job (Neil Williams)
3. Re: reboot during test (Neil Williams)
4. Re: AOSP multiple node job (Chase Qi)
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Jan 2019 20:11:39 +0800
From: cnspring2002 <cnspring2002(a)aliyun.com>
To: lava-users(a)lists.lavasoftware.org
Subject: [Lava-users] reboot during test
Message-ID: <C0C4B61B-7B5A-4DAB-B644-849E77F0119B(a)aliyun.com>
Content-Type: text/plain; charset=us-ascii
Dear all,
In test stage, I have a case, when it run, one firmware OOM. So I trigger the device to reboot, Then all left case cannot run . I can not use multiple boot when define job in advance because I can not predict which case will make OOM, what you suggest doing?
------------------------------
Message: 2
Date: Thu, 24 Jan 2019 15:06:56 +0000
From: Neil Williams <neil.williams(a)linaro.org>
To: Chase Qi <chase.qi(a)linaro.org>
Cc: lava-users(a)lists.lavasoftware.org
Subject: Re: [Lava-users] AOSP multiple node job
Message-ID:
<CAC6CAR3v_i-vOv4BVe56RHR4PahMihexpNa6v4w44UNb+_PVuw(a)mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Thu, 24 Jan 2019 at 11:41, Chase Qi <chase.qi(a)linaro.org> wrote:
>
> Hi,
>
> In most cases, we don't need multiple node job as we can control AOSP
> DUT from lxc via adb over USB. However, here is the use case.
>
> CTS/VTS tradefed-shell --shards option supports to split tests and run
> them on multiple devices in parallel. To leverage the feature in LAVA,
> we need multinode job, right?
If more than one device needs to have images deployed and booted
specifically for this test job, then yes. MultiNode is required. To be
sure that each device is at the same stage (as deploy and boot timings
can vary), the test job will need to wait for all test jobs to be
synchronised to the same point in each test job - synchronisation is
currently restricted to POSIX shells.
> And in multinode job, master-node lxc
> needs access to DUTs from salve nodes via adb over tcpip, right?
Not necessarily. From the LXC, the device can be controlled using USB.
There is no need for devices to have a direct connection to each other
just to use MultiNode. The shards implementation may require that
though.
> Karsten shared a job example here[1]. This probably is the most
> advanced usage of LAVA
All MultiNode is a complex usage of LAVA but VLANd used by the
networking teams is more complex than your use case.
>, and probably also not encouraged? To make it
> more clear, the connectivity should look like this.
There is a problem in this model: Every DUT will have it's own LXC and
that device will be connected to the LXC using USB.
> master.lxc <----adb over usb----> master.dut
> master.lxc <----adb over tcpip ---> slave1.dut
> master.lxc <----adb over tcpip ---> slave2.dut
Do not separate the LXC from the DUT - the LXC and it's DUT are a single node.
Master DUT has a master LXC.
Slave1 DUT has a Slave1 LXC
Slave2 DUT has a Slave2 LXC.
Depending on the boards in use, you may be able to configure each DUT,
including the master DUT, to have TCP/IP networking. That then allows
the processes running in the Master node to access the slave nodes.
(The following model is based on a theoretical device which doesn't
have the crippling USB OTG problem of the hikey - but the hikey can
work in this model if the IP addresses are determined statically and
therefore are available to each slave LXC.)
0: A program executing in the Master LXC which uses USB to send
commands to the master DUT which allow the Master LXC to retrieve the
IP address of the master DUT.
1: That program in the Master LXC then uses the MultiNode API
(lava-send) to declare that IP address to all the slave nodes. This is
equivalent to how existing jobs declare the IP address of the device
when using secondary connections.
2: Each slave node waits for the master-ip-addr message and sets that
value in a program executing in the slave LXC. The slave LXC is
connected to the slave DUT directly using USB so can use this to set
the master IP address, if that is required.
3: Each slave node now runs a program in each slave LXC to connect to
the slave DUT over USB and extract the slave DUT IP address
4: Each slave node then broadcasts that slave-<ID>-ip-addr message, so
the first slave sends slave-1-ip-addr containing an IP address, slave
2 sends slave-2-ip-addr containing a different IP address.
5: The master node is waiting for all of these messages to be sent and
retrieves the values in turn. This information is now available to a
program executing inside the master LXC. This program could use USB to
set these values in the master DUT, if that is required.
6: During this time, all the slave nodes are waiting for the master
node to broadcast another message saying that the work on the master
is complete.
7: Once the master sends the complete message, each slave node picks
up this message from the MultiNode API and the script executing in the
slave LXC then ends the Lava Test Definition and the slave test job
completes.
8: The master can then do some other stuff and then complete.
https://staging.validation.linaro.org/scheduler/job/246447/multinode_defini…https://staging.validation.linaro.org/scheduler/job/246230/multinode_defini…
Don't obsess about the LXC either. With upcoming changes for docker
support, we could remove the presence of the LXC entirely. The LXC
with android devices only exists as a unit of isolation for the
benefit of the dispatcher. It has useful side effects but the reason
for the LXC to exist is to separate the fastboot operations from the
dispatcher operations.
For hikey and it's broken USB OTG support:
0: Each slave test job turns off the USB OTG support once the slave
LXC has deployed all the test image files and determined that the
slave DUT has booted correctly. If not, use lava-test-raise.
1: Next, each slave LXC uses the IP address of it's own slave DUT to
check connectivity. If this fails, use lava-test-raise.
2: Each slave LXC uses the MultiNode API to declare the IP address of
the slave DUT (because the slave node has determined that this IP is
working).
3: The master node is waiting for these messages and these are picked
up by the master LXC test definition.
4: The master LXC test definition issues commands to the master DUT -
now depending on how the sharding works, this could be over USB (turn
the USB OTG off later) or over TCP/IP (turn off the master USB OTG at
the start of this test definition).
5: The master DUT has enough information to drive the sharding across
the slave DUTs. The slave LXCs are waiting for the master to finish
the sharding. (lava-wait)
6: When the master LXC determines that the master DUT has finished the
sharding, then the master LXC sends a message to all the slave nodes
that the test is complete.
7: Each slave node picks up the completion message in the slave LXC
and the test definition finishes.
8: The master node can continue to do other tasks or can also complete
it's test definition.
> ....
>
> I see two options for adb over tcpip.
>
> Option #1: WiFi. adb over wifi can be enabled easily by issuing adb
> cmds from lxc. I am not using it for two reasons.
Agreed, this doesn't need to rely on WiFi.
>
> * WiFi isn't reliable for long cts/vts test run.
> * In Cambridge lab, WiFi sub-network isn't accessible from lxc
> network. Because of security concerns, there is no plan to change
> that.
>
> Option #2: Wired Ethernet. On devices like hikey, we need to run
> 'pre-os-command' in boot action to power off OTG port so that USB
> Ethernet dongle works. Once OTG port is off, lxc has no access to the
> DUT, then test definition should be executed on DUT, right? I am also
> having the following problems to do this.
Before the OTG is switched, all data from the DUT needs to be
retrieved (and set) using the USB connection.
What information you need to set depends on how the sharding works.
The problem, as I see it, is that the slave DUTs have no way to
declare their IP address to the slave LXC once the OTG port is
switched. Therefore, you will need to put in a request for the boards
to have static IP addresses declared in the device dictionary. Then
the OTG can be switched and things become easier because the LXC knows
the IP address and can simply declare that to the MultiNode API so
that the master LXC can know which IP matches which node. There are
already a number of hikey devices with the static_ip device tag and
you can specify this device tag in your MultiNode test definition.
>
> * Without context overriding, overlay tarball will be applied to
> '/system' directory and test job reported "/system/bin/sh:
Why are you talking about /system ??? MultiNode only operates in a
POSIX shell - the POSIX shell is in the LXC and each DUT has a
dedicated LXC. In this use case, MultiNode API calls are only going to
be made from each LXC. The master LXC sends some information and then
receives information from test definitions running in each of the
slave LXCs.
The overlay is to be deployed to the LXC, not the DUT because this is
an Android system. What the android system does is determined either
by commands run inside the slave LXC to deploy files (before the OTG
switch) or commands run inside the master LXC (with knowledge of the
IP address from the MultiNode API) to execute commands on the DUT over
TCP/IP.
Use the LXC to deploy the files and boot the device, then to declare
information about each particular node. Once that is done, whatever
thing is controlling the test needs to just use TCP/IP to communicate
and use the MultiNode API to send messages and allow some nodes to
wait for other nodes whilst the test proceeds.
> /lava-247856/bin/lava-test-runner: not found"[2].
> * With the following job context, LAVA still runs
> '/lava-24/bin/lava-test-runner /lava-24/0' and it hangs there. It is
> tested in my local LAVA instance, test job definition and test log
> attached. Maybe my understanding on the context overriding is wrong, I
> thought LAVA should execute '/system/lava-24/bin/lava-test-runner
> /system/lava-24/0' instead. Any suggestions would be appreciated.
>
> context:
> lava_test_sh_cmd: '/system/bin/sh'
> lava_test_results_dir: '/system/lava-%s'
>
> I checked on the DUT directly, '/system/lava-%s' exist, but I cannot
> really run lava-test-runner. The shebang line seems problematic.
>
> --- hacking ---
> hikey:/system/lava-24/bin # ./lava-test-runner
> /system/bin/sh: ./lava-test-runner: No such file or directory
> hikey:/system/lava-24/bin # cat lava-test-runner
> #!/bin/bash
>
> #!/bin/sh
>
> ....
> # /system/bin/sh lava-test-runner
> lava-test-runner[18]: .: /lava/../bin/lava-common-functions: No such
> file or directory
> --- ends ---
>
> I had a discussion with Milosz. He proposed the third option which
> probably will be the most reliable one, but it is not supported in
> LAVA yet. Here is the idea. Milosz, feel free to explain more.
>
> **Option #3**: Add support for accessing to multiple DUTs in single node job.
>
> * Physically, we need the DUTs connected via USB cable to the same dispatcher.
I don't see that this solves anything and it adds a lot of unnecessary
lab configuration - entirely duplicating the point of having ethernet
connections to the boards. Assign static IP addresses to each board
and when the test job starts, each dedicated LXC can declare the
static information according to whichever board was assigned to
whichever node.
The DUTs only need to be visible to programs running on the master
node and that can be done by declaring static IP addresses using the
MultiNode API.
> * In single node job, LAVA needs to add the DUTs specified(somehow) or
> assigned randomly(lets say both device type and numbers defined) to
> the same lxc container. Test definitions can take over from here.
No - the LXC is used to issue commands to deploy test images to the
DUT. The LXC is a transparent part of the dispatcher, it is not just
for test definitions. The LXC cannot be used for multiple test jobs,
it is part of the one dispatcher.
>
> Is this can be done in LAVA? Can I require the feature? Any
> suggestions on the possible implementations?
>
>
> Thanks,
> Chase
>
> [1] https://review.linaro.org/#/c/qa/test-definitions/+/29417/4/automated/andro…
> [2] https://staging.validation.linaro.org/scheduler/job/247856#L1888
> _______________________________________________
> Lava-users mailing list
> Lava-users(a)lists.lavasoftware.org
> https://lists.lavasoftware.org/mailman/listinfo/lava-users
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
------------------------------
Message: 3
Date: Thu, 24 Jan 2019 15:09:58 +0000
From: Neil Williams <neil.williams(a)linaro.org>
To: cnspring2002 <cnspring2002(a)aliyun.com>
Cc: lava-users(a)lists.lavasoftware.org
Subject: Re: [Lava-users] reboot during test
Message-ID:
<CAC6CAR3fV+b1p5T2EVxUCPP7d=Erno-20MNVxPaZPVf3tbK3Yg(a)mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Thu, 24 Jan 2019 at 12:13, cnspring2002 <cnspring2002(a)aliyun.com> wrote:
>
> Dear all,
>
> In test stage, I have a case, when it run, one firmware OOM. So I trigger the device to reboot, Then all left case cannot run . I can not use multiple boot when define job in advance because I can not predict which case will make OOM, what you suggest doing?
The out of memory killer is a fatal device error. The test job is not
going to be able to continue because the failure mode is
unpredictable.
The cause of the OOM needs to be determined through standard triage,
not automation. (Although automation may help create a data matrix of
working and failing combinations and test operations.)
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
------------------------------
Message: 4
Date: Fri, 25 Jan 2019 15:45:56 +0800
From: Chase Qi <chase.qi(a)linaro.org>
To: Neil Williams <neil.williams(a)linaro.org>
Cc: lava-users(a)lists.lavasoftware.org
Subject: Re: [Lava-users] AOSP multiple node job
Message-ID:
<CADzYPRFJiX8qKt_NyHZCi0qs5iotx0wg0OMN9o7SOi84sYYTow(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Neil,
Thanks a lot for your guidance. It is really good to see you back :)
On Thu, Jan 24, 2019 at 11:07 PM Neil Williams <neil.williams(a)linaro.org> wrote:
>
> On Thu, 24 Jan 2019 at 11:41, Chase Qi <chase.qi(a)linaro.org> wrote:
> >
> > Hi,
> >
> > In most cases, we don't need multiple node job as we can control AOSP
> > DUT from lxc via adb over USB. However, here is the use case.
> >
> > CTS/VTS tradefed-shell --shards option supports to split tests and run
> > them on multiple devices in parallel. To leverage the feature in LAVA,
> > we need multinode job, right?
>
> If more than one device needs to have images deployed and booted
> specifically for this test job, then yes. MultiNode is required. To be
> sure that each device is at the same stage (as deploy and boot timings
> can vary), the test job will need to wait for all test jobs to be
> synchronised to the same point in each test job - synchronisation is
> currently restricted to POSIX shells.
>
> > And in multinode job, master-node lxc
> > needs access to DUTs from salve nodes via adb over tcpip, right?
>
> Not necessarily. From the LXC, the device can be controlled using USB.
> There is no need for devices to have a direct connection to each other
> just to use MultiNode. The shards implementation may require that
> though.
CTS/VTS sharding shards a run into given number of independent chunks,
to run on multiple devices that connected to the same host. The host
will be the master lxc in our case.
>
> > Karsten shared a job example here[1]. This probably is the most
> > advanced usage of LAVA
>
> All MultiNode is a complex usage of LAVA but VLANd used by the
> networking teams is more complex than your use case.
>
> >, and probably also not encouraged? To make it
> > more clear, the connectivity should look like this.
>
> There is a problem in this model: Every DUT will have it's own LXC and
> that device will be connected to the LXC using USB.
>
> > master.lxc <----adb over usb----> master.dut
> > master.lxc <----adb over tcpip ---> slave1.dut
> > master.lxc <----adb over tcpip ---> slave2.dut
>
> Do not separate the LXC from the DUT - the LXC and it's DUT are a single node.
>
> Master DUT has a master LXC.
> Slave1 DUT has a Slave1 LXC
> Slave2 DUT has a Slave2 LXC.
>
> Depending on the boards in use, you may be able to configure each DUT,
> including the master DUT, to have TCP/IP networking. That then allows
> the processes running in the Master node to access the slave nodes.
>
Yes, that is what I am trying to do. The above connectivity topology I
wrote is the goal not the initial state with LAVA design. Master lxc
needs access to all the DUT nodes, either via USB or tcpip.
> (The following model is based on a theoretical device which doesn't
> have the crippling USB OTG problem of the hikey - but the hikey can
> work in this model if the IP addresses are determined statically and
> therefore are available to each slave LXC.)
>
> 0: A program executing in the Master LXC which uses USB to send
> commands to the master DUT which allow the Master LXC to retrieve the
> IP address of the master DUT.
>
> 1: That program in the Master LXC then uses the MultiNode API
> (lava-send) to declare that IP address to all the slave nodes. This is
> equivalent to how existing jobs declare the IP address of the device
> when using secondary connections.
>
> 2: Each slave node waits for the master-ip-addr message and sets that
> value in a program executing in the slave LXC. The slave LXC is
> connected to the slave DUT directly using USB so can use this to set
> the master IP address, if that is required.
>
> 3: Each slave node now runs a program in each slave LXC to connect to
> the slave DUT over USB and extract the slave DUT IP address
>
> 4: Each slave node then broadcasts that slave-<ID>-ip-addr message, so
> the first slave sends slave-1-ip-addr containing an IP address, slave
> 2 sends slave-2-ip-addr containing a different IP address.
>
> 5: The master node is waiting for all of these messages to be sent and
> retrieves the values in turn. This information is now available to a
> program executing inside the master LXC. This program could use USB to
> set these values in the master DUT, if that is required.
>
> 6: During this time, all the slave nodes are waiting for the master
> node to broadcast another message saying that the work on the master
> is complete.
>
> 7: Once the master sends the complete message, each slave node picks
> up this message from the MultiNode API and the script executing in the
> slave LXC then ends the Lava Test Definition and the slave test job
> completes.
>
> 8: The master can then do some other stuff and then complete.
>
> https://staging.validation.linaro.org/scheduler/job/246447/multinode_defini…
>
> https://staging.validation.linaro.org/scheduler/job/246230/multinode_defini…
>
> Don't obsess about the LXC either. With upcoming changes for docker
> support, we could remove the presence of the LXC entirely. The LXC
> with android devices only exists as a unit of isolation for the
> benefit of the dispatcher. It has useful side effects but the reason
> for the LXC to exist is to separate the fastboot operations from the
> dispatcher operations.
>
> For hikey and it's broken USB OTG support:
>
> 0: Each slave test job turns off the USB OTG support once the slave
> LXC has deployed all the test image files and determined that the
> slave DUT has booted correctly. If not, use lava-test-raise.
>
> 1: Next, each slave LXC uses the IP address of it's own slave DUT to
> check connectivity. If this fails, use lava-test-raise.
>
> 2: Each slave LXC uses the MultiNode API to declare the IP address of
> the slave DUT (because the slave node has determined that this IP is
> working).
>
> 3: The master node is waiting for these messages and these are picked
> up by the master LXC test definition.
>
> 4: The master LXC test definition issues commands to the master DUT -
> now depending on how the sharding works, this could be over USB (turn
> the USB OTG off later) or over TCP/IP (turn off the master USB OTG at
> the start of this test definition).
>
> 5: The master DUT has enough information to drive the sharding across
> the slave DUTs. The slave LXCs are waiting for the master to finish
> the sharding. (lava-wait)
>
> 6: When the master LXC determines that the master DUT has finished the
> sharding, then the master LXC sends a message to all the slave nodes
> that the test is complete.
>
> 7: Each slave node picks up the completion message in the slave LXC
> and the test definition finishes.
>
> 8: The master node can continue to do other tasks or can also complete
> it's test definition.
>
>
> > ....
> >
> > I see two options for adb over tcpip.
> >
> > Option #1: WiFi. adb over wifi can be enabled easily by issuing adb
> > cmds from lxc. I am not using it for two reasons.
>
> Agreed, this doesn't need to rely on WiFi.
>
> >
> > * WiFi isn't reliable for long cts/vts test run.
> > * In Cambridge lab, WiFi sub-network isn't accessible from lxc
> > network. Because of security concerns, there is no plan to change
> > that.
> >
> > Option #2: Wired Ethernet. On devices like hikey, we need to run
> > 'pre-os-command' in boot action to power off OTG port so that USB
> > Ethernet dongle works. Once OTG port is off, lxc has no access to the
> > DUT, then test definition should be executed on DUT, right? I am also
> > having the following problems to do this.
>
> Before the OTG is switched, all data from the DUT needs to be
> retrieved (and set) using the USB connection.
>
> What information you need to set depends on how the sharding works.
>
> The problem, as I see it, is that the slave DUTs have no way to
> declare their IP address to the slave LXC once the OTG port is
> switched. Therefore, you will need to put in a request for the boards
That is the problem I had. And that is why I was trying to run test
definition on Android DUT directly to enable adb over tcpip and
declare IP address. As you mentioned below, it is the wrong direction.
> to have static IP addresses declared in the device dictionary. Then
> the OTG can be switched and things become easier because the LXC knows
> the IP address and can simply declare that to the MultiNode API so
> that the master LXC can know which IP matches which node. There are
> already a number of hikey devices with the static_ip device tag and
> you can specify this device tag in your MultiNode test definition.
Brilliant and brand new idea to me. I didn't realize static-ip tag is
the solution. I have managed to enable and test adb over tcpip in this
way(In my local instance). I have attached my test job definition here
in case it is any help for other LAVA users. The following definitions
are essential.
tags:
- static-ip
reboot_to_fastboot: false
- test:
namespace: tlxc
timeout:
minutes: 10
protocols:
lava-lxc:
- action: lava-test-shell
request: pre-os-command
timeout:
minutes: 2
Thanks,
Chase
>
> >
> > * Without context overriding, overlay tarball will be applied to
> > '/system' directory and test job reported "/system/bin/sh:
>
> Why are you talking about /system ??? MultiNode only operates in a
> POSIX shell - the POSIX shell is in the LXC and each DUT has a
> dedicated LXC. In this use case, MultiNode API calls are only going to
> be made from each LXC. The master LXC sends some information and then
> receives information from test definitions running in each of the
> slave LXCs.
>
> The overlay is to be deployed to the LXC, not the DUT because this is
> an Android system. What the android system does is determined either
> by commands run inside the slave LXC to deploy files (before the OTG
> switch) or commands run inside the master LXC (with knowledge of the
> IP address from the MultiNode API) to execute commands on the DUT over
> TCP/IP.
>
> Use the LXC to deploy the files and boot the device, then to declare
> information about each particular node. Once that is done, whatever
> thing is controlling the test needs to just use TCP/IP to communicate
> and use the MultiNode API to send messages and allow some nodes to
> wait for other nodes whilst the test proceeds.
>
> > /lava-247856/bin/lava-test-runner: not found"[2].
> > * With the following job context, LAVA still runs
> > '/lava-24/bin/lava-test-runner /lava-24/0' and it hangs there. It is
> > tested in my local LAVA instance, test job definition and test log
> > attached. Maybe my understanding on the context overriding is wrong, I
> > thought LAVA should execute '/system/lava-24/bin/lava-test-runner
> > /system/lava-24/0' instead. Any suggestions would be appreciated.
> >
> > context:
> > lava_test_sh_cmd: '/system/bin/sh'
> > lava_test_results_dir: '/system/lava-%s'
> >
> > I checked on the DUT directly, '/system/lava-%s' exist, but I cannot
> > really run lava-test-runner. The shebang line seems problematic.
> >
> > --- hacking ---
> > hikey:/system/lava-24/bin # ./lava-test-runner
> > /system/bin/sh: ./lava-test-runner: No such file or directory
> > hikey:/system/lava-24/bin # cat lava-test-runner
> > #!/bin/bash
> >
> > #!/bin/sh
> >
> > ....
> > # /system/bin/sh lava-test-runner
> > lava-test-runner[18]: .: /lava/../bin/lava-common-functions: No such
> > file or directory
> > --- ends ---
> >
> > I had a discussion with Milosz. He proposed the third option which
> > probably will be the most reliable one, but it is not supported in
> > LAVA yet. Here is the idea. Milosz, feel free to explain more.
> >
> > **Option #3**: Add support for accessing to multiple DUTs in single node job.
> >
> > * Physically, we need the DUTs connected via USB cable to the same dispatcher.
>
> I don't see that this solves anything and it adds a lot of unnecessary
> lab configuration - entirely duplicating the point of having ethernet
> connections to the boards. Assign static IP addresses to each board
> and when the test job starts, each dedicated LXC can declare the
> static information according to whichever board was assigned to
> whichever node.
>
> The DUTs only need to be visible to programs running on the master
> node and that can be done by declaring static IP addresses using the
> MultiNode API.
>
> > * In single node job, LAVA needs to add the DUTs specified(somehow) or
> > assigned randomly(lets say both device type and numbers defined) to
> > the same lxc container. Test definitions can take over from here.
>
> No - the LXC is used to issue commands to deploy test images to the
> DUT. The LXC is a transparent part of the dispatcher, it is not just
> for test definitions. The LXC cannot be used for multiple test jobs,
> it is part of the one dispatcher.
>
> >
> > Is this can be done in LAVA? Can I require the feature? Any
> > suggestions on the possible implementations?
> >
> >
> > Thanks,
> > Chase
> >
> > [1] https://review.linaro.org/#/c/qa/test-definitions/+/29417/4/automated/andro…
> > [2] https://staging.validation.linaro.org/scheduler/job/247856#L1888
> > _______________________________________________
> > Lava-users mailing list
> > Lava-users(a)lists.lavasoftware.org
> > https://lists.lavasoftware.org/mailman/listinfo/lava-users
>
>
>
> --
>
> Neil Williams
> =============
> neil.williams(a)linaro.org
> http://www.linux.codehelp.co.uk/
Dear all,
In test stage, I have a case, when it run, one firmware OOM. So I trigger the device to reboot, Then all left case cannot run . I can not use multiple boot when define job in advance because I can not predict which case will make OOM, what you suggest doing?
Hello list,
Apologies if this question has been asked already. I have a test framework which spits out a junit file.
What’s the best way to import data from the junit file into LAVA?
Cheers
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
we have the need to perform tests that require reboots of the DUT between their executions. Few examples are to check rootfs upgrades or to check configurations changes to persist .
I have few questions:
* Does LAVA support those cases?
* If yes, does LAVA support multiple reboots?
* If yes, how can I write tests in order to run different sets of tests at any boot.
* Example: 1) do an upgrade 2) reboot the device 3) Check if the upgrade was successful
* How can I structure my pipeline?
Thanks
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
>
> When Lava start test or finish the test job, squad zmq SUB socket seems
> not receive log message from lava-server.
>
> It just print out '[2019-01-22 08:26:24 +0000] [DEBUG]
> nexell.lava.server2: connected to tcp://192.168.1.20:2222:5500'.
>
The url is really strange as two port numbers are specified. Should be
"tcp://192.168.1.20:5500"
Rgds
--
Rémi Duraffort
LAVA Team, Linaro
Hello,
we have the need to perform tests that require reboots of the DUT between their executions. Few examples are to check rootfs upgrades or to check configurations changes to persist .
I have few questions:
* Does LAVA support those cases?
* If yes, does LAVA support multiple reboots?
* If yes, how can I write tests in order to run different sets of tests at any boot.
* Example: 1) do an upgrade 2) reboot the device 3) Check if the upgrade was successful
* How can I structure my pipeline?
Thanks
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Dear Lava users,
I'm trying to create a job that performs the following steps :
Deploy to flasher our custom tool (OK)
Boot in bootloader mode - u-boot (OK)
Test in interactive mode (OK)
From interactive mode start kernel (OK)
Launch a test from kernel (KO)
The last part fails because I don't know where to check the kernel prompt. I cannot add a boot stage and declare an additional prompt because I don't want to reboot, that would reset the configuration done in interactive mode.
Do you have any piece of advice or example of job showing how to proceed to manage the kernel prompt & autologin in such a job?
Best regards,
Denis
Hello,
A request from some Lava users internally.
We have 3 boot stages, TF-A, U-boot, and kernel.
Is there a way, in a Lava job, to test that these components' versions are the expected ones?
That would mean, as far as I understand, not testing the embedded software itself, but the Lava job log...
Best regards,
Denis
Two questions here:
1. If a master-only instance here, how to upgrade without data loss?
2. If a slave-only instance here, how to upgrade without data loss?
Please suggest, thanks.
Hello,
the lava-dispatcher package installs a file in /etc/modules-load.d/lava-modules.conf, containing the following lines:
install ipv6 modprobe ipv6
install brltty /bin/false
On my debian 9.3 system, this file leads to failures when the systemd-modules-load service starts:
Job for systemd-modules-load.service failed because the control process exited with error code.
See "systemctl status systemd-modules-load.service" and "journalctl -xe" for details.
The details in journalctl say:
Jan 07 15:08:30 a048 systemd[1]: Starting Load Kernel Modules...
-- Subject: Unit systemd-modules-load.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit systemd-modules-load.service has begun starting up.
Jan 07 15:08:30 a048 systemd-modules-load[2088]: Failed to find module 'install ipv6 modprobe ipv6'
Jan 07 15:08:30 a048 systemd-modules-load[2088]: Failed to find module 'install brltty /bin/false'
Jan 07 15:08:30 a048 systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
Jan 07 15:08:30 a048 systemd[1]: Failed to start Load Kernel Modules.
Obviously the "install" syntax is supported only in /etc/modprobe.d:
https://manpages.debian.org/stretch/kmod/modprobe.d.5.en.html
But not in /etc/modules-load.d:
https://manpages.debian.org/stretch/systemd/modules-load.d.5.en.html
Is this a known issue?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Folks,
We have the need to run some tests which requires a process off DUT to be executed.
Examples are:
* port scan like process against the DUT
* cli tests which interact with the DUT
The workflow could be like:
* Deploy the DUT
* Boot the DUT
* Run a process off DUT (actual test)
* Collect test results
In our setup we assume there is always a network connection between the DUT and the LAVA dispatcher.
How can we achieve such workflow with LAVA?
Cheers
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Dear all,
I need to get "jobs logs" using lavacli. To do that, I use the following command : lavacli jobs logs <job_id>
I can perform this operation with a user that has a profile "superuser".
We have also users with restricted permissions ( they can only submit jobs using lavacli ), and I would like them
to get logs using lavacli.
So, I have consulted in the Lava django administration page, the users permission that can be set, but I could not find
which option could allow a "basic user" to get log jobs using lavacli.
Is it possible to allow a user with "basic profile" to do that ?
If yes, with user permission have to be set ?
Best regards
Philippe Begnic
Just use the sample command "python zmq_client.py -j 357 --hostname tcp://127.0.0.1:5500 -t 1200"
Get the error:
Traceback (most recent call last):
File "zmq_client_1.py", line 155, in <module>
main()
File "zmq_client_1.py", line 139, in main
publisher = lookup_publisher(options.hostname, options.https)
File "zmq_client_1.py", line 109, in lookup_publisher
socket = server.scheduler.get_publisher_event_socket()
File "/usr/lib/python3.5/xmlrpc/client.py", line 1092, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python3.5/xmlrpc/client.py", line 1432, in __request
verbose=self.__verbose
File "/usr/lib/python3.5/xmlrpc/client.py", line 1134, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib/python3.5/xmlrpc/client.py", line 1146, in single_request
http_conn = self.send_request(host, handler, request_body, verbose)
File "/usr/lib/python3.5/xmlrpc/client.py", line 1259, in send_request
self.send_content(connection, request_body)
File "/usr/lib/python3.5/xmlrpc/client.py", line 1289, in send_content
connection.endheaders(request_body)
File "/usr/lib/python3.5/http/client.py", line 1103, in endheaders
self._send_output(message_body)
File "/usr/lib/python3.5/http/client.py", line 934, in _send_output
self.send(msg)
File "/usr/lib/python3.5/http/client.py", line 877, in send
self.connect()
File "/usr/lib/python3.5/http/client.py", line 849, in connect
(self.host,self.port), self.timeout, self.source_address)
File "/usr/lib/python3.5/socket.py", line 694, in create_connection
for res in getaddrinfo(host, port, 0, SOCK_STREAM):
File "/usr/lib/python3.5/socket.py", line 733, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known
I wonder for following code, why http://tcp://127.0.0.1:5500/RPC2 will finally be passed to ServerProxy?
If I remove http, just tcp://127.0.0.1:5500/RPC2, it will say "OSError: unsupported XML-RPC protocol"
If I remove tcp, just http://127.0.0.1:5500/RPC2, it will hang in get_publisher_event_socket
I use 2018.11 version, please suggest!!!
xmlrpc_url = "http://%s/RPC2" % (hostname)
if https:
xmlrpc_url = "https://%s/RPC2" % (hostname)
server = xmlrpc.client.ServerProxy(xmlrpc_url)
try:
socket = server.scheduler.get_publisher_event_socket()
I am trying to submit test job using squad.
When squad fetch the result of lava, the interval is too long.
It takes at least 1 hour. I want to reduce fetch time as short as possible.
This is what Squad team answer.
Alternatively you can turn on ZMQ notifications in LAVA and run squad
listener. This will cause test results to be fetched immediately after
the test job finishes in LAVA. Enabling ZMQ publisher:
https://master.lavasoftware.org/static/docs/v2/advanced-installation.html#c….
SQUAD listener is a separate process. It doesn't need any additional
settings on top of what you already have.
So I want to try restart lava-publisher service.
I am running lava-server and dispatcher using Linaro lava docker image.
On docker container, there is no service named lava-publisher.
How can I manage this?
Thanks.
Hello,
Our LAVA deployment has both RPi3 B and B+ and we are interested only on the 32bit version. The device type to use looks like:
https://git.lavasoftware.org/lava/lava/blob/master/lava_scheduler_app/tests…
Does this device type cover both B and B+? I mean, can we use it for B+ as well?
If yes, what's the best way to differentiate those on LAVA? Creating a new device type for B+ (which is the same of the above) or using tags?
Thanks
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi,
I've been using the lava-server docker image (hub.lavasoftware.org/lava/lava/lava-server:2018.10) for a couple of weeks and I had some problems on making the data persistent for the postgres (mapping the volume from host to container). Anyways I decided to take postgres out from the startup by modifying the entrypoint.sh file:
++++++++++++++ Added these lines after start_lava_server_gunicorn -function ++++++++++++++++++++++++++
if [[ ! -z $DJANGO_POSTGRES_SERVER ]]; then
txt="s/LAVA_DB_SERVER=\"localhost\"/LAVA_DB_SERVER=\"$DJANGO_POSTGRES_SERVER\"/g"
sed -i $txt /etc/lava-server/instance.conf
fi
if [[ ! -z $DJANGO_POSTGRES_PORT ]]; then
txt="s/LAVA_DB_PORT=\"5432\"/LAVA_DB_PORT=\"$DJANGO_POSTGRES_PORT\"/g"
sed -i $txt /etc/lava-server/instance.conf
fi
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
---------------------------- Commented out these lines -----------------------------
# Start all services
#echo "Starting postgresql"
#/etc/init.d/postgresql start
#echo "done"
#echo
#echo "Waiting for postgresql"
#wait_postgresql
#echo "[done]"
#echo
-------------------------------------------- ----------------------------------------------------
After that I created a new Dockerfile and built a new image:
+++++++++++++++++++++++++ Dockerfile +++++++++++++++++++++++
FROM hub.lavasoftware.org/lava/lava/lava-server:2018.10
COPY ./entrypoint.sh /root/
RUN chmod 755 /root/entrypoint.sh
ENTRYPOINT ["/root/entrypoint.sh"]
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> sudo docker build -t lava-server:mod .
Just to get all up and running I made a docker-compose.yml file to kick postgres and lava-server up
+++++++++++++++++++++++++++ docker-compose.yml +++++++++++++++++++++++++
version: '3'
services:
postgres:
image: postgres:11
restart: always
environment:
POSTGRES_DB: lavaserver
POSTGRES_USER: lavaserver
POSTGRES_PASSWORD: d3e5d13fa15f
lava-server:
depends_on:
- postgres
image: lava-server:mod
environment:
DJANGO_POSTGRES_PORT: 5432
DJANGO_POSTGRES_SERVER: postgres
ports:
- "80:80"
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I still feel that there is too much going on inside that lava-server:mod image, since it has following softwares running:
* Lavamaster
* Gunicorn
* Logger
* Publisher
What do you think, should I still break it into smaller pieces? Pros on this would be that softwares wouldn't die silently (started by using '&' and docker could try to restart them), logs would be in their own logs windows' (docker log CONTAINER) and containers themselves would be more configurable via environment variables.
Br
Olli Väinölä
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Wed, 16 Jan 2019 at 17:33, Steve McIntyre <steve.mcintyre(a)linaro.org> wrote:
>
> Hi,
>
> In founding the LAVA Software Community Project, the team planned to
> open up LAVA development more. As already announced by Neil in
> September, we have already moved our infrastructure to a GitLab
> instance and LAVA developers and users can collaborate there. [1]
>
> The next step in our process is to also open our regular development
> design meetings to interested developers. The LAVA design meeting is
> where the team gets together to work out deep technical issues, and to
> agree on future development goals and ideas. We run these as a weekly
> video conference using Google Hangouts Meet [2], We now wish to
> welcome other interested developers to join us there too, to help us
> develop LAVA.
Steve, the only missing bit is which day and what time? :)
milosz
>
> Summaries of the meetings will be posted regularly to the lava-devel
> mailing list [3], and we encourage interested people to subscribe and
> discuss LAVA development there.
>
> [1] https://git.lavasoftware.org/
> [2] https://meet.google.com/qre-rgen-zwc
> [3] https://lists.lavasoftware.org/mailman/listinfo/lava-devel
>
> Cheers,
> --
> Steve McIntyre steve.mcintyre(a)linaro.org
> <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
> _______________________________________________
> Lava-announce mailing list
> Lava-announce(a)lists.lavasoftware.org
> https://lists.lavasoftware.org/mailman/listinfo/lava-announce
Hi everyone,
I want to change the default path of MEDIA_ROOT and ARCHIVE_ROOT.
So in /etc/lava-server-settings.conf I wrote this :
"MEDIA_ROOT": "/data/lava/var/lib/lava-server/default/media",
"ARCHIVE_ROOT": "/data/lava/var/lib/lava-server/default/archive",
This seems to work but the web UI doesn't display the job output and when I
try to download
the plain log, it returns an error saying it can't be found.
Could you tell me what should I do to make the web ui find the job outputs ?
Best regards,
Axel
In the thread about Git Authentication a solution was proposed using git credentials and the fact that the dispatcher is running as root.
See: https://lists.lavasoftware.org/pipermail/lava-users/2018-December/001455.ht…
I've worked out that even though the dispatcher is running as root, the environment is purged based upon env.yaml that is sent over from the master.
I found that I had to add HOME=/root into env.yaml on the master for the git clone to pick up the files in the /root folder.
Hope this helps anyone else trying to do this.
Pete
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Dear Remi,
I ran those commands you suggested in lava shell and it printed as below :
Python 3.5.3 (default, Jan 19 2017, 14:11:04)
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.contrib.sites.models import Site
>>> Site.objects.all()
<QuerySet [<Site: 192.168.100.103>]>
>>> Site.objects.count()
1
>>>
Dear all,
I was encountered with a login in issue . I've changed domain name and display name to IP , but when I relogin now, I can't reach login page , and it reports as below :
500 Internal Server ErrorSite matching query does not exist.
Oops, something has gone wrong!
And I set 'DEBUG = True' in settings.conf , and it reported like below :
DoesNotExist at /accounts/login/
Site matching query does not exist.
| Request Method: | GET |
| Request URL: | http://127.0.0.1:8000/accounts/login/?next=/scheduler/job/42 |
| Django Version: | 1.11.14 |
| Exception Type: | DoesNotExist |
| Exception Value: |
Site matching query does not exist.
|
| Exception Location: | /usr/lib/python3/dist-packages/django/db/models/query.py in get, line 380 |
| Python Executable: | /usr/bin/python3 |
| Python Version: | 3.5.3 |
| Python Path: |
['/',
'/usr/bin',
'/usr/lib/python35.zip',
'/usr/lib/python3.5',
'/usr/lib/python3.5/plat-x86_64-linux-gnu',
'/usr/lib/python3.5/lib-dynload',
'/usr/local/lib/python3.5/dist-packages',
'/usr/local/lib/python3.5/dist-packages/icsectl-0.2-py3.5.egg',
'/usr/lib/python3/dist-packages']
|
So I just wanna know how can I set it back?
Yours , sincerely
Su Chuan
Hello LAVA mailing list,
I see RPI3 is supported by LAVA but unfortunately it doesn't fit Mbed Linux OS (MBL) case. Our build system produces a WIC image which can be written on the SD card directly (instructions here: https://os.mbed.com/docs/linux-os/v0.5/getting-started/writing-and-booting-…).
This is needed for two main reasons:
* MBL has its own booting flow
* MBL expects a partition layout (not only the rootfs) with multiple partitions in order to work.
What's the best way to automate the deployment on MBL on RPI3 via LAVA in order to run our tests?
Cheers
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
https://fosdem.org/2019/
(No registration is necessary for FOSDEM - if you can get to Brussels,
you are welcome to just turn up on site. Avoid trying to park near the
site unless you get there very early, use public transport.)
https://fosdem.org/2019/practical/https://fosdem.org/2019/stands/
If you haven't been to FOSDEM before, note that there will be a huge
number of people attending FOSDEM (well over 8,000 are expected), so
the only real chance of meeting up is to have a known meeting point.
Hopefully, you'll have a chance to get to some of the 700 sessions
which have been arranged over the 2 days.
Linaro will have a stand at FOSDEM 2019 in the AW building. The stand
will be on the ground floor, along the corridor from AW120 near
MicroPython and PINE64. Various Linaro and LAVA people will be around
the stand during the event, so this can act as a focal point for
anyone wanting to talk about Linaro and or LAVA during FOSDEM.
https://fosdem.org/2019/schedule/room/aw1120/
The AW building is near the car park, across from Janson and the H building.
Various Linaro and LAVA people have been routinely attending FOSDEM
for a number of years. If you are able to get there, we will be happy
to see you.
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
Hi lava team,
I want to use lava for running shell scripts on several devices which are connected to the lava server via ssh.
Is there a way to deploy the overlay to another directory than "/"?
Example:
The overlay is downloaded to /lava-123.tar.gz and extracted to /lava-123 by default.
What if my rootfs "/" is read-only and I want to download and extract the overlay to /tmp or /data, which are read-write mounted?
Best regards,
Christoph
Hi,
I have some test files stored in a private GIT repository. As I understand it there is no easy way to get the authentication passed through to the Test Definition, so I am looking for other options.
Is there a way that I can write the Test Definition to reference the files elsewhere?
I can bundle them into a tarball or zipfile and have them served via http without the need for authentication, but I cannot figure out how to describe this in the Test Definition.
Thanks.
Pete
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello,
What is the rationale to ignore individual lava-test-case results when running a health check jobs?
For example, the following job failed one case: https://validation.linaro.org/scheduler/job/1902316
A failing test case can be an indication of device malfunction (e.g. out of disk space, hw issues). Is it possible to force LAVA to fail a health check and thus put device in a "bad" state if one of the test cases is not successful?
Thanks,
Andrei Narkevitch
Cypress Semiconductors
This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.
After setup a master & a worker, I add this worker to this master, also add device to this worker.
Then submit this job, the web page just show the task is in the status "Submit".
The same configures seems work on my local machine(with master & worker on the same machine)
I cannot find the root cause as job's device-type which the device have is idle & the health is good.
For such kind of issue, any way to debug? I mean if any log I can find for why lava cannot dispatch the task with its 20 seconds poll?
Hello,
please keep the mailing-list in copy when replying.
thanks for your help . I will discuss two questions (1. Change site
> issue ; 2 secure boot mode ; ) in this reply.
> 1) Change site issue : We changed both 'display name' and
> 'display name' (example.com ) to IP address , and now we found that we
> couldn't login in , when we pressed login in link on home page , it
> reported as below:
>
>
> *500 Internal Server Error**Site matching query does not exist.*
>
> *Oops, something has gone wrong! *
>
That's really strange. Could you update /etc/lava-server/settings.conf to
set "DEBUG" to true, restart lava-server-gunicorn, refresh the page and
send back the stack trace.
Keep in mind that settings.conf is a json file, so check that the syntax is
valid json.
> 2) secure boot mode : at present , we solved it by utilizing
> ''ramdisk" key words and forcing it not to decompress utee file , but we
> don't know if we will utilize this key words in the future , so maybe it's
> not a good solution. If we find any better solution after we reviews all
> source codes ,we will submit it !
>
Right.
Rgds
--
Rémi Duraffort
Dear all,
I'm trying booting my devices under test in a secure boot mode , which means i have to download dtb、kernel 、uTee files and set nfs serverip to mount rootfs in uboot , so there's an extra uTee file . And i checked key words in deploy steps and there was none extra for this action . And we only found 'image' 、’ramdisk‘、'dtb'、'rootfs' in job_templates.py under lava_server directionary . So what should i do to add this action in deploy?
Dear all,
I'm bothered with lava site changing function( at http://10.193.101.30/admin/sites/site/1/change/ , pls change IP address here to yours). When i changed default domain name to IP address and set notification email in my job as below:
notify:
recipients:
- to:
method: email
email: temp(a)163.com
criteria:
status: complete
verbosity: verbose
and then i received messy code as below:
Job details and log file: http://???/scheduler/job/19
So I just don't know what's wrong!
Hi lava team,
I want to use lava for running shell scripts on several devices which are connected to the lava server via ssh.
Is there a way to deploy the overlay to another directory than "/"?
Example:
The overlay is downloaded to /lava-123.tar.gz and extracted to /lava-123 by default.
What if my rootfs "/" is read-only and I want to download and extract the overlay to /tmp or /data, which are read-write mounted?
Best regards,
Christoph
Hi all,
At NXP, we would like the result app to report regressions/progressions
between 2 tests.
We run CTS/VTS job on Android 9, and as we add some features to the OS (DRM
for example), we want to make sure we get the expected behavior. For that,
we need to know exactly which test cases results are different between the
two last jobs. CTS runs about 400 000-500 000 test cases, it's kind of
heavy to process manually.
For example, the result table could show 2 tables, one would be the same it
is atm, and the other would show the list of test cases results that are
different from the previous job.
What do you think about this ? I think this could be useful to everyone.
Should I submit an issue to https://git.lavasoftware.org/lava/lava/ ?
Best regards,
Axel
Im deploying lava using the docker container and I am looking at the
correct paths to mount as volumes as to not lose data between cluster
rollovers. (and to have to backups)
If I change the instance.conf to point to a database that is outside
of the container that gets backed up and includes these paths in my
volume mounts is that all I need to do? Or is there additional
paths/files that should be included.
https://master.lavasoftware.org/static/docs/v2/admin-backups.html
If anyone knows anything about this thanks!
Hi all,
I am running LTP tests through LAVA on a Yocto based system.
If I run a LTP test suite (like syscalls) by directly calling runltp, LAVA will display it as a single TC, with a single PASS/FAIL verdict.
I think the test definition here solves this problem: https://git.linaro.org/qa/test-definitions.git/tree/automated/linux/ltp/ltp…
But couldn't find a job template that makes use of it.
Could you please let me know:
* If this could run on yocto?
* Where to find an example job that makes use of this?
Thanks and regards,
Philippe
Hi, I have a problem for Installing LAVA server and dispatcher using
docker images that Linaro offer.
I installed both two images(server and dispatcher) on my local pc.
When I submit job, submitted job is listed on Lava server.
But it remain the status as 'Submitted' and not change.
When i visit server {local ip address:port number}/scheduler/device/qemu01,
I can see message like below.
Is this mean that health-check job have to be registered before
submitting test job? If then, how to do?
I have looked for the way to figure out this problem, but I couldn't.
Although I tried to disable health check on this device and forced to
change Health as 'Good',
Health status soon change like Good → Bad (Invalid device configuration).
Below is what I did for installing LAVA server and dispatcher.
- LAVA Server
1) Pull docker image and run.
$ |docker pull lavasoftware/lava-server||:2018.11|
||$ docker run -itd --name new_lava_server --cap-add=NET_ADMIN \||
|| -p 9099:80 -p 5557:5555 -p 5558:5556 -h new_lava_server \
||
|| lavasoftware/lava-server||||:2018.11||
||2) Create superuser||
||Create id as admin, pw as admin.||
||||
||$ ||||lava-server manage createsuperuser||
||3) Create token||
||Create token for admin account on server web ui.||
4) Add device type and device
$ lava-server manage device-types add qemu
5) Add device dictionary
$ lava-server manage devices add --device-type qemu --worker
new_lava_slave qemu01
- LAVA dispatcher
1) Pull docker image and run.
$ |docker pull lavasoftware/lava-dispatcher||:2018.11|
|$ ||docker run -it --name new_lava_slave \|
|||-||v||/boot||:||/boot||-||v||/lib/modules||:||/lib/modules||-||v||/home/lava-slave/LAVA-TEST||:||/opt/share||\|
|||-||v||/dev/bus/usb||:||/dev/bus/usb||-||v||~/.||ssh||/id_rsa_lava||.pub:||/home/lava/||.||ssh||/authorized_keys||:ro
-||v||/sys/fs/cgroup||:||/sys/fs/cgroup||\|
|||--device=||/dev/ttyUSB0||\|
|||-p 2022:22 -p 5555:5555 -p 5556:5556 \|
|||-h new_lava_slave \|
|||--privileged \|
|||-e LAVA_SERVER_IP=||"192.168.1.44"||\|
|||-e||"LOGGER_URL=tcp://192.168.1.44:5557"||\|
|||-e||"MASTER_URL=tcp://192.168.1.44:5558"||\|
|||-e||"DISPATCHER_HOSTNAME=--hostname=new_lava_slave"||\|
|||lavasoftware||/lava-dispatcher||:2018.11|
|2) Submit job file|
||
$ ./submityaml.py -p -k apikey.txt qemu01.yaml
|Below is submityaml.py python code.|
|apikey.txt file is token created on server.
|
||
#!/usr/bin/python
import argparse
import os.path
import sys
import time
import xmlrpclib
SLEEP = 5
__version__ = 0.5
LAVA_SERVER_IP = "192.168.1.44"
def is_valid_file(parser, arg, flag):
if not os.path.exists(arg):
parser.error("The file %s does not exist!" % arg)
else:
return open(arg, flag) # return an open file handle
def setup_args_parser():
"""Setup the argument parsing.
:return The parsed arguments.
"""
description = "Submit job file"
parser = argparse.ArgumentParser(version=__version__,
description=description)
parser.add_argument("yamlfile", help="specify target job file",
metavar="FILE",
type=lambda x: is_valid_file(parser, x, 'r'))
parser.add_argument("-d", "--debug", action="store_true",
help="Display verbose debug details")
parser.add_argument("-p", "--poll", action="store_true", help="poll
job status until job completes")
parser.add_argument("-k", "--apikey", default="apikey.txt",
help="File containing the LAVA api key")
parser.add_argument("--port", default="9099", help="LAVA/Apache
default port number")
return parser.parse_args()
def loadConfiguration():
global args
args = setup_args_parser()
def loadJob(server_str):
"""loadJob - read the JSON job file and fix it up for future submission
"""
return args.yamlfile.read()
def submitJob(yamlfile, server):
"""submitJob - XMLRPC call to submit a JSON file
returns jobid of the submitted job
"""
# When making the call to submit_job, you have to send a string
jobid = server.scheduler.submit_job(yamlfile)
return jobid
def monitorJob(jobid, server, server_str):
"""monitorJob - added to poll for a job to complete
"""
if args.poll:
sys.stdout.write("Job polling enabled\n")
# wcount = number of times we loop while the job is running
wcount = 0
# count = number of times we loop waiting for the job to start
count = 0
f = open("job_status.txt", "w+")
while True:
status = server.scheduler.job_status(jobid)
if status['job_status'] == 'Complete':
f.write("Complete\n")
break
elif status['job_status'] == 'Canceled':
f.write("Canceled\n")
print '\nJob Canceled'
exit(0)
elif status['job_status'] == 'Submitted':
sys.stdout.write("Job waiting to run for % 2d
seconds\n" % (wcount * SLEEP))
sys.stdout.flush()
wcount += 1
elif status['job_status'] == 'Running':
sys.stdout.write("Job Running for % 2d seconds\n" %
(count * SLEEP))
sys.stdout.flush()
count += 1
else:
f.write("unkonwn status\n")
print "unknown status"
exit(0)
time.sleep(SLEEP)
print '\n\nJob Completed: ' + str(count * SLEEP) + ' s (' +
str(wcount * SLEEP) + ' s in queue)'
def process():
print "Submitting test job to LAVA server"
loadConfiguration()
user = "admin"
with open(args.apikey) as f:
line = f.readline()
apikey = line.rstrip('\n')
server_str = 'http://' + LAVA_SERVER_IP + ":" + args.port
xmlrpc_str = 'http://' + user + ":" + apikey + "@" + LAVA_SERVER_IP
+ ":" + args.port + '/RPC2/'
print server_str
print xmlrpc_str
server = xmlrpclib.ServerProxy(xmlrpc_str)
server.system.listMethods()
yamlfile = loadJob(server_str)
jobid = submitJob(yamlfile, server)
monitorJob(jobid, server, server_str)
if __name__ == '__main__':
process()
|The job file named qemu01.yaml is below.|
||
|# Your first LAVA JOB definition for an x86_64 QEMU
device_type: qemu
job_name: QEMU pipeline, first job
timeouts:
job:
minutes: 15
action:
minutes: 5
connection:
minutes: 2
priority: medium
visibility: public
# context allows specific values to be overridden or included
context:
# tell the qemu template which architecture is being tested
# the template uses that to ensure that qemu-system-x86_64 is executed.
arch: amd64
metadata:
# please change these fields when modifying this job for your own tests.
docs-source: first-job
docs-filename: qemu-pipeline-first-job.yaml
# ACTION_BLOCK
actions:
- deploy:
timeout:
minutes: 5
to: tmpfs
images:
rootfs:
image_arg: -drive format=raw,file={rootfs}
url:
https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz
compression: gz
# BOOT_BLOCK
- boot:
timeout:
minutes: 2
method: qemu
media: tmpfs
prompts: ["root@debian:"]
auto_login:
login_prompt: "login:"
username: root
- test:
timeout:
minutes: 5
definitions:
- repository: http://git.linaro.org/lava-team/lava-functional-tests.git
from: git
path: lava-test-shell/smoke-tests-basic.yaml
name: smoke-tests|
|
|
||
Hello,
I have noticed sometimes when I run healthchecks, LAVA gets stuck when doing a http download of the kernel and ramdisk to run a healthcheck.
For example in [1] there seems to be a 3 min timeout for the deploy images section, but LAVA didn’t pick this up, and was stuck there for 17 hours. After the job was cancelled and the device health was manually set to unknown again, the healthcheck succeeds (eg. job 25 on the same lava instance).
I am running LAVA 2018.7.
[1] https://lava.ciplatform.org/scheduler/job/20
Thanks,
Patryk
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Hello everyone,
I have written a backup script for my LAVA instance. While testing the restore process I stumbled upon issues. Are there any dependencies between the master and workers concerning backups? When the master crashes, but the worker does not, is it safe to restore the master only and keep the worker as it is? Or do I have to keep master and worker backups in sync and always restore both at the same time?
Restoring my master as described in the LAVA docs generally works. The web interface is back online, all the jobs and devices are in consistent states.
Restoring the worker is relatively easy, according to the docs. I installed the LAVA packages in their previous versions on a fresh (virtual) machine, restored /etc/lava-dispatcher/lava-slave and /etc/lava-coordinator/lava-coordinator.conf. The worker has status "online" in the LAVA web interface afterwards, so the communication seems to work.
However, starting a multinode job does not work. The job log says:
lava-dispatcher, installed at version: 2018.5.post1-2~bpo9+1
start: 0 validate
Start time: 2018-12-18 12:25:14.335215+00:00 (UTC)
This MultiNode test job contains top level actions, in order, of: deploy, boot, test, finalize
lxc, installed at version: 1:2.0.7-2+deb9u2
validate duration: 0.01
case: validate
case_id: 112
definition: lava
result: pass
Initialising group b6eb846d-689f-40c5-b193-8afce41883ee
Connecting to LAVA Coordinator on lava-server-vm:3079 timeout=90 seconds.
This comes out in a loop, until the job times out.
The lava-slave logfile says:
2018-12-18 12:27:15,114 INFO master => START(12)
2018-12-18 12:27:15,117 INFO [12] Starting job
[...]
2018-12-18 12:27:15,124 DEBUG [12] dispatch:
2018-12-18 12:27:15,124 DEBUG [12] env : {'overrides': {'LC_ALL': 'C.UTF-8', 'LANG': 'C', 'PATH': '/usr/local/bin:/usr/local/sbin:/bin:/usr/bin:/usr/sbin:/sbin'}, 'purge': True}
2018-12-18 12:27:15,124 DEBUG [12] env-dut :
2018-12-18 12:27:15,129 ERROR [EXIT] 'NoneType' object has no attribute 'send_start_ok'
2018-12-18 12:27:15,129 ERROR 'NoneType' object has no attribute 'send_start_ok'
It is the "job = jobs.create()" call in lava-slave's handle_start() routine which fails. Obviously there is a separate database on the worker (of which I did not know until now), which fails to be filled with values. Does this database have to be backup'ed and restored? What is the purpose of this database? Is there anything I need to know about it concerning backups?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Please make sure you include the mailing list in all replies so that
others know when a problem has been fixed (and how it was fixed)
On Tue, 18 Dec 2018 at 12:00, Chuan Su <lavanxp(a)126.com> wrote:
>
> According to your comments , we checked our setups and we found that we utilized ser2net & telnet to communicate with DUT , however , ser2net set default timeout parameter as 600 seconds . When DUT runs a long duration case (more than 600 seconds ) without any log outputting , the connection is usually dropped by ser2net , and telnet program always prints logs as 'Connection closed by foreign host ' . Anyway thanks for your help !
See https://git.linaro.org/lava/lava-lab.git/tree/shared/server-configs/ser2net…
The Linaro lab in Cambridge sets all the ser2net configs to have a zero timeout.
> Sincerely,
> Chuan Su
>
>
>
>
>
> At 2018-12-18 15:59:00, "Neil Williams" <neil.williams(a)linaro.org> wrote:
> >On Tue, 18 Dec 2018 at 06:16, Chuan Su <lavanxp(a)126.com> wrote:
> >>
> >> Dear all,
> >> We are encountered with an issue that our job always exits halfway when running a long duration test case (around 20 minutes) which outputs nothing , and lava server reports an InfrastructureError error and prints as below :
> >> Connection closed by foreign host.Marking unfinished test run as failed
> >
> >Connection closed by foreign host means that the serial connection
> >failed at the DUT - this is not a problem in the LAVA test job, this
> >is an infrastructure failure at your end. The foreign host (the DUT)
> >closed the serial connection. There is nothing LAVA can do about that.
> >The serial connection to the DUT has simply failed.
> >
> >If the serial connection is USB, check for logs on the worker like
> >/var/log/messages and /var/log/syslog for events related to the serial
> >connection. Check that the DUT didn't simply kill the serial
> >connection - maybe the DUT went into some kind of suspend mode.
> >
> >> definition: lava
> >> result: fail
> >> case: 0_apache-servers1
> >> uuid: 597_1.4.2.4.1
> >> duration: 603.53
> >> lava_test_shell connection dropped.end: 3.1 lava-test-shell (duration 00:10:05) [ns_s1]
> >> namespace: ns_s1
> >> extra: ...
> >> definition: lava
> >> level: 3.1
> >> result: fail
> >> case: lava-test-shell
> >> duration: 604.55
> >> lava-test-retry failed: 1 of 1 attempts. 'lava_test_shell connection dropped.'lava_test_shell connection dropped.
> >>
> >> And we just test it with a very simple python script as below:
> >> #!/usr/bin/env python3
> >> import time
> >> print('Hello,world!')
> >> time.sleep(1200)
> >> print("Hello,Lava!")
> >> We can see 'Hello,world!' string outputs , but there's no more output of this program found on webUI!
> >> We just don't know what's wrong , so we have to mail to you for help!
> >> Sincerely,
> >> Chuan Su
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Lava-users mailing list
> >> Lava-users(a)lists.lavasoftware.org
> >> https://lists.lavasoftware.org/mailman/listinfo/lava-users
> >
> >
> >
> >--
> >
> >Neil Williams
> >=============
> >neil.williams(a)linaro.org
> >http://www.linux.codehelp.co.uk/
>
>
>
>
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
https://git.lavasoftware.org/lava/lava/issues/179
If your Lava-Test Test Definition 1.0 YAML files explicitly use a
parse: block (like:
https://git.linaro.org/qa/test-definitions.git/tree/automated/linux/ltp/ltp…)
then this will remain supported in Definition 1.0.
If you use the monitors or interactive test actions, this does not
affect you at all.
If you rely on LAVA to create a TestCase based on a command in the
Lava-Test Test Definition just echoing "pass" or "fail", then this is
the Default Pattern and this change will directly affect those test
jobs.
The current Default Pattern and Fixup are lifted directly from V1
(https://git.lavasoftware.org/lava/lava/blob/master/lava_common/constants.py…):
# V1 compatibility
DEFAULT_V1_PATTERN =
"(?P<test_case_id>.*-*)\\s+:\\s+(?P<result>(PASS|pass|FAIL|fail|SKIP|skip|UNKNOWN|unknown))"
DEFAULT_V1_FIXUP = {
"PASS": "pass",
"FAIL": "fail",
"SKIP": "skip",
"UNKNOWN": "unknown",
}
We've recently updated the documentation to drop mention of the
default pattern support for the following reasons:
* It has always been problematic to encode a Python regular expression
in YAML. Failures are difficult to debug and patterns are global for
the entire test operation.
* The move towards more portable test definitions puts the emphasis on
parsing the test output locally on the DUT using a customised parser.
This has further advantages:
* The pattern does not have to be mangled into YAML
* The pattern can be implemented by a language other than Python
* The pattern can change during the operation of the test shell,
e.g. a different pattern may be required for setup than for the test
itself.
We are now starting to plan for Lava-Test Test Definition 2.0 with an
emphasis on requiring portable test scripts and removing more of the
lava_test_shell Test Helper scripts. Full information on 2.0 will be
available early in 2019.
As a first step, the generally unhelpful Default Pattern and Default
Fixup dict are likely to be removed. If you need this support, the
pattern can be added to your Lava-Test Test Definition 1.0 YAML files.
In the next release, it is proposed that unless an explicit pattern is
specified in the Lava-Test Test Definition 1.0 YAML file, then no
pattern will be implemented. Processes which echo "pass" or "fail"
would be ignored and no TestCase would be created.
Let us know if there are any thoughts or problems on this proposal.
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
Dear all,
We are encountered with an issue that our job always exits halfway when running a long duration test case (around 20 minutes) which outputs nothing , and lava server reports an InfrastructureError error and prints as below :
Connection closed by foreign host.Marking unfinished test run as failed
definition: lava
result: fail
case: 0_apache-servers1
uuid: 597_1.4.2.4.1
duration: 603.53
lava_test_shell connection dropped.end: 3.1 lava-test-shell (duration 00:10:05) [ns_s1]
namespace: ns_s1
extra: ...
definition: lava
level: 3.1
result: fail
case: lava-test-shell
duration: 604.55
lava-test-retry failed: 1 of 1 attempts. 'lava_test_shell connection dropped.'lava_test_shell connection dropped.
And we just test it with a very simple python script as below:
#!/usr/bin/env python3
import time
print('Hello,world!')
time.sleep(1200)
print("Hello,Lava!")
We can see 'Hello,world!' string outputs , but there's no more output of this program found on webUI!
We just don't know what's wrong , so we have to mail to you for help!
Sincerely,
Chuan Su
Hi everyone,
Is it possible to handle git authentication in a test job ?
I need LAVA to clone a repo that can't be set to public,
and obviously it won't work because of the authentication step.
So is it possible to specify a password or a token ?
Best regards,
Axel
Dear , all
We found that when lava executed a script which may output a long string (more than 30000 bytes) in a line (only one line break), lava web UI always hung and there was no more lava log outputting and devices under test (short for DUT) were still powered until Lava Job time-out function triggered , however, after checked the whole log file we found that cases behind the hanging case were executed (there's new files generated) .
So the problem is that when lava encountered those cases lava web UI always hangs and DUTs may not be powered off when all the cases are completed !
best wishes,
Chuan Su
Dear , all
We found that when lava executed a script which may output a long string (more than 30000 bytes) in a line (only one line break), lava web UI always hung and there was no more lava log outputting and devices under test (short for DUT) were still powered until Lava Job time-out function triggered , however, after checked the whole log file we found that cases behind the hanging case were executed (there's new files generated) .
So the problem is that when lava encountered those cases lava web UI always hangs and DUTs may not be powered off when all the cases are completed !
best wishes,
Chuan Su
On Mon, 11 Dec 2018 at 11:30, Neil Williams <neil.williams at linaro.org> wrote:
> On Tue, 11 Dec 2018 at 11:28, Tim Jaacks <tim.jaacks(a)garz-fricke.com> wrote:
> >
> > Thanks, the CLI operations are very helpful for automating the process.
> > However, the docs say that all devices in "Reserved" state have to
> > have their "current job" cleared. I can use "lava-server manage devices details"
> > to check whether this field is actually set. There is no command to
> > modify it, though. Seems like using the Python API is the only way to
> > go here, right? The same applies to setting "Running" jobs to "Cancelled".
>
> https://git.lavasoftware.org/lava/lava/merge_requests/273
>
> This should get into the upcoming 2018.12 release.
Thank you very much for your quick help. The "lava-server manage jobs fail"
command takes care of clearing the "current job" field of the associated
device, do I understand that right?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hi folks,
We at Fairphone have developed a variant of the Tradefed-runner in LAVA
test-definitions that is meant to run complete Tradefed test suites on
multiple devices by making use of the shards feature in Tradefed. The
runner is currently in “staging” state. We still want to share now what
we are using and developing to see if there are more people with
interest in it. Feedback on the general approach taken would also be
much appreciated.
On the higher level, our setup works as follows:
• Use MultiNode to allocate multiple devices for one test submission.
• One “master” runs the Tradefed shell, similarly as in the
existing runner.
• The master connects to the workers’ DUTs via adb TCP/IP. These
DUTs are transparently available to Tradefed just in the same way as
USB-attached devices.
• Workers ensure that their respective DUTs remain accessible to
the master, especially in case of WLAN disconnects, reboots, crashes, etc.
Major features of our runner:
• Support for Android CTS, GTS and STS.
• Test run split into “shards” in Tradefed to run tests in parallel
on multiple devices. This allows for a major speedup when running large
test suites.
• Tradefed retry: Rerun test suites until the failure count stabilizes.
• No adb root required.
• Based on the original Tradefed runner, having at least parts of
the common code moved to python libraries.
Current limitations:
• Test executions are not always stable. This needs further
investigation.
• Test executions produce more false positives than local test
runs. This needs further investigation but is at least partially due to
using adb TCP/IP instead of a local USB connection.
• Android VTS not implemented (would require only minor changes)
Our current changes have been pushed to the tradefed_shards_with_retry
topic on Gerrit[1]. Besides the two major changes to add MultiNode adb
support and then Tradefed support on top of that, a couple of smaller
changes that could be useful on their own have also been pushed.
We are looking forward to your feedback and to joint efforts in
automating and speeding up Tradefed test executions!
Best regards,
Karsten for the Fairphone Software Team
[1]
https://review.linaro.org/q/topic:%22tradefed_shards_with_retry%22+(status:…
On Mon, 10 Dec 2018 at 20:16, Neil Williams <neil.williams at linaro.org> wrote:
> Yes, there is a problem there - thanks for catching it. I think the
> bulk of the page dates from the last stages of the migration when V1
> data was still around. I'll look at an update of the page tomorrow.
> Step 7 is a sanity check that the install of the empty instance has
> gone well, Step 9 is to ensure that the newly restored database is put
> into maintenance as soon as possible to prevent any queued test jobs
> from attempting to start. The critical element of Step 9 is to ensure
> that the lava-master service is stopped.
>
> The emphasis of the section is on ensuring that the instance only
> serves a "Maintenance" page, e.g. the default Debian "It works!"
> apache page, to prevent access to the instance during the restore.
Thanks for pointing that out, Neil. I got the point, that the Apache
server has to serve a static site during the restore process.
> Accessing the UI would involve having an alternative way to serve the
> pages. If that can be arranged, just for admins, (e.g. by changing the
> external routing to the box or redirecting DNS temporarily) then the
> UI on the instance can be used with the change that the
> lava-server-gunicorn service does not need to be stopped (because
> access has been redirected). Other services would be stopped. However,
> this would involve a fair number of apache config changes, so is best
> left to those admins who have such config already on hand.
>
> The operations can be done from the command line and that's probably
> best for these docs.
>
> Step 7 can be replaced by:
>
> lava-server manage check --deploy
>
> Step 9 can be replaced by looping over:
>
> lava-server manage devices update --health MAINTENANCE --hostname ${HOSTNAME}
>
> or, if there are a lot of devices:
>
> lava-server manage maintenance --force
>
> (This maintenance helper has been fixed in master - soon to be 2018.12
> - so older versions would use the first command & loop.)
Thanks, the CLI operations are very helpful for automating the process.
However, the docs say that all devices in "Reserved" state have to have
their "current job" cleared. I can use "lava-server manage devices details"
to check whether this field is actually set. There is no command to
modify it, though. Seems like using the Python API is the only way to go
here, right? The same applies to setting "Running" jobs to "Cancelled".
> I'll look at changing the page to use CLI operations for steps 7 and
> 9. Some labs can do the http redirect / routing method but the detail
> of that is probably not in scope for this page in the LAVA docs. I'll
> add a note that admins have that choice but leave it for those admins
> to implement.
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hello everyone,
I am trying to implement a backup and restore routine for our LAVA server, based on the documentation:
https://validation.linaro.org/static/docs/v2/admin-backups.html#restoring-a…
The creation of the backup is straight-forward. I have problems with the order of the proposed restore steps, though.
Step 6 is "Stop all LAVA services". However, afterwards in step 7 it says "Make sure that this instance actually works by browsing a few (empty) instance pages." This should obviously be done before, right?
The actual problem is that step 9 says "In the Django administration interface, take all devices which are not Retired into Offline". This cannot be an ordering issue, because the LAVA services actually must not be available during these modifications. How do I use the Django admin interface, while all LAVA services are stopped?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Dear all,
I have a question when use lava.
Background:
1. I have only one hardware device with android.
2. I have a device-type jinja2 file start with "{% extends 'base-fastboot.jinja2' %}"
Here, I use "adb reboot bootloader" to enter in to fastboot.
3. I have another device-type jinja2 file start with "{% extends 'base-uboot.jinja2' %}"
Here, I use "fastboot 0" in uboot to enter in to fastboot.
Now, we have a scenario which need to test with above both methods, but we just have one device, if possible user can define some parameter in job.yaml, then can switch between the two methods just for one device? Any suggestion?
Thanks,
Larry
Hello
I got the following crash with 2018.11 on debian stretch
dpkg -l|grep lava
ii lava
2018.11-1~bpo9+1 all Linaro Automated
Validation Architecture metapackage
ii lava-common
2018.11-1~bpo9+1 all Linaro Automated
Validation Architecture common
ii lava-coordinator
0.1.7-1 all LAVA Coordinator
daemon
ii lava-dev
2018.11-1~bpo9+1 all Linaro Automated
Validation Architecture developer support
ii lava-dispatcher
2018.11-1~bpo9+1 amd64 Linaro Automated
Validation Architecture dispatcher
ii lava-server
2018.11-1~bpo9+1 all Linaro Automated
Validation Architecture server
ii lava-server-doc
2018.11-1~bpo9+1 all Linaro Automated
Validation Architecture documentation
ii lavacli
0.9.3-1~bpo9+1 all LAVA XML-RPC command
line interface
ii lavapdu-client
0.0.5-1 all LAVA PDU client
ii lavapdu-daemon
0.0.5-1 all LAVA PDU control
daemon
2018-12-04 14:14:40,187 ERROR [EXIT] Unknown exception raised, leaving!
2018-12-04 14:14:40,187 ERROR string index out of range
Traceback (most recent call last):
File
"/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py",
line 193, in handle
self.main_loop()
File
"/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py",
line 253, in main_loop
while self.wait_for_messages(False):
File
"/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py",
line 287, in wait_for_messages
self.logging_socket()
File
"/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py",
line 433, in logging_socket
job.save()
File
"/usr/lib/python3/dist-packages/django_restricted_resource/models.py", line
71, in save
return super(RestrictedResource, self).save(*args, **kwargs)
File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 796,
in save
force_update=force_update, update_fields=update_fields)
File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 820,
in save_base
update_fields=update_fields)
File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py", line
191, in send
response = receiver(signal=self, sender=sender, **named)
File "/usr/lib/python3/dist-packages/lava_scheduler_app/signals.py", line
139, in testjob_notifications
send_notifications(job)
File
"/usr/lib/python3/dist-packages/lava_scheduler_app/notifications.py", line
305, in send_notifications
title, body, settings.SERVER_EMAIL, [recipient.email_address]
File "/usr/lib/python3/dist-packages/django/core/mail/__init__.py", line
62, in send_mail
return mail.send()
File "/usr/lib/python3/dist-packages/django/core/mail/message.py", line
342, in send
return self.get_connection(fail_silently).send_messages([self])
File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py",
line 107, in send_messages
sent = self._send(message)
File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py",
line 120, in _send
recipients = [sanitize_address(addr, encoding) for addr in
email_message.recipients()]
File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py",
line 120, in <listcomp>
recipients = [sanitize_address(addr, encoding) for addr in
email_message.recipients()]
File "/usr/lib/python3/dist-packages/django/core/mail/message.py", line
161, in sanitize_address
address = Address(nm, addr_spec=addr)
File "/usr/lib/python3.5/email/headerregistry.py", line 42, in __init__
a_s, rest = parser.get_addr_spec(addr_spec)
File "/usr/lib/python3.5/email/_header_value_parser.py", line 1988, in
get_addr_spec
token, value = get_local_part(value)
File "/usr/lib/python3.5/email/_header_value_parser.py", line 1800, in
get_local_part
if value[0] in CFWS_LEADER:
IndexError: string index out of range
2018-12-04 14:14:40,211 INFO [EXIT] Disconnect logging socket and
process messages
2018-12-04 14:14:40,211 DEBUG [EXIT] unbinding from 'tcp://0.0.0.0:5555'
2018-12-04 14:14:50,221 INFO [EXIT] Closing the logging socket: the
queue is empty
Regards
Hi,
I'm trying to experiment with 'interactive' test shell. The docs are here:
https://master.lavasoftware.org/static/docs/v2/actions-test.html#index-1
As I understand the feature should work in the following way (the docs
aren't very clear):
1. wait for one of the prompts
2. send command
3. match the result to regex (pass or fail)
However when I try it out, there is no wait for prompt. LAVA
immediately sends the command and adds value from prompts to list of
expressions to match. Is this correct? Example job:
https://staging.validation.linaro.org/scheduler/job/245886#L53
LAVA sends the command even before the board starts booting.
Any help is appreciated.
milosz
Hi everyone,
I’m facing an issue when U-Boot commands are sent one after another without waiting for a prompt. Obviously, device is not able to boot.
Excerpt from logs:
dhcp
=> dhcp
bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:56)
setenv serverip 172.17.1.189
setenv serverip 172.17.1.189
bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:56)
tftp 0x80000000 60/tftp-deploy-46_3_i9j/kernel/zImage-am335x-vcu.bin
tftp 0x80000000 60/tftp-deploy-46_3_i9j/kernel/zImage-am335x-vcu.bin
bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:56)
tftp 0x83000000 60/tftp-deploy-46_3_i9j/ramdisk/ramdisk.cpio.gz.uboot
tftp 0x83000000 60/tftp-deploy-46_3_i9j/ramdisk/ramdisk.cpio.gz.uboot
bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:55)
setenv initrd_size ${filesize}
setenv initrd_size ${filesize}
bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:55)
tftp 0x82000000 60/tftp-deploy-46_3_i9j/dtb/am335x-vcu-prod1.dtb
tftp 0x82000000 60/tftp-deploy-46_3_i9j/dtb/am335x-vcu-prod1.dtb
bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:55)
dhcp
dhcp
link up on port 0, speed 10, half duplex
BOOTP broadcast 1
setenv serverip 172.17.1.189
tftp 0x80000000 60/tftp-deploy-46_3_i9j/kernel/zImage-am335x-vcu.bin
BOOTP broadcast 2
tftp 0x83000000 60/tftp-deploy-46_3_i9j/ramdisk/ramdisk.cpio.gz.uboot
setenv initrd_size ${filesize}
tftp 0x82000000 60/tftp-deploy-46_3_i9j/dtb/am335x-vcu-prod1.dtb
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
Retry time exceeded
setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp'
=> setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp'
bootloader-commands: Wait for prompt ['=>', 'Resetting CPU', 'Must RESET board to recover', 'TIMEOUT', 'Retry count exceeded', 'ERROR: The remote end did not respond in time.'] (timeout 00:04:50)
setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp'
setenv bootargs 'console=ttyS2,115200n8 root=/dev/ram0 ti_cpsw.rx_packet_max=1526 ip=dhcp'
=>
bootz 0x80000000 0x83000000 0x82000000
=> bootz 0x80000000 0x83000000 0x82000000
bootloader-commands: Wait for prompt Starting kernel (timeout 00:04:50)
bootz 0x80000000 0x83000000 0x82000000
bootz 0x80000000 0x83000000 0x82000000
Bad Linux ARM zImage magic!
=>
Bad Linux ARM zImage magic!
As you see, all commands that were sent between `dhcp` command and until it was able to complete or fail are simply dropped.
Device type config:
{% extends 'base-uboot.jinja2' %}
{% set device_type = "vcu" %}
{% set console_device = 'ttyS2' %}
{% set baud_rate = 115200 %}
{% set interrupt_prompt = 'Press s to abort autoboot' %}
{% set interrupt_char = 's' %}
{% set bootloader_prompt = '=>' %}
{% set uboot_mkimage_arch = 'arm' %}
{% set bootz_kernel_addr = '0x80000000' %}
{% set bootz_ramdisk_addr = '0x83000000' %}
{% set bootz_dtb_addr = '0x82000000' %}
{% set extra_kernel_args = 'ti_cpsw.rx_packet_max=1526' %}
{% set kernel_start_message = 'Welcome to' %}
Device config:
{% extends 'vcu.jinja2' %}
{% set connection_command = 'telnet lava-disp-1.local 7000' %}
{% set power_on_command = 'relay-ctrl --relay 1 --state on' %}
{% set power_off_command = 'relay-ctrl --relay 1 --state off' %}
{% set hard_reset_command = 'relay-ctrl --relay 1 --toggle' %}
Boot action block from job definition:
- boot:
timeout:
minutes: 5
method: u-boot
commands: ramdisk
auto_login:
login_prompt: 'am335x-nmhw21 login: '
username: root
prompts:
- 'fct@am335x-nmhw21:~# '
Have I misconfigured something? What I’m missing? Thanks!
Best regards,
Andrejs Cainikovs.
Hello,
I have a LAVA job with long running test, so I put a timeout of 180
minutes in the test action itself[1].
However, but the job times out after 3989 seconds (~ 66 min)[2].
Looking closer at the "Timing" section of the job, I see that
lava-test-shell indeed has a timeout of ~3989 seconds, but I have no
idea where that number comes from. That's neither the 10 minutes in the
default "timeouts" section, nor the 180 minutes I put in the "test"
action.
Hmm, after almost pushing send on this, I now seeing that in the
"timeouts" sections, the whole job has a timeout of 70 minutes. So, I
assume that means an absolute max, even if one of the actions puts a
higher timeout?
So I guess this email now turns into a feature request rather than a bug
report.
Maybe LAVA should show a warning at the top of the job if any of the
actions has a timeout that's longer than the job timeout.
Kevin
[1] http://lava.baylibre.com:10080/scheduler/job/60374/definition#defline89
[2] http://lava.baylibre.com:10080/scheduler/job/60374#results_694663
Hi all,
When I try to run a test in lava , hacking session is not starting .
it is exiting by showing:
Using /lava-18
export SHELL=/bin/sh
# export SHELL=/bin/sh
/lava-18/bin/lava-test-runner /lava-18/0
/lava-18/bin/lava-test-runner /lava-18/0
Test shell timeout: 10s (minimum of the action and connection timeout)
export SHELL=/bin/sh
# /lava-18/bin/lava-test-runner /lava-18/0
Illegal instruction
<LAVA_TEST_RUNNER EXIT>
ok: lava_test_shell seems to have completed
end: 3.1 lava-test-shell (duration 00:00:01) [common]
end: 3 lava-test-retry (duration 00:00:01) [common]
start: 4 finalize (timeout 00:10:00) [common]
start: 4.1 power-off (timeout 00:00:05) [common]
end: 4.1 power-off (duration 00:00:00) [common]
my board linux has busybox init system
Please help me resolve the issue.
I've attached the job log below.
Thanks & Regards,
Manoj
Hi everyone,
I'm currently running CTS tests on imx8mq on Android 9.
My test job is based on Linaro's test definition located here :
https://git.linaro.org/qa/test-definitions.git/tree/automated/android/trade…
I had issue concerning the Java heap size, causing the test to abort and
skip a lot of tests.
So, I cloned this git tree and made modifications in "tradefed.sh" :
export _JAVA_OPTIONS="-Xmx350M"
replaced by :
export _JAVA_OPTIONS="-Xmx700M"
Since this modification, I'm able to run the full CTS 9.
So, I think you should consider modify this script, so other users
can benefit from it.
Best regards,
Axel
Hi all,
In Tftp deploy , How to give new set of u-boot bootargs by modifying device
configuration file?
I've tried by giving:
{% set base_kernel_args = "setenv bootargs console=serial1,115200
console=tty1 root=/dev/ram0 ip=dhcp rootwait" %}
But it is not taking these args.
Please suggest the modifications I have to make.
Thanks and regards,
Manoj
Hi Neil,
When LAVA start container from image for the first time(usually docker run ), if failed, it will bring a zoobie container.
And I found that LAVA did not check whether LAVA run is OK, and has no dead container cleanup method.(maybe I was wrong).
Does LAVA have some method to prevent it or do you think it is necessary?
Best Regards
Li Xiaoming
Hi all,
During send-reboot-commands phase in Health check on my raspberry pi 3
board,
LAVA is trying to match the keyword "The system is going down for reboot
NOW" after sending the reset command "reboot -n" to the DUT.
But the problem is when my board starts Reboot it shows "Started Show
Plymouth Reboot Screen .." , not the same as what LAVA want.
So is there any way to specify the keywords to what it should be("Started
Show Plymouth Reboot Screen" or something) in the corresponding DUTs jinja2
file?
I've attached the reslult log of my test below.
Regards,
Manoj
Hi everyone,
I have some troubles to log in my Web UI. I type the good password and
username and then the website sends me back to the home page. If I type a
wrong password, I get an error message. It does the same thing for all user
accounts. Tried to restart lava services, apache2 but it's still doing the
same thing. No error messages returned in logs.
Best regards,
Axel Le Bourhis
Hi all,
When health check is running on my raspberry pi 3 board , in boot phase it
is
taking default soft reboot commands like reboot , reboot -n , reboot -nf.
which is not working with
U-boot boot type. It is showing unknown command ' reboot' .
How to set soft reboot command manually in test job definition?
Thanks & regards,
Manoj
Hi everyone,
I got an issue using LAVA today. After trying to load a job page, LAVA
crashed returning PROXY ERROR. I tried to restart lava-master, lava-slave
and lava-server-gunicorn services without success. The django.log returns
an error about django tables2, saying it can't find the module. I'm running
LAVA 2018.10.
See attached log for more precision.
Best regards,
Axel Le Bourhis
Ok i'll keep that in mind.
To mailing list : I confirm this solution fixed the issue.
Kind regards,
Axel
On Tue, 6 Nov 2018 at 16:55, Neil Williams <neil.williams(a)linaro.org> wrote:
> Yes, please always include the mailing list in replies. When people do
> search for help in the list archives, it is frustrating to find the
> question without the solution - or even just a confirmation that the
> reply worked.
> On Tue, 6 Nov 2018 at 15:47, Axel Lebourhis <axel.lebourhis(a)linaro.org>
> wrote:
> >
> > Thank you for the clarification. I've been able to fix the problem
> thanks to your help.
> >
> > Just a quick question : should I reply including the mailing list ?
> >
> > Regards,
> > Axel
> >
> > On Tue, 6 Nov 2018 at 16:08, Neil Williams <neil.williams(a)linaro.org>
> wrote:
> >>
> >> On Tue, 6 Nov 2018 at 14:59, Axel Lebourhis <axel.lebourhis(a)linaro.org>
> wrote:
> >> >
> >> > Hi everyone,
> >> >
> >> > I just upgraded NXP's installation for DRM team from 2018.4 to
> 2018.10.
> >> > I changed my default LXC folder for storage purpose and when I was at
> 2018.4, there was a constant.py file in
> /usr/lib/python3/dist-packages/lava_dispatcher/utils in order to make LAVA
> know where are located LXC containers.
> >>
> >> Avoid making code changes for these kinds of settings. Constants and
> >> settings can be modified in configuration files. There is no need to
> >> alter anything in /usr/lib/python3/dist-packages/lava* - any change
> >> there will always be undone at the next package upgrade.
> >>
> >>
> https://git.lavasoftware.org/lava/lava/blob/master/etc/dispatcher.yaml#L13
> >>
> >> So on a per-worker basis, you can set the LXC_PATH
> >>
> >> This support is covered under simple administration in the LAVA help:
> >>
> https://master.lavasoftware.org/static/docs/v2/simple-admin.html#lava-server
> >>
> >> In 2018.10 release, this file doesn't exist anymore, so I'd like to
> >> know how I can specify to LAVA the correct path to LXC containers.
> >> >
> >> > Best regards,
> >> > Axel Le Bourhis
> >> >
> >> > _______________________________________________
> >> > Lava-users mailing list
> >> > Lava-users(a)lists.lavasoftware.org
> >> > https://lists.lavasoftware.org/mailman/listinfo/lava-users
> >>
> >>
> >>
> >> --
> >>
> >> Neil Williams
> >> =============
> >> neil.williams(a)linaro.org
> >> http://www.linux.codehelp.co.uk/
>
>
>
> --
>
> Neil Williams
> =============
> neil.williams(a)linaro.org
> http://www.linux.codehelp.co.uk/
>
Hi everyone,
I just upgraded NXP's installation for DRM team from 2018.4 to 2018.10.
I changed my default LXC folder for storage purpose and when I was at
2018.4, there was a constant.py file in
/usr/lib/python3/dist-packages/lava_dispatcher/utils in order to make LAVA
know where are located LXC containers. In 2018.10 release, this file
doesn't exist anymore, so I'd like to know how I can specify to LAVA the
correct path to LXC containers.
Best regards,
Axel Le Bourhis
Hello,
I am having an issue adding a health-check job for a device-type using the API. I have tried doing so using both lavacli and through a python script using the xml-rpc client, but both times I get the following error:
With lavacli:
Unable to call 'device-types.health-check': <Fault 400: 'Unable to write health-check: Permission denied'>
With the python script:
Traceback (most recent call last):
File "./API.py", line 9, in <module>
server.scheduler.device_types.set_health_check("r8a7743-iwg20d-q7-dbcm-ca","r8a7743-iwg20d-q7-dbcm-ca.yaml")
File "/usr/lib/python3.5/xmlrpc/client.py", line 1092, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python3.5/xmlrpc/client.py", line 1432, in __request
verbose=self.__verbose
File "/usr/lib/python3.5/xmlrpc/client.py", line 1134, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib/python3.5/xmlrpc/client.py", line 1150, in single_request
return self.parse_response(resp)
File "/usr/lib/python3.5/xmlrpc/client.py", line 1322, in parse_response
return u.close()
File "/usr/lib/python3.5/xmlrpc/client.py", line 655, in close
raise Fault(**self._stack[0])
xmlrpc.client.Fault: <Fault 400: 'Unable to write health-check: Permission denied'>
The user I use to authenticate the xml-rpc client has superuser privileges and I have tried using a number of different API functions (including ones which require superuser privileges like device-types add and devices add), all of which have worked with both lavacli and the python script.
I have also made sure that the name of the healthcheck file matches the device-type.
Has anyone else encountered this issue?
Thanks,
Patryk
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Hi all,
I've installed lava-docker from
https://github.com/kernelci/lava-docker
but I'm little confused about adding devices and device-types to it .
As described in the link above , i've edited boards.yaml file and added the
board name as follows
masters:
- name: master1
host: local
users:
- name: admin
token: longrandomtokenadmin
password: admin
superuser: yes
staff: yes
tokens:
- username: admin
token: dfjdfkfkdjfkdsjfsl
description: no description
slaves:
- name: lab-slave-0
host: local
remote_master: master1
remote_user: admin
boards:
- name: bcm2837-rpi-3-b-01
type: bcm2837-rpi-3-b
uart:
idvendor: 0x0403
idproduct: 0x6001
serial: A904MHLH
after I built docker image and ran it.
i'm getting following error while loading docker images
Removing local_lab-slave-0_1
local_master1_1 is up-to-date
Recreating 5b8d2c91c519_local_lab-slave-0_1 ... error
ERROR: for 5b8d2c91c519_local_lab-slave-0_1 Cannot start service
lab-slave-0: linux runtime spec devices: error gathering device information
while adding custom device "/dev/bcm2837-rpi-3-b-01": lstat
/dev/bcm2837-rpi-3-b-01: no such file or directory
ERROR: for lab-slave-0 Cannot start service lab-slave-0: linux runtime
spec devices: error gathering device information while adding custom device
"/dev/bcm2837-rpi-3-b-01": lstat /dev/bcm2837-rpi-3-b-01: no such file or
directory
help me resolve this issue.
Thanks,
Manoj
Hello Lava-users,
I am trying to run some test suites in LAVA and my test suite is organized
as below
-single script with multiple test cases
-want to have report the results from LAVA of all test cases
-don't want to depend on the return value of script which will make as test
case as PASS or FAIL
Developing test suites in shell script and using sh-test-lib and attached
is sample test script for reference.
Want to report the result of iptable_packageCheck_test and
iptable_kernel_config_test separately in LAVA framework and will be having
single script for both the test cases.
Based on above criteria which is best method of running the test script in
LAVA.Referred
https://validation.linaro.org/static/docs/v2/developing-tests.html
Following is the content of LAVA Test Shell Definition I am using
metadata:
name: applications
format: "Lava-Test-Shell Test Definition 1.0"
description: "Application tests."
os:
- debian
scope:
- Functional
environment:
- lava-test-shell
run:
steps:
- cd /opt/applications
- ./cron.sh
- ./iptable.sh
- . ../utils/send-to-lava.sh output/result.txt
Thanks,
Hemanth.
Hello,
Is there a way to overwrite the SERVER_IP variable either in the LAVA environment or in the device-types template/device dictionary? https://lava.ciplatform.org/static/docs/v2/migrating-admin-example.html?hig…
No matter what I do, it remains in the rendered yaml file for a device. Unfortunately, the IP it picks up for the environment I'm working is wrong, as I'm running LAVA within a docker-container and it picks up the IP of the container, but the tftp server (within docker) is proxified to the host, meaning that the IP address it needs to pick up is the host's IP. Hence my question, is there a way to overwrite it so that the desired IP appears in the rendered job submission yaml?
Thanks,
Patryk
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Hello,
When trying to use lavacli to add a remote worker, it works fine if
the user is a superuser. However, if I drop the superuser privileges
and add just the privileges for adding workers, it fails with:
Unable to call 'workers.add': <Fault 403: "User 'testuser' is not superuser."
we even tried enabling all the permissions for that user, but leaving
the superuser flag off, and it still fails.
Why does this require superuser and the specific permissions related
to workers don't work?
Kevin
Hi,
I made a first attempt to add REST API for some LAVA objects (jobs,
devices and device types). The API is very rudimentary but already
solves some basic job filtering issues. However I'm not sure how to
add dependencies. There are 2 packages required for this code to work
properly. Pip packages are named 'djangorestframework' and
'djangorestframework-filters'. Former has a corresponding debian
package 'python3-djangorestframework' but the later does not. Any
hints how to add proper dependencies to LAVA?
The code can be found here:
https://git.lavasoftware.org/mwasilew/lava/tree/rest_api
milosz
Hello,
I am looking for a suitable method for the following use-case: during test,
I need to access the connection to the workstation that runs my LAVA worker
and use it as a second namespace in order to be able to issue some commands
on the the workstation (like playing an audio file). In other words I need
to integrate the workstation as an auxiliary device needed for testing in
the test job definition (like ssh <user>@<ws_ip_addr> and send some
commands). Using LXC is not an option at this moment.
At a first sight, the Multinode support would have the most of the needed
features, but I did not find an example of such an usage, if there is any
example you can point me to, I will be grateful.
Thank you in advance,
Oana Ercus
Hello everyone,
is there a way of setting tags for existing devices via the command line? The "lava-server manage devices update" command does not have a "--tags" parameter, as the "lava-server manage devices add" has.
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz
In lava job definition, boot action can use "connection-namespace" to indicate use previous namespace's connection.Does deploy action have such as "deploy-namespace" to indicate to use previous deploy image?
For example in an application scenario, it need to sequential execution two phases pipeline(deploy,boot,test), it can be solved by define two namespace in job definiton.
When run it executed in serial as : phase1(namespace1) deploy->boot->test -> phase2(namespace2) deploy->boot->test.
If phase2 deploy images(kernel,dtb,rootfs) are exactly same as phase2 deploy images,how to speed up phase2 deploy execution? I guess if deploy action have such as "deploy-namespace" to indicate previous deploy,then phase2 deploy process can be pass.
Before test job,we need to add a "device_type" .jinja2 file to directory /etc/lava-server/dispatcher-config/device-types/,and add a "device" .jinja2 file to /etc/lava-server/dispatcher-config/devices/.
The "device_type" .jinja2 file defines device type(for example different hardware) ,and "device" .jinja2 file(at: /etc/lava-server/dispatcher-config/devices/) defines a concrete device.
When the dispatcher submits job, a job should be submited to a concrete device.But In job defintion file,the description of the related device is only the "device_type" but no "device", why is not "device"?
for example:
# Your first LAVA JOB definition for arm
device_type: arm
job_name: arm pipeline, first job
## why not as:
# Your first LAVA JOB definition for arm
device: arm01
job_name: arm pipeline, first job
https://validation.linaro.org/static/docs/v2/admin-lxc-deploy.html#lxc-depl…
,
It say that LXC devices can run lava tests within a container without
disturbing the dispatcher host.
Does LXC support the arm device? Although LXC may supports to run the arm
virtual machine in PC server,but how does it support the completed arm
device(Including various peripheral interfaces eg ethernet,usb.. ) ?
Because the test job often test various peripheral interfaces,Is LXC
emulating these interfaces?
Hello,
Currently I'm testing a board type which deploys OE via u-boot-ums. Before flashing the image into the device, LAVA slave modifies the image copying tests definition onto it. Once the image is modified with all the tests, this is dd'ed into the device, booted and tests will be running.
This is OK so far but as soon as we enable signed images (roofs will be R/O but we will be having other R/W partitions) this won't work anymore as we are changing the image and it needs to be resigned. Moreover, this is very board specific.
I'm here to investigate alternative solutions which have a more "generic" approach which also a developer (without LAVA) can run. The only assumption is that *the DUT has always wired network connectivity with the SLAVE*.
The workflow I have in mind is something like:
1) I have a signed image which I deploy onto the DUT
2) Boot the DUT
3) Instruct the device to get tests from somewhere (either from the SLAVE or internet)
4) Run those tests
The step I'd like to solve is 3). I was thinking something like that:
* download/compile all I need on the SLAVE (it is not possible to do it on the DUT due to limited resources/libraries/tooling)
* setup some sort of server http on the SLAVE in order to serve those files
* wget those files onto the DUT
* setup and execute the tests.
The above approach should work WITHOUT LAVA as well. Basically, replace SLAVE with "developer computer"
Is it something I can architect with LAVA? Does LAVA give me this flexibility?
Thanks for your help
Regards
--
Diego Russo
Staff Software Engineer - diego.russo(a)arm.com
Direct Tel. no: +44 1223 405920
Main Tel. no: +44 1223 400400
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - http://twitter.com/diegorhttp://www.linkedin.com/in/diegor
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>On Mon, 8 Oct 2018 at 10:19, Tim Jaacks <tim.jaacks at garz-fricke.com> wrote:
>
>> Hello everyone,
>>
>> is there a detailed description for all the user permissions defined by
>> LAVA? Or where do I find them in the source code?
>>
>
>LAVA currently only has one level of permissions - superuser or not.
>
>There is on custom permission - cancel or resubmit test job.
>
>Everything else comes from Django and is ignored.
>
At least the "Can add test job" permission seems to be evaluated as well. The UI element "Scheduler -> Submit" is available only if this permission is set.
>
>>
>> There are lots of permissions of which I have no idea what they mean, e.g.
>> "Can [add|change|delete] action data". How is this permission used?
>>
>> Mit freundlichen Grüßen / Best regards
>> Tim Jaacks
>> DEVELOPMENT ENGINEER
>> Garz & Fricke GmbH
>> Tempowerkring 2
>> 21079 Hamburg
>> Direct: +49 40 791 899 - 55
>> Fax: +49 40 791899 - 39
>> tim.jaacks at garz-fricke.com
>> www.garz-fricke.com
>> SOLUTIONS THAT COMPLETE!
>>
>> Sitz der Gesellschaft: D-21079 Hamburg
>> Registergericht: Amtsgericht Hamburg, HRB 60514
>> Geschäftsführer: Matthias Fricke, Manfred Garz
>>
>> _______________________________________________
>> Lava-users mailing list
>> Lava-users at lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lava-users
>>
>
>
>--
>
>Neil Williams
>=============
>neil.williams at linaro.org
>http://www.linux.codehelp.co.uk/
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://lists.linaro.org/pipermail/lava-users/attachments/20181008/bf5abb68/…>
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz
>On Mon, 8 Oct 2018 at 10:19, Tim Jaacks <tim.jaacks at garz-fricke.com> wrote:
>
>> Hello everyone,
>>
>> is there a detailed description for all the user permissions defined by
>> LAVA? Or where do I find them in the source code?
>>
>
>LAVA currently only has one level of permissions - superuser or not.
>
>There is on custom permission - cancel or resubmit test job.
>
>Everything else comes from Django and is ignored.
>
Oh thanks, I didn't know that. Is this noted anywhere in the docs?
>
>>
>> There are lots of permissions of which I have no idea what they mean, e.g.
>> "Can [add|change|delete] action data". How is this permission used?
>>
>> Mit freundlichen Grüßen / Best regards
>> Tim Jaacks
>> DEVELOPMENT ENGINEER
>> Garz & Fricke GmbH
>> Tempowerkring 2
>> 21079 Hamburg
>> Direct: +49 40 791 899 - 55
>> Fax: +49 40 791899 - 39
>> tim.jaacks at garz-fricke.com
>> www.garz-fricke.com
>> SOLUTIONS THAT COMPLETE!
>>
>> Sitz der Gesellschaft: D-21079 Hamburg
>> Registergericht: Amtsgericht Hamburg, HRB 60514
>> Geschäftsführer: Matthias Fricke, Manfred Garz
>>
>> _______________________________________________
>> Lava-users mailing list
>> Lava-users at lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lava-users
>>
>
>
>--
>
>Neil Williams
>=============
>neil.williams at linaro.org
>http://www.linux.codehelp.co.uk/
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://lists.linaro.org/pipermail/lava-users/attachments/20181008/bf5abb68/…>
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz
Hello everyone,
is there a detailed description for all the user permissions defined by LAVA? Or where do I find them in the source code?
There are lots of permissions of which I have no idea what they mean, e.g. "Can [add|change|delete] action data". How is this permission used?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz
The bootloader-commands step breaks into u-boot and begins to issue commands, but some commands are issued prior to receiving the prompt.
I've attempted changing the boot_char_delay, but it doesn't solve the issue.
I'm getting symptoms much like the ones in this thread, except I'm sending space rather than a newline, so the fix is not relevant to me.
https://lists.linaro.org/pipermail/lava-users/2018-May/001069.html
Jeremy Stashluk
Embedded Software Engineer
[cid:image002.jpg@01D45B04.B75D2A40]
Geophysical Survey Systems, Inc.
40 Simon Street * Nashua, NH 03060-3075
603. 893.1109 main * 603.681.2045 direct * 603.889.3984 fax
stashlukj(a)geophysical.com<mailto:stashlukj@geophysical.com> * www.geophysical.com<http://www.geophysical.com/>
Dear users,
I'm looking for a way to detect a possible watchdog in u-boot during a test session.
It happened that on one our test platforms a watchdog was triggered, u-boot restarted, and eventually the test session started. Unless we take a look at every trace of every job, there is a big chance to leave this type of errors undetected.
Do you have any idea on a possible way to handle this in Lava, maybe via device dictionary?
Thanks in advance,
Denis
Hi,
We're using LAVA 2018.5.post1 and we have not been able to log into the web interface since upgrading to this version. The system is running within a docker container. Trying to log in results in a CSRF warning.
The same version of LAVA running on a dedicated debian machine does start working when adding the mentioned lines from this page: https://validation.linaro.org/static/docs/v2/installing_on_debian.html#djan…
Making the same changes to /etc/lava-server/settings.conf within the docker container has no effect on the way the web interface works. It still provides the same errors.
Is there anything else we should do to try to get the web interface to allow logins? I'm not even sure the settings.conf file is being read when restarting the LAVA services, would it appear in one of the logs so that I could search for it?
Thanks for any help you can provide regarding this matter.
Regards,
Jorgen Peddersen
Jorgen Peddersen
Researcher
t +61 2 6103 4700
m
e jorgen.peddersen(a)seeingmachines.com
a 80 Mildura Street, Fyshwick ACT 2609, Australia
SEEINGMACHINES.COM<http://seeingmachines.com>
[SEEINGMACHINES]
This email may contain confidential information. If you are not the intended recipient, destroy all copies and do not disclose or use the information within. Any content that is not concerned with the business of the Seeing Machines Group reflects the views of the sender only, not those of Seeing Machines. No warranties are given that this email does not contain viruses or harmful code. [http://www.seeingmachines.com/wp-content/uploads/2018/04/sm-email-twitter-i…] <https://twitter.com/seeingmachines> [http://www.seeingmachines.com/wp-content/uploads/2018/04/sm-email-linkedin-…] <https://www.linkedin.com/company/258949/>
Hi everyone,
I'm a newbie to LAVA, so this may be a stupid question, but I have no idea
how to fix this issue.
I am using a device for which I enabled the usage of the second serial port
as described in the example beaglebone-black job with a second serial port
- it seems that the configuration works fine, I was able to enable the
secondary connection.
The problem is the following: the second serial port connects to a
different shell, which at this moment is used for freeRTOS application, and
its prompt ("SHELL>>") is different of the primary connection prompt which
is used for Linux("root@imx8mqevk"). When trying to actually run some
commands on freeRTOS, I get timeout error and I have no idea how to fix it.
I attached to this e-mail my test job definition, together with the log and
the snip from my web.
Thanks in advance for your support,
Oana
[image: image.png]
[image: image.png]
Hi,
As far as I could figure out - the uboot environment server ip is set in the base_uboot_dhcp_command in base-ubooy.jinja2. The value of SERVER_IP seems to be set somehow within lava. And it looks if it's not possible to overide it in the device dictionary, isn't it?
Is there a way to change the value of SERVER_IP?
Thanks in advance.
Best regards,
Thomas Klaehn
Senior Software Engineer
u-blox Berlin GmbH
Rudower Chaussee 9
DE-12489 Berlin
Phone +49 30 55573 1032
Mobile +49 151 23990904
www.u-blox.com<http://www.u-blox.com/>
locate.communicate.accelerate
follow us on twitter<https://twitter.com/ublox> | subscribe to our youtube channel<https://www.youtube.com/c/ublox1> | follow us on linkedin<https://www.linkedin.com/company/u-blox> | connect with us on facebook<https://www.facebook.com/ublox1> | follow us on google+<https://plus.google.com/+ublox1>
u-blox Berlin GmbH
CEO (Geschäftsführer): Daniel Ammann
Registered: Berlin HRB 164301 B
This message contains confidential information intended only for the use of the addressee(s) and may be legally privileged. If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return email and destroy all copies of the original message.
All suggestions, recommendations, or other comments contained in this email are provided as a courtesy only. We do not assume any responsibility or liability for the correctness of the information contained in the email.
Hi Neil,
thanks for your quick and direct feedback and please excuse my incautiousness. Being a software developer, I am still new to admin stuff and don't have much experience in hosting servers.
The "flush" command is documented in the help text of "lava-server manage". From the information there it seemed as if "lava-server manage dumpdata" would create a dump of the database (which it did) and that I might be able to restore it with "lava-server manage loaddata" (which I couldn't) if the flush would not do what I expected.
However, the database in that installation was not important at all, I spent some time experimenting with LAVA on this machine and just wanted to have a clean database for starting production use. I assumed there should be an easy way to achieve this.
With your help, I was able to reset my LAVA database using the following commands:
sudo apt-get purge lava-server
sudo rm -rf /etc/lava-server/
sudo rm -rf /var/lib/lava-server/
sudo pg_dropcluster 9.6 main --stop
sudo pg_createcluster 9.6 main --start
sudo apt-get install lava-server
Thanks for pointing me to the backup topic, I will address that in my next step.
Cheers,
Tim
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz
Hello everyone,
is there a way to reset the LAVA database to the state of a fresh installation? From the docs I thought that "lava-server manage flush" command would do that. However, there are some things missing afterwards, e.g. the lava-health user and the master worker. Any hints on how to repair this? Re-installing lava-server did not help.
Mit freundlichen Grüßen / Best regards
i.A. Tim Jaacks
Software Engineering
Garz & Fricke GmbH
Tempowerkring 2, 21079 Hamburg - Germany
Amtsgericht Hamburg HRB 60514
Geschäftsführer: Manfred Garz, Matthias Fricke
Phone: +49 40 791899 - 55
Fax: +49 40 791899 – 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
Hello to Linaro developers,
Recently I have learned that Linaro has developed its own tool to build
Embedded Debian-based system images.
I am very interested in this work/this tool. So I have some questions
regarding this domain.
[1] Do you have published this tool on the Open Source?
[2] If YES, what are the web pointers to it, and the docs I can read and
get familiar with the process?
[3] Does it include scripts to enhance initramfs (the technology Linaro
uses to do that), and where are the locations to read about it?
[4] You name it (if I miss something, please, feel free to fill the gaps)!
I use (almost always) YOCTO based build tool to create initramfses to test
upon them (you know this already if you read my recent emails to this list).
But I would like to have alternative method, and Linaro tool seems
excellent one as alternative, for many reasons.
Thank you in advance,
Zoran Stojsavljevic
_______
Lava xml-rpc notification machnism, criteria.status indicates which event can be notified to user (by hook callback). But the criteria.status only has such as "Complete Incomplete,Canceled,finished" events. Why the lava is not designed a machnism that notify user when only a test case is complete(err..),if so that user has more rights to control test process execution.
hi all
i add a worker to master from the slave container by lavacli..,
But the worker is offline in the localhost:10080 web .
Master and slave can ping each other sucessfully.
any guy konw why?
THX
https://validation.linaro.org/static/docs/v2/glossary.html#term-multinodehttps://validation.linaro.org/static/docs/v2/multinode.html
it said "A single test job which runs across multiple devices".
I still don't quite understandt the purpose of MultiNode. Is that mean
that a single test job's all test cases are parallel executed
simultaneously on multiple devices?
For example it have 10 test cases and 5 devices, when job is running,
firstly the former 5 cases is distributed to 5 devices and parallel run
(case 1 is run on device 1,case 2 is run on device 2,... device 5 is run on
device 5). When a case is end(suppose case 2) ,then case 6 is scheduled to
run on device 2... and so on.Is my understanding correct?
I want to implement a function: When a test case in job is crush or return err(no zero), the job can be rescheduled(or resubmit). Does it need to write own event notification? Need monitor "job Incomplete" action?
In addition, according to lava xmlrpc doc, I input command in lava server console: python zmq_client.py -j 121 --hostname tcp://127.0.0.1:5500 -t 1200 .The was error :
....
File "/usr/lib/python2.7/httplib.py", line 821, in connect
self.timeout, self.source_address)
File "/usr/lib/python2.7/socket.py", line 557, in create_connection
for res in getaddrinfo(host, port, 0, SOCK_STREAM):
In lava website,it is lack the documents on how to build multiple remote slave test system.For example,if our system has a lot of test devices.
What are the general design principles about how to plan to deploy remote workers, how many dut connect to one worker,etc.
Is there any background knowledges about multiple slave and multiNode?
The board has usb serial, it connected to computer running dispatcher. On dispatcher computer that usb serial device name is /dev/ttyUSB0 .
How to configure usb serial in device .jinja2 file?
Hello Lava users,
Do you have any example or advice to share on a way to measure boot time using Lava?
Let's say that I use u-boot, a minimal boot for a device running Linux, and I want to measure the time spent between Power On (pdu-reboot e.g) and Linux prompt.
Best regards,
Denis
Hi Team,
Do you know how to fix below issue when I trigger one LAVA job on LAVA V2 server?
Traceback (most recent call last):
File "trigger.py", line 184, in <module>
main(sys.argv[1:])
File "trigger.py", line 174, in main
lava_bn = lava_server.submit_job(lava_jd)
* File "trigger.py", line 52, in submit_job*
return self._server.scheduler.submit_job(job_data)
File "/usr/lib/python3.5/xmlrpc/client.py", line 1092, in _call_
return self._send(self._name, args)
File "/usr/lib/python3.5/xmlrpc/client.py", line 1432, in __request
verbose=self.__verbose
File "/usr/lib/python3.5/xmlrpc/client.py", line 1134, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib/python3.5/xmlrpc/client.py", line 1150, in single_request
return self.parse_response(resp)
File "/usr/lib/python3.5/xmlrpc/client.py", line 1322, in parse_response
return u.close()
File "/usr/lib/python3.5/xmlrpc/client.py", line 655, in close
raise Fault(**self._stack[0])
xmlrpc.client.Fault: <Fault -32603: 'Internal Server Error (contact server administrator for details): relation "lava_scheduler_app_build" does not exist\nLINE 1: ...number", "lava_scheduler_app_build"."branch" FROM "lava_sche...\n
Best Regards
Zhanghui Yuan
OTC Production Kernel Integration Test
Refer to https://validation.linaro.org/scheduler/job/1890179,I had run a test case in real board successfully
The nfsrootfs image is too big ,it took too many download time in every test. So I put kernel nfs and dtb image files on tftp server, then delete deploy action and add a few boot action commands to specify tftp addr... The parameters(login_prompt&usrname&prompts) of the boot action are same with success version(has deploy action):
...
- boot:
connection: telnet localhost 7000
method: u-boot
##note the fellow commands lines is new added,the success version(has deploy action)that commands line is only "commands:nfs"
commands:
- setenv serverip 192.168.1.5
- tftp 0x8...0000 zImage_arm_1
- tftp 0x4...0000 dtb_arm_1
- setenv nfsroot rootfs_1
- boot
auto_login:
login_prompt: "arm login:"
username: root
prompts:
- root@arm:~#
timeout:
minutes: 3
...
After job submited,the log display that kernel startup and rootfs mount ok, but it always failed at login error.
error log lines:
err info:lava-test-shell: Wait for prompt ['root@arm:~#', 'Login incorrect', 'Login timed out', 'lava-test: # '] (timeout 00:05:00)
Nothing to run. Maybe the 'deploy' stage is missing, otherwise this is a bug which should be reported.
In addition, does the uboot prompts(u-boot=>) no need to describe in boot action section? In other words the prompts auto_login is only described for kernel?
Lava document contains content of how to add simple qemu devices and how to write its job define. But it does not contain how to add real machine device and how to write its test job like uboot image and linex kernel specifications,etc.
Is there any document on how to step by step to build real machine testing?