Hi everyone,
As I have probably mentioned in previous emails, Im using the yocto
project to generate some linux images that I want to test using lava as
part of the continuous integration development.
So far so good, i can submit the job description to lava using lava-tool
and it will start the tests. I'm happy so far with all the results.
Now my question is to ask you what would be the correct way do this
procedure. Do you think it is reasonable to have a lava-tool submit-job
followed by a waiting step using lava-tool job-status to report the
final build result? or there is a nicer way to do this?
Thanks a lot for your help in advance :)
Best,
Alfonso
By default, a uboot header is automatically added to the ramdisk image.
For bootloaders without INITRD_ATAG support, the ramdisk needs to be
passed on the command line and cannot have the uboot header added.
To enable this feature, add a "ramdisk_raw" option that device files can
set so that a uboot header is not added.
Signed-off-by: Kevin Hilman <khilman(a)baylibre.com>
---
Patch applies on 2016.9
lava_dispatcher/config.py | 1 +
lava_dispatcher/device/bootloader.py | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/lava_dispatcher/config.py b/lava_dispatcher/config.py
index 66a9e70021fa..c91c5634280d 100644
--- a/lava_dispatcher/config.py
+++ b/lava_dispatcher/config.py
@@ -312,6 +312,7 @@ class DeviceSchema(schema.Schema):
uimage_xip = schema.BoolOption(default=False)
append_dtb = schema.BoolOption(default=False)
prepend_blob = schema.StringOption(default=None)
+ ramdisk_raw = schema.BoolOption(default=False)
# for dynamic_vm devices
dynamic_vm_backend_device_type = schema.StringOption(default='kvm')
diff --git a/lava_dispatcher/device/bootloader.py b/lava_dispatcher/device/bootloader.py
index 634d22ef3311..c88fba8937e6 100644
--- a/lava_dispatcher/device/bootloader.py
+++ b/lava_dispatcher/device/bootloader.py
@@ -208,7 +208,7 @@ class BootloaderTarget(MasterImageTarget):
decompress=False)
extract_overlay(overlay, ramdisk_dir)
ramdisk = create_ramdisk(ramdisk_dir, self._tmpdir)
- if self._is_uboot():
+ if self._is_uboot() and not self.config.ramdisk_raw:
# Ensure ramdisk has u-boot header
if not self._is_uboot_ramdisk(ramdisk):
ramdisk_uboot = ramdisk + ".uboot"
--
2.5.0
Hello everyone,
Can you help me on below two questions?
1. I did email notification settings for sending emails after job complete or incomplete.
How can I get whole logs (where are logs?) about email sending process? I need to debug email sending.
2. I want to use script to control device state periodically.
How can I set device to maintenance state using command, like lava-tool command?
Thanks in advance.
Hello everyone,
just a simple question. I might be wrong but I understand that
submitting a job through lava-dispatch and lava-tool should lead to the
same process. Now, with the dispacher you can already specify an
specific target device encoded in yaml format. Does the lava-tool at
some point reach a similar target configuration? does it generate it or
it is stored somewhere? in the latter case, where is it stored?
thanks in advance :)
Best,
Alfonso
Hello everyone,
just a quick question.
I am trying to run a job to test a qemu image which is stored remotely.
The image is packed in a tar.xz file with both the kernel and the file
system.
is there a way to specify in the job description json file that before
the deploy action it must open this tar.xz file and then use the kernel
and filesystem?
Thanks a lot :)
Best,
Alfonso
Hello guys,
I am currently trying to install the lava-server/dispatcher on my local
pc with Ubuntu 16.04. Unfortunately, I had little success installing the
source projects from github.com/linaro. I just wanted to ask if you
could recommend me what would be the best approach for me.
Thanks for your help.
Best regards,
Alfonso
Hi,
I'm trying to get the proper relationship between requested tests and
results in LAVA v2. Here is example job:
https://validation.linaro.org/scheduler/job/1109234
and results for this job:
https://validation.linaro.org/results/1109234
How can I tell:
- which result matches which test?
- if there are multiple occurrences of the same test with different
parameters, how to recognize the results?
In LAVA v1 the matching was a very arduous process. One had to
download the job definition, look for lava-test-shell actions, pull
the test definition yaml sources and match yaml ID and to ID found in
result bundle. How does this work in v2?
milosz
Hello,
Google has release the latest version of Tradefed with the Android N
release.
https://source.android.com/devices/tech/test_infra/tradefed/index.html
Lots of dispatcher/slave features which LAVA already supports.
Given this update, is LAVA exploring to adopt the new mechanism or continue
developing its own architecture ?
Thanks
Sandeep
Hi,
Chase did an excellent job and put together a piece of code that
allows us local execution of lava-test-shell. This means we can use
our 'lava' test definitions on the boards that are not deployed in any
LAB. There are 2 main reasons for doing that:
- prototyping tests for LAVA
- semi-automated execution of tests on targets that are not deployed in any LAB
Major part of this code is taken directly from lava dispatcher. There
are slight modifications but I would like to keep them to minimum or
remove at all (if possible). So the question follows - is there a way
to achieve the same goal with only LAVA code? One of the biggest
problems was requirement for ACKing that lava-test-shell requires.
This makes the tests 'interactive' which isn't best for semi-automated
execution. This bit was removed and now we're able to use test shell
locally in non-interactive mode. The README file describes the use
cases we're covering. Any comments are welcome. Code can be found
here:
https://git.linaro.org/qa/lava-local-test.git
milosz
