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