Hello，Neil：
1.Can you give me a deploy flow for a x86 device .
2．I want to use web UI submit job for one time N jobs. (N>10)
How can I do it?
Thanks.
Amanda
This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.
Hi,
I've hit an issue after upgrading LAVA on Debian Stretch from
2017.5-6486.59742fe-1 to 2017.5-6509.d71f267-1, trying to add or
update device dictionaries using the "lava-tool
device-dictionary" command then always failed.
Between these two revisions, the following change was introduced:
commit ae4d4776ca7b7454f5406159226e3c9327dd207f
Author: Rémi Duraffort <remi.duraffort(a)linaro.org>
Date: Tue May 2 15:22:33 2017 +0200
LAVA-757 Move device dictionaries to file system
The device dictionaries are now saved in:
/etc/lava-server/dispatcher-config/devices
which was previously installed with the root user. The LAVA
server instance is running under the "lavaserver" user, which
didn't have write access to this directory. So I had to manually
change the permissions, and then it all worked.
Could you please add a step in the Debian package installation to
change the permissions and ownership of the files in
/etc/lava-server/ to fix this issue?
Note: It may also be a good idea to propagate the IOError into
the xmlrpclib.Fault error message rather than replacing it with a
rather mysterious "Unable to store the configuration for %s on
disk". I had to do this to find out the root cause of the error;
I can send a patch, let me know.
Best wishes,
Guillaume
Hey all,
I'm currently hitting an interesting issue; We're deploying debian-
based images in our tests which have most of / mounted read-only.
Unfortunately the default deployment data for Debian indicates that the
various lava-test-shell related directories show live in /lava-xxxxx to
which in our booted image ofcourse nothing can write.
It would be good to give test writers the freedom to specify a sensible
base-path for lava's usage to avoid these types of issues. The option
to add a Debian variant to deployment data on our setup is somewhat
less attractive as that requires server configuration. (Changing the
images to mount / as read-write is not an option as that would defeat
the point of the test).
--
Sjoerd Simons
Collabora Ltd.
Hi,
With delivery of May, we can now defined timer for each test of a job.
Some of our tests are not correctly executed and then timeout expired.
But we want to execute next test and not stop the job with an incomplete verdict
How can we configure this behavior in yaml ?
See following example of yaml used
Thanks in advance for your answer
Regards
[Description: Description: Description: Description: Description: Description: logo_big5]
Florence ROUGER-JUNG | TINA: 166 7356 | Tel: +33 2 44 02 73 56 | Mobile: +33 6 13 49 38 02
STMicroelectronics | MCD
Auriga Building | 9-11, rue Pierre-Félix Delarue | 72100 Le Mans | FRANCE
I currently have an issue with starting lava-publisher. Whenever I run python manage.py lava-publisher I get output log:
2017-05-22 20:10:28,061 INFO publisher Dropping priviledges
2017-05-22 20:10:28,061 ERROR publisher Unable to lookup the user or the group
2017-05-22 20:10:28,062 ERROR publisher Unable to drop priviledges
I currently Have the same binaries in my own workstation and I am able to successfully connected to lava-publisher my output log gets:
2017-03-27 19:34:43,909 INFO publisher Dropping priviledges
2017-03-27 19:34:43,909 DEBUG publisher Switching to (lavaserver(126), lavaserver(133))
2017-03-27 19:34:43,909 INFO publisher Creating the input socket at ipc:///tmp/lava.events
2017-03-27 19:34:43,910 INFO publisher Creating the publication socket at tcp://*:5500
2017-03-27 19:34:43,910 INFO publisher Creating the additional sockets:
2017-03-27 19:34:43,910 INFO publisher Starting the proxy
I followed same steps to install from same repository on both machines. I somehow think this has to do with user or group not stored in database but I am not sure.
BTW: lava server/dispatcher both work well on both machines I just want to have an event notification client working on my second machine.
Thank you.
- Randy
Hello,
I am trying to setup Android tests on a B2260 board using LAVA V2 (
version 2017-05 ).
I have read LAVA documentation about Android tests and investigate about
existing Android jobs
and devices that have developed Android tests.
My questions:
* Is it essential to use linux container to perform Androids tests ?
* Do you have device-type, devices and jobs that would help me to
achieve my android tests ?
Best regards
Philippe
Hello,
Until then I've installed extra test packages from embedded test scripts.
Using the latest V2 version, I'm trying to manage this in my test jobs.
e.g.:
install:
deps:
- python-pytest
- python-lxml
- packagegroup-core-buildessential
- phoronix-test-suite
At execution time, I get a Error: OPKG package manager not found in the path.
Does this mean that OPKG is the only installer supported? Or is this the default one meaning that I can select DPKG or aptitude instead?
Best regards,
Denis
Hello Team,
This is just the request as a lava user.
It would be better if lava supports static ip configuration to deploy and
etc stuff with target board.
The user who dont have dhcp setup means this will be very useful to work
with target locally.
I hope you will consider this request and will support static ip also for
lava users.
Regards,
Guru
Hi Everyone,
In the Beaglebone-Black Health Check, `bbb_debian_ramdisk_test.yaml`,
located in the Linaro master repository
(https://git.linaro.org/lava-team/refactoring.git), there are the
following lines in the "action:" block:
---
kernel:
url:
http://snapshots.linaro.org/components/lava/standard/debian/jessie/armhf/4/…
ramdisk:
url:
http://snapshots.linaro.org/components/lava/standard/debian/jessie/armhf/4/…
compression: gz
# the bootloader needs a u-boot header on the modified ramdisk
add-header: u-boot
modules:
url:
http://snapshots.linaro.org/components/lava/standard/debian/jessie/armhf/4/…
compression: gz
---
How is the `initramfs.cpio.gz` generated? KernelCI's build.py script
doesn't generate it. None of the Lava scripts generate it, yet it is
required to perform the boot test of a kernel on the Beaglebone Black. I
can't find it mentioned anywhere in the documentation either.
How did you generate this so it is compatible with the BBB? We want to
follow Linaro's standards, guidelines and recommendations as close as we
can, but this particular part seems to be missing.
Any help you can offer would be greatly appreciated.
Thank you!
--
Don Brown
Codethink, Ltd.
Software Engineering Consultant
Indianapolis, IN USA
Email: don.brown(a)codethink.co.uk
Mobile: +1 317-560-0513
