Lava-users

lava-users@lists.linaro.org

358 discussions

by Hemanth K V

Hello Lava-Users, I have UEFI based x86 target board which I want to connect to LAVA and execute tests. When I go through https://validation.linaro.org/static/docs/v2/integrate-uefi.html it specifies different mechanism available.I am confused here as I am not completely clear on differences between systems mentioned. If I just know UEFI implementations method of target is it enough to select which method can be used for booting. What are the things I need to know before concluding the method to be used for booting x86 based target board? Thanks, Hemanth.

8 years

Is LAVA suitable for us?

by magnus＠minimum.se

Hey, Where I work, we've been using LAVA since 2014 to test our in-house Linux distribution. Our devices are typically "low-end" devices with 128 to 256 MB RAM and up to 512 MB NAND flash. We use LAVA to test our BSPs, e.g lots of connectivity/interface/IO tests. We also use it for stability-testing and performance testing (like measuring the application context switch time or Ethernet TX rates). For a while, there has been a growing concern within our team that LAVA might not be ideal for our testing needs. Right now, the team is discussing if we should drop LAVA and use something else. There is even talks about developing our own test framework. I personally like the idea behind LAVA but also agree that it has been a bumpy road these past 4 years. Due to various bugs and missing features, we've several times been forced to upgrade to an unstable version of LAVA just to get normal operations working. Two times we've lost the entire test database because we were unable to recover from a LAVA upgrade. In those cases, it was easier for us to just "start over". Today we use LAVA 2018.02. I've compiled a list that summarize the most pressing issues we've experience with LAVA: 1. Test development is slow. Several members of my team avoids test development because the process of developing a test with LAVA is tedious / very timeconsuming. I think it mostly boils down to making a change, pushing it to a Git repo, submitting a job, running the job and then watching the LAVA job output for result. This will in our environment take several minutes, just to verify a change in a test. I'm aware of the guidelines for making portable tests and I personally think we can be a lot better at it for single-node tests which could enable us to run testscripts on local devices, but we have also quite a number of multinode jobs that we find are difficult to run in any other environment than LAVA. We've also tried using hacksessions to speed up development (e.g you edit the tests on the DUT and then synchronize it back to your host once you're happy). This works quite well, but feels a bit hacky and if the hacksession timeout hits, you lose all your work ;-) 2. Can't test bootloaders. Several of our hardware contain FPGAs and the FPGA images / "firmware" is tightly bundled with the bootloader. In addition to configuring the FPGA, the bootloader also contains in-house developed code for firmware update that we would like to autotest. We have a _lot_ of bootloader variants and we need a way of testing it along with the Linux system. Our current setup is that we manually flash bootloaders in our LAVA lab and then cross our fingers that the Linux system we test on the device is compatible with the bootloader. The ideal situation for us would be to always test the Linux system and the matching bootloader together. Granted, the better solution would be to move away the FPGA loading from the bootloader, but this is a design chosen by our SoC provider and we prefer to keep it. We also manage a "LTS" branch of our Linux distro. We support it for several years and we need to ensure our test setup can test both our "master" branch and our LTS branch. With our current setup, this is not possible because all devices in our lab runs a bootloader that was manually flashed at some arbitrary time. We've considered setting up several hardware of the same type, but with different bootloaders and then let LAVA treat them as different device types. This would work but our lab would fill up fast and the usage of each device would be low. We also tried making jobs that boot a golden Linux system, write the software under test (including bootloader), reboot and run tests. This did work, but required customization per device since the test has to know where to write the bootloader. We would rather put this information into the LAVA device type definition somehow. 3. Can't write to NAND. Our devices are NAND-based and we use UBIFS ontop of UBI. We have not found a way for LAVA to write NAND because the LAVA mechanism that embeds stuff into the rootfs before deployment doesn't support UBIFS. At the moment, we ramboot our devices but we are now at a point where our devices OOM because they don't have enough RAM to fit both the rootfs and running the tests. Our current solution is to split the job into several jobs that each run a smaller amount of tests, but this is less than ideal because it makes our test run slower (we need to reboot) and it is a bit annoying that test results are spread across several jobs. We have our own deployment tool that would be nice to integrate into LAVA as a deployment method. It accepts a kernel, rootfs, DT and bootloader and will write it using TFTP or DFU (USB) depending on target. To avoid forking all of LAVA in order to implement such deploy method, is there any plugin architecture that allows us to install additional boot methods alongside the LAVA packages? I'd love to get your views on these issues and if there is a solution when using LAVA. Best regards, Magnus.

8 years

Repeat action block and auto-login issue

by Hemanth K V

Hello Lava-Users, We are running tests on imxqsaberlite target in LAVA .The Lava version that we are using is 2018.4 release. We are facing 2 issues 1.Related to auto_login section in boot action.When we are specifying the username as root in auto_login section sometimes out of 5 tries once the root is getting changed as "oroot" due to which test execution is failing Following is the boot action part of job definition - boot: namespace: nfs_boot repeat: 3 method: u-boot commands: nfs auto_login: login_prompt: 'login:' username: root prompts: - 'root@mx6q:~#' timeout: minutes: 10 Following is the job log output Matched prompt #6: login: Sending username root root mx6q login:root auto-login-action: Wait for prompt ['root@mx6q:~#', 'Login incorrect', 'Login timed out'] (timeout 00:07:24) orot 2.Related to the Repeat action block of LAVA https://validation.linaro.org/static/docs/v2/actions-repeats.html?highlight… We are trying to use repeat action in boot action part of job definition as we want to repeat booting of the target 3 times.Issue we are facing is it is not stopping at the end of 3 iterations of boot and it is continuing till the timeout specified duration of the job. Thanks, Hemanth.

8 years

Re: [Lava-users] Running large test suites

by Tim Jaacks

Hi Dan, >Here's an example of generating lava templates using jinja2. It's probably more complicated than you need. > >See >https://git.linaro.org/ci/job/configs.git/tree/openembedded-lkft/lava-job-d… >for a directory of templates, and see >https://git.linaro.org/ci/job/configs.git/tree/openembedded-lkft/submit_for… >for the python code that does the generation. Lastly, you can run https://git.linaro.org/ci/job/configs.git/tree/openembedded-lkft/test_submi… >and it will generate all of the YAML files into "./tmp". > >Like I said, this is likely more complicated than you are looking for. I suggest starting simpler using https://pypi.python.org/pypi/jinja2-cli/0.6.0. Thank you, that really helps a lot. We want to trigger the LAVA jobs from Jenkins as well, and we need lots of metadata because the tests will be part of our release notes in the end. So no, this is definitely not more complicated than we need. In fact, this is a very good starting point for us. You should think about adding a chapter to the LAVA documentation about how to generate YAML job submissions via templates. I assume we are not the only ones facing this problem. And I had basically no experience with jinja2 at all before evaluating LAVA, so I would not have come up with the idea of using this mechanism for the job submissions myself. 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

8 years

Fault 400: 'Unable to store the configuration for device_hostname on disk'

by Sathyamurthy, Raghuram

Hi, I am getting the below error while adding device-dictionary for my device "xyz" for my worker "worker" $ sudo lava-tool device-dictionary http://worker@url/RPC2/ xyz --update xyz.jinja2 Updating device dictionary for xyz on http://worker@url/RPC2/ <Fault 400: 'Unable to store the configuration for xyz on disk'> Please help. Regards, Raghu

8 years

How to add pub key to download source code after LAVA create the container

by Yuan, ZhanghuiX

Hi LAVA mainters, Nice to meet you. I want to add my pub key after LAVA installed container. But I don't which parameters should I need add in my job xx.yaml file. Could you give me some help and advice. >>>>>>>>>>>>>>> Some part information of my xx.yaml file: <<<<<<<<<<<<<<<<<<<<<<<<<< actions: - deploy: timeout: minutes: 300 to: lxc os: ubuntu packages: [python, wget, unzip, python-pexpect, python-serial, openssh-server] - boot: prompts: - '[root(a)(.*) /]#' timeout: minutes: 300 method: lxc - test: timeout: minutes: 300 gefinitionsg - run: steps: lava-test-shell: echo "------------------------------------- debug 1 -----------------------" lava-test-shell: wget --no-proxy -q http://otcpkt.bj.intel.com/downloads/pubkey/sys_oak.zip lava-test-shell: mkdir -p ~/.ssh lava-test-shell: unzip sys_oak.zip -d ~/.ssh definitions: - repository: ssh://sys_oak@git-amr-4.devtools.intel.com:29418/pk_osi_test-source.git from: git path: <device>/<test_type>_lxc.yaml name: <test_type>-<device> params: BUILD_NUMBER: <build_number> IMAGE_URL: <image_url> PRODUCT: <build_name> IRC_USER: "sys_oak" PUB_KEY: "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDCDJvT5UPE*************************** >>>>>>>>>>>>>>> Some part information of my xx.yaml file: <<<<<<<<<<<<<<<<<<<<<<<<<< Best Regards Zhanghui Yuan OTC Production Kernel Integration Test

8 years

LAVA test dependencies in jobs

by Anibal Limon

Hi, We are doing boot regression test using (in DB{410,820}c) an Android boot image that contains a ramdisk [1]. We aim to do functional testing in a way that if the basic testing fails the next test definition dosen't run, that's implies dependencies over -test entries in the job [2]. Does LAVA test shell provides this kind of functionality? If not, any idea to achieve this functionality. Regards, Anibal [1] https://validation.linaro.org/scheduler/job/1884978/definition [2] https://validation.linaro.org/scheduler/job/1884978/definition#defline117

8 years

Automation & Risk

by Neil Williams

The LAVA software team created a document to summarise the experience, so far, of automating devices for validation and that document formed the basis of a presentation at Linaro Connect in Hong Kong earlier this year by Steve McIntyre. The content has been living inside a wiki within Linaro but there have been delays in making the URL visible to anonymous viewers. I have therefore migrated the content to my blog: https://linux.codehelp.co.uk/automation-and-risk.html A link to the presentation is included. Available under CC BY-SA 3.0 and shortly to appear on planet.debian.org Please share with anyone involved in designing hardware which is likely to end up on your desk for automation support and anyone else who may be interested in the hardware challenges of device automation. A second shorter post on Firmware Best Practices will follow - some of the elements of that document were also covered in the presentation at Connect. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

8 years

答复: Some problem I met in Setting up CI environment using Lava2

by Chenchun (coston)

发件人: Neil Williams [mailto:neil.williams@linaro.org] 发送时间: 2018年6月26日 16:25 收件人: Chenchun (coston) <chenchun7(a)huawei.com> 抄送: Lava Users Mailman list <lava-users(a)lists.linaro.org>; Lixuan (F) <joe.lixuan(a)huawei.com>; Fengguilin (Alan) <fengguilin(a)huawei.com>; yangjianxiang <yangjianxiang(a)huawei.com>; Yewenzhong (jackyewenzhong) <jack.yewenzhong(a)huawei.com>; Liyuan (Larry, Turing Solution) <Larry.T(a)huawei.com>; zengmeifang <zengmeifang(a)huawei.com>; pangbo (A) <pangbo6(a)huawei.com>; liuchunfeng (A) <liuchunfeng2(a)huawei.com>; Zhangyi ac <zhangyi.ac(a)huawei.com> 主题: Re: [Lava-users] Some problem I met in Setting up CI environment using Lava2 On Tue, 26 Jun 2018 at 09:08, Chenchun (coston) <chenchun7(a)huawei.com<mailto:chenchun7@huawei.com>> wrote: Hi all Problem 1: I find Lava2 re-download Test case repository if more than two test suite needed test in a lava job. Personal think this is waste of time. How can I make lava download Test case repository only once in a lava job ( ps : all of our test suite in some repository) .I want to know lava can do or cant not do, if can please tell me how to do THX. Not currently supported. We already support shallow clones by default and you can use the history option to remove the .git directory if you are short of space. https://staging.validation.linaro.org/static/docs/v2/test-repositories.html… We have looked at various options for this support - none were reliable across all devices & test jobs at scale. Not due to short of space But spent so many time to re-download Problem 2: As all we know lava must install os before execute the test task in standard procedure. But in our practical application we find no need mechanical implementation of the Process. In some case, we just need install os only ones and repeated test, even we install manually os and just use lava to do test. We want lava2 like M-lab install os and execute test task uncoupling. we met the problems : can not judge the os installed in DUT(device under test ) whether is our SUT(system under test). All caused by very little information can we read from DUT. I want to know how can I uncoupling install system and execute test ,user can choose only install os 、only execute test 、install os and execute test 、install os ones and repeat execute test ... That is entirely down to your own test shell definitions - follow best practice for portability and then run separate test actions. Do not use simplistic testing with the problems of persistence - each test job needs to start with a clean setup, not whatever was left behind by a previous test job. Please explain in more detail what you are actually trying to achieve. The test writer can already choose to install (i.e. deploy) and then test - the test job specifies deploy, boot and test actions. *If* the test writer knows that it is then safe to run other tests, those can be added into another job by extending the list of test definitions used by the action. Not all device-types support rebooting the device between test actions in the same test job. This is a limitation of the hardware. We want lava more smarter. do not re-deploy system if more than two lava job show the same type system(centos、ubuntu、debian)—just deploy system ones. We have eliminated destructive cases problem 3: According to your experience, optimally how many DUT can mount under a lava worker and what is a constrain bottleneck? That depends on a wide range of factors. * What kind of test jobs are being run on the worker? ** TFTP is lighter load, fastboot is high load (1 CPU core per fastboot device + at least 1 core for the underlying OS) * What is the I/O performance of the worker? ** Many images need manipulation and that can produce high I/O load spikes * Infrastructure limits play a role as well - network switch load and LAN topology. There is no definitive answer to your question. Start small, scale slowly and test with known good functional tests at every change. We will try fellow the rules: Start small, scale slowly and test with known good functional tests at every change. Best coston _______________________________________________ Lava-users mailing list Lava-users(a)lists.linaro.org<mailto:Lava-users@lists.linaro.org> https://lists.linaro.org/mailman/listinfo/lava-users -- Neil Williams ============= neil.williams(a)linaro.org<mailto:neil.williams@linaro.org> http://www.linux.codehelp.co.uk/

8 years

Fwd: Some problem I met in Setting up CI environment using Lava2

by Neil Williams

The mailing list does not accept a long list of people on CC - everyone who is expecting a reply from the list needs to be subscribed to the list. (This is part of the spam management for the list.) ---------- Forwarded message --------- From: Neil Williams <neil.williams(a)linaro.org> Date: Tue, 26 Jun 2018 at 09:25 Subject: Re: [Lava-users] Some problem I met in Setting up CI environment using Lava2 To: <chenchun7(a)huawei.com> Cc: Lava Users Mailman list <lava-users(a)lists.linaro.org>, < joe.lixuan(a)huawei.com>, <fengguilin(a)huawei.com>, <yangjianxiang(a)huawei.com>, <jack.yewenzhong(a)huawei.com>, <Larry.T(a)huawei.com>, <zengmeifang(a)huawei.com>, <pangbo6(a)huawei.com>, <liuchunfeng2(a)huawei.com>, <zhangyi.ac(a)huawei.com> On Tue, 26 Jun 2018 at 09:08, Chenchun (coston) <chenchun7(a)huawei.com> wrote: > Hi all > > Problem 1: > > I find Lava2 re-download Test case repository if more than two test > suite needed test in a lava job. Personal think this is waste of time. How > can I make lava download Test > > case repository only once in a lava job ( ps : all of our test suite in > some repository) .I want to know lava can do or cant not do, if can please > tell me how to do THX. > Not currently supported. We already support shallow clones by default and you can use the history option to remove the .git directory if you are short of space. https://staging.validation.linaro.org/static/docs/v2/test-repositories.html… We have looked at various options for this support - none were reliable across all devices & test jobs at scale. > > Problem 2: > > As all we know lava must install os before execute the test task in > standard procedure. But in our practical application we find no need > mechanical implementation of the > > Process. In some case, we just need install os only ones and repeated > test, even we install manually os and just use lava to do test. We want > lava2 like M-lab install os and > > execute test task uncoupling. we met the problems : can not judge the os > installed in DUT(device under test ) whether is our SUT(system under test). > All caused by very little > > information can we read from DUT. I want to know how can I uncoupling > install system and execute test ,user can choose only install os 、only > execute test 、install os and execute > > test 、install os ones and repeat execute test ... > That is entirely down to your own test shell definitions - follow best practice for portability and then run separate test actions. Do not use simplistic testing with the problems of persistence - each test job needs to start with a clean setup, not whatever was left behind by a previous test job. Please explain in more detail what you are actually trying to achieve. The test writer can already choose to install (i.e. deploy) and then test - the test job specifies deploy, boot and test actions. *If* the test writer knows that it is then safe to run other tests, those can be added into another job by extending the list of test definitions used by the action. Not all device-types support rebooting the device between test actions in the same test job. This is a limitation of the hardware. > > problem 3: > > According to your experience, optimally how many DUT can mount under a > lava worker and what is a constrain bottleneck? > That depends on a wide range of factors. * What kind of test jobs are being run on the worker? ** TFTP is lighter load, fastboot is high load (1 CPU core per fastboot device + at least 1 core for the underlying OS) * What is the I/O performance of the worker? ** Many images need manipulation and that can produce high I/O load spikes * Infrastructure limits play a role as well - network switch load and LAN topology. There is no definitive answer to your question. Start small, scale slowly and test with known good functional tests at every change. > > Best > > coston > > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lava-users > -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/ -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

8 years

← Newer
1
...
4
5
6
7
8
9
10
...
36
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Lava-users