I'd like a single device-type to list load addrs for booti, bootz, and
bootm so it can support all three modes. That seems ok.
Next, I'd like the device-dict (not the job parameters) to be able to
decide which of those to use.
For example, device-A and device-B share this same device-type.
device-A runs mainline uboot and can use booti, but device-B runs a
vendor uboot, which doesn't support booti, so it needs LAVA to convert
the kernel "image" to a "uimage". But the job submitter is not (and
should not be) aware which of the devices will be chosen, so the job
submitter always submits a job with "kernel_type: image" (Yes, this
is similar to the thread started by Corentin[1], but I'm trying to
rephrase.)
So, device-B needs to put the text_offset in its dict, possibly
override some other vars for the vendor uboot (e.g.
bootloader_prompt), and that all works swimmingly.
However, the problem is that the decision to convert to uimage is made
based on job paramaters (e.g. kernel_type == "uimage'[2]). But, that
implies that the job *sender* needs to know whether the device to be
selected supports booti or bootm, and that defeats the whole goal of
LAVA hiding that. The job should just pass in an kernel with "type:
image" and the device-dict is the one that should decide whether to
convert to a uimage.
IOW, is there a way for the device-dict to say "I know I recevied an
image of kernel_type=image, but please convert to kernel_type=uimage."
?
>From what I can tell by checking the code[2], if kernel_type = "image"
and "booti" is in device_params (and it always will be because it's
set in the device-type), then a uimage will never be created.
For this to work, the device-dict for device-B has to *remove* the
booti_*_addr set by the device-type. I suppose that's possible in
jinja2, but that seems a bit ugly. I'm hoping there's a cleaner way
for the device-dict to say "please force uimage conversion and use
bootm.
Thanks,
Kevin
[1] https://lists.linaro.org/pipermail/lava-users/2018-April/000994.html
[2] https://github.com/Linaro/lava/blob/master/lava_dispatcher/actions/deploy/p…
Hello Lava users,
I'm coming back with an old question that I think is worth asking again.
Here is an example of a test definition from Lava documentation:
test:
failure_retry: 3
timeout:
minutes: 10
name: kvm-basic-singlenode
definitions:
- repository: git://git.linaro.org/lava-team/lava-functional-tests.git
from: git
path: lava-test-shell/smoke-tests-basic.yaml
name: smoke-tests
- repository: http://git.linaro.org/lava-team/lava-functional-tests.git
from: git
path: lava-test-shell/single-node/singlenode03.yaml
name: singlenode-advanced
revision: 441b61
In this example, 2 tests are defined, and they're contained in the same git repo. The test overlay will be built by Lava using this type of tree:
Lava_session_number/test1/
Lava_session_number/test2/
In each test folder, a git clone will be performed and data will be duplicated.
Nowadays, I understand that the trend is to test more in and embedded configurations, and less in nfs configurations. This is what we do for our product validation.
Embedded storages are limited, therefore we need to carefully think about our git management:
- First strategy: have a single git containing all the tests. In this case size of test overlay may increase dangerously
- Second strategy: one git per test. This is not the spirit of a git, but you solve the size issue.
The last time we asked the question, more than a year ago, there was no solution or workaround to prevent duplicating the same git in a Lava job. Has the situation changed? If not, I believe it would be great to have a mechanism to store gits no longer in the test folder itself, but in a common repository folder. I know this cannot be done in every case, for example you may have 2 tests on the same git but on a different branch, but this may be an optional feature trigger by a "shared" tag in the job definition.
If shared is declared, links to the common repo would be created in the test overlay folder.
For example:
test:
failure_retry: 3
timeout:
minutes: 10
name: kvm-basic-singlenode
definitions:
- repository: git://git.linaro.org/lava-team/lava-functional-tests.git
from: git
shared: yes
path: lava-test-shell/smoke-tests-basic.yaml
name: smoke-tests
- repository: http://git.linaro.org/lava-team/lava-functional-tests.git
from: git
shared: yes
path: lava-test-shell/single-node/singlenode03.yaml
name: singlenode-advanced
What do you think? Am I the only one needing this, are you aware of a better solution?
Best regards,
Denis
Hi lava-users,
I have a device which is sd-card booted. I want to run test on this device
using lava platform.
I did read dummy-deploy is an option but didn't find any relevant
information regarding the same.
If anyone has any example or document regarding the same then kindly share.
--
Regards,
Nikita Gupta
Hi
Our CIP VM's LAVA install [1] is broken by the 2018 version that's just
appeared in stretch-backports, it would be helpful for us if we could
move more slowly to new versions - are there any instructions on how to
install from git? the INSTALL file is a bit empty...
Robert
[1] https://gitlab.com/cip-project/cip-testing/board-at-desk-single-dev/blob/ma…
Hi all,
we are using the lava system for test of several i.mx6 boards with yocto
based linux images.
Sometimes the test cases failed with following error message:
"Test error: Unable to handle the test shell signal correctly:
_on_sync() takes exactly 2 arguments (16 given)"
A closer look into the logfile shows, that the Message
"<LAVA_SIGNAL_TESTCASE ... >" seems to be interrupted by output of
kernel messages.
# example from logfile start#
<LAVA_SIGNAL_TESTCASE TEST_CASE_ID=Test[ 113.747589] cfg80211:
(5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm)
_Step_22 RESULT=pass>
2018-05-08 03:24:20,633 INFO [ 113.759603] cfg80211: (5250000 KHz -
5330000 KHz @ 80000 KHz), (N/A, 2000 mBm)
: PerformShellCmd:
testcase_throughput_sta_2_4ghz_Station2_4GHz_Linksys0302[ 113.774770]
cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm)
4 pass
Received signal: <TESTCASE> TEST_CASE_ID=Test[ 113.747589] cfg80211:
(5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm)
_Step_22 RESULT=pass
Ignoring malformed parameter for signal: "113.747589]".
# example from logfile end#
Is there someone with semilar observations and a solution for this problem?
Best Regards
Steffen Volkmann
Hello everyone,
I added an email notification to a test job but forgot to configure an SMTP server first. The job reported:
"JobError: Your job cannot terminate cleanly."
Afterwards nothing happened. The job was still running, even after all timeouts had been passed, so I tried to cancel it. Now the job remains in "Cancelling" state and I have no idea why and how to fix this. Any hints?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz
Dear all,
I'm testing QEMU on LAVA with my first job.
I have taken a sample here:
https://staging.validation.linaro.org/static/docs/v2/first-job.html#index-0
But, it's failed at "apply-overlay-guest" action:
Overlay: /var/lib/lava/dispatcher/slave/tmp/15/overlay-1.3.4.tar.gz
Traceback (most recent call last):
File
"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line
290, in run_actions
new_connection = action.run(connection, args)
File
"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/deploy/apply_overlay.py",
line 83, in run
self.job.device['actions']['deploy']['methods']['image']['parameters']['guest']['size'])
File
"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/utils/filesystem.py",
line 128, in prepare_guestfs
guest.launch()
File "/usr/lib/python2.7/dist-packages/guestfs.py", line 5705, in launch
r = libguestfsmod.launch(self._o)
RuntimeError: /usr/bin/supermin exited with error status 1.
To see full error messages you may need to enable debugging.
Do:
export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
and run the command again. For further information, read:
http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
I'm using docker LAVA version 2017.11. And, attached is my log.
Do you have idea for this issue?. Thanks in advance
Best regards,
Canh Nguyen
My contact email:
phongcanhit(a)gmail.com
canh.nguyen.vz(a)rvc.renesas.com
Hi,
I am using Lava as our automation test infrastructure now. Now we are trying find all key words collection in Jobs.
For example:
timeouts:
job:
minutes: 30
action:
minutes: 30
priority: medium
visibility: public
actions:
- deploy:
timeout:
minutes: 30
to: docker
os: debian
packages: [python]
key word to and os, its value is docker and debian here. Maybe there are different value for these ker words in another jobs. We just want to find all these possible value for these key word in Lava.
Could anyone kindly provide some method and configuration file/document to find this efficiently? Thanks in advance.
Thanks,
Deli
Hello everybody,
I have some testcases which need a remote network connection to the DUT. I already managed to implement this using an LXC container as part of a multinode job.
Example: Check whether a telnet server is running on the DUT.
Implementation:
* DUT and LXC are deployed and booted as two roles in a multinode job
* DUT sends its IP address to LXC via the multinode API (lava-send) and then waits for a signal (lava-wait)
* LXC reads the IP address (lava-wait, lava_multi_node_cache.txt), tries a telnet connection to DUT (lava-test-case) and then sends a signal to DUT (lava-send)
* DUT and LXC are shut down
Now I read that LXC containers can be used in a singlenode job context as well, using the "namespace" attribute. I tried this and got the LXC container running along with my DUT, without the need of a multinode job. However, the multinode API cannot be used in this case, obviously. Is there another possibility to submit the DUT's IP address to the LXC?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz
Hello Lava-Users,
When we want to use SSH as the primary remote connection for connecting to
target and executing tests in LAVA how should private key which can be used
for this connections be placed.
Is there any sample job definition example for this type of connection.
Thanks,
Hemanth.
