Hi,
In LAVA v1, as I remember, I can use either "device" or "device_type" to
request a device for the test.
If I use "device", for example "device": "beaglebone-black03", then the
specific device, beaglebone-black03, will be used for the test.
Can I do the same thing in LAVA v2? To request a device by using device
name?
Thanks,
Arthur
Hi,
I've got 2 jobs stuck in canceled mode which are preventing any other job from running.
I'm running lava (2017-7) in a VM and have tried rebooting the VM to
clear the issue but without success (ie the jobs still block the queue).
an extract from /var/log/lava-server/django.log
is attached
I get this 500 error when viewing the results for the job
Is there a manual way of clearing this? The health check has
notification associated with it (and set to verbose) and every time I
reboot I get an email and irc saying that it's finished!
Robert
Hi everyone,
I'm implementing the nfsroot for my devices but it seems that when
extracting my rootfs.tar.xz lava keep the parent folder rootfs and didn't
extract all the files in extract-nfsrootfs-XXXXX so that the lava test
overlay is putting outside of rootfs folder and raises an error during
execution.
Is there a way in job definition to ask lava to put the test overlay in the
rootfs folder ?
Thanks
Benjamin AUCLAIR
--
- Confidential -
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
