Hi everyone,
hope you're fine ! I'm quite stuck in my platform development: indeed, I
succedded in adding my own device type, I'm able to boot on linux by TFTP
and to perform auto-login actions.
However, I face difficulties with test-shell.
I have the following error:
https://pastebin.com/grPcvb14
And the definition of stage is:
https://pastebin.com/ArV11Gbb
Stage value seems to be none and I also realized that my test shell isn't
downloaded from git during server processing. Thus I think, that stage is
empty because the test shell definition isn't in the temporary files. Am I
wrong ?
Even if I think I found my problem, I don't know how to solve it, may it be
due to my device-type config ?
Thanks a lot and have a nice day !
Benjamin AUCLAIR
--
- Confidential -
Hi All,
I am adding BBB board on LAVA server I want to change
"UBOOT_AUTOLOAD_MESSAGE" in constant.py, I used "interrupt_prompt"
parameters in job submission but it took the message written in
constant.py. If I changed the message in constant.py its working but I know
this is not the right way to do that, Please suggest if any one has idea
what is the problem with me.
Below is the my Job:
device_type: beaglebone-black
# NFS fails on panda and arndale.
job_name: BBB smoke test
timeouts:
job:
minutes: 240
action:
minutes: 240
connection:
minutes: 2
priority: medium
visibility: public
metadata:
source: https://git.linaro.org/lava-team/refactoring.git
path: health-checks/beaglebone-black-health.yaml
build-readme:
http://images.validation.linaro.org/snapshots.linaro.org/components/lava/st…
build-console:
https://ci.linaro.org/view/lava-ci/job/lava-debian-armmp-armhf/1/console
build-script:
http://images.validation.linaro.org/snapshots.linaro.org/components/lava/st…
actions:
- deploy:
timeout:
minutes: 40
to: tftp
kernel:
url: file:////home/pi/lava/dl/vmlinuz
ramdisk:
url: file:////home/pi/lava/dl/initramfs.cpio.gz
compression: gz
# the bootloader needs a u-boot header on the modified ramdisk
add-header: u-boot
modules:
url: file:////home/pi/lava/dl/modules.tar.gz
compression: gz
nfsrootfs:
url: file:////home/pi/lava/dl/jessie-armhf-nfs.tar.gz
compression: gz
os: debian
dtb:
url: file:////home/pi/lava/dl/am335x-boneblack.dtb
- boot:
method: u-boot
commands: nfs
parameters:
shutdown-message: 'INIT: Sending processes the TERM signal'
interrupt_prompt: 'Press SPACE to abort autoboot in 10 seconds'
interrupt_char: ' '
send_char: False
type: bootz
auto_login:
login_prompt: 'beaglebone login: '
username: root
prompts:
- 'root@jessie:'
timeout:
minutes: 10
- test:
timeout:
minutes: 50
definitions:
- repository: git://git.linaro.org/qa/test-definitions.git
from: git
path: ubuntu/smoke-tests-basic.yaml
name: smoke-tests
Hi Lava Team
I am trying to mount a directory of worker (host computer) to LXC
instance running on it with job.
I have added this entry in lxc default configuration file of worker
computer.
Default Configuration file path is : /etc/lxc/default.conf
Entry is :-
lxc.mount.entry = /var/lib/nfsdir var/nfsmnt none bind,create=dir 0 0
After restart lxc service. I executed lava job then this directory
"/var/lib/nfsdir" of worker machine is not mounting on LXC instance in
directory "/var/nfsmnt".
But if i manually create and start lxc instance on worker, then this
directory "/var/lib/nfsdir" of worker machine is mounted on LXC instance.
Can anyone assist me on this issue, that how i can resolve this issue.
--
Thanks & Regards
Chetan Sharma
Hi Lava Team
Can you assist me on this usecase that how i can share LXC data with
DUT.
We have LXC and DUT TEST defined in a Job. LXC Tests generates
some data and logs which is required to be accessed by DUT TEST.
--
Thanks & Regards
Chetan Sharma
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
