- lava-users - op-lists.linaro.org

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.

7 years, 9 months

2
1
0 0

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

7 years, 9 months

4
5
0 0

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

7 years, 9 months

2
1
0 0

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

7 years, 9 months

2
1
0 0

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

7 years, 9 months

2
1
0 0

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/

7 years, 9 months

1
0
0 0

答复: 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/

7 years, 9 months

2
1
0 0

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/

7 years, 9 months

1
0
0 0

Some problem I met in Setting up CI environment using Lava2

by Chenchun (coston)

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. 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 ... problem 3: According to your experience, optimally how many DUT can mount under a lava worker and what is a constrain bottleneck? Best coston

7 years, 9 months

1
0
0 0

Running unit tests

by Edmund Szeto

Hi All, I am having a bit of problem running the lava_scheduler_app unit tests as per the instructions at https://validation.linaro.org/static/docs/v2/dispatcher-testing.html. I keep getting errors such as the following: $ sudo ./ci-run lava_scheduler_app.tests.test_device.TestTemplates.test_x86_template + set -e + getopts :pdty opt + shift 0 + pep8 --ignore E501,E722 . + '[' -n '' ']' + echo 'Removing old .pyc files and cache' Removing old .pyc files and cache + echo + find . -name '*.pyc' -delete + rm -rf ./.cache/ + rm -rf ./__init__.py + echo 'Starting unit tests' Starting unit tests + echo + '[' -z '' -a -z '' -a -z '' ']' + echo 'If it exists, a broken test database will be deleted without prompting.' If it exists, a broken test database will be deleted without prompting. + python3 ./lava_server/manage.py test --noinput -v 2 lava_scheduler_app linaro_django_xmlrpc.tests lava_results_app Traceback (most recent call last): File "./lava_server/manage.py", line 78, in <module> main() File "./lava_server/manage.py", line 74, in main execute_from_command_line(django_options) File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 364, in execute_from_command_line utility.execute() File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 356, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/lib/python3/dist-packages/django/core/management/commands/test.py", line 29, in run_from_argv super(Command, self).run_from_argv(argv) File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 283, in run_from_argv self.execute(*args, **cmd_options) File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 330, in execute output = self.handle(*args, **options) File "/usr/lib/python3/dist-packages/django/core/management/commands/test.py", line 62, in handle failures = test_runner.run_tests(test_labels) File "/usr/lib/python3/dist-packages/django/test/runner.py", line 600, in run_tests suite = self.build_suite(test_labels, extra_tests) File "/usr/lib/python3/dist-packages/django/test/runner.py", line 526, in build_suite suite = reorder_suite(suite, self.reorder_by, self.reverse) File "/usr/lib/python3/dist-packages/django/test/runner.py", line 640, in reorder_suite partition_suite_by_type(suite, classes, bins, reverse=reverse) File "/usr/lib/python3/dist-packages/django/test/runner.py", line 663, in partition_suite_by_type partition_suite_by_type(test, classes, bins, reverse=reverse) File "/usr/lib/python3/dist-packages/django/test/runner.py", line 663, in partition_suite_by_type partition_suite_by_type(test, classes, bins, reverse=reverse) File "/usr/lib/python3/dist-packages/django/test/runner.py", line 667, in partition_suite_by_type bins[i].add(test) File "/usr/lib/python3/dist-packages/django/utils/datastructures.py", line 17, in add self.dict[item] = None TypeError: unhashable type: 'TestSchedulerAPI' I have backed out all my changes and I still get the TypeErrors. I tried the latest in the master branch, and also the 2018.5 release tag. Could someone please let me know what I am doing incorrectly? Thanks! Cheers, Edmund This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

7 years, 9 months

2
4
0 0

[Lava BBB01 health check problems?!] Wrong Ramdisk Image Format - Ramdisk image is corrupt or invalid

by Zoran S

Hello Folks, Long time no see. Seems that I am back (for limited time) to Lava testing, and after all the setups and catches 22, I managed to get to the bottom of it, within few days. I have interesting problem to report. vagrant@stretch:/etc/lava-server/dispatcher-config/device-types$ dpkg -l lava-server lava-dispatcher Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==========================================-==========================-==========================-========================================================================================== ii lava-dispatcher 2018.5-3~bpo9+1 amd64 Linaro Automated Validation Architecture dispatcher ii lava-server 2018.5-3~bpo9+1 all Linaro Automated Validation Architecture server ## Issue Background Issue CIP testing #16 seems to be very similar: Beaglebone Black health-check job is failing at restart ## Issue description Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid ## Acceptance criteria The tftp 0x88080000 22/tftp-deploy-on2jld77/ramdisk/ramdisk.cpio.gz.uboot Using cpsw devtftp 0x88080000 22/tftp-deploy-on2jld77/ramdisk/ramdisk.cpio.gz.uboot The initramdisk is built by the following instructions: https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipsystembuild… I used both BusyBox 28.0 and latest stable BusyBox 28.4 (failure seems to be the same)! Should download seamlessly, but it does not. It reports that the image is corrupt. The full log is at: local test of ramdisk test on bbb - Lava job 22 https://pastebin.com/y9n4GM5G The .yaml file is at: [lava 2018.5-3] job_name: local test of ramdisk test on bbb https://pastebin.com/kqS2dqWM _______ Namely, the download order is somehow scrambled! Thank you, Zoran Stojsavljevic

7 years, 9 months

2
1
0 0

lava-logs crash

by Corentin Labbe

Hello Since our upgrade to 2018.4 we experience lots of lava-logs crash with the following trace in lava-logs.log 2018-06-20 13:43:08,964 INFO Saving 1 test cases 2018-06-20 13:43:16,614 DEBUG PING => master 2018-06-20 13:43:16,618 DEBUG master => PONG(20) 2018-06-20 13:43:19,524 INFO Saving 21 test cases 2018-06-20 13:43:29,535 INFO Saving 62 test cases 2018-06-20 13:43:37,983 DEBUG PING => master 2018-06-20 13:43:37,985 DEBUG master => PONG(20) 2018-06-20 13:43:39,541 INFO Saving 3 test cases 2018-06-20 13:43:58,009 DEBUG PING => master 2018-06-20 13:43:58,010 DEBUG master => PONG(20) 2018-06-20 13:44:01,770 INFO Saving 9 test cases 2018-06-20 13:44:01,771 ERROR [EXIT] Unknown exception raised, leaving! 2018-06-20 13:44:01,771 ERROR 'bool' object has no attribute 'pk' Traceback (most recent call last): File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py", line 181, in handle self.main_loop() File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py", line 232, in main_loop self.flush_test_cases() File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py", line 217, in flush_test_cases TestCase.objects.bulk_create(self.test_cases) File "/usr/lib/python3/dist-packages/django/db/models/manager.py", line 85, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 441, in bulk_create self._populate_pk_values(objs) File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 404, in _populate_pk_values if obj.pk is None: AttributeError: 'bool' object has no attribute 'pk' 2018-06-20 13:44:02,109 INFO [EXIT] Disconnect logging socket and process messages 2018-06-20 13:44:02,109 DEBUG [EXIT] unbinding from 'tcp://0.0.0.0:5555' 2018-06-20 13:44:02,185 INFO Saving 9 test cases 2018-06-20 13:44:02,186 ERROR [EXIT] Unknown exception raised, leaving! 2018-06-20 13:44:02,186 ERROR 'bool' object has no attribute 'pk' Traceback (most recent call last): File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py", line 201, in handle self.flush_test_cases() File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-logs.py", line 217, in flush_test_cases TestCase.objects.bulk_create(self.test_cases) File "/usr/lib/python3/dist-packages/django/db/models/manager.py", line 85, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 441, in bulk_create self._populate_pk_values(objs) File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 404, in _populate_pk_values if obj.pk is None: AttributeError: 'bool' object has no attribute 'pk' 2018-06-20 13:44:02,186 INFO Saving 9 test cases Any idea on how to fix this ? Thanks Regards

7 years, 9 months

2
2
0 0

How to handle reboots within tests

by Tim Jaacks

Hello everyone, I have two cases in which I need to reboot my device during tests: 1. Reboot is active part of the test (e.g. store some persistent settings, reboot, check if persistent settings are correctly loaded after reboot) 2. Reboot is triggered and has to be evaluated (e.g. activate watchdog, stop resetting it, wait, check if system reboots automatically) How can I hadle these two cases in LAVA? 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<http://www.garz-fricke.com/> SOLUTIONS THAT COMPLETE! [cid:image001.jpg@01D407D7.E4232AA0] Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz

7 years, 9 months

3
4
0 0

Re: [Lava-users] [Lava-announce] 2018.5.post1 Security hot fix

by Remi Duraffort

Dear users, the corresponding CVEs has been assigned: * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12563 * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12564 * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12565 Regards 2018-06-15 23:29 GMT+02:00 Neil Williams <neil.williams(a)linaro.org>: > 2018.5.post1 > ============ > > During routine development, a new security scanning tool (bandit) was used > on the LAVA codebase. Three security problems were found relating to the > Job Submit UI and the loading of YAML files through XMLRPC. The problems > date back to 2013, possibly earlier, so all releases of LAVA are affected. > > Fixes were developed and have now been released. > > https://review.linaro.org/#/c/25917/ Remove the ability to paste > URLs in the submit page > > https://review.linaro.org/25918 Use requests instead of urlopen > > https://review.linaro.org/25919 Use yaml.safe_load when parsing > user data > > Thanks to Remi Duraffort for identifying and fixing the issues. > > Note: These changes are not trivial to backport to previous releases. It > is possible but some familiarity with the codebase will be required. We > have packed a lot of changes into the time since the end of the migration > and we are hoping to have a more stable time ahead. The LAVA software team > recommend that all instances look to upgrade to 2018.5.post1. Our apologies > for these problems. > > We are NOT aware of any exploits using these issues but now that the > problems are public, it is prudent to apply the available fixes before > anything happens. > > We expect to make more use of bandit and similar tools in future. > > CVE's have been requested but we don't have the CVE numbers back at this > time. > > The production repo now carries these changes as 2018.5.post1-1+stretch > > An upload to Debian unstable will follow in due course. (The Debian > security team were notified once we had a fix.) An upload to Debian > Stretch to update 2016.12-1 is being prepared. > > -- > > Neil Williams > ============= > neil.williams(a)linaro.org > http://www.linux.codehelp.co.uk/ > > _______________________________________________ > Lava-announce mailing list > Lava-announce(a)lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lava-announce > > -- Rémi Duraffort LAVA Team

7 years, 9 months

1
0
0 0

question about result parse pattern in monitor action

by Chase Qi

Hi, To match the result lines in the following log from zephyr sanity test: — output — ***** Booting Zephyr OS v1.11.0-1194-g4b0b65c1b ***** Running test suite poll_api =================================================================== starting test - test_poll_no_wait PASS - test_poll_no_wait =================================================================== starting test - test_poll_wait PASS - test_poll_wait =================================================================== starting test - test_poll_multi PASS - test_poll_multi =================================================================== =================================================================== — output ends — I started with this pattern: '(?P<result>(PASS|FAIL))\s-\s(?P<test_case_id>\w+)', but the test_case_ids it matched are incomplete, shown as below. Refer to https://validation.linaro.org/scheduler/job/1807112 test_po test_poll_ test_poll_mu I also tried the following patterns, but no lucky. '(?P<result>(PASS|FAIL))\s-\s(?P<test_case_id>\w+)$’ matched sth similar as above, but the not the same. Refer to https://validation.linaro.org/scheduler/job/1807117 '(?P<result>(PASS|FAIL))\s-\s(?P<test_case_id>\w+)\n’ didn’t match anything. A search online hit https://stackoverflow.com/questions/14689531/how-to-match-a-new-line-charac… . Then I tried manually in python shell. '(?P<result>(PASS|FAIL))\s-\s(?P<test_case_id>\w+)’ works, '(?P<result>(PASS|FAIL))\s-\s(?P<test_case_id>\w+)$’ works only when re.M enabled. — debug — >>> s "\nTrying ::1...\nConnected to localhost.\nEscape character is '^]'.\nFRDM-KW41Z-01 7113 [115200 N81]\n***** Booting Zephyr OS v1.11.0-1194-g4b0b65c1b *****\nRunning test suite poll_api\n===================================================================\nstarting test - test_poll_no_wait\nPASS - test_poll_no_wait\n===================================================================\nstarting test - test_poll_wait\nPASS - test_poll_wait\n===================================================================\nstarting test - test_poll_multi\nPASS - test_poll_multi\n===================================================================\n===================================================================\n" >>> p.search(s).group() 'PASS - test_poll_no_wait' >>> p = re.compile(r'(?P<result>(PASS|FAIL))\s-\s(?P<test_case_id>\w+)$') >>> p.search(s).group() Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'NoneType' object has no attribute 'group' >>> p = re.compile(r'(?P<result>(PASS|FAIL))\s-\s(?P<test_case_id>\w+)$', re.M) >>> p.search(s).group() 'PASS - test_poll_no_wait’ — ends — Could you please advise me how to handle the parsing with the monitor action? Thanks, Chase

7 years, 10 months

2
2
0 0

lavaserver Database

by Conrad Djedjebi

Good morning everyone, I would like to know if the default password for lavaserver database created in Postgresql is available somewhere in the default configuration files? Also, Is there a way to find out the default password for lavaserver user in the host? regards,

7 years, 10 months

2
4
0 0

NFS mount failures on Debian stretch

by Matt Hart

Hi all, For the boards I am using in my LAVA lab, if I try an NFS job on my jetson-tk1, it fails to mount the filesystem from the debian installed NFS server. http://lava.streamtester.net/scheduler/job/120050 my nfs-kernel-server version is 1:1.3.4-2.1, which was installed with LAVA from Debian Stretch. If I add 'vers=3' to the kernel NFS command line, it mounts the filesystem successfully. http://lava.streamtester.net/scheduler/job/120049 This is being discussed here to make it a default option https://review.linaro.org/#/c/25666/ But really this does seem like there's an issue with the NFS kernel server in Debian Stretch. Has anyone else had this issue? Matt

7 years, 10 months

2
1
0 0

u-boot devices broken after 2018.4 upgrade, strange u-boot interaction

by Kevin Hilman

Hello, After upgrading to 2018.4 (also tried .5) many of our device-types using base-uboot.jinja2 are broken. While I really like the major improvement to run commands individually, there seems to be some problems and the LAVA output logs are very confusing, showing concatenated strings, etc. Here is an example for an upstream device-type (meson-gxbb-p200), and here is where it starts interacting with u-boot: http://khilman.ddns.net/scheduler/job/15#L336 The "Parsed boot commands" look perfect, and all the commands in black all look good, but notice the commands at the u-boot prompt, they appear to be concatenated, starting right away at the "setenv initrd_high ..." However, observing the commands on the actual serial port (I use conmux, so can observe the serial console interactions directly), I'm not seeing concatenated strings, but the "setenv serverip ..." never shows up, so the TFTP downloads fail, and the job fails. Here's what I see directly on the serial console: Hit Enter or space or Ctrl+C key to stop autoboot -- : 0 gxb_p200_v1# gxb_p200_v1#setenv autoload no gxb_p200_v1#setenv initrd_high 0xffffffff gxb_p200_v1#setenv fdt_high 0xffffffff gxb_p200_v1#dhcp dwmac.c9410000 Waiting for PHY auto negotiation to complete.. done Speed: 100, full duplex BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 192.168.0.216 (267 ms) gxb_p200_v1#tftp 0x1080000 14/tftp-deploy-5v1wo7fv/kernel/uImage Speed: 100, full duplex Using dwmac.c9410000 device TFTP from server 192.168.0.1; our IP address is 192.168.0.216 Filename '14/tftp-deploy-5v1wo7fv/kernel/uImage'. Load address: 0x1080000 Loading: * TFTP error: 'File not found' (1) Even more interesting is that on the same setup, a beaglebone-black device, using the same base-uboot.jinja2 is working just fine: http://khilman.ddns.net/scheduler/job/1 Any help would be appreciated, I'm thoroughly confused by what's going on here. Thanks, Kevin

7 years, 10 months

2
7
0 0

QEMU health check apparently not running

by Robert Marshall

At some point last week - I think because of network connectivity issues a job got stuck and I I cancelled it, it when run again it again appeared to hang. I again cancelled it and am now seeing the health check not start (at least no output appears on the job's webspage. Looking at the output.yaml (in /var/lib/lava-server/default/media/job-output/2018/05/23/32 ) I see ... progress output for downloading https://images.validation.linaro.org/kvm/standard/stretch-2.img.gz - {"dt": "2018-05-23T07:39:54.728015", "lvl": "debug", "msg": "[common] Preparing overlay tarball in /var/lib/lava/dispatcher/tmp/32/lava-overlay-aye3n2ke"} - {"dt": - "2018-05-23T07:39:54.728root@stretch:/var/lib/lava-server/default/media/job-output/2018/05/23/32 But none of this appears in http://localhost:8080/scheduler/job/32 and at the head of that page I see the message: Unable to parse invalid logs: This is maybe a bug in LAVA that should be reported. which other logs are best for checking whether this is an error that should be fed back? (LAVA 2018.4) Robert

7 years, 10 months

2
4
0 0

Unable to run test on multiple devices using Lava-multi-node functionality

by Onkar Bokshe

Hi All, I am trying to run test on multiple ssh devices using multi-node functionality(protocols,tags and ssh connection) , device is detected in multi-node information as below but no unable to get the debug log i.e no actions are processing after devices detection please help me to resolve this. Following is working fine a) I am able to run test using single node on both devices b) Framework detects devices mentioned in protocols as mentioned below Mulitnode info : 125.0 <http://134.86.62.95/scheduler/job/125.0> (125) on: uno-ssh <http://134.86.62.95/scheduler/device/uno-ssh> as: node1 125.1 <http://134.86.62.95/scheduler/job/125.1> (126) on: nano-mel <http://134.86.62.95/scheduler/device/nano-mel> as: node2 125.2 <http://134.86.62.95/scheduler/job/125.2> (127) No device assigned as node2. Job Info is displaying : 13*6** Submitted* *ssh* python-test-suite obokshe May28, 8:47a.m. — — 12*5** Scheduling* uno-ssh <http://134.86.62.95/scheduler/device/uno-ssh> python-test-suite obokshe May28, 8:47a.m. — — *124 Scheduling* nano-mel <http://134.86.62.95/scheduler/device/nano-mel> python-test-suite obokshe May28, 8:47a.m. — — Please find test definition used by me for lava-multinode test run at https://pastebin.com/Tdp7q6SF Thanks and Regards, Onkar

7 years, 10 months

2
3
0 0

Unable to run test on multiple devices using Lava-multi-node functionality

by Onkar Bokshe

Hi All, I am trying to run test on multiple ssh devices using multi-node functionality(protocols,tags and ssh connection) , device is detected in multi-node information as below but no unable to get the debug log i.e no actions are processing after devices detection please help me to resolve this. Following is working fine a) I am able to run test using single node on both devices b) Framework detects devices mentioned in protocols as mentioned below Mulitnode info : 125.0 <http://134.86.62.95/scheduler/job/125.0> (125) on: uno-ssh <http://134.86.62.95/scheduler/device/uno-ssh> as: node1 125.1 <http://134.86.62.95/scheduler/job/125.1> (126) on: nano-mel <http://134.86.62.95/scheduler/device/nano-mel> as: node2 125.2 <http://134.86.62.95/scheduler/job/125.2> (127) No device assigned as node2. Job Info is displaying : 13*6** Submitted* *ssh* python-test-suite obokshe May28, 8:47a.m. — — 12*5** Scheduling* uno-ssh <http://134.86.62.95/scheduler/device/uno-ssh> python-test-suite obokshe May28, 8:47a.m. — — *124 Scheduling* nano-mel <http://134.86.62.95/scheduler/device/nano-mel> python-test-suite obokshe May28, 8:47a.m. — — Please find test definition used by me for lava-multinode test run at https://pastebin.com/Tdp7q6SF Thanks and Regards, Onkar

7 years, 10 months

1
0
0 0

Test on Device which doesn't stop at bootloader

by Nikita Gupta

Hi Lava-Users, I have a device 'raspberry-pi' whose boot method doesn't stop at bootloader. I tried removing 'method' from boot-action but then it doesn't accept it as valid test job. Changing of method from u-boot to fastboot or to any other also gives error as not supported boot methods for this device. After device bring up, it gives u-boot interrupt timed-out and job gets incomplete. Is there any way thru which we can run tests on such devices? -- Regards, Nikita Gupta

7 years, 11 months

2
1
0 0

multiple devices job submission

by Hemanth K V

Hello Stevan, Thanks for quick response.Is there any reference of creating and assigning device tag to specific device. The issue I am facing is whatever device tags are created are getting default assigned to all devices. Thanks, Hemanth. ___________________________________________________________________________________________ Hi Hemanth, You can achieve this by adding device tags to the devices and then specifying which tags you'd like to use in the test job definition. Please take a look at https://validation.linaro.org/static/docs/v2/developing-tests.html#device-t… HTH, On 05/16/2018 12:26 PM, Hemanth K V wrote: >* Hello Lava-Users, *>>* When we have multiple devices of same device-type in LAVA Instance and *>* want to submit job on a particular device how can this be achieved in *>* LAVA.Tried to follow *>* https://validation.linaro.org/static/docs/v2/first-job.html <https://validation.linaro.org/static/docs/v2/first-job.html> but didn't *>* find how device can be specified. *>>* Thanks, *>* Hemanth. *>>>* _______________________________________________ *>* Lava-users mailing list *>* Lava-users at lists.linaro.org <https://lists.linaro.org/mailman/listinfo/lava-users> *>* https://lists.linaro.org/mailman/listinfo/lava-users <https://lists.linaro.org/mailman/listinfo/lava-users> *

7 years, 11 months

2
5
0 0

multiple devices job submission

by Hemanth K V

Hello Lava-Users, When we have multiple devices of same device-type in LAVA Instance and want to submit job on a particular device how can this be achieved in LAVA.Tried to follow https://validation.linaro.org/static/docs/v2/first-job.html but didn't find how device can be specified. Thanks, Hemanth.

7 years, 11 months

2
1
0 0

submit multinode tests via XML-RPC API

by steffen＠volkmann.com

Hi all, I am using the XML-RPC API to submit test jobs from a jenkins server to lava server. The used methode is described here: https://validation.linaro.org/api/help/#scheduler.jobs.submit In the case of multi node tests with first role is 'Server' and second role is "Client", the API returns a list of created job ID's (e.g. [500.0, 500.1]). How can I determine which ID is the 'Server' job and wich ID is the 'Client' job? Best Regards Steffen Volkmann

7 years, 11 months

2
1
0 0

support bootm and booti from a single device-type

by Kevin Hilman

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…

7 years, 11 months

2
2
0 0

Git duplication in test jobs

by Denis HUMEAU

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

7 years, 11 months

2
1
0 0

write test for already deployed system

by Nikita Gupta

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

7 years, 11 months

2
1
0 0

Installing LAVA from the git repos

by Robert Marshall

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…

7 years, 11 months

3
5
0 0

Unable to handle the test shell signal correctly

by Steffen Volkmann

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

7 years, 11 months

2
1
0 0

JobError / Job stuck in "Canceling" state

by Tim Jaacks

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

7 years, 11 months

3
8
0 0

Failed testing with QEMU

by Nguyễn Phong Cảnh

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

7 years, 11 months

2
6
0 0

Lava test Job key/value collection

by Niu, Deli

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

7 years, 11 months

4
4
0 0

Exchange data between DUT and LXC without multinode

by Tim Jaacks

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

7 years, 11 months

3
6
0 0

ssh deployment

by Hemanth K V

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.

7 years, 11 months

1
0
0 0

Callback results truncated

by Loys Ollivier

Hi all! I am working on writing LAVA test definitions and using the callback method to send test results to kernelCI. I noticed a sort of bug (?) when the test definitions are reporting a lot of elements. The job finishes and the callback gets triggered before the end of the log parsing. I think the callback method is not waiting for the parser to finish before sending the event. The callback output is then missing some test results. I made a simple test script that reports 300 test elements and returns. I can see in the LAVA log that they are all detected. But in the callback object there is around 80 test results. If I add a sleep (15 seconds) to hold the script before returning, the callback has the 300 test results bundled in the json. Did anyone experienced this before ? Thanks ! -- Loys OLLIVIER Baylibre

7 years, 11 months

5
7
0 0

devicedict: differentiate vendor and mainline uboot

by Corentin Labbe

Hello I want to introduce a devicedict parameter for differentiate mainline/vendor uboot. For example, amlogic boards could work with both, but thet have some differences like uboot prompt. So for example I have modified lava_scheduler_app/tests/device-types/meson-gxl-s905x-khadas-vim.jinja2 like this: +{% if use_vendor_uboot %} {% set bootloader_prompt = bootloader_prompt|default('kvim#') %} +{% endif %} Note that my way is to assume that mainline uboot is the default. But since non-amlogic boards (imx6q-sabrelite for example) will need the same way for differentiate, having an agreement on the name could be usefull. Does use_vendor_uboot is good for you ? Regards

7 years, 11 months

3
3
0 0

Re: [Lava-users] LAVA Scheduler App | Debugging

by Neil Williams

On 26 April 2018 at 10:26, Conrad Djedjebi <conrad.djedjebi(a)linaro.org> wrote: > Good morning everyone, > Changing to the lava-users mailing list. > > I am looking for some advice with the LAVA Scheduler App. > I noticed the file /etc/lava-server/settings.conf is not allowing users to > activate debug messages from the LAVA Scheduler App. > settings.conf is for Django settings (which includes support for DEBUG = True) and that can be enabled on any development instance. There is also the django-toolbar which can be used for UI work. https://staging.validation.linaro.org/static/docs/v2/debian.html#debugging-… > > Is there a way to activate debug messages in LAVA Scheduler App? If it is > the case, which file shall I edit? > > In the file /lava_scheduler_app/models.py for instance, some loggers are > being called. However, their outputs are not appearing during the job > process. > logging goes into the lava-master logs typically. Django exceptions go into the django.log There is more on this in the documentation. https://staging.validation.linaro.org/static/docs/v2/development.html#devel… https://staging.validation.linaro.org/static/docs/v2/pipeline-debug.html#de… -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 11 months

2
1
0 0

Deadlock in scheduler

by Quentin Schulz

Hi all, I've encountered a deadlock in my LAVA server with the following scheme. I have an at91rm9200ek in my lab that got submitted a lot of multi-node jobs requesting an other "board" (a laptop of type dummy-ssh). All of my other boards in the lab have received the same multi-node jobs requesting the same and only laptop. I had to take the at91rm9200ek out of the lab because it was behaving. However, LAVA is still scheduling multi-node jobs on the laptop which requires the at91rm9200ek as the other part of the job, while its status is clearly Maintenance. Now, until I put the at91rm9200ek back in the lab, all my boards are reserved and scheduling for a multi-node job and thus, my lab is basically dead. Let me know if I can be of any help debugging this thing or testing a possible fix. I'd have a look at the scheduler but you, obviously knowing the code base way better than I do, might have a quick patch on hand. Best regards, Quentin

7 years, 11 months

3
12
0 0

LAVA Notifications

by Conrad Djedjebi

Hi everyone, I am writing this email in order to have your opinion on the following : I am trying to use LAVA Notifications in my LAVA instance. I used the following template in one of my LAVA Test Job Definition files : notify: recipients: - to: method: email email: conrad.djedjebi(a)linaro.org criteria: status: complete verbosity: verbose compare: query: name: OPTEE_xtest_Jobs username: admin In that template, OPTEE_xtest_Jobs is the name of a query (testjob query) and admin is the user who owns that query. The query is listing all the completed jobs of that kind (I mean that the job I am currently running will be listed in the query OPTEE_xtest_Jobs). But each time my LAVA job is completed, I am not getting any email notification. In my user profil (my user name is conrad in the instance of LAVA I am working on), I already provided an email. So even if I used the following template, I should have get an email notification : notify: recipients: - to: method: email user: conrad criteria: status: complete verbosity: verbose compare: query: name: OPTEE_xtest_Jobs username: admin Is there a point I missed? If anyone has some advices to give me in order to get the notifications work, I would appreciate. regards,

7 years, 11 months

3
5
0 0

Re: [Lava-users] [Lava-announce] Merging the LAVA code source

by Zoran S

> lava-server and lava-dispatcher have been merged into a single source repository - lava If you ask me, this is the (very) questionable decision. Indeed!? lava-server is the front-end manager of the whole Lava test environment, while lava-dispatcher is the back-end. Connected/splitted by ZMQ protocol. And... They should be separately maintained, since they represent (very) different things. Essentially, they do (very) different tasks. They are, after all, apples and oranges. In other words, if you update/buy advanced/more expensive apples, you also force testers to update for nuthin'/buy for the loss the same oranges, they had before?! Is it the wise decision??? Two cents worth lamenting/analysis, Zoran _______ On Thu, Apr 19, 2018 at 3:41 PM, Neil Williams <neil.williams(a)linaro.org> wrote: > This is for particular note for developers as it changes the way that > reviews happen. > > If you've noticed a few reviews being abandoned, this is why. > > lava-server and lava-dispatcher have been merged into a single source > repository - lava > > lava-coordinator will follow in time, to ease the update of lava-coordinator > to Python3. > > This will, in future, allow easier testing of device integrations by > allowing the lava_scheduler_app unit tests to be linked to the > lava_dispatcher unit tests and have a single review which adds both sides of > the device support. > > There will be a lot of testing, as normal, so staging will be moving to > packages built from the new source repository tree. > > The old lava-server.git and lava-dispatcher,git repositories will become > read-only and will get no further code changes. All changes will be done in > lava.git > > https://git.linaro.org/lava/lava.git/ > > The documentation will be updated over the next few days. > > -- > > Neil Williams > ============= > neil.williams(a)linaro.org > http://www.linux.codehelp.co.uk/ > > _______________________________________________ > Lava-announce mailing list > Lava-announce(a)lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lava-announce >

7 years, 11 months

3
8
0 0

LAVA device tags

by Conrad Djedjebi

Good morning everyone, I am looking for few guidelines while using device tags in LAVA. The following link on LAVA Documentation's webpage explains how to use tags: https://staging.validation.linaro.org/static/docs/v2/developing-tests.html *However, once the tags are created, how to assign them to specific devices ?* I created tags in the scheduler app, but I am not finding any option in the web page of LAVA to assign a specific tag to a specific device. I saw many devices using tags in LAVA LAB. I hope the engineers who set up those devices can give me advice. If anyone else has some ideas about the trick around setting up those tags, I would appreciate. regards,

7 years, 11 months

3
4
0 0

Notify callback section causing health check to fail

by Robert Marshall

I had a notification section as follows notify: criteria: status: complete verbosity: verbose callback: url: http://localhost:8080/scheduler/job/{ID} method: POST token: mytoken content-type: json dataset: results recipients: - to: method: email email: address(a)site.org largely copying that from other examples as experiments. I've been seeing as I changed other parts of the health check that it was failing - timing out when booting the kernel. If I remove the callback section so notify: criteria: status: complete verbosity: verbose recipients: - to: method: email email: address(a)site.org then the health check consistently works. Is there some side effect going on here - or is my callback section causing the error, that localhost url should be ok. I'd expect it to always fail if there's a problem with it? Robert

7 years, 12 months

2
5
0 0

Installing LAVA-2018.2

by ankit gupta

Hi All, I have Debian 9(stretch) installed on my system and I want to install LAVA 2018.2 (server as well as the dispatcher), I used "*deb https://images.validation.linaro.org/production-repo <https://images.validation.linaro.org/production-repo> stretch-backports main*" repository for this. But it only installing LAVA 2017.7 version and it's only showing LAVA-server version 2018.2 in the upgrade but not LAVA-dispatcher-2018.2. Please suggest do I need to use some different repository for LAVA-dispatcher-2018.2? Thanks, Ankit

7 years, 12 months

3
6
0 0

Test Results

by mayuri mohite

Hello All, I am following https://validation.linaro.org/static/docs/v2/results-intro.html for charts and queries. My LAVA version is $ dpkg -l lava-server Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============================================-============================-============================-================================================================================================== ii lava-server 2018.2+7178.53c57de9-1+stret all Linaro Automated Validation Architecture server I have created "test job" query and added that query while running my job by adding below lines in my job notify: recipients: - to: method: email user: mayuri criteria: status: complete verbosity: verbose query: name: test_job username: mayuri But,I am getting only email notifications of test result for this job but, I am not getting any query related information or chart related information through this job. Only one message related to query I am getting which is " No query is set for results comparing" Please help me in to this. Regards, Mayuri

7 years, 12 months

3
3
0 0

Re: [Lava-users] fastboot in LXC LAVA

by Karsten Tausche

Hi Conrad, one of the devices in our setup is a nexus4, which will be most useful for reference. It has this device dictionary jinja: {% extends 'nexus4.jinja2' %} {% set adb_serial_number = 'someserialnumber' %} {% set fastboot_serial_number = 'someserialnumber' %} {% set device_info = [{'board_id': 'someserialnumber'}] %} {% set static_info = [{'board_id': 'someserialnumber'}] %} Maybe the fastboot_serial_number is the critical part here? I think some parts in the device type definition expected this value to be defined. The device type is the nexus4 definition that is included in LAVA. It runs with the health check from the LAVA repos [1], expect that Debian Sid is replaced by Stretch for LXC (seems that the scripts are not compatible with the current Sid). Adding the following test demonstrates some fastboot commands that work here: - test: namespace: tlxc timeout: minutes: 5 definitions: - from: inline name: some-fastboot-commands path: inline/some-fastboot-commands.yaml repository: metadata: format: Lava-Test Test Definition 1.0 name: some-fastboot-commands description: "some-fastboot-commands" run: steps: - adb start-server || true - adb wait-for-device - adb reboot bootloader - sleep 60 - fastboot devices -l - fastboot reboot - sleep 10 - adb wait-for-device The LAVA master+dispatcher are running on Debian Buster. LAVA version is 2018.2-1 (Debian packages). [1] https://git.linaro.org/lava-team/refactoring.git/tree/health-checks/nexus4.… Regards, Karsten On Wed, Apr 11, 2018 at 8:42 PM, Conrad Djedjebi <conrad.djedjebi(a)linaro.org > wrote: > Hi Karsten, > > Thank you for your answer, > > In the device dictionnary, I wrote the board_id number but neither > vendor_id nor product_id. I did the same thing as you. My adb serial number > is the same as my fastboot serial number. The board_id was set to > adb/fastboot serial number. > > It is really strange that the device is not being discovered in fastboot > mode. > > Can you share with me the configuration you used while testing fastboot? (Is > it a debian LXC?, which versions of fastboot/adb packages did you use? If > you runned a LAVA Test Job Definition, can you share it with me?). There > must be a detail I missed. > > Thanks > > Regards, > > Le mer. 11 avr. 2018 à 19:58, Karsten Tausche <karsten(a)fairphone.com> a > écrit : > >> Hi, >> >> out of curiosity I tried using fastboot on our setup. It works here >> without any issues. Could your problem be related to different USB meta >> data reported in adb and fastboot mode? The documentation here [1] suggests >> to add usb_vendor_id/usb_product_id to the device dictionary. However, >> these can be different in different boot stages. That's why I'm only >> setting board_id, which is for our devices the Android serial number and >> equal to iSerial reported by lsusb in fastboot and adb modes. >> >> Regards, >> Karsten >> >> [1] https://staging.validation.linaro.org/static/docs/v2/ >> admin-lxc-deploy.html#android-testing-with-lxc-support >> >> On Wed, Apr 11, 2018 at 4:31 PM, Conrad Djedjebi < >> conrad.djedjebi(a)linaro.org> wrote: >> >>> Hi Senthil, Chris, >>> >>> Thank you for your answers, >>> >>> >>> Senthil, the udev rule is triggered each time my device switch from >>> fastboot to adb mode or from adb to fastboot mode. I tried the process of >>> switching from adb to fastboot mode and vice versa in the container. Before >>> that, I uninstalled fastboot and adb packages from the host so there is no >>> way the adb and fastboot daemons of the host are creating conflicts with >>> the fastboot and adb deamons of the container. >>> >>> >>> Each time the device enters adb mode, the udev rule is triggered and I >>> can find the device with the command adb devices. But each time the device >>> switchs to fastboot mode, I can 't see it with the command fastboot >>> devices. I can see that the udev rule is triggered in the logs but the >>> device is still not appearing. *I even did a "lxc-device -n myLxcName >>> add /dev/bus/usb/001/056" manually to add the device to the container in >>> fastboot mode*. The add process was done properly but there was still >>> no fastboot device visible. >>> >>> >>> Chris, my container is successfully adding the usb device each time it >>> is plugged. In adb mode, I can easily run Android CTS or Android VTS test >>> suites on the device. So I think the container have access to >>> "/dev/bus/usb" and also to the host's network stack. >>> >>> >>> Someone told me he had to add an additional mount entry >>> into /usr/share/lxc/config/debian.common.conf otherwise fastboot could >>> not see his device from the container. I will explore that option. >>> >>> >>> >>> *I am still looking for a way to fix my issue anyway.* >>> >>> >>> >>> regards, >>> >>> >>> On 8 April 2018 at 14:47, Senthil Kumaran S <senthil.kumaran(a)linaro.org> >>> wrote: >>> >>>> Hi Conrad, >>>> >>>> On Sunday 08 April 2018 06:39 PM, Conrad Djedjebi wrote: >>>> > I am currently running jobs on a device through adb without issues. >>>> LAVA >>>> > is adding udev rules which make it possible for the LXC container to >>>> > successfully attach the target. >>>> > >>>> > However, when the device turns into fastboot mode, a "fastboot >>>> devices" >>>> > command in the LXC returns nothing. In fastboot mode, the USB link of >>>> > the device is added whereas the device is not listed among the >>>> fastboot >>>> > devices. >>>> >>>> The udev rules gets applied only when the device gets re-enumerated / >>>> restarted ie., on an udev add event. Otherwise the udev rule will not >>>> get applied to a device. For devices that are attached already when the >>>> job starts or if the device will not get re-enumerated, then use >>>> static_info as seen here - >>>> https://git-us.linaro.org/lava/lava-lab.git/tree/ >>>> staging.validation.linaro.org/master-configs/staging-master. >>>> lavalab/lava-server/dispatcher-config/devices/ >>>> staging-hi6220-hikey-r2-02.jinja2#n16 >>>> along with the device_info variable in the device dictionary. >>>> >>>> > In the host, a "fastboot devices" command returns the id of the >>>> device. >>>> >>>> I haven't faced this. But on the other hand when the host runs adb >>>> daemon, then it takes control of all the devices and the devices will >>>> not be visible from within the containers (LXC), even when the udev rule >>>> is applied. So care should be taken that 'adb' daemon is not running on >>>> the host. It is good, not to run any operation with fastboot too on the >>>> host, when the device is accessed via a container within the same host. >>>> >>>> Thank You. >>>> -- >>>> Senthil Kumaran S >>>> http://www.stylesen.org/ >>>> http://www.sasenthilkumaran.com/ >>>> >>> >>> >>> _______________________________________________ >>> Lava-users mailing list >>> Lava-users(a)lists.linaro.org >>> https://lists.linaro.org/mailman/listinfo/lava-users >>> >>> >>

8 years

2
2
0 0

[RFC] meta-lava

by Remi Duraffort

Hello, in order to validate that lava-server and lava-dispatcher are not regressing from one version to another, we added a lot of unit tests that are run every time a commit is pushed under review on https://review.linaro.org/ Before each release, we also run integrations tests on real hardware. However, we don't have access to most of the hardware currently supported by LAVA. Which mean that we cannot fully tests that LAVA is not regressing. For this reason, we created a project called meta-lava (currently available at https://framagit.org/ivoire/meta-lava) When run, meta-lava will: 1/ build a docker image for lava-server and lava-dispatcher * install lava-server and lava-dispatcher Debian packages from the production repo * pull the sources from git and overwrite installed sources 2/ start the containers in a specific network (meta-lava-net) 3/ wait for lava-slave to connect to the master 4/ launch a bunch of tests 5/ compare the results against the expected results In order to run the tests (as the meta-lava slave is *not* connected to any real hardware), we use a program called DummySys ( https://framagit.org/ivoire/DummySys) that will: * print the exact lines that lava is expecting * expect the exact inputs that lava is supposed to send This allow to test that lava will always behave exactly the same, for a given type of board, from one release to another. We can also simulate hardware failures, kernel crashes, ...and check that LAVA will continue to report the error correctly. meta-lava is currently running health-check for 24 device types (see https://framagit.org/ivoire/meta-lava/tree/master/tests/health-checks) and also checking for some common errors (like auto-login failures) or use cases (doing a GET on a given url when a job is finished). However without some help from the lava community we won't be able to add every boards that you care about nor all your specific use cases. So if you are interested, please raise your hand and contact me. Thanks -- Rémi Duraffort LAVA Team Linaro

8 years

1
0
0 0

fastboot in LXC LAVA

by Conrad Djedjebi

Good morning everyone, I would like to have your advices on the following subject : attaching a fastboot device in LXC container during a LAVA job. I am currently running jobs on a device through adb without issues. LAVA is adding udev rules which make it possible for the LXC container to successfully attach the target. However, when the device turns into fastboot mode, a "fastboot devices" command in the LXC returns nothing. In fastboot mode, the USB link of the device is added whereas the device is not listed among the fastboot devices. In the host, a "fastboot devices" command returns the id of the device. Did anyone here already faced that situation in the past? regards,

8 years

2
2
0 0

Trigger another job or task on completion of job

by Chetan Sharma

Hi Team, Can we trigger a another job/task of completion of one TestJob ? Can you share any reference if we can perform this action. -- Thanks & Regards Chetan Sharma

8 years

4
8
0 0

multinode+lxc/fastboot: reboot_to_fastboot, multinode device count

by Karsten Tausche

Hi Folks, I'm experimenting with Multinode for distributing tests across multiple Android DUTs (for using the CTS shards option at some point). The problem now is that the devices are rebooted to fastboot after the test although reboot_to_fastboot: false is specified in the test parameters. Apparently this parameter is not passed over from the multinode job to the LxcProtocol. Any idea on how to fix this? I attached a basic test shell definition that demonstrates the problem. A side question here: If I set the count of the worker role to something larger than 1, one of the job instance will stop incompletely with "error_msg: Invalid job data: ["Missing protocol 'lava-lxc'"] <http://localhost/results/testcase/817>", and the other two time out at "Multinode wait/sync". Am I missing something here or is this a limitation of the multinode/lxc protocol combination? Thank you, Karsten

8 years

2
3
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users