There are delays getting packages into stretch-backports, as expected.
In the meantime, this is a reminder of how to use backports: first
start with stable.
So when installing LAVA on Stretch, even if what you want is the
latest release from production-repo or staging-repo (currently
2017.7), then your first step is to install 2016.12 from Stretch.
# apt -y install lava-server
# apt -y install vim
# wget http://images.validation.linaro.org/production-repo/production-repo.key.asc
# apt-key add production-repo.key.asc
# vim /etc/apt/sources.list.d/lava.list
# # edit the file to specify: deb
http://images.validation.linaro.org/production-repo jessie-backports
main
Yes, that is jessie-backports - we don't have packages in
stretch-backports at this time.
# apt update
# apt upgrade
If you specify backports too early, you'll get a range of other
packages from backports - you don't actually need jessie-backports or
stretch-backports from Debian at this time.
Packages for jessie-backports are built on jessie. Packages for
stretch-backports are built on stretch. It's the same source code in
each case. Right now, there aren't any problems with installing from
jessie-backports on stretch - particularly if you install lava-server
from stretch in the first place so that the majority of your packages
come from stretch.
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
Hi Lava Team,
Can anyone assist me with these 2 quires as
1. Can we enable interface inside LXC to access host network, so
that we can access any device on network of host machine and can access
internet inside LXC to execute script.
2. Can we pass Params in Lava job, which can propagate to
lava-test-action job or yaml.
If possible can you guide me with process to perform this
action ? share a reference job which perform this task.
--
Thanks & Regards
Chetan Sharma
Dear all,
Do you have any example or recommendation on the way to implement the following use case in Lava?
DUT under Linux
A PC under Linux to use as a "server" for VLC or iPerf test cases
I guess Multinode can be used to manage these use cases, but I don't know how to deal with the constraints linked to the PC: no reboot, no dedicated test kernel.
Thanks,
Denis
Hi Neil, Kevin !
> On 20 July 2017 at 02:57, Kevin Hilman <khilman at baylibre.com> wrote:
> > Hello,
> >
> > There are many configurable options when starting QEMU that are
> > controlled by environment variables, and I'm trying to figure out how to
> > pursuade LAVA v2 to set them.
>
> It's not something which should be done with the QEMU device type
> because that is installed on the worker - it is not a device that can
> be reconfigured to suit test writers and much of the functionality of
> QEMU must remain off-limits when QEMU is running on the worker.
>
> > As an example, configuring the host audio driver used by QEMU is set by
> > running QEMU with: QEMU_AUDIO_DRV=<option> qemu-system-x86_64.
>
> The worker is typically a server, it might not have any audio support.
> Even if it does, that functionality is off-limits to test writers. The
> available options to QEMU must be tightly constrained to protect other
> tasks on the worker.
A see. There is a valid point here in that there should not be control of the
environment from the 'outside' though a job description.
>
> > Unfortunately, device-types/qemu.jinja2 doesn't provide anyway to
> > override the qemu-system binary used (it's conditional based on arch),
>
> This is deliberate, to protect the worker from aberrant processes and
> to give the admins sufficient control over how the worker behaves.
Now for the above case:
QEMU_AUDIO_DRV=<option> qemu-system-*
I see this as a *very valid env var* for a server-side deployment - exactly as
you said - a server does not have a sound card and QEMU_AUDIO_DRV=none is what
we need to use there to prevent qemu from looking for a host sound card. We
should even set this by default - we don't expect any sound to reach the
worker - do we ;) ? I don't think so.
IMHO this should be an option set on the worker node in the lava-
dispatcher.conf (e.g. LAVA_EXTRA_QEMU_ENV="QEMU_AUDIO_DRV=none").
Enable the admins to choose this.
>
> No. This is not something that the worker can support. It needs to
> happen only on a test device. The worker is not itself a test device.
As I said, I think this belongs to the worker setup and we should enable the
admins to make their choice.
Dipl.-Ing.
Jan-Simon Möller
jansimon.moeller(a)gmx.de
Hello,
There are many configurable options when starting QEMU that are
controlled by environment variables, and I'm trying to figure out how to
pursuade LAVA v2 to set them.
As an example, configuring the host audio driver used by QEMU is set by
running QEMU with: QEMU_AUDIO_DRV=<option> qemu-system-x86_64.
Unfortunately, device-types/qemu.jinja2 doesn't provide anyway to
override the qemu-system binary used (it's conditional based on arch),
but even a quick hack to allow it to be overriden[1], and adding the env
as a prefix didn't because LAVA assumes the first item is an actual
binary expected in $PATH. My attempt led to:
Invalid job definition
Cannot find command 'QEMU_AUDIO_DRV=none qemu-system-x86_64' in $PATH
Seems like there should be a more general way to pass enviornment
variables to QEMU that I must be missing. If there's not, would be the
recommended way to add this feature?
Kevin
[1]
diff --git a/lava_scheduler_app/tests/device-types/qemu.jinja2 b/lava_scheduler_app/tests/device-types/qemu.jinja2
index 786f53bdb30d..e7c265a3048b 100644
--- a/lava_scheduler_app/tests/device-types/qemu.jinja2
+++ b/lava_scheduler_app/tests/device-types/qemu.jinja2
@@ -41,7 +41,7 @@ actions:
{% elif arch == 'arm' %}
qemu-system-arm
{% elif arch == 'amd64' or arch == 'x86_64' %}
- qemu-system-x86_64
+ {{ qemu_command|default('qemu-system-x86_64') }}
{% elif arch == 'i386' %}
qemu-system-i386
{% endif %}
With that change, I added
context:
qemu_command: "QEMU_AUDIO_DRV=none qemu-system-x86_64"
to the job definition
Dear lava Community,
I want to use Image charts2.0 for viewing my lava job results.
I am using "lava-test-case" to check pass/fail & I am getting results also.
steps:
- lava-test-case linux-linaro-ubuntu-pwd --shell pwd
- lava-test-case linux-linaro-ubuntu-uname --shell uname -a
- lava-test-case linux-linaro-ubuntu-vmstat --shell vmstat
I want to know how to get these results in image charts, I can see it ask to add chart & addfilter , but there no data is available when I try to add filter?
Similarly if I have to use query api, what kind of query should be used to fetch test data from lava suite?
Detailed info to use image chart will be appreciated, as I am new to Charts/Lava...or at any link.
Thanks,
Varun
Hi everyone,
I'm trying to add own device-type to my lab, but I'm facing some
difficulties when running jobs. I have the following log error:
https://pastebin.com/Eznq6RLA
I clearly understand the log but I'm not able to figure out what to do: I
thought it will be enough describing boot/power actions into device-type.
But it seems not... Do I need to create a .conf file into
/usr/lib/python2.7/dist-packages/lava_dispatcher/default-config/lava-dispatcher/device-types
folder ?
By the way I'm not sure to understand the .conf purpose ? Are they here,
only to be some default files ?
I attached my device-type and my job, maybe it will help you !
Thanks a lot ;)
P.S: I already did some jobs on Qemu and bbb and read the whole
documentation.
--
- Confidential -
Hi,
I'm not entirely sure this job definition is correct, but the only
error I'm getting is only "Problem with submitted job data: Invalid
YAML - check for consistent use of whitespace indents.". The YAML
validates just fine so I'm unsure what is wrong. Any hints? The YAML
in question is enclosed.
milosz
