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

correspondence between uboot manual commands and job definition script commands.

by ljh_dev

I have an important question neet to clarify. For exampe when I manunl boot kernel by uboot, once board startup and into uboot interactive environment, I manual input follow command as: setenv image zImage_mx.... setenv nfsroot /rootfs/rootfs001.... ... if I whan to dispatcher to boot the board kernel, I need write job definition,Is it written like this?: boot: # list of boot methods which this device supports. methods: - u-boot: parameters: ... oe: commands: - setenv image zImage_mx.... - setenv nfsroot /rootfs/rootfs001....

6 years, 9 months

3
2
0 0

In which config file is described the path of uboot and kernel image or qemu?

by ljh_dev

Through web admin interface,I had added qemu device,and web devices list can display qemu device. It seems qemu device had startuped ok. We know that if linux device startup successfully it must included uboot and kernel image. But where are the uboot image and kernel image of qemu ? In which config file is described the path of uboot and kernel image?

6 years, 9 months

2
1
0 0

about qemu device dictionary config

by ljh_dev

I am building lava test system and currently add new addvice. According to document than step of "Adding a dictionary to the first QEMU device",follow config items neet to write to .jianja2 file. {% extends 'qemu.jinja2' %} {% set mac_addr = '52:54:00:12:34:59' %} {% set memory = '1024' %} Which file is to be writen to above config items ?does its directory path must be at path:/etc/lava-server/dispatcher-config/device-types/? How to make these items take effect immediatly?which command to use to take effect above config items? the document is not said.

6 years, 9 months

3
3
0 0

booting from USB thumb drive

by Hussin, Mohamad Noor Alim

Hi, I using LAVA version 2018.5-post1 to boot from USB thumb drive using Yocto Project's image. The LAVA job definition contain 2 deployments and booting actions. The first deployment is deploy the image to NFS server and boot using TFTP method. The second deployment is download an image to DUT and flash it on USB thumb drive. The DUT was able to download the image however it failed at flash to thumb drive. I'm use dd command as my tool to flash the image. Below is an example on lava-job definition and output message from LAVA. Due to this issue, I unable to boot from USB thumb drive. Did anyone know what is the problem? Snipped code from lava-job definition to deploy on USB thumb drive - deploy: timeout: minutes: 30 to: usb image: url: file:///home/user/image/yocto-image.xz compression: xz root_partition: 1 device: 'boot' download: tool: '/usr/bin/wget' prompt: 'HTTP request sent, awaiting response...' options: '--S {DOWNLOAD_URL}' os: oe The command from LAVA wget http://lavadisptcher.com/tmp/storage/image/yocto-image.xz | dd of=/dev/disk/by-id/<myusbthumdriveid> bs=4M This is the output message form LAVA after download flash the image 0+0 records in 0+0 records out 0 bytes copied Regards, Alim Hussin

6 years, 9 months

2
1
0 0

when add a new real device, do the uboot and kernel program need to be modified according to the lava specifications?

by ljh_dev

Hi, I think the lava web document is relatively simple.I still have some basic questions that didn’t understand. I want to add new real board(for example the arm development board,includes serial,ethernet interface etc)into lava environment. The board had ordinary uboot program, and uboot can download linux kernel image by ethernet interface. If treat it as DUT to run test,do the uboot and kernel program need to be modified or both configuration need to be modified?

6 years, 9 months

2
1
0 0

is the uboot image location specified in the job definition file?

by ljh_dev

When used real board(not qemu),is the uboot image location specified in the job definition file? If so, what keyword is used to indicate the uboot image location? The lava document description is not enough.

6 years, 9 months

2
1
0 0

How to rename a devicetype (and deprecate the old one)

by LABBE Corentin

Hello I have a cubietruck in LAVA, but its devicetype does not follow the rule "devicetype should be the same as devicetree name". Diverting from this rule, make difficult to find if the device is already handled by LAVA. I have lots of other boards which suffer the same problem (odroid-xu3 for example) Do you already have a process for renaming devicetype ? If not, why about duplicating to the correct name (sun7i-a20-cubietruck) and adding some tags (comment like "{# set deprecated = true}") to the old one. The deprectation warning could be printed by the LAVA web interface like the warning about not having health checks. After some release, the deprecated devicetype could be removed. Regards

6 years, 9 months

2
1
0 0

Does board test system must include PDU device?

by john zhang

Does board test system must include PDU device? If test system has no PDU and in job definition the boot action method is u-boot. When board had startup to enter linux interactive environment and submit job at this time. Then how does dispatcher restart the board?

6 years, 10 months

2
1
0 0

How to restart LAVA server master service after LAVA server host restart

by Yuan, ZhanghuiX

Hi LAVA team, I meet one critical error. We restart our LAVA server host machine. We can’t know how to restart our LAVA server service. Could you tell me how to restart LAVA server master service with detail steps? Thanks! The LAVA server is not installed by us. So we are not clear about this. BR/Zhanghui

6 years, 10 months

2
4
0 0

How the parameter {KERNEL} of boot action be passed ?

by ljh_dev

https://validation.linaro.org/static/docs/v2/actions-boot.html#index-9 - setenv loadkernel 'tftp {KERNEL_ADDR} {KERNEL}' It say the {KERNEL} will be substituted. Where is {KERNEL} variable defined? When I submit job definition by web interface,I did't find where to define {KERNEL} variable

6 years, 10 months

2
1
0 0

transfer_overlay file in the same location regardless of test

by Jorgen Peddersen

Hi, I'm trying to use a situation where a large bulk of similar jobs are being sent to several devices of the same device type. These devices require the 'transfer_overlay' option in order for the tests to work due to their setup. We currently are using a single master and worker on the same server. It seems that the same transfer overlay file location (i.e., /var/lib/lava/dispatcher/tmp/overlay-1.3.2.5.tar.gz) is used regardless of the job id and that some of our jobs are experiencing a collision trying to use different copies of that file at the same time. Thus, one of our jobs is deleting the transfer overlay file before another job tries to delete it and the second gets errors. This is the error LAVA produces when viewing the job in the GUI: File "/usr/bin/lava", line 11, in <module> load_entry_point('lava-tool==0.25', 'console_scripts', 'lava')() File "/usr/lib/python2.7/dist-packages/lava/tool/dispatcher.py", line 150, in run raise SystemExit(cls().dispatch(args)) File "/usr/lib/python2.7/dist-packages/lava/tool/dispatcher.py", line 140, in dispatch return command.invoke() File "/usr/lib/python2.7/dist-packages/lava/dispatcher/commands.py", line 247, in invoke self.args.validate) File "/usr/lib/python2.7/dist-packages/lava/dispatcher/commands.py", line 91, in run_pipeline_job exitcode = job.run() File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/job.py", line 340, in run self.cleanup(self.connection) File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/job.py", line 375, in cleanup self.pipeline.cleanup(connection) File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 251, in cleanup child.cleanup(connection) File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 649, in cleanup self.internal_pipeline.cleanup(connection) File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 251, in cleanup child.cleanup(connection) File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 649, in cleanup self.internal_pipeline.cleanup(connection) File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 251, in cleanup child.cleanup(connection) File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/boot/__init__.py", line 458, in cleanup os.unlink(self.url) OSError: [Errno 2] No such file or directory: '/var/lib/lava/dispatcher/tmp/overlay-1.3.2.5.tar.gz' We are working on the 2017.7 build of LAVA, so if this has been changed in a later build, please let me know. If this has not been updated, is there another way to change things so that each job uses a different name and/or location for the overlay file? Thanks, Jorgen Peddersen Jorgen Peddersen Researcher t +61 2 6103 4700 m e jorgen.peddersen(a)seeingmachines.com a 80 Mildura Street, Fyshwick ACT 2609, Australia SEEINGMACHINES.COM<http://seeingmachines.com> [SEEINGMACHINES] This email may contain confidential information. If you are not the intended recipient, destroy all copies and do not disclose or use the information within. Any content that is not concerned with the business of the Seeing Machines Group reflects the views of the sender only, not those of Seeing Machines. No warranties are given that this email does not contain viruses or harmful code. [http://www.seeingmachines.com/wp-content/uploads/2018/04/sm-email-twitter-i…] <https://twitter.com/seeingmachines> [http://www.seeingmachines.com/wp-content/uploads/2018/04/sm-email-linkedin-…] <https://www.linkedin.com/company/258949/>

6 years, 10 months

2
2
0 0

[BUG] Cannot cancel a job

by LABBE Corentin

Hello I have queued jobs that I want to cancel but I get instead: 500 Internal Server Error [Errno 2] No such file or directory: '/var/lib/lava-server/default/media/job-output/2018/07/10/7181/job_data.gz' when I click on cancel. Note that thoses queued jobs are only queued and not assigned to any device. Regards

6 years, 10 months

2
4
0 0

Questions of Test Cases

by 刘彩丽

6 years, 10 months

2
1
0 0

Question about "emulator-5554 connecting"

by kong.jia.yan

Hi, I'm sending this email to confirm if anyone has encountered the same problem as me when using LAVA...I have installed a lava single node instance in a docker container and are trying to add an Android device for testing. But when I ran the adb devices command, in addition to the Android device I connected, an "emulator-5554 connecting" appeared. I have tried many ways to remove this device but I failed. I am sure that the emulator appeared after the docker container containing LAVA instance started, so I wonder if this issue is related to LAVA. Thanks Jiayan Kong

6 years, 10 months

1
0
0 0

Linaro Open Source Lava Server?!

by Zoran S

> Just configure the worker to connect to your master. > This is done in /etc/lava-dispatcher/lava-slave > An example configuration file is available at /usr/share/lava-dispatcher/ lava-slave > > For a first try, you can start without encryption and only define the following variables in the configuration file: > MASTER_URL="tcp://localhost:5556" > LOGGER_URL="tcp://localhost:5555" Hello Remi, Do you, Linaro guys, have some Open Source Lava Server on the Cloud, where I can create lava admin account, hook to it my Lava Worker and try it? I need some access to create device-type BeagleBone Black and device BBB0x as well. This will be interesting experiment, don't you agree? Thank you, Zoran Stojsavljevic _______ On Tue, Aug 7, 2018 at 1:53 PM, Remi Duraffort <remi.duraffort(a)linaro.org> wrote: > Hello, > > the worker will register itself to the master automatically. You don't > have to create the worker manually. > > Just configure the worker to connect to your master. > This is done in /etc/lava-dispatcher/lava-slave > An example configuration file is available at /usr/share/lava-dispatcher/ > lava-slave > > For a first try, you can start without encryption and only define the > following variables in the configuration file: > MASTER_URL="tcp://localhost:5556" > LOGGER_URL="tcp://localhost:5555" > > You can also specify the HOSTNAME if you want. By default the slave will > use the name of the server it's running on. > > This will instruct you local lava-slave (this is the name of the service) > to connect to the local lava-master. > Then restart the lava-slave with "service lava-slave restart" > >

6 years, 10 months

2
2
0 0

single Master Instance installation, worker must only have one?

by ljh_dev

The document about installing lava system, does "Single Master Instance installation " mean master(include lava-server) and worker(include lava-dispatcher) can be installed in the one physical computer? In this simple mode,wheather the worker(logic unit)must only have one?

6 years, 10 months

2
6
0 0

about dispatcher configure

by ljh_dev

I am ready to deploy a local lava single master demo system. The server and dispatcher had be installed in a single computer. In order to enable the server to kno the dispatcher(worker),Then how to configure something. Is doing this?: sudo lava-server manage workers add <HOSTNAME> ,that HOSTNAME is changed in /etc/lava-dispatcher/lava-slave file? And when did,How to see whether dispatcher is working already?

6 years, 10 months

2
3
0 0

lava-server login error

by ljh_dev

Hi, According to lava installation document ,I had installed lava-server to debian 9.5.0.Creating super user operation is ok(sudo lava-server manage createsuperuser --username $USERNAME --email=$EMAIL) . But when using firefox browser to login in by created name , response message: -- SRF verification failed. Request aborted. You are seeing this message because this site requires a CSRF cookie when submitting forms. This cookie is required for security reasons, to ensure that your browser is not being hijacked by third parties. If you have configured your browser to disable cookies, please re-enable them, at least for this site, or for 'same-origin' requests. -- After configured browser to disable cookies,the response is still so. Jiang Lao

6 years, 10 months

6
13
0 0

Re: [Lava-users] about DUT inner program to communicate with Worker

by ljh_dev

Hi,If there is no “dameon” program in DUT. How to add/update the program running in DUT for example application test program or linux kernel or uboot etc.?Jiang Lao -------------------------------------------- On Wed, 1 Aug 2018 at 10:18, ljh_dev <ljh_dev at 126.com> wrote: > Hi, > I have browsed the website documentation of lava overall. I think the > DUT(Device Under Test) should has "dameon" program to communicate with the > Worker Dispatcher module. But I did not find where the DUT "dameon" > program source code is,and how to build&install this DUT "dameon" program. > It does not need to be built or installed. The lava-dispatcher package does all that work for you. https://validation.linaro.org/static/docs/v2/index.html#architecturehttps:/… /var/log/lava-dispatcher/lava-slave.log

6 years, 10 months

2
1
0 0

Re: [Lava-users] about DUT inner program to communicate with Worker Dispatcher.

by Jack Lu

If there is no "dameon" program in DUT. How to add/update the program running in DUT for example application test program or linux kernel or uboot etc.? Best regards,

6 years, 10 months

1
0
0 0

about DUT inner program to communicate with Worker Dispatcher.

by ljh_dev

Hi, I have browsed the website documentation of lava overall. I think the DUT(Device Under Test) should has "dameon" program to communicate with the Worker Dispatcher module. But I did not find where the DUT "dameon" program source code is,and how to build&install this DUT "dameon" program. thanks, Jiang Lao

6 years, 10 months

2
1
0 0

is lava supported to install in debian-9.5.0 version?

by ljh_dev

Hi, Is lava supported to install in debian-9.5.0 version? thanks, Jiang Lao

6 years, 10 months

2
1
0 0

is lava supporte installation in debian-9.5.0?

by ljh_dev

Hi, is lava supporte installation in debian-9.5.0 version? thanks Jiang Lao

6 years, 10 months

1
0
0 0

Regarding Queries in LAVA

by Hemanth K V

Hello Lava Users, We are creating queries in LAVA and adding multiple conditions to query.For example in our yaml job definition we have included os field in metadata section which will have different values.For example following is the metadata section for 2 different jobs Job1: metadata: description: '"Build SiemensIPC-327E target with latest build"' os: Debian device: imx6q Build_ID: QA-BUILD-F0150 Job2: metadata: description: '"Build SiemensIPC-327E target with latest build"' os: Ubuntu device: imx6q Build_ID: QA-BUILD-F0150 Now with queries I am trying to just filter out job running with Build_ID( QA-BUILD-F0150 ) and on only os debian. Entity Field Operator Value namedtestattribute Build_ID exact QA-BUILD-F0150 namedtestattribute os exact Debian When I am creating queries with above information, as a user when I run the query the query results will just list Job1 information but at present in LAVA both the jobs are getting listed. Is this the expected behavior?The LAVA server version used is 2018.5.post1 release. Thanks, Hemanth.

6 years, 10 months

2
5
0 0

Configuration management / Salt / documentation

by Tim Jaacks

Hello everyone, is there any documentation on how Linaro uses Salt for configuring LAVA nodes? I know the infrastructure code is hosted at https://git.linaro.org/lava/lava-lab.git, but since I am new to Salt (and configuration management in general), I would love to have some kind of starting point. Where is this repository checked out? Who applies the defined Salt states and when? Are there any automatic processes happening when someone commits to the repository (e.g. changing a device type or health check job)? What is Linaro's workflow in these cases? 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

6 years, 10 months

2
1
0 0

unable to login to local django account from lava webpage

by Hussin, Mohamad Noor Alim

Hi, I just install lava-server to latest release, 2018.5-post1 & created a local Django account. I unable to login using lava webpage from my local machine. Lava webpage did not prompt any error message and I have no idea how to debug this problem. Any idea? Regards, Alim Hussin

6 years, 10 months

2
2
0 0

LAVA email notification configuration

by Diego Russo

Hello, In my LAVA pipeline I have the following snippet: notify: recipients: - to: method: email mail: diego.russo(a)arm.com criteria: status: finished verbosity: verbose When the job ends though I'm not receiving any email. I've looked at the documentation, but I couldn’t find anything about mail configuration. Logs also are not very helpful to debug this issue. How/where can I configure the email client? I'm also interested in changing the "from:" field. Thanks -- Diego Russo Staff Software Engineer - diego.russo(a)arm.com Direct Tel. no: +44 1223 405920 Main Tel. no: +44 1223 400400 ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - http://twitter.com/diegor http://www.linkedin.com/in/diegor IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 11 months

2
2
0 0

x86 based boot

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.

6 years, 11 months

2
1
0 0

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.

6 years, 11 months

2
1
0 0

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.

6 years, 11 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

6 years, 11 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

6 years, 11 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

6 years, 11 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

6 years, 11 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/

6 years, 11 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/

6 years, 11 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/

6 years, 11 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

6 years, 11 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.

6 years, 11 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

6 years, 11 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

6 years, 11 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

6 years, 11 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

6 years, 11 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

6 years, 12 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

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

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

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

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

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

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

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

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

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

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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 >>> >>> >>

7 years, 2 months

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

7 years, 2 months

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,

7 years, 2 months

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

7 years, 2 months

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

7 years, 2 months

2
3
0 0

How to plot in Lava

by Zoran S

Hello to everyone, Suppose I am able to retrieve from the DUT my cyclictest results, in the form of the table. Am I able to plot these results directly from Lava? If yes, any examples in V2 test definitions how to do that? Thank you, Zoran

7 years, 2 months

2
1
0 0

A deployment strategy using USB Gadget

by Ros Dos Santos, Alfonso (CT RDA DS EVO OPS DIA SE 1)

Hi everyone, in the last few months my team and I have being using LAVA in our Continuous Integration process for the development of a Yocto Linux image for some development boards. These boards were not compatible with the available strategies in LAVA so we had to improvise a little. These boards are however capable of booting from a USB device. Our idea was then to create a new deployment strategy that will download the image file into some Linux device with a OTG USB port and "expose" it using the g_mass_storage kernel module. The OTG USB port will be connected to the test development board USB. For the booting strategy we use the already existing minimal boot where we simply power up the device and let it boot from the USB. We would like to know your thoughts about this idea and if you see any value in these changes for a possible contribution. In the board's device configuration we add the host to where download and mount the image actions: deploy: methods: usbgadget: usb_gadget_host: {{ usb_gadget_host }} We developed these changes on top of the lava-dispatcher verision 2017.7-1~bpo9+1 from the strerch-backports repository. Here is our patch with the changes: We also added some options to apply a patch to the image boot partition to make it usb bootable, but if the image is already usb bootable it is not needed. --- .../pipeline/actions/deploy/strategies.py | 1 + .../pipeline/actions/deploy/usbgadget.py | 254 +++++++++++++++++++++ 2 files changed, 255 insertions(+) create mode 100644 lava_dispatcher/pipeline/actions/deploy/usbgadget.py diff --git a/lava_dispatcher/pipeline/actions/deploy/strategies.py b/lava_dispatcher/pipeline/actions/deploy/strategies.py index da1e155..cfd6438 100644 --- a/lava_dispatcher/pipeline/actions/deploy/strategies.py +++ b/lava_dispatcher/pipeline/actions/deploy/strategies.py @@ -32,3 +32,4 @@ from lava_dispatcher.pipeline.actions.deploy.lxc import Lxc from lava_dispatcher.pipeline.actions.deploy.iso import DeployIso from lava_dispatcher.pipeline.actions.deploy.nfs import Nfs from lava_dispatcher.pipeline.actions.deploy.vemsd import VExpressMsd +from lava_dispatcher.pipeline.actions.deploy.usbgadget import USBGadgetDeployment diff --git a/lava_dispatcher/pipeline/actions/deploy/usbgadget.py b/lava_dispatcher/pipeline/actions/deploy/usbgadget.py new file mode 100644 index 0000000..65347f4 --- /dev/null +++ b/lava_dispatcher/pipeline/actions/deploy/usbgadget.py @@ -0,0 +1,254 @@ +import os +import patch +import guestfs +import errno +import gzip + +from paramiko import SSHClient, AutoAddPolicy +from scp import SCPClient +from tempfile import mkdtemp +from shutil import rmtree + +from lava_dispatcher.pipeline.action import Pipeline, InfrastructureError, Action +from lava_dispatcher.pipeline.logical import Deployment +from lava_dispatcher.pipeline.actions.deploy import DeployAction + +from lava_dispatcher.pipeline.actions.deploy.download import ( + DownloaderAction, +) + +from lava_dispatcher.pipeline.actions.deploy.overlay import ( + OverlayAction, +) + +from lava_dispatcher.pipeline.actions.deploy.apply_overlay import ( + ApplyOverlayImage, +) + + +class PatchFileAction(Action): + + def __init__(self): + super(PatchFileAction, self).__init__() + self.name = "patch-image-file" + self.summary = "patch-image-file" + self.description = "patch-image-file" + + def run(self, connection, max_end_time, args=None): + connection = super(PatchFileAction, self).run( + connection, max_end_time, args) + + decompressed_image = self.get_namespace_data( + action='download-action', label='image', key='file') + self.logger.debug("Image: %s", decompressed_image) + + partition = self.parameters['patch'].get('partition') + if partition is None: + raise JobError( + "Unable to apply the patch, image without 'partition'") + + patchfile = self.get_namespace_data( + action='download-action', label='file', key='patch') + + destination = self.parameters['patch'].get('dst') + + self.patch_file(decompressed_image, partition, destination, patchfile) + return connection + + @staticmethod + def patch_file(image, partition, destination, patchfile): + """ + Reads the destination file from the image, patchs it and writes it back + to the image. + """ + guest = guestfs.GuestFS(python_return_dict=True) + guest.add_drive(image) + guest.launch() + partitions = guest.list_partitions() + if not partitions: + raise InfrastructureError("Unable to prepare guestfs") + guest_partition = partitions[partition] + guest.mount(guest_partition, '/') + + # create mount point + tmpd = mkdtemp() + + # read the file to be patched + f_to_patch = guest.read_file(destination) + + if destination.startswith('/'): + # copy the file locally + copy_dst = os.path.join(tmpd, destination[1:]) + else: + copy_dst = os.path.join(tmpd, destination) + + try: + os.makedirs(os.path.dirname(copy_dst)) + except OSError as exc: + if exc.errno == errno.EEXIST: + pass + else: + raise + + with open(copy_dst, 'w') as dst: + dst.write(f_to_patch) + + # read the patch + ptch = patch.fromfile(patchfile) + + # apply the patch + ptch.apply(root=tmpd) + + # write the patched file back to the image + with open(copy_dst, 'r') as copy: + guest.write(destination, copy.read()) + + guest.umount(guest_partition) + + # remove the mount point + rmtree(tmpd) + + +class USBGadgetScriptAction(Action): + + def __init__(self, host): + super(USBGadgetScriptAction, self).__init__() + self.name = "deploy-usb-gadget" + self.summary = "deploy-usb-gadget" + self.description = "deploy-usb-gadget" + self.host = host + + def validate(self): + if 'deployment_data' in self.parameters: + lava_test_results_dir = self.parameters[ + 'deployment_data']['lava_test_results_dir'] + lava_test_results_dir = lava_test_results_dir % self.job.job_id + self.set_namespace_data(action='test', label='results', + key='lava_test_results_dir', value=lava_test_results_dir) + + def print_transfer_progress(self, filename, size, sent): + current_progress = (100 * sent) / size + if current_progress >= self.transfer_progress + 5: + self.transfer_progress = current_progress + self.logger.debug( + "Transferring file %s. Progress %d%%", filename, current_progress) + + def run(self, connection, max_end_time, args=None): + connection = super(USBGadgetScriptAction, self).run( + connection, max_end_time, args) + + # # Compressing the image file + uncompressed_image = self.get_namespace_data( + action='download-action', label='file', key='image') + self.logger.debug("Compressing the image %s", uncompressed_image) + compressed_image = uncompressed_image + '.gz' + with open(uncompressed_image) as f_in, gzip.open(compressed_image, 'wb') as f_out: + f_out.writelines(f_in) + + # # Try to connect to the usb gadget host + ssh = SSHClient() + ssh.set_missing_host_key_policy(AutoAddPolicy()) + ssh.connect(hostname=self.host, username='root', password='') + dest_file = os.path.join('/mnt/', os.path.basename(compressed_image)) + + # # Clear /mnt folder + self.logger.debug("Clearing /mnt directory") + stdin, stdout, stderr = ssh.exec_command('rm -rf /mnt/*') + exit_code = stdout.channel.recv_exit_status() + if exit_code == 0: + self.logger.debug("/mnt clear") + else: + self.logger.error("Could not clear /mnt on secondary device") + + # # Transfer the compressed image file + self.logger.debug( + "Transferring file %s to the usb gadget host", compressed_image) + self.transfer_progress = 0 + + scp = SCPClient(ssh.get_transport(), + progress=self.print_transfer_progress, + socket_timeout=600.0) + scp.put(compressed_image, dest_file) + scp.close() + + # # Decompress the sent image + self.logger.debug("Decompressing the file %s", dest_file) + stdin, stdout, stderr = ssh.exec_command('gzip -d %s' % (dest_file)) + exit_code = stdout.channel.recv_exit_status() + if exit_code == 0: + self.logger.debug("Decompressed file") + else: + self.logger.error("Could not decompress file: %s", + stderr.readlines()) + + # # Run the g_mass_storage module + dest_file_uncompressed = dest_file[:-3] + self.logger.debug( + "Exposing the image %s as a usb storage", dest_file_uncompressed) + + stdin, stdout, stderr = ssh.exec_command('rmmod g_mass_storage') + exit_code = stdout.channel.recv_exit_status() + + stdin, stdout, stderr = ssh.exec_command( + 'modprobe g_mass_storage file=%s' % (dest_file_uncompressed)) + exit_code = stdout.channel.recv_exit_status() + if exit_code == 0: + self.logger.debug("Mounted mass storage file") + else: + self.logger.error("Could not mount file: %s", + stderr.readlines()) + + ssh.close() + return connection + + +class USBGadgetDeploymentAction(DeployAction): + + def __init__(self): + super(USBGadgetDeploymentAction, self).__init__() + self.name = 'usb-gadget-deploy' + self.description = "deploy images using the fake usb device" + self.summary = "deploy images" + + def populate(self, parameters): + self.internal_pipeline = Pipeline( + parent=self, job=self.job, parameters=parameters) + path = self.mkdtemp() + + # Download the image + self.internal_pipeline.add_action(DownloaderAction('image', path)) + + if self.test_needs_overlay(parameters): + self.internal_pipeline.add_action(OverlayAction()) + self.internal_pipeline.add_action(ApplyOverlayImage()) + + # Patch it if needed + if 'patch' in parameters: + self.internal_pipeline.add_action(DownloaderAction('patch', path)) + self.internal_pipeline.add_action(PatchFileAction()) + + host = self.job.device['actions']['deploy'][ + 'methods']['usbgadget']['usb_gadget_host'] + self.internal_pipeline.add_action(USBGadgetScriptAction(host)) + + +class USBGadgetDeployment(Deployment): + """ + Only for iot2000-usb + """ + compatibility = 4 + + def __init__(self, parent, parameters): + super(USBGadgetDeployment, self).__init__(parent) + self.priority = 1 + self.action = USBGadgetDeploymentAction() + self.action.section = self.action_type + self.action.job = self.job + parent.add_action(self.action, parameters) + + @classmethod + def accepts(cls, device, parameters): + """ + Accept only iot2000-usb jobs + """ + return device['device_type'] == 'iot2000-usb' -- 2.7.4

7 years, 2 months

2
1
0 0

u-boot commands in Lava

by Denis HUMEAU

Dear all, I'm adding a new device to my test farm This device supports u-boot. Device-type and device have been created, I want to test a simple nfs job. To manage to start the kernel, I need to trigger 2 commands from u-boot before launching the nfs boot command: dcache off and icache off My question here is to know how to manage that with Lava V2. Should it be done in the device or device-type, or should it be done in the test job? Any example is welcome. Best regards, Denis

7 years, 2 months

2
1
0 0

Executing JSON scripts in Lava

by Zoran S

Hello, I have another problem/ignorance with Lava, so I need a bit of push here. I did execute cyclic test (timer interrupt measurements, time of reaction), using as application hackbench, which introduces tremendous application load (in the peak around 300 loads per 1m/3m/15m) on the core. So, poking around, I found the following JSON script: https://github.com/kernelci/lava-ci/blob/master/templates/cyclictest/generi… Since i know (at least this is my understanding) that the Lava V2 works as a pipeline, so the test jobs must be broken to some blocks *(deploy*, *boot* and *test)*. I would like to a bit change this JSON script to get hackbench as load, but much more important is how I can use this JSON script as Lava test job? I guess, I need to incorporate this script into some yaml format, as explained/described above... Am I correct? How to do this? Any description, example... Advice? Thank you, Zoran _______

7 years, 2 months

2
2
0 0

Yet another problem I discovered with Lava 2018.2

by Zoran S

Hello Folks, I have really interesting problem with Lava, this time while executing tests. Lava versions: root@stretch:/usr/share# 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.2.post2-1+str amd64 Linaro Automated Validation Architecture dispatcher ii lava-server 2018.2-1+stretch all Linaro Automated Validation Architecture server root@stretch:/usr/share# _______ This problem appears while downloading initramfs. Although the initramfs I am using from localhost://8010 has the fixed size: 46275637 (decimal), while I download ramdisk.cpio.gz.uboot (which in theory should be 64 bytes more, exactly 46275701): I am getting the following on The Same Jobs, which I repeated in Lava: Job #113: 46597208 (decimal) Job #114: 46596349 (decimal) Job #115: 46595788 (decimal) In other words, I am downloading each time The Same ingredients: http://localhost:8010/initramfs/initramfs.cpio.gz http://localhost:8010/cip-example/cip_v4.4.120-cyclic/v4.4.120-cip20-rt13/a… http://localhost:8010/cip-example/cip_v4.4.120-cyclic/v4.4.120-cip20-rt13/a… Where I have all three time exact size for: zImage - 4167704 (3f9818 hex) am335x-boneblack.dtb - 31552 (7b40 hex) I removed u-boot-tools, then I installed it back. But this did not help. service tftpd-hpa restart did not help as well. So, Iwill continue investigating this problem myself, but did amybody notice the same? Thank you, Zoran

7 years, 2 months

2
7
0 0

LAVA V2 | 500 Internal Server Error

by Conrad Djedjebi

Good morning everyone, I would like to know if someone here already face the following message while opening a LAVA results page or LAVA alljobs page : I am looking around LAVA documentation to check if it is a known issue. But if someone here already knows something about it, it could help me also. regards,

7 years, 2 months

4
4
0 0

Re: [Lava-users] Running large test suites

by Tim Jaacks

On 19 March 2018 at 16:26, Neil Williams <neil.williams at linaro.org> wrote: >The problem of picking a number is that it depends a lot on the resources >available to the server and the performance of the devices themselves. I get the point. But that information is helpful as well, so maybe some examples of the dimensions in which LAVA can be (and actually is) used might be worth mentioning. I have read most of the LAVA documentation, but had no idea that there are actually running test jobs with 50,000 test cases in it on your servers. >Templating. > >Check out how Jinja2 is used for the server-side device configuration >templates - Jinja2 can output any text-based format, we chose YAML. The >same principles are used by the Linaro QA team to produce the test job >submissions. Templates live in version control, the commit hash of the >template gets included into the metadata of the output. That’s a very good hint, thank you. I haven’t thought of this, yet. Are the repositories containing your templates publicly available? 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, 2 months

2
1
0 0

Re: [Lava-users] Running large test suites

by Tim Jaacks

>150 test cases does not necessarily mean large - we have test jobs which >produce 50,000 test cases per test job, that is when a large test set can >become a problem, depending on the available resources on the server. It >was these test jobs which led to the sections in the documentation which >you mention later. If your server doesn't struggle with the current test >jobs, you might not have anything to do at this stage. > >However, if you have clear groups of test cases, you should investigate >using test sets which preserve those boundaries within the reported results: >https://staging.validation.linaro.org/static/docs/v2/results-intro.html#tes… Thanks for the information. Perhaps it would be a good idea to add these figures to the documentation, so that new users have an idea of what a “large” test set is. I am just starting out with LAVA, so I haven’t set up any productive tests yet. At the moment I am creating a concept of how we can include LAVA into our workflow. Part of this is the question how we handle test jobs and how we store them in our SCM. >MultiNode does offer a possible option but MultiNode itself is complex and >not all test jobs would be able to use it - essentially you can use >MultiNode with SSH to have multiple logins to the same device running the >same software. Problems include issues with locking resources, load on the >device from running tests in parallel, problems within the test being able >to run in parallel in the first place amongst others. > >>From your enquiry, it does not sound as if you need any of that. You might >want to look at a wrapper script which consumes the output of the tests and >filters out noise but apart from that, 150 test cases is really not large. >We routinely run functional tests which produce more test cases than that: >https://staging.validation.linaro.org/results/214157 >https://staging.validation.linaro.org/scheduler/job/214157 I actually have to use MultiNode for some of our testcases anyway. These testcases need a remote server or client connected to the DUT (e.g. testing hardware interfaces like RS485, CAN, etc.). And this is actually part of the question: When I declare all of my testcases in one test job, I have to declare the remote nodes for ALL of the tests in there as well. This makes the test job huge and confusing, though, I think. How do you handle such cases? Do you ever test that kind of interfaces at all? 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, 2 months

2
1
0 0

Not able to have any U-boot scripts executed on Lava

by Zoran S

Hello, I have very interesting problem: I would like to do Lava testing of BBB01, but I am not suceeding. Simple and plain, my U-Boot scripts gets somehow rejected, they are not executed. I do download correctly, I have all the correct ingredients in place, but the U-Boot scripts are not activated, at the time of U-boot prompt. Here is my output, from the testing: https://pastebin.com/hTQQSLU1 Rather, the thing gets executed from SDCard (from /boot on rootfs). I have no idea why this is not executed. Help appreciated! Thank you, Zoran

7 years, 2 months

3
5
0 0

Re: [Lava-users] Sending commands with the minimal bootloader class

by Tim Jaacks

Hi Neil, thanks for your reply. >>(*) As a sidenote I'd like to add, that using "BootloaderCommandsAction" alone does not work. I had to add "BootloaderCommandOverlay" as well, because the "commands" are set at the end of the "run" function of this class: >> >> self.set_namespace_data(action='bootloader-overlay', label=self.method, key='commands', value=subs) >> >>Is this by design? It seems like a bug to me, since I did not find any documentation about this dependency. > >The majority of classes in lava-dispatcher have dependencies which are entirely determined by the way that the test devices need to operate. A new Strategy class would ensure that both are added for this use case. > >You also need to consider whether the test job itself contains a test action and therefore whether an overlay is needed at all. Simple boot testing doesn't have to include a test action at all, just deploy and boot. That's the point: I don't need the overlay action in my strategy. But I had to include it, because the command action did not work without it. And to clarify things: The overlay you are talking about (adding LAVA files to the rootfs) is not the overlay I am talking about (replacing placeholders in the commands with actual values). >I assume that simply no one has ever used "BootloaderCommandsAction" without "BootloaderCommandOverlay", so no one ever noticed. In my opinion "BootloaderCommandsAction" should work on its own. > >No, it should not. The commands frequently need to be modified by other actions. That's okay. But why are they set in "BootloaderCommandOverlay" in the first place? This is totally unexpected. I am new to the code, so I don't know anything about the internals. But from a user's perspective, it seems like bad design to have an action's essential variable set in a different action. 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, 2 months

1
0
0 0

Sending commands with the minimal bootloader class

by Tim Jaacks

Hello everyone, I have a device with a very basic proprietary bootloader and want to automate it with LAVA. I figured out that the "minimal" bootloader class covers basically everything I need, except that it cannot send commands to the bootloader. So for a quick test, I added "self.internal_pipeline.add_action(BootloaderCommandsAction())" to actions/boot/minimal.py. With this modification (*) I was able to create a device class which can run a smoke test successfully on my device. In a former question on this mailing list concerning the integration of my bootloader, someone recommended me to implement a new boot strategy. Would you accept a code contribution which adds a new boot strategy only differing from the "minimal" strategy in this one addition? Or would it perhaps make sense to add the "BootloaderCommandsAction" directly to the "minimal" strategy? (*) As a sidenote I'd like to add, that using "BootloaderCommandsAction" alone does not work. I had to add "BootloaderCommandOverlay" as well, because the "commands" are set at the end of the "run" function of this class: self.set_namespace_data(action='bootloader-overlay', label=self.method, key='commands', value=subs) Is this by design? It seems like a bug to me, since I did not find any documentation about this dependency. I assume that simply no one has ever used "BootloaderCommandsAction" without "BootloaderCommandOverlay", so no one ever noticed. In my opinion "BootloaderCommandsAction" should work on its own. 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, 2 months

2
1
0 0

Running large test suites

by Tim Jaacks

Hello everyone, we have a quite large test suite (> 150 testcases, and counting, devided into ~50 groups) which we want to run on our devices. This is required for each software release and would be nice for nightly builds as well. Our deployment method flashes kernel and root filesystem onto the internal flash memory, which takes ~3 minutes. Booting the OS from RAM or using remote filesystems (NFS) is not an option for us. We need to run all tests on a device booted completely from its internal flash memory. Ideally our OS image should be deployed once and then all the tests should run on top of that deployment. According to the LAVA documentation, best practice is not to put too many tests into one job file, as this would be hard to maintain and logs would become huge and difficult to read. What is recommended in such a scenario? My intentional tendency was to create a job for each test group (each containing ~3 testcases average), which occurs reasonable to me. However, this would result in 50 deployment cycles with 3 minutes each, resulting in 2,5 hours spent with basically unnecessary work. This, in turn, does not seem reasonable to me. Is there a possibility to combine jobs to run on the same device subsequently, so that the images need to be deployed only once? Or can jobs be nested somehow, so that one job does the deployment and contains sub-jobs which perform the actual tests? Or are there any other recommendations for this? 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, 2 months

2
1
0 0

Adding new device type to Lava Dispatcher

by Zoran S

Hello to everyone, I need to add some scripts to the /etc/lava-server/dispatcher-config/device-types. It says to contact Lava mailing list in such a case, to get some guidance. Says here: https://staging.validation.linaro.org/static/docs/v2/device-integration.html *"Please* talk to us *before* starting on the integration of a new device using the Mailing lists <https://staging.validation.linaro.org/static/docs/v2/support.html#mailing-l…> ." The device I need to add is Renesas iwg20m: https://mp.renesas.com/en-us/boards/iW-RainboW-G20D-RZG1M_RZG1N_QsevenDevKi… I have on the device working MLO and U-Boot with some U-Boot environment which boot mmc, I also have working ser2net in Lava VM, it works seamlessly. So these are all the prerequisites for adding the device type, as my best understanding is? My Lava is upgraded: ||/ Name Version Architecture Description +++-======================-================-================-================================================== ii lava-dispatcher 2018.2.post2-1+s amd64 Linaro Automated Validation Architecture dispatche ii lava-server 2018.2-1+stretch all Linaro Automated Validation Architecture server I have beaglebone-black <http://localhost:8080/scheduler/device_type/beaglebone-black> device type and added to it bbb01 device, which I finally made working with Lava. I updated the beaglebone-black-jinja2 script, and created in /etc/lava-server/dispatcher-config/devices bbb01.jinja2, added this device to beaglebone-black device type. I am wondering what should I do else, besides to write iwg20m.jinja2 which inherits base-uboot.jinja2 script??? iwg20m is similar to Beaglebone Black (it is, after all, armv7 silicon/platform based). And I can make iwg20m.jinja2 as similar analogy to beaglebone-black.jinja2 . And, btw, how to add the device-type? Using GUI? CLI? Any description? Thank you, Zoran

7 years, 3 months

1
1
0 0

Re: [Lava-users] Lava-users Digest, Vol 29, Issue 13

by ywang

I ever encountered this issue recently. In my experience, it caused by failing to start postgresql service. Have you changed from Jessie to stretch? You can refer to this page: https://github.com/WindRiver-OpenSourceLabs/lava-base/blob/master/Dockerfile Regards, -Yang (Young) -----Original Message----- Message: 1 Date: Tue, 13 Mar 2018 17:36:27 +0000 From: Conrad Djedjebi <conrad.djedjebi(a)linaro.org> To: Lava Users Mailman list <lava-users(a)lists.linaro.org> Subject: [Lava-users] LAVA V2 | 500 Internal Server Error Message-ID: <CAF9r90RH4h3Z-=FZkcd6J6dV0V8nH+sW=tyDrZcHN0WLPR08Bg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Good morning everyone, I would like to know if someone here already face the following message while opening a LAVA results page or LAVA alljobs page : I am looking around LAVA documentation to check if it is a known issue. But if someone here already knows something about it, it could help me also. regards,

7 years, 3 months

1
0
0 0

Re: [Lava-users] Error "Missing protocol 'lava-lxc'" in multinode LXC job

by Tim Jaacks

Hi Senthil, >It throws an error for me when trying to submit via the UI "Job submission error: u'device_type'". > >Similarly, when trying with command line I get a similar error: > ><snip> >$ lava-tool submit-job >https://senthil.kumaran@staging.validation.linaro.org/RPC2/ >/tmp/multinode-lxc.yaml >ERROR: <Fault -32603: "Internal Server Error (contact server administrator for details): u'device_type'"> </snip> > In my instance it works via the UI as well as via lava-tool. >BTW, what is your lava-server and lava-dispatcher version? tim.jaacks@A048:~$ apt-cache policy lava-server lava-dispatcher lava-server: Installed: 2018.2-1+stretch Candidate: 2018.2-1+stretch Version table: *** 2018.2-1+stretch 500 500 https://images.validation.linaro.org/production-repo stretch-backports/main amd64 Packages 100 /var/lib/dpkg/status 2017.7-1~bpo9+1 100 100 http://ftp.debian.org/debian stretch-backports/main amd64 Packages 2016.12-2 500 500 http://ftp.de.debian.org/debian stretch/main amd64 Packages lava-dispatcher: Installed: 2018.2.post2-1+stretch Candidate: 2018.2.post2-1+stretch Version table: *** 2018.2.post2-1+stretch 500 500 https://images.validation.linaro.org/production-repo stretch-backports/main amd64 Packages 100 /var/lib/dpkg/status 2017.7-1~bpo9+1 100 100 http://ftp.debian.org/debian stretch-backports/main amd64 Packages 2016.12-1 500 500 http://ftp.de.debian.org/debian stretch/main amd64 Packages 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, 3 months

2
1
0 0

Re: [Lava-users] Error "Missing protocol 'lava-lxc'" in multinode LXC job

by Tim Jaacks

Hi Senthil, thanks for your reply. >> I want to set up a multinode job containing an LXC device. Unfortunately I always get the following error: >> >> Missing protocol 'lava-lxc' in ['lava-multinode'] > >This is because each role should have a lava-lxc protocol defined. Even real hardware devices? >Going through your job, I could see you are requesting a single device >(role) in your multinode job, which is not the use-case which multinode caters. There should be more than one device (roles) requested as part of the job. For a single device, single node jobs are the way to go. I know, this was deliberate in order to strip the error down to a minimal example. I started out with one LXC device and one real hardware device (which is actually the setup I want to use), which led to the above error. Then I removed parts of the job for simplification until (I hoped) the error would disappear. But it did not, even with a single LXC device. I assume a multimode job should work even if it only contains one single device, shouldn't it? >See https://staging.validation.linaro.org/scheduler/job/213532 - which is a sample multinode job run with two lxc devices requested as part of the job. You can see how each role has a lava-lxc protocol defined for it. > >The job definition is available here - >https://git.linaro.org/lava-team/refactoring.git/plain/lxc-multinode.yaml Thanks, that pointed me the way. I had to add an additional "remote" key under "protocols/lava-lxc", so the job looks like this: job_name: lxc-pipeline timeouts: job: minutes: 15 action: minutes: 5 priority: medium visibility: public protocols: lava-multinode: roles: remote: device_type: lxc count: 1 timeout: minutes: 6 lava-lxc: remote: name: pipeline-lxc-test template: debian distribution: debian release: stretch mirror: http://ftp.us.debian.org/debian/ security_mirror: http://mirror.csclub.uwaterloo.ca/debian-security/ actions: - deploy: timeout: minutes: 5 to: lxc os: debian role: - remote - boot: prompts: - 'root@(.*):/#' timeout: minutes: 5 method: lxc role: - remote - test: timeout: minutes: 5 definitions: - repository: git://git.linaro.org/qa/test-definitions.git from: git path: common/dmidecode.yaml name: dmidecode role: - remote This job runs without errors, even though it has only one single device in a multinode context. From here I can build my actual multinode job by adding my real device to it. >HTH. Thank You. >-- >Senthil Kumaran S >http://www.stylesen.org/ >http://www.sasenthilkumaran.com/ > 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, 3 months

2
1
0 0

Error "Missing protocol 'lava-lxc'" in multinode LXC job

by Tim Jaacks

Hello, I want to set up a multinode job containing an LXC device. Unfortunately I always get the following error: Missing protocol 'lava-lxc' in ['lava-multinode'] My LXC device works with singlenode jobs. I used this example job for reference: https://github.com/Linaro/lava-dispatcher/blob/release/lava_dispatcher/test… I only changed "release" from "sid" to "stretch" and then this job works correctly. For a minimal multinode job I added the "lava-multinode" protocol, defined a role and assigned this role to each action: job_name: lxc-pipeline timeouts: job: minutes: 15 action: minutes: 5 priority: medium visibility: public protocols: lava-multinode: roles: remote: device_type: lxc count: 1 timeout: minutes: 6 lava-lxc: name: pipeline-lxc-test template: debian distribution: debian release: stretch mirror: http://ftp.us.debian.org/debian/ security_mirror: http://mirror.csclub.uwaterloo.ca/debian-security/ actions: - deploy: timeout: minutes: 5 to: lxc os: debian role: - remote - boot: prompts: - 'root@(.*):/#' timeout: minutes: 5 method: lxc role: - remote - test: timeout: minutes: 5 definitions: - repository: git://git.linaro.org/qa/test-definitions.git from: git path: common/dmidecode.yaml name: dmidecode role: - remote With this job definition the above error appears. Am I missing anything or is this a bug 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 SOLUTIONS THAT COMPLETE! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz

7 years, 3 months

2
1
0 0

LAVABug: KeyError: 'deployment_data'

by Иван Арищенко

Hello everyone, My targets are available via ssh interface and I don't need to update them (install kernel, rootfs, etc) before testing. My test case is: copy test binary at target device, run the test and check the result. As a first step I want to check the ssh connection: log into the device and check the promts. My LAVA 2018.2 instance failed to check the connection with "KeyError: 'deployment_data'" traceback: https://pastebin.com/2rsgBvx3 Job definition: https://pastebin.com/GJymcx3z device dictionary: https://pastebin.com/x08HgSqQ Is it the LAVA bug or lack of my job definition and device dictionary? Best Regards, Ivan Arishchenko

7 years, 3 months

2
2
0 0

Minimal LAVA V2 Setup

by Ioannis Valasakis

I am currently evaluating if LAVA is the right tool for testing our custom flavour of a Raspbian Linux distro. The DUT is going to be a Raspberry Pi3 and I was trying to set it up in a minimal way using another Raspbi3 as a Server & Dispatcher (although first it seemed to work fine, when I followed the LAVA documentation and added the stretch backports sources in the apt list, my whole system crashed because of the depedencies). What is the best way to get a minimal setup running? I am also interested to know the hardware process (ideally everything we want to be automated). So, should the DUT be connected via a USB2serial cable? https://goo.gl/D5ZwxU Other than that should that be connected to an SD multiplexer that burns the resulting .img after Jenkins finishes checking and generating it? Documentation is a bit tricky to go through as it covers many cases and there's not a simpler minimal tutorial. Also all the online blogs/posts seem to work for LAVA V1 only as a few things have changed. So it will look something like this: Linux .img (to be tested) -> SD Multiplexer(?) - DUT - USB2Serial -> LAVA Server & Dispatcher | LCD Screen Are there anywhere some sample tests so I can get an idea of what I will be able to do? (Had already a look at the linaro .git but those seem 'too' basic; probably I've missed smth). Thank you all for your help.

7 years, 3 months

2
1
0 0

Re: [Lava-users] Integrating a custom bootloader

by Tim Jaacks

Thanks again, Neil. >Future proofing means keeping up with upstream and, hopefully, contributing >the support back to upstream. A new Strategy class is a requirement for >inclusion upstream, to be able to isolate this bootloader from future >changes to better support U-Boot in ways that your bootloader cannot manage. I get your point and agree with you on that. So does this mean you would accept contributions for a new bootloader, even if it is a proprietary one? However, for a quick check how LAVA works I was able to go the hacky way and abuse the uboot class to send commands to our own bootloader. This led me to further questions: 1. The TFTP deployment strategy does not seem to support deploying a rootfs. Is that correct? If yes, why? 2. Our bootloader supports download via HTTP as well, so actually we could get the files from the web to the device directly. The test system would not need to download any files then. LAVA does not seem to support such a scenario. All deployment strategies download the files first, before performing further steps. How could I handle this case in LAVA? Obviously I could remove the deploy action from the job completely and handle everything in the boot command sequence. Still I would need some possibility to specify the URL of the image within the job, which the boot command sequence then should use. Is there a way to achieve this? I assume the correct way would be to implement a new deployment strategy for this, which does not do anything. However, this seems a bit weird to me. Is there another way? Or would the whole idea work against the general LAVA workflow? 3. As far as I understand, LAVA needs to apply an overlay tarball to the image before executing tests, which is usually performed directly on the image file before it is deployed to the target. This would not work in the case of (2). But I saw there is a boot action "transfer_overlay" to do this after the actual deployment. Is it correct, that I could use this action in such a case? 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, 3 months

2
1
0 0

Lava BBB01 HW test failing at the command: Wait for prompt ['=>']

by Zoran S

I finally tracked down what is going on here: Here is the point of the problem while running test script: Press SPACE to abort autoboot in 10 seconds end: 2.4.2 bootloader-interrupt (duration 00:00:02) [common] start: 2.4.3 bootloader-commands (timeout 00:01:58) [common] bootloader-commands: Wait for prompt ['=>'] (timeout 00:01:58) Script does detect "Press SPACE to abort autoboot in 10 seconds", and issues a " ". Then it does NOT detect: Wait for prompt ['=>']. I replaced old prompt ['U-Boot'] with ['=>'], but neither way it detects U-Boot prompt. Anyway, I do not understand the jinja2 command: {% set bootloader_prompt = bootloader_prompt|default('U-Boot') %} ??? Hasn't => been always U-Boot prompt? Thank you, Zoran _______ On Fri, Mar 2, 2018 at 11:44 AM, <magnus(a)minimum.se> wrote: > I believe your issue is that LAVA doesn't detect your U-boot prompt > correctly and does not try to issue any commands. Meanwhile, your kernel is > autobooting and at line 541 of your pastebin, LAVA gives up waiting for a > U-boot prompt. > > You may need to tweak your u-boot prompt settings and/or uboot interrupt > sequence. I am not sure if LAVA is doing substring matching of the > interrupt-prompt, so "Press SPACE to abort autoboot" _may_ not match a line > that reads "Press SPACE to abort autoboot 10 seconds". But I'll leave that > to the LAVA devs to answer. > > BTW, you should avoid making copies of base-uboot.jinja2. Instead you can > override these things from your device type config, for example to override > the interrupt-string you can do: > > {% set interrupt_prompt = 'Press SPACE to abort autoboot 10 seconds' %} > > and it will override the default value specified in base-uboot.jinja2. Same > goes for your TFTP commands, > > {% set uboot_tftp_bootcmd = '- your list of uboot commands here as a > yaml-list' %} > > > > > On Fri, Mar 2, 2018 at 10:58, Zoran S <zoran.stojsavljevic.de(a)gmail.com> > wrote: > > Some additional data to the use case from the initial email. I have > changed /etc/lava-server/dispatcher-config/device-types/base-uboot.jinja2 > (changed u-boot massge before prompt, since I am using U-Boot 2017.12, > and also hard-coded SERVER_IP since I have two networks inside VM - > one public - 10.0.2.0/24, second private - 192.168.15.0/24). > > https://pastebin.com/T8Q7bhWj > > Zoran > _______ > > On Thu, Mar 1, 2018 at 4:56 PM, Zoran S > <zoran.stojsavljevic.de(a)gmail.com> wrote: > > Hello, > > I have very interesting problem: I would like to do Lava testing of > BBB01, but I am not suceeding. > > Simple and plain, my U-Boot scripts gets somehow rejected, they are > not executed. > > I do download correctly, I have all the correct ingredients in place, > but the U-Boot scripts are not activated, at the time of U-boot > prompt. > > Here is my output, from the testing: > https://pastebin.com/hTQQSLU1 > > Rather, the thing gets executed from SDCard (from /boot on rootfs). > > I have no idea why this is not executed. > > Help appreciated! > > Thank you, > Zoran > > > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lava-users

7 years, 3 months

2
4
0 0

LAVA callbacks: including artifacts

by Kevin Hilman

Hello, When attachments were deprecated with v1, that left a hole in how to easily get test artifacts (e.g. results files, image files, large logs, etc.) off the DUT and into LAVA results. I'm aware of tools like Artifactorial[1] which seem to help getting files off the DUT and into a web service, but I'm not entirely sure how to add pointers/URLs for those artifacts into the LAVA output, such that they would be included in the notify callbacks. Are there examples someplace for how to include links to artifacts pushed to Artifactorial in LAVA callbacks? Thanks, Kevin [1] https://github.com/ivoire/Artifactorial

7 years, 3 months

2
2
0 0

Re: [Lava-users] LAVA 2018

by ywang

Here could be a reference for you guys: https://github.com/WindRiver-OpenSourceLabs/lava-base Regards, -Yang Message: 3 Date: Thu, 1 Mar 2018 19:29:13 -0500 From: Chris McClellan <ckuhn203(a)gmail.com> To: Conrad Djedjebi <conrad.djedjebi(a)linaro.org> Cc: Lava Users Mailman list <lava-users(a)lists.linaro.org> Subject: Re: [Lava-users] LAVA 2018 Message-ID: <07DC74CF-1EDC-4A20-AB08-F29739C0BCBB(a)gmail.com> Content-Type: text/plain; charset="utf-8" We're starting to look into it. We've only gotten about as far as creating a dockerfile (for sid) that defines the installation process though. > On Mar 1, 2018, at 4:49 PM, Conrad Djedjebi <conrad.djedjebi(a)linaro.org> wrote: > > Good morning LAVA users, > > I would like to know if there is someone among the LAVA users who installed his own LAVA 2018 master instance ? > > Is everyone here using the LAVA LAB master instance available here : https://validation.linaro.org ? > > Am I the only one who is installing his own LAVA 2018 master instance? >

7 years, 3 months

1
0
0 0

Re: [Lava-users] LAVA 2018

by Conrad Djedjebi

Hi Magnus Olsson, Have you experienced issues regarding CSRF token? After migrating from LAVA 2016 to LAVA 2018, did your first login into your server return the following : Django.png <https://drive.google.com/a/linaro.org/file/d/0B0v46EqqhhcaVk9zM2N1UHJnM2NXd…> ? Regards, Le 2 mars 2018 05:47, "Magnus Olsson" <magnus(a)minimum.se> a écrit : > We recently upgraded our master from an old 2016.11 to 2018.2. After about > a week of fixing migration issues things are starting to work again. 2018.2 > is so far a good release, the only open issue we have left is the broken > csv export that breaks our tools for generating external reports ( > https://projects.linaro.org/browse/LAVA-1253) > > > On Mar 1, 2018 22:49, Conrad Djedjebi <conrad.djedjebi(a)linaro.org> wrote: > > > > Good morning LAVA users, > > > > I would like to know if there is someone among the LAVA users who > installed his own LAVA 2018 master instance ? > > > > Is everyone here using the LAVA LAB master instance available here : > https://validation.linaro.org ? > > > > Am I the only one who is installing his own LAVA 2018 master instance? > > > > > > Best regards,

7 years, 3 months

3
3
0 0

Re: [Lava-users] LAVA 2018

by Magnus Olsson

7 years, 3 months

1
0
0 0

Re: [Lava-users] LAVA 2018

by Magnus Olsson

We recently upgraded our master from an old 2016.11 to 2018.2. After about a week of fixing migration issues things are starting to work again. 2018.2 is so far a good release, the only open issue we have left is the broken csv export that breaks our tools for generating external reports (https://projects.linaro.org/browse/LAVA-1253) On Mar 1, 2018 22:49, Conrad Djedjebi <conrad.djedjebi(a)linaro.org> wrote: > > Good morning LAVA users, > > I would like to know if there is someone among the LAVA users who installed his own LAVA 2018 master instance ? > > Is everyone here using the LAVA LAB master instance available here : https://validation.linaro.org ? > > Am I the only one who is installing his own LAVA 2018 master instance? > > > Best regards,

7 years, 3 months

1
0
0 0

LAVA 2018

by Conrad Djedjebi

Good morning LAVA users, I would like to know if there is someone among the LAVA users who installed his own LAVA 2018 master instance ? Is everyone here using the LAVA LAB master instance available here : https://validation.linaro.org ? Am I the only one who is installing his own LAVA 2018 master instance? Best regards,

7 years, 3 months

2
1
0 0

CSV export on LAVA 2018.2

by magnus＠minimum.se

Hey, Not sure where to report LAVA bugs, https://wiki.linaro.org/LAVA (https://wiki.linaro.org/LAVA) indicates I should use the Linaro bugzilla but it seems to be closed? Anyway, I think there's an issue with the CSV result export in LAVA 2018.2, can anyone confirm? Example CSV: https://validation.linaro.org/results/1686046/csv (https://validation.linaro.org/results/1686046/csv) The first line of the CSV file is: [u'job', u'suite', u'result', u'measurement', u'unit', u'duration', u'timeout', u'logged', u'level', u'metadata', u'url', u'name', u'id']1686046,12_bootchart-stop,pass,None,,,,2018-02-28 05:01:35.935783+00:00,,"{'case': 'generate-bootchart-graphic', 'definition': '12_bootchart-stop', 'result': 'pass'}",/results/testcase/2871860,generate-bootchart-graphic,2871860 .. when it probably should've been two lines: job,suite,result,measurement,unit,duration,timeout,logged,level,metadata,url,name,id 1686046,12_bootchart-stop,pass,None,,,,2018-02-28 05:01:35.935783+00:00,,"{'case': 'generate-bootchart-graphic', 'definition': '12_bootchart-stop', 'result': 'pass'}",/results/testcase/2871860,generate-bootchart-graphic,2871860 I believe the issue is 1) a missing linebreak after the header-line and 2) the formatting of the header line (drop the Python repr stuff).

7 years, 3 months

2
1
0 0

Django CSRF Token cookies

by Bill Fletcher

I have the same problem trying to login to admin on localhost. For me it's independent of browser and browser cookie configuration. I assume it's an issue with Django configuration. Regards Bill -- EMEA Field Engineering Linaro Ltd Harston Mill CB22 7GG Cambridge UK +44 7833 498336 <+44%207833%20498336>

7 years, 3 months

2
1
0 0

Django CSRF Token cookies

by Conrad Djedjebi

Good morning everyone, I would like to show you the following : Did anyone encounter that error in the past while trying to log into a local standalone master instance of lava ? I installed LAVA 2018 and the localhost page in being opened without issues. Things get worst when I try to login. I am getting that error on chromium and Firefox. Both of them have cookies enabled. Best regards,

7 years, 3 months

2
1
0 0

Error while submitting a LAVA Test Job Definition | Standalone LAVA Master installation

by Conrad Djedjebi

Good morning everyone, I am getting in touch with you in order to show you an issue i am facing after submitting a basic Test Job Definition through my LAVA web page (localhost). I am a new LAVA user. After submitting my job, I see the following error in the job's page : Something seems to be going wrong with "commands" and I am trying to figure out what it is. Did anyone already encountered this error in the past? (I edited a jinja2 device type file and a jinja2 dictionary file as well to match my device's properties. The device type file is saved in /etc/lava-server/dispatcher-config/device-types/ and the device dictionary file is saved in /etc/lava-server/dispatcher-config/devices/). Thank you for your help,

7 years, 3 months

3
4
0 0

Does LAVA v2 support test image dummy deployed

by Arthur She

Hi, I have an impression that we can have test image "dummy" deployed once I am sure the image in the device is bootable. That will save time for downloading and flashing to the device. Does it still be supported in LAVA v2? Thanks, Arthur

7 years, 3 months

2
1
0 0

Re: [Lava-users] set up issue

by Christopher McClellan

Hermanth, You were able to install on stretch? I was attempting to do so, but the python3-django-auth-ldap package wasn't available on anything but sid. Did you run into the same issue? Regards, Chris > Date: Tue, 27 Feb 2018 14:10:46 +0530 > From: Hemanth K V <kv.hemanth.mys(a)gmail.com> > To: Lava Users Mailman list <lava-users(a)lists.linaro.org> > Subject: [Lava-users] set up issue > Message-ID: > <CAEua01SDZE6=7+rgnr6+1WA-j3Z3g2ECywP0qtT0xR8Z9GE9Gw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello Lava-Users, > > After following the setup of LAVA on Debian 9 stretch and when we try to > login from UI we face the following error Ref > https://validation.linaro.org/static/docs/v2/installing_on_debian.html > > $ sudo apt install postgresql > $ sudo apt install lava-server > > If the default Apache configuration from LAVA is suitable, you can enable > it immediately: > > $ sudo a2dissite 000-default > $ sudo a2enmod proxy > $ sudo a2enmod proxy_http > $ sudo a2ensite lava-server.conf > $ sudo service apache2 restart > > Forbidden (403) > > CSRF verification failed. Request aborted. > > You are seeing this message because this site requires a CSRF cookie when > submitting forms. This cookie is required for security reasons, to ensure > that your browser is not being hijacked by third parties. > > If you have configured your browser to disable cookies, please re-enable > them, at least for this site, or for 'same-origin' requests. > > > Is there anything missing from the setup. > > > Thanks, > > Hemanth.

7 years, 3 months

2
1
0 0

User notifications in LAVA

by Xu, Hongyu

Hi all, Why I can't receive the email when I use the 'User notifications' in LAVA ? notify: criteria: status: canceled verbosity: quiet recipients: - to: method: email email: hongyu.xu(a)hxt-semitech.com<mailto:hongyu.xu@hxt-semitech.com> or notify: criteria: status: complete verbosity: quiet recipients: - to: user: '1680141' method: email [cid:image001.png@01D3AFE4.37D7A500] Best Regards XuHongyu This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

7 years, 3 months

2
1
0 0

Re: [Lava-users] set up issue

by Tim Jaacks

This is a django configuration issue. I don’t understand why this case (it is very common, obviously) is not handled in the LAVA documentation explicitly. There is a short hint, though, here: https://validation.linaro.org/static/docs/v2/pipeline-debug.html#using-loca… You have to add these two variables to /etc/lava-server/settings.conf: "CSRF_COOKIE_SECURE": false, "SESSION_COOKIE_SECURE": false I achieved this using the following commands: sudo apt-get install jq jq '.CSRF_COOKIE_SECURE=false | .SESSION_COOKIE_SECURE=false' /etc/lava-server/settings.conf > /tmp/settings.conf && mv /tmp/settings.conf /etc/lava-server/settings.conf sudo chown root:root /etc/lava-server/settings.conf sudo service lava-server-gunicorn restart 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, 3 months

1
0
0 0

set up issue

by Hemanth K V

Hello Lava-Users, After following the setup of LAVA on Debian 9 stretch and when we try to login from UI we face the following error Ref https://validation.linaro.org/static/docs/v2/installing_on_debian.html $ sudo apt install postgresql $ sudo apt install lava-server If the default Apache configuration from LAVA is suitable, you can enable it immediately: $ sudo a2dissite 000-default $ sudo a2enmod proxy $ sudo a2enmod proxy_http $ sudo a2ensite lava-server.conf $ sudo service apache2 restart Forbidden (403) CSRF verification failed. Request aborted. You are seeing this message because this site requires a CSRF cookie when submitting forms. This cookie is required for security reasons, to ensure that your browser is not being hijacked by third parties. If you have configured your browser to disable cookies, please re-enable them, at least for this site, or for 'same-origin' requests. Is there anything missing from the setup. Thanks, Hemanth.

7 years, 3 months

1
0
0 0

x86 sample job

by Hemanth K V

Hello Lava Users, Trying to setup the x86 based board to our local lava farm to execute tests. Want to boot the target with pxe based mechanism .Trying to follow the job definition https://staging.validation.linaro.org/scheduler/job/210084/definition .With this facing the following error when running the job.Let me know if i am missing anything with job defination or device defination . File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 563, in validate self.internal_pipeline.validate_actions() File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 201, in validate_actions action.validate() File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/boot/ipxe.py", line 221, in validate elif self.parameters['commands'] not in device_methods[self.parameters['method']]: TypeError: unhashable type: 'list' Device dictionary defination is Device dictionary yaml: connection_command: telnet localhost 8021 extends: x86.jinja2 Thanks, Hemanth.

7 years, 3 months

3
8
0 0

LAVA V2 hangs over non-existent job!

by Zoran S

Hello to LAVA admins, You have fatal error in Lava V2. I submitted job, which hangs in submitted state indefinitely. I also see the non-existent job 92 (which is deleted) running there?! http://localhost:8080/scheduler/device/bbb01 254 2018-02-21 12:05 Reserved → Running — Job 92 running 253 2018-02-21 12:04 Idle → Reserved — Reserved for job 92 252 2018-02-21 12:03 Running → Idle — Job 91 cancelled 251 2018-02-21 12:03 Reserved → Running — Job 91 running 250 2018-02-21 12:03 Idle → Reserved — Reserved for job 91 249 2018-02-21 11:33 Running → Idle — Job 89 has ended. Setting job status Incomplete But when I look to this local pointer: http://localhost:8080/admin/lava_scheduler_app/testjob/ 102 Submittednobodylessbeaglebone-black -Feb. 21, 2018, 1:07 p.m.-- 76 Incompletenobodylessbeaglebone-black bbb01 (Running, health Unknown)Feb. 20, 2018, 9:50 a.m.Feb. 20, 2018, 9:50 a.m.Feb. 20, 2018, 9:55 a.m. 49 Completenobodylessqemu qemu01 (Idle, health Unknown)Feb. 16, 2018, 10:44 a.m.Feb. 16, 2018, 10:44 a.m.Feb. 16, 2018, 10:50 a.m. 43 Completenobodylessqemu qemu01 (Idle, health Unknown)Feb. 16, 2018, 8:42 a.m.Feb. 16, 2018, 8:43 a.m.Feb. 16, 2018, 8:49 a.m. How to force submitted job to be active job (from both CLI and GUI)? How to delete nonexistent jobs (from both CLI and GUI)? Thank you, Zoran

7 years, 3 months

2
7
0 0

Lava dispatcher long test runs executions in V.L.O.

by Anibal Limon

Hi, I created a Piglit test definition [1] before i try to test it out into the V.L.O. i used test-runner to make a run locally (db410c) without lava-dispatcher, the run took ~2 hours 5 minutes [2] (wo download/flash) after that i tried to execute into the V.L.O. and it consumes 8 hours of execution and then finalize with a timeout, the test didn't reach the end and was able to execute only 14486 tests of 39249. So i download the definition and executed the lava-run command in my desktop and the full test execution was in ~2 hours 38 minutes that makes sense because needs to download and flash the boot and rootfs images. [4] I introduced a time call for measure the piglit time execution in test-runner and lava-dispatcher and the exec times are the same ~96 minutes in both executions, search for ' Thank you for running Piglit' in the logs [2][5]. I noticed when i ran lava-run into my desktop the CPU usage increases to 100% when reaches the step of actually running the test [6], i made some debugging and discover that the manner to get the results and notifications from serial console is using pexpect and certain regexes, i attached the gdb to the python process and found that the regexes executes over the whole serial buffer in very short intervals [7] That could be the reason of the delay in the test execution since the Piglit command takes the same time to run with test-runner and lava-dispatcher. Best regards, Anibal [1] https://git.linaro.org/qa/test-definitions.git/tree/automated/linux/piglit/… [2] http://qcom-hackbox.linaro.org:8090/stdout_testrunner.log.gz [3] https://lkft.validation.linaro.org/scheduler/job/101274 [4] http://qcom-hackbox.linaro.org:8090/stdout_dispatcher.log.gz [5] http://qcom-hackbox.linaro.org:8090/stdout_dispatcher_time.log.gz [6] http://qcom-hackbox.linaro.org:8090/lava_run_top.log [7] http://qcom-hackbox.linaro.org:8090/lava_run_gdb.log [8] https://git.linaro.org/lava/lava-dispatcher.git/tree/lava_dispatcher/action…

7 years, 3 months

2
3
0 0

Problems with jinja2 scripts in /etc/lava-server/dispatcher-config/devices

by Zoran S

Hello, I am bringing now the target Beaglebone Black, as DUT in Lava. Here is my BBB01.jinja2 device definition: {% extends 'beaglebone-black.jinja2' %} {% set connection_command = '/vagrant/scripts/connectBBB.sh localhost 8020 root ""' %} {% set power_on_command = '/usr/bin/egctl egenie on left left left' %} {% set power_off_command = '/usr/bin/egctl egenie off left left left' %} {% set hard_reset_command = '/usr/bin/egctl egenie on left left left' %} Where the line: "vagrant/scripts/connectBBB.sh localhost 8020 root ""' represents as $@ the following: 127.0.0.1 8020 root and "" ("" represents empty password, actually <cr>). It seems that this part works correctly: end: 2.4.1 reset-device (duration 00:00:00) start: 2.4.2 u-boot-interrupt (timeout 00:03:00) Changing prompt to 'Press SPACE to abort autoboot' u-boot-interrupt: Wait for prompt Press SPACE to abort autoboot (timeout 00:03:00) spawn telnet localhost 8020 Trying ::1... Connected to localhost. Escape character is '^]'. ser2net port 8020 device /dev/ttyUSB0 [115200 N81] (Debian GNU/Linux) end: 2.4.2 u-boot-interrupt (duration 00:00:02) start: 2.4.3 bootloader-commands (timeout 00:02:58) Changing prompt to start interaction: U-Boot bootloader-commands: Wait for prompt U-Boot (timeout 00:03:00) switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** Unable to read file boot.scr ** ** Unable to read file uEnv.txt ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** Unable to read file boot.scr ** ** Unable to read file uEnv.txt ** 4161168 bytes read in 293 ms (13.5 MiB/s) 35016 bytes read in 23 ms (1.5 MiB/s) ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 Loading Device Tree to 8fff4000, end 8ffff8c7 ... OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.13.8-jumpnow (oe-user@oe-host) (gcc version 7.2.0 (GCC)) #1 Fri Jan 12 13:27:03 CET 2018 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] OF: fdt: Machine model: TI AM335x BeagleBone Black [ 0.000000] Memory policy: Data cache writeback [ 0.000000] cma: Reserved 16 MiB at 0x9f000000 [ 0.000000] CPU: All CPU(s) started in SVC mode. But when it comes to login to kernel login, it fails! Starting OpenBSD Secure Shell server: sshd key_load_public: invalid format Could not load host key: /etc/ssh/ssh_host_rsa_key key_load_public: invalid format Could not load host key: /etc/ssh/ssh_host_dsa_key key_load_public: invalid format Could not load host key: /etc/ssh/ssh_host_ecdsa_key key_load_public: invalid format Could not load host key: /etc/ssh/ssh_host_ed25519_key sshd: no hostkeys available -- exiting. Starting rpcbind daemon...done. starting statd: done exportfs: can't open /etc/exports for reading modprobe: can't change directory to '/lib/modules': No such file or directory NFS daemon support not enabled in kernel Starting syslogd/klogd: done Poky (Yocto Project Reference Distro) 2.3.2 beaglebone /dev/ttyO0 beaglebone login: [ 170.488770] random: crng init done bootloader-commands timed out after 178 seconds end: 2.4.3 bootloader-commands (duration 00:02:58) uboot-retry failed: 1 of 1 attempts. 'bootloader-commands timed out after 178 seconds' bootloader-commands timed out after 178 seconds end: 2.4 uboot-retry (duration 00:03:00) uboot-action failed: 1 of 1 attempts. 'bootloader-commands timed out after 178 seconds' bootloader-commands timed out after 178 seconds end: 2 uboot-action (duration 00:03:00) Cleaning after the job Cleaning up download directory: /var/lib/lava/dispatcher/tmp/84/tftp-deploy-a0ZzPD/ramdisk Cleaning up download directory: /var/lib/lava/dispatcher/tmp/84/tftp-deploy-a0ZzPD/kernel Cleaning up download directory: /var/lib/lava/dispatcher/tmp/84/tftp-deploy-a0ZzPD/dtb Cleaning up download directory: /var/lib/lava/dispatcher/tmp/84/tftp-deploy-a0ZzPD/modules start: 4.1 power-off (timeout 00:00:05) nice /usr/bin/egctl egenie off left left left command output socket 1 - off socket 2 - off socket 3 - off socket 4 - off It seems that empty character as "" in jinja2 is noit well represented (or maybe I need to have somehow <CR>)?! Any advise too this problem? Thank you, Zoran zo

7 years, 3 months

2
6
0 0

Re: [Lava-users] Integrating a custom bootloader

by Tim Jaacks

Hi Neil, thanks for your reply. >Why do you need an in-house bootloader? (Hint: Just because you can / have >is the worst possible reason.) Honestly, just find some other way to do it >- it will likely be much quicker. We have developed our own bootloader for our hardware, for various reasons, and want our OS to be tested in combination with it. Our devices do not support any other bootloader except our own anyway, so there is no other possibility. This is what we have, and we need to automate testing somehow. So I am trying to figure out whether LAVA is suitable for this task. >Supporting a new bootloader is a very complex and time-consuming process >for any test framework. It typically takes several months. Once done, there >is an ongoing maintenance burden as the code for the supported bootloaders >continues to advance. This is not a problem generally. We are planning long-term and want a future-proof solution. >You need a new Strategy Class, as per the documentation. You must not >overload the "method: u-boot" support for anything except U-Boot. You must >create a new boot method. Why? What is wrong with using the u-boot method for a bootloader which works similarly? As far as I can see right now, I would only remove stuff from the u-boot method and set a bunch of already existing variables to new values. I do not see the need for a completely new boot method. Is there any hard reason for this, except that it would be neater? 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, 3 months

2
1
0 0

Integrating a custom bootloader

by Tim Jaacks

Hello, I am evaluating LAVA as a candidate for software release testing on our devices. I have already set up a LAVA instance with a Beaglebone Black board running regular health checks. Our own devices do not use a standard bootloader, but a custom one developed by our team. It has the following characteristics: * Always boots to a shell (no interruption needed) * OS is installed on internal eMMC by calling an installation script * Installation script and OS images are deployed to the device via TFTP by calling a bootloader command sequence * Installed OS is booted via a bootloader command sequence So LAVA has already implemented TFTP as a deployment method, which I can re-use. As far as I understand, this deployment method copies the files to the machine's TFTP server directory, so that they are available to the device for download. However, the actual download (from TFTP server to device) is implemented as a command sequence in the boot method. Is that correct? At least, this is what I see in the base-uboot.jinja2 device type template. I thought that it should be possible to re-use the "u-boot" bootloader class for our own bootloader, since the basic concepts (calling bootloader commands for TFTP download, calling bootloader commands for OS execution) are similar. The only difference might be that we don't need interruption, but that seems to be handled by the "needs_interrupt" parameter, which I could set to False. Are these assumptions correct from an experienced LAVA point of view? Would this be a reasonable approach for getting LAVA to work with our own bootloader? Or is it necessary to implement our own bootloader python class in lava_dispatcher/actions/boot/? 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, 3 months

2
1
0 0

Re: [Lava-users] Unable to get job summary for running test job in master-slave configuration

by Neil Williams

Please *always* reply to the list, not to the individual. On 19 February 2018 at 13:35, mayuri mohite <mayumohite18393(a)gmail.com> wrote: > Hello Neil, > > Thanks for your valuable reply i have uncomment encryption option file in > /etc/lava-server/lava-logs still i am not getting any log on GUI. > > Here i have attached my screen shots and my master and slave log > You've used tail on the slave.log but that has excluded all of the relevant content for this particular job - the messages when the job started. Restart lava-slave, resubmit the test job and then attach the full lava-slave.log to a reply to the mailing list. You've sent screenshots of quite an old UI as well - what version of LAVA are you running? (Include the output of dpkg -l lava-server lava-dispatcher ) > > I have submitted same job which is mentioned in > https://validation.linaro.org/static/docs/v2/first-job.html > > ####Below steps i am running on server side if any wrong please correct > me:#### > 1)$ sudo apt install postgresql > 2)$ sudo apt install lava-server > 3)$ sudo a2dissite 000-default > 4)$ sudo a2enmod proxy > 5)$ sudo a2enmod proxy_http > 6)$ sudo a2ensite lava-server.conf > 7)$ sudo service apache2 restart > 8)sudo lava-server manage createsuperuser --username <username> > --email=mail_ID > 9)ADD DEVICE TYPE AND DEVICES(whose worker host is hostnamefqdn of local > machine) using GUI AND THEN RUN BELOW COMMAND to add device dictionary > $ sudo lava-server manage device-dictionary --hostname qemu01 --import > qemu01.dict > $ cat qemu01.dict > {% extends 'qemu.jinja2' %} > {% set mac_addr = '52:54:00:12:34:59' %} > {% set memory = '1024' %} > 10)sudo /usr/share/lava-dispatcher/create_certificate.py master > 11)edit /etc/lava-server/lava-master file > $ cat /etc/lava-server/lava-master > # Configuration for lava-master daemon > > # Socket addresses of the master and logger > # MASTER_SOCKET="tcp://*:5556" > # LOGGER_SOCKET="tcp://*:5555" > > # Logging level should be uppercase (DEBUG, INFO, WARNING, ERROR) > # LOGLEVEL="DEBUG" > > # Encryption > # If set, will activate encryption using the master public and the slave > # private keys > ENCRYPT="--encrypt" > MASTER_CERT="--master-cert /etc/lava-dispatcher/certificates.d/master.key_ > secret" > SLAVES_CERTS="--slaves-certs /etc/lava-dispatcher/certificates.d/" > > 11)edit /etc/lava-server/lava-logs > $ cat /etc/lava-server/lava-logs > # Encryption > # If set, will activate encryption using the master public and the slave > # private keys > ENCRYPT="--encrypt" > > MASTER_CERT="--master-cert /etc/lava-dispatcher/certificates.d/master.key_ > secret" > SLAVES_CERTS="--slaves-certs /etc/lava-dispatcher/certificates.d" > > > ####Below steps i am running on Dispatcher side if any wrong please > correct me:#### > > 1)$ sudo apt install lava-dispatcher > 2)Create certificates > $ sudo /usr/share/lava-dispatcher/create_certificate.py foo_slave_1 > 3)copy certificates to server side > 4)changed /etc/lava-dispatcher/lava-slave configuration file > > $ cat /etc/lava-dispatcher/lava-slave > # Configuration for lava-slave daemon > > # URL to the master and the logger > MASTER_URL="tcp://134.86.62.197:5556" > # LOGGER_URL="tcp://<lava-master-dns>:5555" > > # Logging level should be uppercase (DEBUG, INFO, WARNING, ERROR) > # LOGLEVEL="DEBUG" > > # Enable IPv6 to connect to the master and logger > # # IPV6="--ipv6" > # > # # Slave hostname > # # Should be set for host that have random hostname (containers, ...) > # # The hostname can be any unique string, except "lava-logs" which is > reserved > # # for the lava-logs daemon. > HOSTNAME="--hostname mayuridb.mayuri" > > # Encryption > # If set, will activate encryption using the master public and the slave > # private keys > ENCRYPT="--encrypt" > MASTER_CERT="--master-cert /etc/lava-dispatcher/certificates.d/master.key" > SLAVE_CERT="--slave-cert /etc/lava-dispatcher/certificates.d/foo_slave_1. > key_secret" > 5)Now restart lava-salve > > > ######## GUI setup ############ > 1)Add worker host as newly added worker i.e dispatcher hostname > 2)Then submit job > > On Mon, Feb 19, 2018 at 12:35 PM, Neil Williams <neil.williams(a)linaro.org> > wrote: > >> On 16 February 2018 at 12:24, mayuri mohite <mayumohite18393(a)gmail.com> >> wrote: >> >>> Hello all, >>> >>> I am following steps mentioned in https://validation.linaro.org/ >>> static/docs/v2/pipeline-server.html#zmq-curve for installing lava >>> dispatcher on local machine (slave which is my worker machine) and >>> https://validation.linaro.org/static/docs/v2/installing_on_debian.html >>> for installing lava server on another machine (master) >>> >> >> It's always useful to mention which version of LAVA you are running. >> >> Check: https://staging.validation.linaro.org/static/docs/v2/ >> pipeline-server.html#enable-master-encryption >> >> Also edit /etc/lava-server/lava-logs to enable encryption: >> >> # Encryption >> # If set, will activate encryption using the master public and the slave >> # private keys >> ENCRYPT="--encrypt" >> >> Then restart the lava-master and lava-logs services. >> >> >>> >>> I have added device through GUI using https://validation.linaro.org/ >>> static/docs/v2/first-devices.html#create-device-database documentation >>> >>> I have successfully added worker to serevr side and able to get message >>> showing that encryption has been enabled on the both master and slave side. >>> >>> I am able to run test job on added target which has worker as slave >>> machine on which my dispatcher is running. >>> My job is started it is showing runnig state but I am not getting any >>> console log in job summary. >>> >>> please help me to get debug log in job summary. >>> >>> Regards, >>> >>> Mayuri. >>> >>> _______________________________________________ >>> 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, 3 months

3
2
0 0

deploying to secondary media

by Hemanth K V

Hello Lava Users, Is there any sample example describing the "Enabling Secondary Media". I want to boot x86 based board with primary OS booted from USB and want to deploy the image to SATA used as secondary media. Thanks, Hemanth.

7 years, 3 months

2
1
0 0

Error while submitting a Test Definition | Standalone LAVA Master installation

by Conrad Djedjebi

Good morning everyone, I am getting in touch with you in order to show you an issue i am encountering while submitting a basic Test Definition through my LAVA web page (localhost). I am a new LAVA user. Both the two attached scripts are returning the following error in the interface : I checked the syntax of my yaml files using an online tool. Here is a description of the steps I followed while installing the Standalone Master instance of LAVA on my computer : - Installing lava-server - Setting up Apache2 server - Setting ser2net - Adding a superuser to lava system - Creating a device type (.jinja2) file and a device - Writing a Test Definition (.yaml file) - Submitting that Test Definition through the GUI of lava thank you for your help,

7 years, 3 months

2
2
0 0

Unable to get job summary for running test job in master-slave configuration

by mayuri mohite

Hello all, I am following steps mentioned in https://validation.linaro.org/static/docs/v2/pipeline-server.html#zmq-curve for installing lava dispatcher on local machine (slave which is my worker machine) and https://validation.linaro.org/static/docs/v2/installing_on_debian.html for installing lava server on another machine (master) I have added device through GUI using https://validation.linaro.org/static/docs/v2/first-devices.html#create-devi… documentation I have successfully added worker to serevr side and able to get message showing that encryption has been enabled on the both master and slave side. I am able to run test job on added target which has worker as slave machine on which my dispatcher is running. My job is started it is showing runnig state but I am not getting any console log in job summary. please help me to get debug log in job summary. Regards, Mayuri.

7 years, 3 months

2
1
0 0

[IMPORTANT - test issue #99] Issues with installing when running behind a web proxy

by Zoran S

More about proxies: Here is update on the Lava proxy business. Please, read this very carefully, since this is the solution to the problems with Lava proxies, as well as Lava DUT ones. YES, after applying what Remi advised to me, the qemu01 test: https://www.validation.linaro.org/static/docs/v2/first-job.html worked like a charm. I simply copied /etc/lava-server/env.yaml to /etc/lava-server/env.dut.yaml (and created the new file). Remi, I would like to thank you for the advise! Best Regards, Zoran Stojsavljevic ---------- Forwarded message ---------- From: Remi Duraffort <remi.duraffort(a)linaro.org> Date: Thu, Feb 15, 2018 at 4:30 PM Subject: Re: [Lava-users] [HW target questions] Pointers from Lava test suite to the HW target To: Zoran S <zoran.stojsavljevic.de(a)gmail.com> Cc: Lava Users Mailman list <lava-users(a)lists.linaro.org> Not exactly. 1/ The process that is deploying, booting and testing a DUT (Device Under test) is called lava-run. lava-run environment variables are controlled by /etc/lava-server/env.yaml By default, all environment variables are removed and only a small set of variables are added. This helps to make executions reproducible between dispatchers and instances. So if you need an environment variable to be set, then you have to add it to /etc/lava-server/env.yaml 2/ On the DUT itself, by default, we don't add or change any environment variable. Because that's the user responsibility. However, if /etc/lava-server/env.dut.yaml does exists, it will be used to add environment variables to the DUT shell. To create the list of environment variables to add to the DUT, we take the full environment from lava-run (as defined by /etc/lava-server/env.yaml) and we apply the rules from env.dut.yaml. I hope that does help you to understand how environment is setup in lava. Rgds On Wed, Feb 14, 2018 at 2:04 PM, Zoran S <zoran.stojsavljevic.de(a)gmail.com> wrote: > https://gitlab.com/cip-project/cip-testing/testing/issues/99 > > Also from: > https://lists.cip-project.org/pipermail/cip-dev/2017-July/000338.html > > At the end of test issue #99, I added the solution to this problem. > > Lava does NOT read VM's ENV variables. It ignores them. Lava reads > /etc/lava-server/env.yaml as setup proxy file! > > Included there also /etc/lava-server/env.yaml file example. > > It could be done also DIRECTLY (every time bringing up the VM) using > python, tapping into the urllib3 python code (example given): > https://stackoverflow.com/questions/31151615/how-to-handle-proxies-in-urlli… > > I've tried this, using in-line python interpreter, it worked. > > Zoran

7 years, 3 months

1
0
0 0

Test execution without creating images

by Hemanth K V

Hello Lava Users, Trying to reproduce LAVA installation in our lab.Was able to successfully test deploy boot and test through nfs metod. But having difficulty when device is booted with *preinstalled Debian or OpenEmbedded images and ** we just want to execute tests on it (no need to create images at moment).* Can have any reference documents or templates to refer when just want to execute tests on device. Thanks, Hemanth.

7 years, 3 months

2
3
0 0

[HW target questions] Pointers from Lava test suite to the HW target

by Zoran S

Hello to the Lava users, I am the new Lava user. My aim is to use Lava (for now V1) setup for my testing, from the beginning just to hook-up my Beagle Bone Black (BBB) to Lava worker, and from Lava apache to set the proper context for testing BBB HW. As I am reading Lava framework, I got the following impression about the test suite: [1] I need to prepare BBB's U-Boot for the Lava U-Boot jinja2 setup; [2] I need to hook-up my EG-PMS2-LAN (energenie) to the Lava (to PO and POFF HW platform); [3] I need to hook-up ser2net interface (which I already have working over TCP) to the Lava. so Lava can control it; [4] I need to hook-up uImage, .dtb and ramdisk images to the Lava (which will be FTPed and set in memory for board setup and testing). Question 1: Does manual have some Beagle Bone Black U-Boot default scripts, which should be provisioned to the BBB U-Boot for the correct Lava U-Boot behavior? Question 2: How do I do [1], [2], [3] and [4], does Lava manual have some explanation as working example how to do these points? Question 3: Anything else I missed for the proper Lava test setting? Thank you in advance, Zoran

7 years, 3 months

3
16
0 0

Unable to connect to mirror.bytemark.co.uk:http: [IP: 2001:41c8:20:5e6::10 80]

by Zoran S

After figuring out proxies and setting them correctly, I let run First QEMU job, described here: https://staging.validation.linaro.org/static/docs/v2/first-job.html And have the following errors: https://pastebin.com/334xHvX8 For example, there are no elements requested from this job such as: E: Failed to fetch http://mirror.bytemark.co.uk/debian/pool/main/p/python3.5/python3.5-minimal… Unable to connect to mirror.bytemark.co.uk:http: [IP: 2001:41c8:20:5e6::10 80] E: Failed to fetch http://mirror.bytemark.co.uk/debian/pool/main/p/python3-defaults/python3-mi… Unable to connect to mirror.bytemark.co.uk:http: [IP: 2001:41c8:20:5e6::10 80] But I am getting on ping mirror.bytemark.co.uk PING mirror.bytemark.co.uk (212.110.161.69)... ??? IP address seems to be IPV6 (which points that something is not correctly set)?! I also checked a routing table, everything there within VM is set correctly. Do I need to set more of the proxies?! What is the problem here??? Thank you, Zoran

7 years, 3 months

3
6
0 0

Regarding LXC Job

by Chetan Sharma

Hi Everyone, If i execute a LXC Job. If this job execution failed due to any reason, then in that case LXC-stop is not called, directly lxc-destroy is called by which LXC instance is still running on system and consumes memory and Space. How we can can make sure that this instance destroys with Job completion either Failed/Passed/Incomplete. -- Thanks & Regards Chetan Sharma

7 years, 4 months

2
1
0 0

user logins via http and https

by Kevin Hilman

Is there a way to make user logins to work whether you're connecting over HTTP or HTTPS on the same instance? I know that to get user logins to work without https, you have to add this to /etc/lava-server/settings.conf: "CSRF_COOKIE_SECURE": false, "SESSION_COOKIE_SECURE": false, But it would be nice if user logins would also work over https at the same time. The use case for this is an internal LAVA instance that doesn't have https so internal connections are all over http. The same instance is also available to the outside world via an nginx reverse proxy with TLS termination, so connections from outside are over https. Can it be made to work for both internal (http) and external (https) connections? Thanks, Kevin

7 years, 4 months

2
1
0 0

how to achieve sync among multi-node in job definition

by Liao, Guoqi

Hi Guys: When I am doing a multi-node testing, I create one job definition liking below. For example: Sub-job 1 finished booting and testing, but sub-job 2 is on-going booting. So sub-job 1 will Remove the template file like <lava_dipatcher>/tmp/overlay****, that will cause sub-job 2 could NOT download The overlay**** file, sub-job 2 failed in the end. My question is how to do sync between multi-node in the job Definition? My job definition: protocols: lava-multinode: roles: foo: tags: - board1 device_type: ********** context: grub_method: centos grub_installed_device: (hd1,gpt1) count: 1 bar: tags: - board2 device_type: ********** context: grub_method: centos grub_installed_device: (hd2,gpt1) count: 1 timeout: minutes: 6 job_name: centos openjdk test timeouts: job: minutes: 1500 action: minutes: 50 connection: minutes: 30 priority: medium visibility: public actions: - deploy: role: - foo - bar kernel: url: http://******** type: zimage os: centos timeout: minutes: 80 to: tftp - boot: timeout: minutes: 40 role: - bar method: grub commands: centos_installed auto_login: login_prompt: 'login:' username: root password_prompt: 'Password:' password: root prompts: - 'root@localhost ~' transfer_overlay: download_command: rm -f /root/overlay* ; ifconfig ; wget -S --progress=dot:giga unpack_command: tar -C / -xaf parameters: shutdown-message: "reboot: Restarting system" - boot: timeout: minutes: 40 role: - foo method: grub commands: centos_installed auto_login: login_prompt: 'login:' username: root password_prompt: 'Password:' password: root prompts: - 'root@localhost ~' transfer_overlay: download_command: rm -f /root/overlay* ; ifconfig ; wget -S --progress=dot:giga unpack_command: tar -C / -xaf parameters: shutdown-message: "reboot: Restarting system" - test: role: - foo - bar timeout: minutes: 50 definitions: - repository: ssh://**********/test-definitions from: git branch: ********** path: automated/linux/openjdk/openjdk-smoke.yaml name: openjdk-smoke Thanks B.R. Guoqi This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

7 years, 4 months

2
3
0 0

Minimal Boot: manage additional parameters

by Philippe BEGNIC

Hello Lava Team, I have created some Lava jobs that use our proprietary Flasher, based on a DFU connection. As our flasher is not a "standard" flasher, I have adapted the boot process to be able to use our flasher. I use the boot method "minimal" to achieve this. To call our flasher script, I have used the script called by the method "power_on". This is defined in the device configuration. Find below an extract of the device content : ....................................................................................... .. .. {% set hard_reset_command = '/usr/bin/pduclient --daemon localhost --hostname lava_pdu_01.lme.st.com --command reboot --port 1' %} {% set power_off_command = '/usr/bin/pduclient --daemon localhost --hostname lava_pdu_01.lme.st.com --command off --port 1' %} {% set power_on_command = '/root/git/lava-config/scripts/flash_stm32_programmer.sh -u lava_pdu_01.lme.st.com -p 1 -d usb1 -b ds378_2.lme.st.com -s 4_5_6 -f /tmp/test' %} {% set connection_command = 'telnet localhost 2001' %} .. .. ....................................................................................... This works correctly for a "static" configuration. The settings for the flasher are defined outside Lava by a script that configure the flashing parameters. The "power_on" script reads these parameters, and launch the flashing on the board. My problem now, is when I launch simultaneously jobs on several boards that requires different flashing binaries version. I am unable to indicate to each boards which binary version to be used by our flasher. The best way would be to pass parameters in the job to indicate which binary version has to be used by the flasher. This could be done in the "deploy action" and pass to the "power_on" command, but I don't know how to implement it. I don't know also if it is possible to do that easily ? Find below my job definition. ###### Job definition ############## actions: - deploy: timeout: minutes: 5 to: ssh os: oe device: - boot: method: minimal failure_retry: 2 auto_login: login_prompt: 'login:' username: root prompts: - 'root@stm32mp1' timeout: minutes: 10 transfer_overlay: download_command: sync && sleep 15 && wget unpack_command: tar -C / -xzf - test: ... ############################# Thanks to support me. BR Philippe

7 years, 4 months

3
7
0 0

request: disable LXC support, or make it optional

by Kevin Hilman

When using LAVA inside a docker container, the LXC support adds lots of unnecessary overhead since the docker images are already made to include the necessary tools. So having another container is pointless. Even worse, LXC doesn't work inside docker anyways. The LXC support should be made optional for a given LAVA install. Until LXC can be disabled, projects like lava-docker[1] simply cannot support fastboot devices which is a major problem. Kevin [1] https://github.com/kernelci/lava-docker/

7 years, 4 months

4
5
0 0

Enabling ZMQ authentication leads to lava-logs offline

by Chase Qi

Hi, I have lava-master and lava-slave v2018.1 installed, and a qemu device added. Test job can be scheduler. Then I followed https://validation.linaro.org/static/docs/v2/pipeline-server.html#using-zmq… to enable ZMQ authentication. Certificates were generated correctly, public certificates were copied to master and slave respectively. With the following configs: lava-master ``` MASTER_SOCKET="--master-socket tcp://*:5556" LOGLEVEL="DEBUG" ENCRYPT="--encrypt" MASTER_CERT="--master-cert /etc/lava-dispatcher/certificates.d/master.key_secret" SLAVES_CERTS="--slaves-certs /etc/lava-dispatcher/certificates.d/" ``` lava-slave ``` MASTER_URL="tcp://192.168.11.214:5556" LOGGER_URL="tcp://192.168.11.214:5555" HOSTNAME="--hostname lava-slave1" LOGLEVEL="DEBUG" ENCRYPT="--encrypt" MASTER_CERT="--master-cert /etc/lava-dispatcher/certificates.d/master.key" SLAVE_CERT="--slave-cert /etc/lava-dispatcher/certificates.d/slave1.key_secret" ``` After lava-master and lava-slave restarted, I see the following logs. Seems the connect was established, but lava-logs went offline. lava-master ``` 2018-01-30 11:05:50,260 DEBUG lava-slave1 => PING(20) 2018-01-30 11:05:52,086 DEBUG lava-master => PING(20) 2018-01-30 11:06:08,728 DEBUG lava-logs => PING(20) 2018-01-30 11:06:10,261 INFO scheduling health checks: 2018-01-30 11:06:10,270 DEBUG -> disabled on: lxc, qemu 2018-01-30 11:06:10,271 INFO scheduling jobs: 2018-01-30 11:06:10,272 DEBUG - lxc 2018-01-30 11:06:10,292 DEBUG - qemu 2018-01-30 11:06:10,332 DEBUG lava-slave1 => PING(20) 2018-01-30 11:06:12,115 DEBUG lava-master => PING(20) 2018-01-30 11:06:20,252 INFO [POLL] Received a signal, leaving 2018-01-30 11:06:20,254 INFO [CLOSE] Closing the controler socket and dropping messages 2018-01-30 11:06:21,203 INFO [INIT] Dropping privileges 2018-01-30 11:06:21,204 DEBUG Switching to (lavaserver(114), lavaserver(119)) 2018-01-30 11:06:21,204 INFO [INIT] Marking all workers as offline 2018-01-30 11:06:21,209 INFO [INIT] Starting encryption 2018-01-30 11:06:21,211 DEBUG [INIT] Opening master certificate: /etc/lava-dispatcher/certificates.d/master.key_secret 2018-01-30 11:06:21,238 DEBUG [INIT] Using slaves certificates from: /etc/lava-dispatcher/certificates.d/ 2018-01-30 11:06:21,245 INFO [INIT] LAVA master has started. 2018-01-30 11:06:21,246 INFO [INIT] Using protocol version 2 2018-01-30 11:06:41,247 WARNING lava-logs is offline: can't schedule jobs 2018-01-30 11:07:01,255 WARNING lava-logs is offline: can't schedule jobs 2018-01-30 11:07:04,433 INFO lava-slave1 => HELLO 2018-01-30 11:07:04,433 WARNING New dispatcher <lava-slave1> 2018-01-30 11:07:09,450 DEBUG lava-slave1 => PING(20) 2018-01-30 11:07:21,260 WARNING lava-logs is offline: can't schedule jobs 2018-01-30 11:07:29,477 DEBUG lava-slave1 => PING(20) 2018-01-30 11:07:41,265 WARNING lava-logs is offline: can't schedule jobs ``` lava-slave ``` 2018-01-30 11:06:10,283 DEBUG PING => master (last message 20s ago) 2018-01-30 11:06:10,335 DEBUG master => PONG(20) 2018-01-30 11:06:30,356 DEBUG PING => master (last message 20s ago) 2018-01-30 11:07:04,379 INFO [INIT] LAVA slave has started. 2018-01-30 11:07:04,380 INFO [INIT] Using protocol version 2 2018-01-30 11:07:04,390 INFO [INIT] Starting encryption 2018-01-30 11:07:04,390 DEBUG Opening slave certificate: /etc/lava-dispatcher/certificates.d/slave1.key_secret 2018-01-30 11:07:04,413 DEBUG Opening master certificate: /etc/lava-dispatcher/certificates.d/master.key 2018-01-30 11:07:04,414 INFO [INIT] Connecting to master as <lava-slave1> 2018-01-30 11:07:04,415 INFO [INIT] Greeting the master => 'HELLO' 2018-01-30 11:07:04,440 INFO [INIT] Connection with master established 2018-01-30 11:07:04,442 INFO Master is ONLINE 2018-01-30 11:07:04,443 INFO Waiting for instructions 2018-01-30 11:07:09,450 DEBUG PING => master (last message 5s ago) 2018-01-30 11:07:09,455 DEBUG master => PONG(20) ``` >From django admin console, I see lava-slave1 still is online, but both lava-master and lava-logs workers went offline, and it stopped scheduling test job. Have you guys ever see/hit this issue? Any advice and suggestions would be appreciated. Thanks, Chase

7 years, 4 months

2
2
0 0

IOZone test to measure performance of DUT

by Florence ROUGER JUNG

Hi All, We use IOZone test to measure performance of our DUT Same command executed several time in a Lava session provide a diversity of results iozone -az -i0 -i1 -I -e -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -f /mnt_emmc//tmp/iozone.tmp Example1: kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 5053 4420 12471 12137 102400 16 5070 5218 22101 22207 102400 512 11733 12630 40799 40862 102400 1024 11446 11494 39982 39976 102400 16384 13839 14235 42093 42094 Example 2: kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 5088 5006 13496 13095 102400 16 5395 5549 17199 17220 102400 512 9203 10038 27819 27586 102400 1024 9382 8482 32514 32430 102400 16384 13569 13986 41992 42081 When same command is executed without LAVA with same DUT, results are more homogeneous (similar to exemple1) and permit to define clear targets How to reduce interaction from Lava to measure performance of DUT ? Is it possible to disable some checks / interactions with DUT during execution of each test (around 3 / 4 minutes) ? Thanks in advance for your answer Florence Rouger-Jung

7 years, 4 months

5
11
0 0

Using power-on command with pyocd boot method

by Andrei Narkevitch

Hi, our boards are powered via PDU and before flashing with pyocd, they need to be powered up first. I defined power_on_command in the device dictionary, but it is ignored. It looks like an only limited set of methods add ResetDevice action to the pipeline and pyocd is not among them. Contrarily, if defined, power_off command always gets invoked because it is added by FinalizeAction to every test. I'm wondering if there is any way to issue the power-on command without modifying the dispatcher pipeline source code. Thanks, Andrei Narkevitch, Cypress Semiconductor 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, 4 months

2
2
0 0

Request to know one example on prepare-scp-overlay

by Chetan Sharma

Hi Everyone Can anyone share sample Yaml File and Usecase using "prepare-scp-overlay" using MultiNode. Some calls can only be made against specific actions. Specifically, the prepare-scp-overlay action needs the IP address of the host device to be able to copy the LAVA overlay (containing the test definitions) onto the device before connecting using ssh to start the test. This is a complex configuration to write. -- Thanks & Regards Chetan Sharma

7 years, 4 months

2
7
0 0

Procedure to install lava-coordinator setup

by Chetan Sharma

Hi Everyone, Can anyone share a step by step process to install Lava-coordinator in existing Setup to execute multinode job. Existing Setup :- 1. Lava-Server (Machine 1) 2. Lava-worker (Machine 2) 3. Lava-worker (Machine 3) -- Thanks & Regards Chetan Sharma

7 years, 4 months

3
4
0 0

lava-tool wait-job-events

by Loys Ollivier

Hello everyone, I am using lava-tool to monitor my jobs. Previously I used: $ lava-tool submit-job --block Using version of lava-tool 0.23 I now have this message: --> This kind of polling is deprecated and will be removed in the next release. Please use "wait-for-job" command. But "wait-for-job" doesn't exist. There is a "wait-job-events" option though. I tried this one and it doesn't return even once the job has finished. If I manually stop it and restart it with the same job number I get as output: --> Job already finished with status Complete. Command I'm using: $ lava-tool wait-job-events --job-id 20 http://user@lava-server Is there anything I'm doing incorrectly ? Or are you aware of this bug ? Thanks ! -- Loys OLLIVIER

7 years, 4 months

3
13
0 0

Booting with Coreboot/Depthcharge

by Guillaume Tucker

A change was sent a while ago to add support for the Coreboot / Depthcharge bootloader which is used on Chromebook devices. This is useful in particular to avoid having to install U-Boot on Chromebook devices. See this Gerrit review here for previous history: https://review.linaro.org/#/c/15203/ I'm now opening this case again to try and get this resolved, there seem to be several issues with the original patch that would need to be clarified. Also, some things might have changed since then in LAVA or Coreboot which could potentially lead to a different approach - any feedback on this would be welcome. To start with, I understand that running mkimage on the dispatcher is not a valid thing to do, it should receive a FIT (flattened image tree) kernel image ready to be booted. This complicates things a bit for projects like kernelci.org where only a plain kernel image is built and ramdisks are served separately, but it's fair enough to say that LAVA is not meant to be packaging kernel images on the fly. Then I believe creating the command line file in LAVA should be fine, although it probably makes more sense to have both the FIT image and cmdline file generated by the same build system. In any case, both files would need to be served from the dispatcher TFTP server to the target device running Coreboot / Depthcharge. So the idea was basically to have an option in Coreboot / Depthcharge to interactively tell it where to find these files for the current job to run, say: <JOB_NUMBER>/tftp-deploy-<RANDOM>/kernel/vmlinuz <JOB_NUMBER>/tftp-deploy-<RANDOM>/kernel/cmdline It looks like the current patch in Gerrit relies on this location to be hard-coded in the bootloader, which works fine for a private development set-up but not for LAVA. To recap, my understanding is that the "depthcharge" boot support code in LAVA would need to: * maybe create the cmdline file with basically the kernel command line split up with one argument per line * or just download the cmdline file along with the vmlinuz FIT * place both the cmdline and vmlinuz FIT files in the job's TFTP directory on the dispatcher * turn on the device and open the serial console... * interactively pass at least the path to the job TFTP directory on the serial console (and if possible the server IP address as well, and maybe even the individual file names rather than hard-coded vmlinuz and cmdline) * look for a bootloader message to know when the kernel starts to load and hand over to the next action (login...) Please let me know if this sounds reasonable or if we should be doing anything differently. I think it would be good to have some agreement and a clear understanding of how this is going to be implemented before starting to work on the code again. Best wishes, Guillaume

7 years, 5 months

2
17
0 0

LAB Notice: LAVA Instance downtime

by Dave Pigott

[bcc’d to everyone] Hi all, Next week, starting on Monday, we will be upgrading all the LAVA servers to Debian Stretch and then upgrading to LAVA 2018.01. This will involve minimal downtime for each instance. Devices will be off-lined ahead of each upgrade. The order of upgrade will be: Monday: LNG: lng.validation.linaro.org PMWG: pmwg.validation.linaro.org Tuesday: Production: validation.linaro.org LKFT: lkft.validation.linaro.org All being well, the downtime, i.e. the time you will not be able to submit jobs or see the web site, will be of the order of one hour per instance. If that is going to change I will send out a new notification. Thanks for your patience, Dave ---------------- Dave Pigott LAVA Lab Lead Linaro Ltd t: (+44) (0) 1223 400063

7 years, 5 months

1
2
0 0

Re: [Lava-users] No result coming when job submitted in lava

by Robert Marshall

Smita, Yes I looked and confirm that analysis, you've not commented on what the U-Boot prompt is? I'm putting lava-users back on the cc list in case others wish to comment, and making my comment below clearer Robert "Gumansingh, Smita" <Smita_Gumansingh(a)mentor.com> writes: > Hi Robert, > > Have you got any chance to see my bbb health check log > > bbb health check fails at this point > > ------------ ---------------------- > send-reboot-commands timed out after 179 seconds > end: 2.4.1.1 send-reboot-commands (duration 00:02:59) > ---------------------------- > > Please have a look on this log https://pastebin.com/gPmMG84J > > Thanks & Regards, > Smita Gumansingh > > ________________________________________ > From: Robert Marshall <robert.marshall(a)codethink.co.uk> > Sent: Wednesday, January 10, 2018 6:21 PM > To: Gumansingh, Smita > Subject: Re: [Lava-users] No result coming when job submitted in lava > > Smita > > Though you only to replace that line *if* the U-Boot prompt doesn't ^ need > consist of "U-Boot⇒" - interrupt the BBB boot to see what it actually is, > and if it is necessary, you also need to remove the other line - > apologies for the instructions not being clear here. > > Thanks for the fuller output in the other email! > > Robert > > "Gumansingh, Smita" <Smita_Gumansingh(a)mentor.com> writes: > >> Thanks Robert for the quick response >> >> Currently u-boot is showing in /etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2 is: >> >> {% set bootloader_prompt = bootloader_prompt|default('U-Boot') %} >> >> As you suggested I added the line: {% set bootloader_prompt = bootloader_prompt|default('⇒') %} and submitted a job >> >> No output from the job when submitted... >> >> Thanks & Regards, >> Smita Gumansingh >> >> ________________________________________ >> From: Robert Marshall <robert.marshall(a)codethink.co.uk> >> Sent: Wednesday, January 10, 2018 5:08 PM >> To: Gumansingh, Smita >> Cc: lava-users(a)lists.linaro.org >> Subject: Re: [Lava-users] No result coming when job submitted in lava >> >> Hi, some comments below! >> >> "Gumansingh, Smita" <Smita_Gumansingh(a)mentor.com> writes: >> >>> Hi, >>> I am new to lava and trying to submit a job on lava scheduler ,job submitted nut no result is coming. I am trying to >>> test the CIP Kernel on the Beaglebone Black(board is physically connected to my linux machine). Health checkup is >>> working somehow . >> >> By 'somehow' do you mean the health check is completing correctly and the >> device is shown as online? >> >>> I am following the steps from here >>> https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingrefe… >>> >>> Pre-requise: >>> 1. I have built(cip_v4.4.92) the CIP Kernel with Kernel CI as the steps mentioned in >>> https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipsystembuild… >>> 2.Target is booted and up and flashed with debian 4.9 rootfs >>> >> >> What is the U-Boot prompt with this version, if it is ⇒ rather than U-Boot⇒ >> >> on the vagrant machine you need to >> >> sudo vi /etc/lava-server/dispatcher-config/device-types/beaglebone-black.jinja2 >> And add the line: {% set bootloader_prompt = bootloader_prompt|default('⇒') %} >> >> >>> Job Definination is pasted here >>> >>> https://pastebin.com/YwnPXidK >>> >>> Need help for going further !!!! >> >> Do you get any output from the job? >> >>> >>> Thanks & Regards, >>> Smita Gumansingh >>> >> >> Robert

7 years, 5 months

1
0
0 0

No result coming when job submitted in lava

by Gumansingh, Smita

Hi, I am new to lava and trying to submit a job on lava scheduler ,job submitted nut no result is coming. I am trying to test the CIP Kernel on the Beaglebone Black(board is physically connected to my linux machine). Health checkup is working somehow . I am following the steps from here https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingrefe… Pre-requise: 1. I have built(cip_v4.4.92) the CIP Kernel with Kernel CI as the steps mentioned in https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipsystembuild… 2.Target is booted and up and flashed with debian 4.9 rootfs Job Definination is pasted here https://pastebin.com/YwnPXidK Need help for going further !!!! Thanks & Regards, Smita Gumansingh

7 years, 5 months

2
1
0 0

Better bootloader failure detection

by Matt Hart

Currently it is difficult to tell the difference between an infrastructure problem in a device bootloader, or a kernel failure. If a kernel silently fails to boot, LAVA throws a bootloader-commands timeout because it hasn’t matched ‘Linux version’ to know the kernel has started. However, this timeout could also be caused by a real problem in the bootloader, such as a DHCP failure or a TFTP timeout. KernelCI would like to catch actual infrastructure problems in the bootloader, but can’t tell if the kernel just didn’t boot, or the commands actually timed out in the bootloader. To fix this, we're going to: - change the bootloader-commands action to finish when it has sent the last command - have auto-login-action takeover monitoring the kernel boot process - extend bootloader-commands to match more infrastructure problems - update uboot commands to execute the commands in order (like the other bootloader implementations), rather than building a script and then calling that as the last command This work is scoped for the January 2018.1 LAVA release.

7 years, 5 months

3
2
0 0

Job stuck

by Thomas Petazzoni

Hello, We have an installation where we use LAVA 2017.12. We are regularly seeing jobs that remain stuck for several days. For example, I have a job right now on the Armada XP GP that is stuck since 1 day and 11 hours. The log visible in the LAVA Web interface looks like this: http://code.bulix.org/7pvru8-255308?raw This is job #855671 in our setup. The logs on the lava-slave look like this: http://code.bulix.org/c5tejy-255312?raw So, from the lava-slave point of view, the job is finished. However, the "Job END" message had to be resent several times to the master. Interestingly, this sequence lead to a very nice: ERROR [855671] lava-run crashed On the lava-master side (which runs on another machine), the logs look like this: http://code.bulix.org/b61keb-255316?raw And this happens for lots of jobs. Pretty much every day or two, we have ten boards stuck in this situation. I have the lava-master logs with DEBUGs if this can be helpful. However, must DEBUG logs don't have the job number in them, so it makes it difficult to associate the DEBUG messages with the problematic job (since numerous other jobs are running). Does anyone has an idea what could be causing this ? Or how to debug this further ? Best regards, Thomas Petazzoni -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com

7 years, 5 months

3
2
0 0

LXC device not working in multinode jobs

by Andrei Gheorghiu

Hi, I am having issues using an LXC device within the multinode LAVA protocole/API. The job yaml gets validated, but it fails to run with the following error: Missing protocol 'lava-lxc' in ['lava-multinode'] Full yaml used can be found here: https://pastebin.com/BUsX0G0C While searching for a fix I also found this email from a year ago, which wasn't answered (seems related): http://linaro-validation.linaro.narkive.com/mXhxhHqy/issues-with-lava-multi… Thanks, Andrei

7 years, 5 months

2
1
0 0

Help: using custom script - run.sh error

by Mylene JOSSERAND

Hello everyone, I am trying to use lava with a custom script[1]. Previously, my test was used as a shell script (using exit) and I updated it to be a custom script to be able to use "skip" result. I ran a job and I got this error: /lava-854766/0/tests/1_custom-tests/run.sh: line 1: ####: not found It seems to be linked with my echo of "#### Starting NAND test ####" [2]. Here is the yaml used: https://github.com/free-electrons/test_suite/blob/master/tests/custom.yaml the source of the script: https://github.com/free-electrons/test_suite/blob/master/scripts/nand.sh the jinja file: https://github.com/free-electrons/custom_tests_tool/blob/master/src/jobs_te… and some part of the output when the test ran and failed: http://code.bulix.org/ca3mc7-254957?raw As I am new to LAVA, I have probably missed something. On the current test example [3], it seems that there is no output using "echo". Is it possible that my "echo" leads to this error? It is possible to print messages in a custom script, right? [1]: https://validation.linaro.org/static/docs/v2/writing-tests.html#writing-cus… [2]: https://github.com/free-electrons/test_suite/blob/master/scripts/nand.sh#L9 [3]: https://git.linaro.org/lava-team/refactoring.git/tree/functional/unittests.… Thank you in advance for your help, Best regards, -- Mylène Josserand, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com

7 years, 5 months

2
4
0 0

Need Help With Simplistic Testing Over SSH

by Tan, Jian Chern

Hi, I'm trying to get started with LAVA by first attempting to do some simplistic testing over SSH to run some tests on a device that doesn't have a default template. I'm getting a few connection errors and others like output ['Permission denied (publickey,password).\r', 'lost connection', ''] and it's probably because I've misconfigured the jinja files, having little experience with these LAVA jinja templates. Attached are the job logs, jinja2 template files and the test yaml file. Could anyone point me in the right direction by either providing sample ssh jinja files and job files or pointing out the errors in my config. Thanks! Thanks! Jian Chern

7 years, 5 months

1
0
0 0

Unpacking tar.bz2 root filesystems seems to malfunction

by Dragos Iorgulescu

Hi all! I am working with some Raspberry Pi boards and, while defining some particularities for booting via NFS, I came across an issue regarding the way the rootfs file is unpacked. To be more specific, after looking through the LAVA code, it seems that the untar_file() method runs on the conditional branch that states the tar members are specified. I do not understand how this implementation is designed in regards to tar archive manipulation, but the following scenario takes place: * The rootfs archive we specify in the job definition is copied and renamed, the extension being changed from .tar.bz2 to a plain .tar (which seems a bit strange tom e, on its own) * Then, after unpacking to the LAVA temp job dir, only two directories are extracted from the whole rootfs archive. I did manage to „inverveene” while the job was running and looking in the temp dir to see exactly what gets extracted. Since the rest of the folders from the rootfs are not available, the job fails once the system starts booting While investigating, I noticed that the untarf_file() method is invoked from download.py (/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/deploy/) - @ line 344 – with members being specified. I know that, because when I manually changed how this call is made and clearly specified “None” for the “member” positional argument, I get the following error at job runtime: https://paste.debian.net/1001252/ (the full job log can be found here: https://paste.debian.net/1001253/ ) The code changes I am talking about (and the code where I suspect something is ambiguous) are pointed out here: https://paste.debian.net/1001256/ . A job definition we use for this board integration can be analyzed here: https://paste.debian.net/1001257/ The full log of the initial job, that ran without my code changes, can be found here: https://paste.debian.net/1001254/ . The „kernel panic” message ocurs because, as stated in one of the errors, the “init” folder is missing, which is accurate, because only bin & dev are extracted from our rootfs tar.bz2 archive. What could we do? Is this something that needs to be adjusted/fixed in LAVA? Kind regards, Dragoș

7 years, 5 months

4
13
0 0

[RFC][PATCH] lava_dispatcher/actions/boot: Add /dev/loopN device to LXC

by Aníbal Limón

From: Aníbal Limón <anibal.limon(a)linaro.org> Now the Test writer has access to the images inside the LXC to make changes previous deploy/flash into the board, in order to support mount/modify rootfs images the loop device is needed. Add a parameter in the lxc-boot action to map a free loop device (losetup -f) into the LXC. Change-Id: I7060ebac12b10e5390560da082fe6c49568c5ffc Signed-off-by: Aníbal Limón <anibal.limon(a)linaro.org> --- lava_dispatcher/actions/boot/lxc.py | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/lava_dispatcher/actions/boot/lxc.py b/lava_dispatcher/actions/boot/lxc.py index d896d303..e3e3cb48 100644 --- a/lava_dispatcher/actions/boot/lxc.py +++ b/lava_dispatcher/actions/boot/lxc.py @@ -75,7 +75,11 @@ class BootLxcAction(BootAction): def populate(self, parameters): self.internal_pipeline = Pipeline(parent=self, job=self.job, parameters=parameters) self.internal_pipeline.add_action(LxcStartAction()) - self.internal_pipeline.add_action(LxcAddStaticDevices()) + + lxc_add_loop = False + if 'lxc_add_loop' in parameters: + lxc_add_loop = parameters.get('lxc_add_loop', False) + self.internal_pipeline.add_action(LxcAddStaticDevices(lxc_add_loop)) self.internal_pipeline.add_action(ConnectLxc()) # Skip AutoLoginAction unconditionally as this action tries to parse kernel message # self.internal_pipeline.add_action(AutoLoginAction()) @@ -91,11 +95,12 @@ class LxcAddStaticDevices(Action): worker. """ - def __init__(self): + def __init__(self, lxc_add_loop=False): super(LxcAddStaticDevices, self).__init__() self.name = 'lxc-add-static' self.description = 'Add devices which are permanently powered by the worker to the LXC' self.summary = 'Add static devices to the LXC' + self.lxc_add_loop = lxc_add_loop def validate(self): super(LxcAddStaticDevices, self).validate() @@ -115,6 +120,15 @@ class LxcAddStaticDevices(Action): def run(self, connection, max_end_time, args=None): connection = super(LxcAddStaticDevices, self).run(connection, max_end_time, args) lxc_name = self.get_namespace_data(action='lxc-create-action', label='lxc', key='name') + + if self.lxc_add_loop: + lxc_get_loop_cmd = ['losetup', '-f'] + loop_device = self.run_command(lxc_get_loop_cmd, allow_silent=True).strip() + lxc_loop_cmd = ['lxc-device', '-n', lxc_name, 'add', loop_device] + cmd_out = self.run_command(lxc_loop_cmd) + if cmd_out: + self.logger.debug(cmd_out) + # If there is no static_info then this action should be idempotent. if 'static_info' not in self.job.device: return connection -- 2.11.0

7 years, 5 months

2
2
0 0

Re: [Lava-users] Booting with Coreboot/Depthcharge

by Tomeu Vizoso

On 18 Dec 2017 3:45 p.m., "Guillaume Tucker" <guillaume.tucker(a)collabora.com> wrote: On 18/12/17 11:45, Neil Williams wrote: > On 14 December 2017 at 09:47, Guillaume Tucker < > guillaume.tucker(a)collabora.com> wrote: > > On 07/12/17 17:16, Neil Williams wrote: >> >> On 7 December 2017 at 16:20, Guillaume Tucker < >>> guillaume.tucker(a)collabora.com> wrote: >>> >>> A change was sent a while ago to add support for the Coreboot / >>> >>>> Depthcharge bootloader which is used on Chromebook devices. This >>>> is useful in particular to avoid having to install U-Boot on >>>> Chromebook devices. See this Gerrit review here for previous >>>> history: >>>> >>>> https://review.linaro.org/#/c/15203/ >>>> >>>> I'm now opening this case again to try and get this resolved, >>>> there seem to be several issues with the original patch that >>>> would need to be clarified. Also, some things might have changed >>>> since then in LAVA or Coreboot which could potentially lead to a >>>> different approach - any feedback on this would be welcome. >>>> >>>> >>>> Thanks for picking this up. >>> >>> >> You're welcome. I've now uploaded a new version which generates >> the command line file but not the FIT image, it expects the >> kernel image to be already in this format. Still the same >> Gerrit number: >> >> https://review.linaro.org/#/c/15203/ >> >> I've also made a patch to add the rk3288-veyron-jaq as >> a "depthcharge" device type: >> >> https://review.linaro.org/#/c/22992/ >> >> So as a next step, it would be convenient to find a way to have >> the FIT image generated as part of the LAVA job with a given >> kernel image, dtb, maybe the .its file and optionally a ramdisk. >> >> For the reference: >> >> http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/how >> to.txt;hb=master >> >> To start with, I understand that running mkimage on the >> >>> dispatcher is not a valid thing to do, it should receive a >>>> FIT (flattened image tree) kernel image ready to be booted. This >>>> complicates things a bit for projects like kernelci.org where >>>> only a plain kernel image is built and ramdisks are served >>>> separately, but it's fair enough to say that LAVA is not meant to >>>> be packaging kernel images on the fly. >>>> >>>> >>>> We've come up with a method in the meantime, although it does mean using >>> LXC but that makes it completely generic. It's principally designed for >>> boards which need to munge a kernel and other files into an image to be >>> transferred to the device using tools like fastboot. This is how KernelCI >>> will be able to submit boot tests on devices like HiKey and db410c. >>> Sadly, >>> the example test job is suffering because the db410c devices have a >>> different problem which is keeping them offline. Matt has been looking >>> into >>> this. >>> >>> https://staging.validation.linaro.org/scheduler/job/203317/definition >>> >>> https://staging.validation.linaro.org/static/docs/v2/actions >>> -deploy.html#index-25 >>> >>> >> Thanks for the pointers, seems worth investigating. >> >> On the other hand, creating the FIT image is a similar process to >> that of uImage, which is currently being done directly on the >> dispatcher: >> >> https://git.linaro.org/lava/lava-dispatcher.git/tree/lava_di >> spatcher/actions/deploy/prepare.py#n79 >> >> So would it make sense to add some code there to support FIT? >> > > > What is an example command line to mkimage to do this? > mkimage -D "-I dts -O dtb -p 2048" -f rk3288-veyron-jaq.its arch/arm/boot/vmlinuz Is the its file really needed? I added the ramdisk parameter precisely so lava doesn't need to generate one. Regards, Tomeu Are any external configuration files required? > Everything should be in the .its file, and it should also be possible to generate it on the fly using a template and the LAVA device properties (kernel load address etc...). If this proves to not be flexible enough in practice, then I suppose the .its file could be downloaded although I think we should avoid doing this if we can. Then I believe creating the command line file in LAVA should be >> >>> fine, although it probably makes more sense to have both the FIT >>>> image and cmdline file generated by the same build system. In >>>> any case, both files would need to be served from the dispatcher >>>> TFTP server to the target device running Coreboot / Depthcharge. >>>> >>>> >>>> That bit is fine, the problem is why this cannot use the existing >>> temporary >>> paths which all the other TFTP devices use. Is it just to do some >>> mangling >>> of the files? >>> >>> >> This is resolved now with the version I sent yesterday. >> > > > That makes this review much better, thanks. > Great, thanks for confirming. So the idea was basically to have an option in Coreboot / >> >>> Depthcharge to interactively tell it where to find these files >>>> for the current job to run, say: >>>> >>>> <JOB_NUMBER>/tftp-deploy-<RANDOM>/kernel/vmlinuz >>>> <JOB_NUMBER>/tftp-deploy-<RANDOM>/kernel/cmdline >>>> >>>> It looks like the current patch in Gerrit relies on this location >>>> to be hard-coded in the bootloader, which works fine for a >>>> private development set-up but not for LAVA. >>>> >>>> >>>> That makes very little sense because the whole point of TFTP is that >>> everything after the SERVER_IP is just a relative path from the TFTP base >>> directory which is handled by the TFTP daemon itself. >>> >>> >> Ditto. >> >> To recap, my understanding is that the "depthcharge" boot support >> >>> code in LAVA would need to: >>>> >>>> * maybe create the cmdline file with basically the kernel >>>> command line split up with one argument per line >>>> >>>> >>>> Alternatively, do whatever operations are required in a test shell in >>> the >>> LXC and then pass those files to the device - entirely within the test >>> shell support. >>> >>> >> That, or maybe run mkimage on the dispatcher like for uImage... >> >> The cmdline file is now generated on the dispatcher. >> >> * or just download the cmdline file along with the vmlinuz FIT >> >>> >>>> >>> The ready-made FIT kernel image is now downloaded with the >> version I sent yesterday. >> >> * place both the cmdline and vmlinuz FIT files in the job's >> >>> TFTP directory on the dispatcher >>>> >>>> * turn on the device and open the serial console... >>>> >>>> * interactively pass at least the path to the job TFTP >>>> directory on the serial console (and if possible the server >>>> IP address as well, and maybe even the individual file names >>>> rather than hard-coded vmlinuz and cmdline) >>>> >>>> >>>> Isn't this equivalent to what U-Boot already does with TFTP? >>> >>> >> Almost. This part is now all implemented in the last patch I >> sent. One thing though is that the NFS rootfs parameters are >> stored in the kernel cmdline file and not set interactively in >> the bootloader shell. >> > > > How can these be extended by test writers? We do see requests to add > arguments to the NFS parameters but adding options to the kernel command > line itself is all but essential for most testing. > This can be done using the {{ extra_kernel_args }} template variable, see the other change to add base-depthcharge.jinja2: https://review.linaro.org/#/c/22992/1/lava_scheduler_app/tes ts/device-types/base-depthcharge.jinja2 If anything more special ever needs to be done with some parameters such as inserting some IP address, it can be done in DepthchargeCommandOverlay where the command line file is generated. The only command sent is to start the tftp >> boot with the server IP and the relative paths to the kernel and >> cmdline files. >> > On this topic, the changes to add the tftpboot command in Depthcharge are still under review: https://chromium-review.googlesource.com/c/chromiumos/platfo rm/depthcharge/+/451382 So I think it would actually be wiser to not merge base-depthcharge.jinja2 until the review above has been merged in case the command line syntax needs to be adjusted. * look for a bootloader message to know when the kernel starts >> >>> to load and hand over to the next action (login...) >>>> >>>> >>> Done as well, I've now got the veyron-jaq device booting fine >> with NFS rootfs. There was an issue with adding a ramdisk to the >> FIT image as it was to big to boot on the device, will >> investigate this part to add "ramdisk" boot commands. >> >> >> Please let me know if this sounds reasonable or if we should be >> >>> doing anything differently. I think it would be good to have >>>> some agreement and a clear understanding of how this is going to >>>> be implemented before starting to work on the code again. >>>> >>> Best wishes, Guillaume _______________________________________________ Lava-users mailing list Lava-users(a)lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users

7 years, 5 months

2
2
0 0

about the grub parameter : interrupt_prompts

by Xu, Hongyu

Hi , In our testing, we must test the os centos and Ubuntu, but the grub interrupt_prompts is different betweent Ubuntu and centos. So in my device_type template I use "menu_options: {{ grub_method }}", but the "grub_method" must define in device jinjia2 file. I don't want to often chang the device jinja2 file , whether I can define some options in the job file? Please give me some help! The attachmen are my device_type and device file! methods: grub: menu_options: {{ grub_method }} parameters: {% if grub_method == 'centos' %} interrupt_prompt: {{ grub_interrupt_prompt|default('Press \'e\' to edit the selected item, or \'c\' for a command prompt.') }} {% elif grub_method == 'ubuntu' %} interrupt_prompt: {{ grub_interrupt_prompt|default(' Press enter to boot the selected OS') }} {% elif grub_method == 'pxe' %} interrupt_prompt: {{ grub_interrupt_prompt|default('Press \'e\' to edit the selected item, or \'c\' for a command prompt.') }} {% endif %} bootloader_prompt: {{ grub_efi_bootloader_prompt|default('grub>') }} boot_message: {{ kernel_boot_message | default("Booting Linux Kernel...") }} Best Regards XuHongyu This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

7 years, 5 months

2
1
0 0

Connection closed by foreign host

by Philippe BEGNIC

Hello Lava Team, We faced to errors when we launched long tests ( e.g LTP tests, stress tests ... ) since we use Lava dockers. The following messages are returned by Lava and the test stop : Connection closed by foreign host. err: lava_test_shell connection dropped Marking unfinished test run as failed These error messages appears during the test, if no message are generated on the console during approximatively six minutes. We found a workaround that consist to send periodically message to the console, allowing the test to complete. I would like to know if we can setup a setting to I would like to know if there is a way to inhibit this control, or to change the timeout settings of this control ? Our configuration : Lava 2017.6 with dockers Regards Philippe Begnic

7 years, 6 months

3
3
0 0

Troubles using custom notification client

by David Lewin

Hi, >From a client side, I'd like to be notified that jobs are achieved in a distant lava server. I started with the example provided at https://validation.linaro.org/static/docs/v2/data-export.html#write-your-ow… 1. In a 1st try I've changed the example - because I'm using port 10080 - and it works without the <lookup_publisher> . For that, I've hard coded the url returned by lookup_publisher but this only prints out one status at a time, ie :I needed to restart the script each time to have updates : "Submited"->*Ctrl-C*->Running->*Ctrl-C*->complete 2. In a 2nd time I've tried to implement lookup_publisher thinking the status would be updated automatically. In that case it wants to connect to 5500 and obviously fails after timeout import xmlrpclib > > import argparse > import yaml > import signal > import zmq > import xmlrpclib > from urlparse import urlsplit > > > FINISHED_JOB_STATUS = ["Complete", "Incomplete", "Canceled"] > > token = "mytoken" > username = "username" > #hostname = "lava-server:10080" > > > class JobEndTimeoutError(Exception): > """ Raise when the specified job does not finish in certain timeframe. > """ > > > class Timeout(object): > """ Timeout error class with ALARM signal. Accepts time in seconds. """ > class TimeoutError(Exception): > pass > > def __init__(self, sec): > self.sec = sec > > def __enter__(self): > signal.signal(signal.SIGALRM, self.timeout_raise) > signal.alarm(self.sec) > > def __exit__(self, *args): > signal.alarm(0) > > def timeout_raise(self, *args): > raise Timeout.TimeoutError() > > > class JobListener(object): > > def __init__(self, url): > self.context = zmq.Context.instance() > self.sock = self.context.socket(zmq.SUB) > > self.sock.setsockopt(zmq.SUBSCRIBE, b"") > self.sock.connect(url) > > def wait_for_job_end(self, job_id, timeout=None): > > try: > with Timeout(timeout): > while True: > msg = self.sock.recv_multipart() > try: > (topic, uuid, dt, username, data) = msg[:] > except IndexError: > # Droping invalid message > continue > > data = yaml.safe_load(data) > if "job" in data: > if data["job"] == job_id: > if data["status"] in FINISHED_JOB_STATUS: > return data > > except Timeout.TimeoutError: > raise JobEndTimeoutError( > "JobListener timed out after %s seconds." % timeout) > > def lookup_publisher(hostname): > """ > Lookup the publisher details using XML-RPC > on the specified hostname. > """ > xmlrpc_url = "http://%s:10080/RPC2" % (hostname) > server = xmlrpclib.ServerProxy(xmlrpc_url) > socket = server.scheduler.get_publisher_event_socket() > port = urlsplit(socket).port > listener_url = 'tcp://%s:%s' % (hostname,port) > print("Using %s" % listener_url) > return listener_url > > > > if __name__ == '__main__': > # timeout=1200 > > parser = argparse.ArgumentParser() > parser.add_argument("-j", "--job-id", type=int, help="Job ID to wait > for") > parser.add_argument("-t", "--timeout", type=int, help="Timeout in > seconds") > parser.add_argument("--hostname", help="hostname of the instance") > > options = parser.parse_args() > > # server = xmlrpclib.ServerProxy("http://%s:%s@%s/RPC2" % (username, > token, hostname)) > > #print(server.system.listMethods()) > # ret_status=server.scheduler.job_status(options.job_id) > # print (ret_status['job_status']) > > #publisher = 'tcp://%s' % (hostname) > publisher = lookup_publisher(options.hostname) > > listener = JobListener(publisher) > listener.wait_for_job_end(options.job_id, options.timeout) > >

7 years, 6 months

2
1
0 0

help: can't use specific branch of a test definition repository

by Xu, Hongyu

Hi all , I have saw the doc about : https://validation.linaro.org/static/docs/v2/test-repositories.html#test-re…! My test-definition is in the brach dev-br1, not the master . So I point the branch in my yaml file, but it do noting ! Why? Please give me some help? Best Regards XuHongyu This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

7 years, 6 months

2
3
0 0

Problem with LAVA 2017.12

by LABBE Corentin

Hello I have installed a fresh 2017.12 in a docker and I hit two problem: - With the exception of lava-coordinator, all services (lava-master, lava-server, lava-slave, etc...) fail to start with: service lava-xxxx start lava-xxxx: unrecognized service All Other service successfully start (postgresql, apache2) - I have then re-added old init scripts and when I add a worker with: "lava-server manage workers add lab-slave" I get: Traceback (most recent call last): File "/usr/bin/lava-server", line 78, in <module> main() File "/usr/bin/lava-server", line 74, in main execute_from_command_line(django_options) File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 367, in execute_from_command_line utility.execute() File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 359, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 294, in run_from_argv self.execute(*args, **cmd_options) File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 345, in execute output = self.handle(*args, **options) File "/usr/lib/python2.7/dist-packages/lava_server/management/commands/workers.py", line 77, in handle options["disabled"]) KeyError: 'disabled' iNote that before I have successfully done commands like adding user or device-types Regards

7 years, 6 months

3
4
0 0

Device Integration Stories - request for contributions

by Neil Williams

Possibly the hardest thing that can be done with LAVA is to integrate a new device-type. Every story is different, every device has it's own issues. The LAVA software team would like to build a history of integration stories to document the recovery process, provide integration hints for others, build a wider picture of the requirements of automation across the ecosystem. A key part of any device integration is how to recover a device which has been taken offline by a broken build or broken test action. It is rare that a new device is suitable for LAVA directly out of the box, there are usually firmware updates, configuration changes, jumper settings or other mods required. Each of these steps needs to be documented so that someone else can integrate the same board into their instance and the same steps are useful when recovering a bricked device. Having the Jinja2 template is not usually enough. (As a side note on that, we do welcome all contributions of new jinja2 templates. The one place where everyone looks for new device-type support is lava_scheduler_app/tests/device-types/ in the master branch of http://git.linaro.org/lava/lava-server.git. If you have integrated a device-type which does not exist in that directory, please follow the contribution guidelines in the documentation and submit your Jinja2 template for review.) https://git.linaro.org/lava/lava-server.git/tree/lava_scheduler_app/tests/d… Recent device integrations in LAVA are documented through a process of comments on JIRA stories (all LAVA JIRA stories are accessible anonymously). Sometimes this turns out to be trial and error, so sometimes a README document or similar is created for easy reference. I'll post some of our recovery README documents on this thread later. This is a request for contributions of your integration stories, your device recovery README documents and your input on what are the minimum requirements for automation in general. It doesn't matter how unusual the hardware or how commonplace. It doesn't matter if it took months to integrate or days. Someone may need your information to setup the same device in their instance. If your device is available on the open market, someone could be thinking of how to automate it. Please post your recovery README texts, integration stories here. This list is publicly archived, so this should make it easy for others to find your contribution in their favourite search engine. In future, as well as unit tests, the LAVA software team may ask for the recovery notes and integration story to be posted here when reviewing contributions of Jinja2 templates. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 6 months

1
0
0 0

Setting the "inactivity timeout" parameter

by Dragos Iorgulescu

Hello! Is there a way to set/override/disable the inactivity timeout? While working with a (sometimes) slower board, we end up with "Terminal.stop: Inactivity timeout." . I believe this might have to do with the fact that the board fails to respond in a timely fashion and LAVA marks this as hung. While searching for this in the docs, I only found a reference for hacking sessions. Kind regards, Dragos

7 years, 6 months

2
2
0 0

rootfs resize in LAVA2

by Dragos Iorgulescu

Hi everyone! Does LAVA offer a way to resize rootfs images (“ramdisk_files”, as they are referred to in the code) before deploying them? We are working with our own Linux distro on a Cavium board and we need to resize the rootfs image (which is ext4) after the test overlays are added by LAVA. This step is necessary since we need to run a series of community tests that imply a large number of package dependencies. Also, we do not want to resize the whole image by default, since this will have other CI storage side effects and, also, some policy implications (that I am not really aware of 😊). Anyway, we are currently looking at adding/altering apply_overlay.py (pipeline/actions/) in order to run a resize2fs command after the “updated” ramdisk is unmounted. Just wondering if there is already a more elegant way of doing this. We are also considering making some extensions and maybe get to the point where we could specify this type of requirement in the device dictionary or the device template itself, and then specific code would be executed only if such a setting would be encountered at runtime, but that remains to be discussed. Thanks in advance! Dragoș

7 years, 6 months

2
2
0 0

Local lava test

by Denis HUMEAU

Dear all, I'm quite sure I've seen somewhere in Lava documentation an article explaining how to replay some Lava jobs in a local mode, but I can't find this piece of information anymore. By local mode, I mean: - DUT at the developer desk, not in the test farm - Jobs available on a Lava server - Developer wants to replay/modify locally a job Can you share any link or help on this? Many thanks, Denis

7 years, 6 months

5
5
0 0

Customizing the deployment and booting actions

by Ros Dos Santos, Alfonso (CT RDA DS EVO OPS DIA SE 1)

Hello everyone, in our current project we have some devices that are not "directly" supported by lava. I would like to ask for you opinion on which would be the correct way to proceed. The main problem is that our devices have a EFI implementation in the firmware that is making the task of installing uboot very hard. To avoid this, we thought about serving the image through an "emulated" usb stick. On that regard, we made some progress by setting up a secondary device that would use the linux g_mass_storage module to serve the image through the USB otg port. Our setup is then: 1) The actual testing device 2) The secondary device which only serves the image with g_mass_storage 3) The host machine running the lava-slave application. We thought that we could add a new device-type template to the lava server that would somehow override the deployment and boot actions to address our setup. We tried to look into the base.jinja2 file for some sort of entry point that would allow us to, for example, run a script that would first send the image to the secondary device and secondly run the g_mass_storage module with the image file. Unfortunately, it is still not clear for us how exactly we could inject/override those steps and ignore for instance the boot loader commands. The first question would be, are we going in the right direction? Is there any piece of documentation that would describe a similar problem? What would be your recommendations on this topic? thanks a lot in advance. Best, Alfonso

7 years, 6 months

3
4
0 0

how to add the overlay to my os, start the test definition

by Xu, Hongyu

Hi , I deploy the device with grub(uefi) method. Now it can interrupt to grub>, and run the boot cmd and auto login. I use the pxe iso installation boot or the sata boot, not the nfs boot. But the lava-overlay file only add into ramdisk(initrd.img), it will disappear when os bootup. So I use the transfer_overlay in my job , but it do nothing, the test shell can't be find . Please give me some help! Job.yaml: actions: - deploy: to: tftp kernel: url: http://swlab004/1680141/vmlinuz-4.11.0-7.1.hxt.aarch64 type: zimage ramdisk: url: http://swlab004/1680141/initramfs-4.11.0-7.1.hxt.aarch64.img compression: gz install_overlay: false preseed: url: http://swlab004/centos7/anaconda-ks_1026.cfg os: centos timeout: minutes: 5 - boot: timeout: minutes: 200 connection: serial method: uefi-menu commands: ramdisk_boot auto_login: login_prompt: ".* login:" username: root password_prompt: 'Password:' password: root transfer_overlay: download_command: ifconfig;wget -S --progress=dot:giga unpack_command: tar -C / -xzf prompts: - 'Last login: .*' - '[root@.* .*]#' parameters: shutdown-message: "reboot: Restarting system" - test: timeout: minutes: 50 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: smoke-tests-basic description: "Basic system test command for Linaro Ubuntu images. The test runs basic commands like pwd, uname, vmstat, ifconfig, lscpu, lsusb and lsb_release." maintainer: - hongyu.xu(a)hxt-semitech.com os: - centos scope: - functional run: steps: - echo "test1a:" "pass" from: inline name: smoke-tests1 path: inline/smoke-tests.yaml Best Regards XuHongyu This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

7 years, 6 months

2
5
0 0

LAVA and Mender

by Arnstein Kleven

Greetings, my embedded system is using Mender for over-the-air updates. The way Mender works is that the embedded system needs to have to rootfs partitions, where one is actively being used, and the other is written to when a over-the-air update is initiated. After the new rootfs is written, Mender will change a variable in the bootloader environment and reboot, so that the system boots into the new rootfs. If there is a problem booting into the new rootfs, the bootloader will be set to boot into the old one again. Has anyone here written LAVA tests for systems that use Mender? If so, have you experienced that Mender has complicated the test automation? Any Mender boot test templates would also be appreciated. -- Kind regards, Arnstein Kleven

7 years, 6 months

2
2
0 0

how to auto login the os with lava

by Xu, Hongyu

Hi dear all, I boot my device with nfs in lava, but it can't auto login the os , I put the logs to attachment ! Please give me some idear. And I can boot and auto login successful with sata boot, use the same job.yaml file! My job 454 : device_type: amberwing_rep1 job_name: amberwing_rep_nfs priority: medium visibility: public metadata: docs-filename: amberwing_rep_nfs timeouts: job: minutes: 300 action: minutes: 200 connection: minutes: 100 actions: - deploy: to: tftp kernel: url: http://swlab004/centos7/iso20171026-0/images/pxeboot/vmlinuz type: zimage ramdisk: url: http://swlab004/centos7/iso20171026-0/images/pxeboot/initrd.img compression: xz install_overlay: false nfsrootfs: url: http://autotest002/tmp/rootfs_centos.tar.gz install_overlay: true preseed: url: http://swlab004/centos7/anaconda-ks_1026.cfg os: centos timeout: minutes: 5 - boot: timeout: minutes: 200 connection: serial method: uefi-menu auto_login: login_prompt: '.* login:' username: root password_prompt: 'Password:' password: root commands: nfs_boot prompts: - 'Last login: .*' - '[root@.* .*]#' parameters: shutdown-message: "reboot: Restarting system" - test: timeout: minutes: 50 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: smoke-tests-basic description: "Basic system test command for Linaro Ubuntu images. The test runs basic commands like pwd, uname, vmstat, ifconfig, lscpu, lsusb and lsb_release." maintainer: - hongyu.xu(a)hxt-semitech.com os: - centos scope: - functional devices: - amberwing_rep-022 run: steps: - echo "test1a:" "pass" from: inline name: smoke-tests1 path: inline/smoke-tests.yaml Best Regards XuHongyu This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

7 years, 6 months

2
2
0 0

Migrating scheduling into lava-master

by Neil Williams

LAVA requires a range of singleton daemon processes to schedule, organise, publish and log the test job operations. 2017.12 will be retiring the lava-server daemon and the /var/log/lava-server/lava-scheduler.log, moving those operations into the lava-master daemon and the /var/log/lava-server/lava-master.log. This is one of the steps in the removal of V1. This leads a substantial change to how admins approach an instance running 2017.12 or later. When jobs don't appear to be running for some reason, the default action is to check /var/log/lava-server/lava-scheduler.log - once the instance is running 2017.12 or later, admins need to remember that it is correct for: * /var/log/lava-server/lava-scheduler.log to be empty * the status of the lava-server daemon to be active (exited) * the lava-server service to not restart At some point after 2017.12 has been running, admins can choose to archive or purge /var/log/lava-server/lava-scheduler.log* and / or disable the lava-server service using systemctl. The scheduler from 2017.12 onwards will consist of: * /var/log/lava-server/lava-master.log * /var/log/lava-server/lava-logs.log * the status of the lava-master daemon will be active (running) * the lava-master service will restart when admins request it. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 6 months

1
0
0 0

Fitting the LAVA overlay into an Android rootfs

by Steve McIntyre

[ Related-ish to the discussion in the "Fastboot - Android boot image apply-overlay" thread, but also slightly different so I'm starting a new discussion here... ] Hi folks, We were just discussing in IRC about potential problems with Android images in LAVA, in terms of fitting the overlay. Ideally, the Android builds would have a rootfs configured to be as small as possible - it's automatically resized to fit the available space at first boot, and leaving space otherwise is inefficient. However, if we're going to add the LAVA test overlay into the rootfs, space needs to be left for it to fit. That's not *necessarily* a problem, except that at build time the Android builds don't know how much space we're going to need! This leads to a bit of a chicken-and-eff problem. Anibal has already hacked around this a little bit as a workaround in a job definition - see https://validation.linaro.org/scheduler/job/1652299/definition#defline92 In the lxc, he's converting and expanding the rootfs image to make more space, then converting back ready for flashing. This is still quite hacky - there's still no information available there about the size of the LAVA overlay. It might fit now, but what happens if there's a new LAVA version next month with (hypothetically) a much bigger overlay? So, I'm thinking about a better way to do things here, in 2 parts: 1 .At the point when we apply the overlay, we know roughly how big it is and we could do the resizing of the image to fit directly without needing this guesswork. It's a relatively easy thing to do. 2. [Optionally] If we end up growing the rootfs image ourselves, it *might* end up overflowing the size available when we come to flash things, but "fastboot flash" will check this and abort. I even suggested that (to fail more quickly) we could parse the GPT partition table for size ourselves, but Nicolas pointed out that not all jobs will necessarily have such a partition table. Instead, *maybe* we could include a "maximum rootfs size" parameter somewhere if we care. Otherwise, just rely on fastboot doing the right thing. Does this sound sensible? Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

7 years, 6 months

5
9
0 0

Progress on LAVA-1133

by Neil Williams

LAVA: base-uboot: should not always pass console= https://projects.linaro.org/browse/LAVA-1133 Changes have now been made in review https://review.linaro.org/22540 This is one of the changes which is being migrated from the old bugzilla to the lava-users mailing list, so there is no current thread on this list for this topic. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 6 months

1
0
0 0

Fastboot - Android boot image apply-overlay

by Anibal Limon

Hi, I'm trying to apply-overlay (test tarball) to a ramdisk inside Android boot image , the image contains the kernel (zImage), ramdiisk (initrd.img) and a config file (bootimg.cfg). The Android boot image can be modified using abootimg, for example: $ abootimg -x boot.img $ abootimg-extract-unpack-initrd $ tar -xvzf overlay-5.2.4.tgz -C ramdisk $ abootimg-extract-pack-initrd $ abootimg -u boot.img -r init.rd Currently i can execute a test shell into LXC to make the extraction of the boot image [1][2], the issue i have is that the test overlay tarball (for example: overlay-5.2.4.tgz), isn't available because the creation is handled after the LXC pipeline by deploy action to the target device [3][4]. Any feedback would be appreciate. Best regards, Anibal [1] https://staging.validation.linaro.org/scheduler/job/196031/definition#defli… [2] https://staging.validation.linaro.org/scheduler/job/196031 [3] https://staging.validation.linaro.org/scheduler/job/196031/definition#defli… [4] https://git.linaro.org/lava/lava-dispatcher.git/tree/lava_dispatcher/action…

7 years, 6 months

2
3
0 0

error while executing LAVA power on script

by Philippe BEGNIC

Hello Lava team, We have implemented new scripts to support flashing in our "power on" script. This script manage the PDU, boot pins configuration of the board and an external ST flasher. At the beginning of the job, the "power on" script is launched. Then I got the following error message <line way too long ...> . This cause the execution script to be interrupted, but the job is not interrupted and can continue without flashing the board. I do not have any additional logs regarding this error on the LAVA web interface. Our power on script is composed of several scripts that are "chained", script power on call another script, that call another one. Do you have an idea about this error ? Details concerning our configuration : * we use LAVA V2 ( version 06/2017 ). * our jobs are pipelined jobs ( LAVA V2) * Lava server // dispatcher are installed through dockers. BR Philippe

7 years, 6 months

2
1
0 0

Moving to systemd

by Neil Williams

LAVA, until now, has packaged SysVinit files to manage the various daemons but there have been longstanding problems with log rotation and the need to carry redundant code to manage the daemonize process for python scripts. This has allowed instances to support both SysVinit and systemd because systemd automatically converts the SysVinit files to systemd service files. Now that V1 has been removed, it has become possible and advantageous to drop SysVinit support and move to only systemd support. This is expected to mean that lava-dispatcher (and therefore lava-server) will depend on systemd-sysv, i.e. systemd needs to be the init system to be able to start the daemons upon which LAVA relies. A default install of Debian Jessie and Stretch already defaults to using systemd as the init system, so this does not necessarily involve any changes. If there are questions or issues with this, please reply to the lava-users mailing list. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 7 months

1
0
0 0

Binary flashing test for Dragonboard 410

by Alfred Ziskind

Hi all, We are planning implementing a test that uses QDL (https://git.linaro.org/landing-teams/working/qualcomm/qdl.git/) for DragonBoard flashing. Scenario: after we flashed the binaries with QDL we want to check in the serial log if the boot sequence is correct. Can we develop this test in LAVA? If not, please recommend a test framework that can. Thank you, Alfred

7 years, 7 months

2
1
0 0

LAVA 2017.11 release

by Neil Williams

See https://lists.linaro.org/pipermail/lava-announce/2017-September/000037.html 2017.11 is the second release on the roadmap to the removal of V1. This is the single largest change ever made to the LAVA packages. * All dashboard URLs are permanently disabled in lava-server. * All devices which were not enabled for V2 are now hidden and unusable. * All V1 code has been removed from lava-dispatcher. * All V1 documentation has been removed from lava-server-doc. 2017.11 disables all access to any V1 test data - including V1 only devices. The data itself remains in the database but is not accessible via any API. If you have chosen to keep an archive of V1 test data and have not yet done so, you should do this before installing this upgrade. At the very least, you **must** have a backup of your postgresql database **before** you upgraded to 2017.11 in order to make a V1 test data archive later. 2017.11 requires that **all** workers and each associated master are upgraded to 2017.11 for test jobs to continue running. This is because there have been very large changes to the directories and file layout within both lava-server and lava-dispatcher associated with the removal of the V1 components. The LAVA software team have been checking ahead for the final stage of the roadmap and plans are on track, as described. http:// and https:// changes in django ====================================== A reminder, if you are accessing an instance using http:// (whether localhost or not), then the changes described in the documentation **must** be applied for the instance to operate correctly. This is a security change in Django, not a change in LAVA. https://staging.validation.linaro.org/static/docs/v2/pipeline-debug.html#us… Symptoms include HTTP500 errors but can also include the inability to login to an instance using LDAP or local django accounts, depending on your local apache configuration. Changes in 2017.11 ================== Changes in the 2017.11 release are described below, including the short git commit hash. Use the git commit hash to go directly to that commit using a URL like https://git.linaro.org/lava/lava-server.git/commit/?id=b19b9648a for lava-server or https://git.linaro.org/lava/lava-dispatcher.git/commit/?id=1451e3a4 for lava-dispatcher. Where the changelog message includes a story id like LAVA-552, that id can be added to the base URL: https://projects.linaro.org/browse/ to find out more about the change itself. e.g. https://projects.linaro.org/browse/LAVA-552 All LAVA stories are publicly available without requiring a login. 2017.11 also includes large changes to the packaging of both lava-server and lava-dispatcher. The prompts formerly used to configure a V1 remote worker have been removed. Packaging is maintained at https://github.com/Linaro/pkg-lava-server and https://github.com/Linaro/pkg-lava-dispatcher Packages for 2017.11 have been uploaded to Debian unstable and also the LAVA repositories (for jessie-backports and stretch-backports). lava-server =========== a799fc6c Fix links back to the main instance 5b9656b6 Fix broken plural in header b21f8c8f Fix crash in job_section_log c9526f01 Document the LOG_SIZE_LIMIT setting in settings.conf 63b57c94 Remove lava-mount-masterfs 75b403f4 Remove add_device script 8ddea823 Add description about the disc space requirement for pg_upgradecluster. 5c9dceb2 Remove TemporaryDevice imports 9b21ea48 Removed unused Worker functions 2accb4c3 Matching change to templates for directory change 1d384c4a Update docs regarding device-dictionary lava-server manage command. 32472fac Port 77fd10e2 to scheduler.devices.get_dictionary 114bbfa5 LAVA-1093 - Add a management command to drop all materialized views 8bc9d83a Update dashboard XML-RPC API help for api_version bb090e96 LAVA-552 - add system.api_version support 77fd10e2 LAVA-1092 support passing a context to device_config de7ad3aa Remove dashboard_app views and static files. 4bc68531 Remove templates from dashboard_app. 1a618c27 Remove unused functions d50deca7 api: limit the number of jobs returned 59880e14 Fix HTTP 500 on devicetype health history a39fecf5 Remove unused resources (css, js and images) a32ac3b6 Rename base-bootstrap and content-bootstrap 7c108de1 job: print lava.job result in case of failure b51c419f Remove old templates a9139c1f Use bootstrap template 7915f18f Remove unused resources 7331901a scheduler.api.jobs.show: add failure_comment 71233bff Fix print syntax for python3 compatibility 936d5eca Remove unused tags 4ebb2a39 Remove unused sources 21a7eb18 Save more sql queries by caching values 4d0d867e Remove non pipeline jobs support a6648dbd Retain docs on disabling V1 workers 8eac0d74 Revert "LAVA-950 set the master identity" 68573b1a Remove V1 dependencies a8151559 timing: handle new start/end line format 26cc3ad0 Remove unnecessary js lib beautify. c44009fa Simplify job view e1da85d4 Fix loading of description.yaml 7b41f7ef Add documentation for secondary media writer parameters 1b4d3dd5 LAVA-1081 migrate instance name to settings f3dc1987 Fix up typos from earlier changes faa24f59 LAVA-1079 - remove HIDE_V1 and HIDE_V2 doc options 942b84c3 Remove unused functions and imports e61a4831 LAVA-1056 Drop V1 documentation 126dce0c Fix crash introduced by 42451c9cc f0b28214 Remove v1 codebase 31bb1bf0 Fix notification exception when query is used for data comparison. a6cff700 Remove last references to lava_dispatcher v1 043690d9 Remove references to lava_dispatcher v1 4c9e493c Remove dashboard_app traces from rest of the codebase. c371b8ca drop link to removed page 1b1b638e LAVA-876 - Return empty data stubs for dashboard API calls. 919c10c2 Remove links to dashboard_app in the scheduler_app 1483e9fb Remove leftover from job wizard f7a1c976 docker: allow passing extra options 42451c9c Use all_jobs_with_custom_sort when applicable cc4ffd64 Fix broken links in example test job 0ca5d75c Drop the migration status page. b37fe944 Add a device-type config for the rpi-3b in armv7 32bit mode 9e904a18 Revert "LAVA-876 - Remove access to Dashboard" f07e0950 Fix warning regarding naive datetime e8348425 Remove more references to dashboard_app 103a44be LAVA-876 - Remove access to Dashboard d33c9c98 LAVA-876 - Remove access to Dashboard b6fc46aa Revert "LAVA-1038 add a settings to archive the instance" f75a333d Do not run dashboard test anymore d9163445 Remove references to v1 jobs addb61d9 bug 3268: fix lava-master crash with invalid logs febf91b1 Improve advice on api/help ac8b7df3 fix pep8 error 64025cf3 LAVA-1072 test all template connection syntax 10d5fbe1 Adjust U-Boot load addresses for tegra124 devices to allow bigger kernels f30ef936 LAVA-1065 - Remove dashboard_app urls server wide. 096a2f1c LAVA-1049 - Allow for .yml as well as .yaml for healthchecks 918f0bc7 Fix logic so addldapuser and mergeldapuser work for all LDAP configs 36fcb3c2 Documentation changes for multiple uarts b1de8acf Update instructions for migrating postgres 0ff08373 LAVA-1053 Results limit does not work for queries f9e64aa1 Fix SQL request storm when listing jobs 2d9c4757 No need to save after get_or_create or Create() 8988cb36 LAVA-896 fix level in result export 219fa3dd LAVA-1073 - support for a second UART on a device c934bbbe master: fix database reconnection 4f0e0e62 LAVA-950 set the master identity 316d77fb Expand the device integration guidance. lava-dispatcher =============== d91a5b99 Revert "Stop parsing kernel messages when the end of a panic has been found" 1451e3a4 LAVA-1098 unassigned variable in read_feedback 437d57ba Rationalise the devices directory structure bdffb3bf Add power control to pyocd d9553680 Add feedback check to test shell 06588ddf Receive the udev device directly from the udev rule d811b2a8 Fix license 65d6c6a6 Move arduino101 dfu example urls to images.v.l.o 61cff41c Only log when feedback content was found 0ba35392 Move juno removable URLs to images.validation.linaro.org cb983d97 Cleanup after pytest runs 997265c2 LAVA-1086 add handler to listen to feedback 29a60e38 Add ConfigObj dependency for TFTP check 70bd3fab Fix prospector warnings 6edb8ef9 Fix missing import and other pylint issues 6f7f5f05 Remove lava-lxc-device-* scripts which are unused. 578b054b Use py.test 65c03eca docker: allow passing extra options 7b7d920a device-info should be yaml ef8f7d4c Remove deprecated function 165e14f8 Fix linger period: set it to 10s instead of 5ms 49c500ac Fix double crash when the process crash early 7dbdc2b6 Add test case for secondary deployment writer tool parameters 969459c6 LAVA-1069 - migrate dispatcher device configs 9e8e5258 Use optargs to extend ci-run for python3 e1c1561b Fix python3 breakage in unit test 69277753 Read feedback when finalising connections 0fb44088 LAVA-1067 Refactor fastboot flash operations 9ac71872 Add missing import 94430958 Ensure finalize always finalises protocols 9d712364 Add option to not uniquify secondary image download paths cdfd5909 Fix master cert handling for lava-run and lxc helper 73548f7a Rename dd params to tool for removable media 1802c3e8 Handle master and slave certs as filenames only ed306477 Do not rely on SysV runlevel to ensure container is ready. 75b47c6a Remove loop mounts via guestfs, while applying overlay to sparse image. cd1152e3 Support archlinux and slackware rootfs 6fc024a5 Remove deprecated modules ddf5d2fc Remove v1 code 5561be23 LAVA-1074 - second UART support 758a41a6 Allow configurable writes for secondary storage deployment fb75db4a Add flag to disable uniquifying the download paths -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

7 years, 7 months

1
0
0 0

403: Forbidden - CSRF verification failed (2017.10-1)

by Dragos Iorgulescu

Hi everyone! I have recently upgraded our production server to 2017.10-1. Whenever anyone tries to login in the WEB UI, either the “403: Forbidden – CSRF verification failed” error is returned, or no error at all (for the latter, the default LAVA page is shown again, but with no login info). I also tried creating a new superuser from the CLI. That worked, but I can’t use it to logon via the WEB UI, so I guess this has nothing to do with the user accounts stored in LAVA. Is this triggered by a change in Django/LAVA? Kind regards, Dragoș

7 years, 7 months

2
2
0 0

[lava v2] charts and redefining X attribute

by Jonathan Guyot

Hello everybody, I am working with both Jenkins and lava and I thought it was possible to change X attributes in charts to use Jenkins build number instead of a date. In my job, I defined a metadata like this : job_name: quad-ssh-host device_type: ssh *metadata: {jenkins-build: 725, job-context: nightly}* timeouts: job: minutes: 10 action: minutes: 3 connection: seconds: 20 visibility: public […] and I made a query that can select these jobs using job-context as a filter. Then, in the chart, I wanted to use the jenkins-build value to group job instead of a simple date, but the chart does not seem to be able to do that. I made many tries on the lava 2017.2 version. I wonder whether I am misusing lava charts or if it is an issue that need a fix. Thanks in advance for any reply. Jonathan

7 years, 7 months

2
5
0 0

”502 Proxy Error” for large job log & details (in the WEB UI)

by Dragos Iorgulescu

Hello again! After managing to run a consistent series of tests on one of our boards, I came across a situation where the job log seems to be too big for LAVA to display. When clicking the ”Job details” button, the server eventually sends a ”502 Proxy Error” message. Is there a setting or a workaround to make LAVA serve the job log & details in ”chunks”? I did download the plain log (using, for example, http://LAVA_HOST/scheduler/job/JOB_ID/log_file/plain), and it is, indeed, huge (29 MB), but I was just curious if, maybe a ”log rotation”-like mechanism could be used in these situations (somehow). Thanks in advance! -- /Dragoş

7 years, 7 months

3
4
0 0

Git error after upgrading to 2017.10-1: "fatal: index-pack failed"

by Dragos Iorgulescu

Hi! Just upgraded from 2017.6 to 2017.10-1. Tried re-running some jobs that worked fine just before the upgrade and noticed that git checkouts can no longer pe performed. The encountered error is: fatal: The remote end hung up unexpectedly\nfatal: early EOF\nfatal: index-pack failed\n Tried checking out manualy on the host, using the same repo. It works. How could I proceed investigating this? Could this be related to some lava user configuration that got reset (I don't know if git-related configs are associated with LAVA)? Thanks in advance (again)! P.S: I have attached the plain job log -- /Dragoş

7 years, 7 months

2
3
0 0

LAB Notice: Planned maintenance

by Dave Pigott

[bcc’d to everyone to ensure we get full coverage. Please ignore if you have no interest in LAVA and the Lab] Hi all, Starting this week, we are finalising the transition of LAVA main production to LAVA V2. The main update and hopefully minor downtime, will commence at 09:00 UTC on Monday 6th November. Along with this we will also be upgrading all micro-instances to Debian Stretch and LAVA 2017.11. There will be a brief period on Monday morning, which should be less than an hour, when remote logins will be disabled as we upgrade the gateway server. Please note, that when validation.linaro.org <http://validation.linaro.org/> comes back online, LAVA V1 job submissions will be rejected, so if you have any bots which auto-submit V1 jobs, please work with us to transition them to V2. For future reference, for announcements about Lab availability, you should join the lava-users mailing list. Thanks Dave ---------------- Dave Pigott LAVA Lab Lead Linaro Ltd t: (+44) (0) 1223 400063

7 years, 7 months

1
1
0 0

Very long output line seems to interfere with board output/job run

by Dragos Iorgulescu

Good morning everyone! While running some tests using our Linux distro and a SuperMicro Intel D1521 board, we encounter a situation where a very long line (shown as a "broken line" in LAVA's logs - in the WEB UI) seems to interfere with the job run, in a sense that the job eventually ends in a timeout. This does not happen when that particular set of tests is not run and I am wondering if this might be a LAVA issue. -------------------- A bit of context, first. SuperMicro boards "make sure" your board connection options are limited to using SoL (serial-over-lan), IPMI and a serial port (but in a very limited manner). One is not able to do a "typical" image load, since you may not specify hardware addresses or properly interact with the bootloader. This led to an approach which is best illustrated in the attached diagram. For short: LAVA instantiates an LXC container, from where we run a series of scripts to prepare the board (copy some images & files on an already available Linux instance, altering the Grub menu and then rebooting the board, making it start the image we wish to test) and then run remote commands via SSH. So, basically, the LXC container runs each and every command on the board, acting as the middleman. ------------------- Now, we have the following: * https://paste.debian.net/993516/ -> plain log excerpt that contains the very long line I was talking about (please see line no. 90) * https://paste.debian.net/993517/ -> job definition * https://paste.debian.net/993518/ -> test definition Is there a way to further investigate if this type of output is "giving LAVA a hard time"? Is there a setting that limits interpreted output, somehow? May it be that this is a LAVA issue? Kind regards! -- /Dragoş

7 years, 7 months

2
4
0 0

"No such method: u'results.run_query'" when trying to access queries from a Python script

by Dragos Iorgulescu

Good morning everyone! I am trying to "play around" with user queries in LAVA2. After reading about them (https://validation.linaro.org/static/docs/v2/lava-queries-charts.html?highl… ), I downloaded the provided sample script (https://validation.linaro.org/static/docs/v2/examples/source/query-results.… ), made the required updates (user names, query name, hostname & the such) and gave it a try. The only thing I get stuck on is an XML-RPC lib error: "No such method: u'results.run_query'" (the whole traceback can be seen here: https://paste.debian.net/993833/ ) I have attached the modified script I am trying to run at the moment and a screenshot of the query settings. The API Help page is not reachable/present at the moment (nor on https://validation.linaro.org/static/api/help or on our own LAVA instance ), so I am unable to check whether or not the method's name has changed since the last doc update. What am I missing or doing wrong? Many thanks in advance! Have a great day! -- /Dragoş

7 years, 7 months

2
4
0 0

PXE Booting and flashing device

by Rees, Kevron

I have a minnowboard turbot device that I want lava to boot, flash, reboot to flashed image, and then run tests. I would like to boot the device via PXE networking to an initramfs where I will flash an image to permanent storage. I can use efibootmgr within the initramfs image to set next-boot to the permanent storage device. Once booted from the permanent storage device, lava tests will run as per normal. It appears that many of the ipxe examples I have found simply run tests on the initramfs itself. Is it possible to flash the device once the initramfs has booted? It seems like it would be simple for lava-dispatcher to run wget http://someurl/foo.img | dd of=/dev/sda once the initramfs has reached login. However, I do not know if there is such a deploy mechanism. Does anything already exist within lava to help achieve this model? Is there a better way? Any feedback would be appreciated. -Kevron

7 years, 7 months

2
4
0 0

Truncated commands & output in LAVA2

by Dragos Iorgulescu

Hi all! We have been working on integrating a cn8304-based board (uses uboot). We noticed some strange behavior that might be related to LAVA2. On average, 2 out of 3 job runs end up with errors/timeouts. We use the same job definition and device each and every time. Looking through LAVA logs, it seems that commands and some output gets truncated, thus malforming the commands being sent or the prompts that LAVA expects. The prompt we expect is "EBB8304> ", but sometimes it gets truncated to "304>". Also, a command gets mixed up somehow, and instead of "setenv loadinitrd 'tftpboot 0x60000000 358/tftp-deploy-VLCRzw/ramdisk/ramdisk.ext4.gz.uboot'", the board receives "EBB8304> setenv loadkernel 'tftpboot 0x40setenv loadinitrd 'tftpboot 0x60000000 358/tftp-deploy-VLCRzw/ramdisk/ramdisk.ext4.gz.uboot'" Details: * The job definition: https://paste.debian.net/993349/ * An excerpt from the LAVA2 job log/output, showing what gets mixed up: https://paste.debian.net/993350/ * The plain job log is attached to this e-mail Many thanks in advance! -- /Dragoş

7 years, 7 months

2
2
0 0

LAB Notice: Planned maintenance

by Dave Pigott

Hi all, Starting this week, we are finalising the transition of LAVA main production to LAVA V2. The main update and hopefully minor downtime, will commence at 09:00 UTC on Monday 6th November. Along with this we will also be upgrading all micro-instances to Debian Stretch and LAVA 2017.11. There will be a brief period on Monday morning, which should be less than an hour, when remote logins will be disabled as we upgrade the gateway server. Please note, that when validation.linaro.org comes back online, LAVA V1 job submissions will be rejected, so if you have any bots which auto-submit V1 jobs, please work with us to transition them to V2. Thanks Dave ---------------- Dave Pigott LAVA Lab Lead Linaro Ltd t: (+44) (0) 1223 400063

7 years, 7 months

1
0
0 0

LAVA Error 503 Service Unavailable Error

by Tan, Jian Chern

Hey does anyone know why i'm getting an Error 503 Service Unavailable after installing LAVA on a new server? I have it installed on another system and i've never gotten this error on that system before. If it helps, i'm working behind a corporate proxy and here are the pertinent lines from lava-server.log in the apache log folder. [Fri Oct 06 20:01:57.729804 2017] [proxy:error] [pid 2887:tid 140627852187392] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:8000 (127.0.0.1) failed [Fri Oct 06 20:01:57.729851 2017] [proxy_http:error] [pid 2887:tid 140627852187392] [client *IP*:56521] AH01114: HTTP: failed to make connection to backend: 127.0.0.1 Thanks! Jian Chern

7 years, 7 months

2
1
0 0

How to transfer a file from DUT to Server?

by Sathyamurthy, Raghuram

Hello, I working on a requirement for our project where I need to get some log from DUT and send back to Server. How can I achieve it? Thanks, Raghu

7 years, 7 months

2
1
0 0

lava-tool auth-add problem

by Michael Chen

Hi lava users, We're trying to use lava-tool to automate the job submit process, but having problem on using "lava-tool auth-add" command. The error message is ERROR: Username provided but no token found. I tried the instructions from the following page, but without luck. https://validation.linaro.org/static/docs/v2/lava-tool-issues.html I am pretty sure the user name, token, server url are correct since we tested it with the example python script from above page's second paragraph, and we can submit job through it. The version of lava-tool is 0.23-1 and lava-server is 2017.10-1+jessie. Does anyone have similar issue? Thank you. Michael Chen

7 years, 7 months

2
1
0 0

Test job failed due to uefi-menu-selector timeout

by Arthur She

Hi, I got a problem in LAVA v2. My test jobs failed due to uefi-menu-selector timeout occasionally. Like this one <https://staging.validation.linaro.org/scheduler/job/188583> and this one <https://staging.validation.linaro.org/scheduler/job/185376>. When it happened, I usually re-submit the test job and, sometimes, it got recovery and had the test job run successfully, like this <https://staging.validation.linaro.org/scheduler/job/185377>. However, we're working on our own CI loop now, the test job <https://staging.validation.linaro.org/scheduler/job/194340> is submitted automatically. It doesn't make sense to re-submit the test job. Any ideas? Thanks, Arthur

7 years, 7 months

3
2
0 0

Board At Desk v1.0, a downstream of LAVA and kernelci, just released.

by Agustin Benito Bethencourt

Hi, CIP just released Board At Desk v1.0 which is based on LAVAv2 and kernelci. Link: https://www.cip-project.org/blog/2017/10/18/cip-launches-bd-v1-0 From those involved in this release, thanks to all of you who make these technologies possible and also to those involved in kernelci.org project. Thank you also for your support these past months. Best Regards -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito(a)codethink.co.uk

7 years, 7 months

1
0
0 0

Re: [Lava-users] Help running an inline test

by Neil Williams

On 26 Sep 2017 2:59 am, "Daniel Sangorrin" <daniel.sangorrin(a)toshiba.co.jp> wrote: Hi Neil, > -----Original Message----- > From: Neil Williams [mailto:neil.williams@linaro.org] > Sent: Tuesday, September 12, 2017 5:49 PM > To: Daniel Sangorrin > Cc: Robert Marshall; Lava Users Mailman list > Subject: Re: [Lava-users] Help running an inline test > > On 12 September 2017 at 09:25, Daniel Sangorrin > <daniel.sangorrin(a)toshiba.co.jp> wrote: > > > >> -----Original Message----- > >> From: Neil Williams [mailto:neil.williams@linaro.org] > >> Sent: Tuesday, September 12, 2017 4:58 PM > >> To: Daniel Sangorrin > >> Cc: Robert Marshall; Lava Users Mailman list > >> Subject: Re: [Lava-users] Help running an inline test > >> > >> On 12 September 2017 at 08:50, Daniel Sangorrin > >> <daniel.sangorrin(a)toshiba.co.jp> wrote: > >> > Hi Neil, > >> > > >> > Thanks for your reply. > >> > > >> >> -----Original Message----- > >> >> From: Neil Williams [mailto:neil.williams@linaro.org] > >> >> Sent: Tuesday, September 12, 2017 4:16 PM > >> >> To: Daniel Sangorrin > >> >> Cc: Robert Marshall; Lava Users Mailman list > >> >> Subject: Re: [Lava-users] Help running an inline test > >> >> > >> >> On 12 September 2017 at 08:10, Daniel Sangorrin > >> >> <daniel.sangorrin(a)toshiba.co.jp> wrote: > >> >> > Robert, Neil: > >> >> > > >> >> > I managed to prepare a 2017.7 environment. The boot action still works fine. > >> >> > The test action still fails, but in a more 'sane' way I would say. > >> >> > There are strange things like 'None', no lava-test-runner, etc.. Please check the > >> >> > log attached. > >> >> > >> >> You haven't specified a deploy step, so there is no test shell > >> >> created. Boot just does the boot - to deploy the test environment > >> >> there must be a deploy action. > >> > > >> > As far as I understand, the deployment action occurs before the > >> > boot action and consists of preparing a kernel/filesystem in some > >> > media (e.g.: as a network filesystem). > >> > Ref: https://validation.linaro.org/static/docs/v2/actions-deploy.html > >> > > >> > For now, I wanted to run my tests with the kernel and filesystem > >> > that is already installed on the Flash memory. Is this impossible with LAVA? > >> > >> Such a system can only be booted, it cannot operate a Lava Test Shell > >> because there is no way to get the test shell onto the device without > >> a deploy. > >> > >> There is support for primary connections using SSH > >> https://validation.linaro.org/static/docs/v2/dispatcher- design.html#primary-connection > >> > >> See: Problems with simplistic testing in the documentation. > >> https://validation.linaro.org/static/docs/v2/simple-admin. html#problems-with-simplistic-testing > > > > Thanks a lot Neil. > > # I'm not against deployment, I just wanted to prepare the environment step by step. > > > > The primary connection could be a good solution but it looks like I wouldn't be able to use the PDU, > > or the autologin features from the u-boot action through the serial port. I will implement the > > deploy action instead. > > > > By the way, when you talk about "test shell" I am assuming that you mean a shell script or binary > > that is copied into the target filesystem and executed. Is that correct? > > My filesystem is very minimal: basically busybox using the ash shell. > > "test shell" == Lava Test Shell as defined by the test action block. > This relies on POSIX behaviour where the automation drives scripts > installed onto the system to execute the test operations themselves. > > To handle busybox ash compatibility, just set the Operating System as > Open Embedded. > > actions: > - deploy: > # ... rest of the deploy > os: oe > > https://validation.linaro.org/static/docs/v2/actions-deploy.html#index-18 Sorry, it took me a while but I finally got it working. I met several problems. Some of them were a matter of overriding variables. For example, I cannot use dhcp for the board so I had to change uboot_ipaddr_cmd and base_ip_args. There was one variable (SERVER_IP) I couldn't override, so I had to modify base-uboot.jinja2 for it. my jinja2: {% set uboot_serverip = '192.168.1.66' %} base-uboot.jinja2 # vi /etc/lava-server/dispatcher-config/device-types/base-uboot.jinja2 {% set base_uboot_tftp_bootcmd = uboot_tftp_bootcmd|default( " - setenv bootcmd '" + uboot_ipaddr_cmd|default('dhcp') + "; setenv serverip " + uboot_serverip|default('{SERVER_IP}') + "; run loadkernel; run loadinitrd; " + run_load_fdt + uboot_bootx_cmd|default('{BOOTX}') + "' - run bootcmd") -%} Note: I tried modifying LAVA_SERVER_IP and LAVA_NETWORK_IFACE in /etc/lava-dispatcher/lava-dispatcher.conf as well but it didn't work. Those settings are only relevant for V1, so V2 tests will ignore these. Setting the SERVER_IP in the device configuration is the wrong approach. This IP address is for the dispatcher, so it needs to be added to the dispatcher configuration. In V2, the dispatcher configuration is sent from the master. Setting a fixed IP address for the dispatcher is already supported. See /usr/share/lava-dispatcher/dispatcher.yaml for an example. See https://validation.linaro.org/static/docs/v2/pipeline-admin.html#extra-disp… You need a file named according to the hostname of the dispatcher as it appears in the dispatcher-master log file. If you consider it useful, please consider including it in the mainstream code. Thanks for your help, Daniel > >> >> >> -----Original Message----- > >> >> >> From: Lava-users [mailto:lava-users-bounces@lists.linaro.org] On Behalf Of Daniel Sangorrin > >> >> >> Sent: Monday, September 11, 2017 5:16 PM > >> >> >> To: 'Robert Marshall'; 'Lava Users Mailman list' > >> >> >> Subject: Re: [Lava-users] Help running an inline test > >> >> >> > >> >> >> > -----Original Message----- > >> >> >> > From: Lava-users [mailto:lava-users-bounces@lists.linaro.org] On Behalf Of Robert Marshall > >> >> >> > Sent: Monday, September 11, 2017 4:47 PM > >> >> >> > To: 'Lava Users Mailman list' > >> >> >> > Subject: Re: [Lava-users] Help running an inline test > >> >> >> > > >> >> >> > "Daniel Sangorrin" <daniel.sangorrin(a)toshiba.co.jp> writes: > >> >> >> > > >> >> >> > > Hi Neil, > >> >> >> > > > >> >> >> > > Thanks for your quick reply. > >> >> >> > > > >> >> >> > >> -----Original Message----- > >> >> >> > >> From: Neil Williams [mailto:neil.williams@linaro.org] > >> >> >> > >> Sent: Monday, September 11, 2017 3:23 PM > >> >> >> > >> > >> >> >> > >> On 11 September 2017 at 07:06, Daniel Sangorrin > >> >> >> > >> <daniel.sangorrin(a)toshiba.co.jp> wrote: > >> >> >> > >> > Hi, > >> >> >> > >> > > >> >> >> > >> > I have spent a few days learning LAVA with QEMU and the Beagle Bone black. > >> >> >> > >> > Now, I'm trying to setup a Renesas iwg20m board but I have some strange > >> >> >> > >> > problem. > >> >> >> > >> > # I'm using LAVA v2016.12. > >> >> >> > >> > >> >> >> > >> Updates are available - you should follow the LAVA documentation for > >> >> >> > >> the LAVA repositories and upgrade. > >> >> >> > >> > >> >> >> > >> https://staging.validation.linaro.org/static/docs/v2/ installing_on_debian.html#lava-repositories > >> >> >> > > > >> >> >> > > Thanks, I will try with the 2017.9 version then. > >> >> >> > > > >> >> >> > Daniel > >> >> >> > > >> >> >> > If you're doing the test within b@d [1] you should look at my > >> >> >> > https://gitlab.com/rajm/board-at-desk-single-dev/tree/ lava2017-fixes > >> >> >> > branch which has various fixes for our use of lava 2017-7, once that > >> >> >> > branch is merged - soon now! - it should 'just work' > >> >> >> > >> >> >> Wow Robert, just in time! Thanks. > >> >> >> > >> >> >> Daniel > >> >> >> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Lava-users mailing list > >> >> >> Lava-users(a)lists.linaro.org > >> >> >> https://lists.linaro.org/mailman/listinfo/lava-users > >> >> > > >> >> > _______________________________________________ > >> >> > 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/ > > > > > > > > > > -- > > Neil Williams > ============= > neil.williams(a)linaro.org > http://www.linux.codehelp.co.uk/

7 years, 8 months

2
1
0 0

Help running an inline test

by Daniel Sangorrin

Hi, I have spent a few days learning LAVA with QEMU and the Beagle Bone black. Now, I'm trying to setup a Renesas iwg20m board but I have some strange problem. # I'm using LAVA v2016.12. The actions in the job definition looks as follows (sorry pastebin is blocked by our proxy): actions: - boot: method: u-boot commands: msd type: uimage auto_login: login_prompt: '$none$ login: ' username: root prompts: - 'myiwg20m: # ' timeout: minutes: 2 failure_retry: 5 - test: timeout: minutes: 5 failure_retry: 3 name: kernel-version-singlenode definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: kernel-version-basic description: "check kernel version" run: steps: - lava-test-case linux-INLINE-uname --shell uname -a from: inline name: kernel-version-inline path: inline/kernel-version-basic.yaml So far LAVA has been successful at powering on the board, interrupting u-boot, sending the u-boot commands, recognizing the boot login prompt and auto-login in. In other words, the boot actions seems to be working fine. The problem comes with the 'test' action. I have mostly copied the code from the inline example included in the help but I get the following errors: (sorry again for not pasting it on pastebin) - {"dt": "2017-09-11T05:19:03.602576", "lvl": "target", "msg": "Debian GNU/Linux 8 (none) /dev/ttySC0"} - {"dt": "2017-09-11T05:19:03.605709", "lvl": "debug", "msg": "Matched prompt #6: \$none\$ login: "} - {"dt": "2017-09-11T05:19:03.606979", "lvl": "debug", "msg": "Sending username root"} - {"dt": "2017-09-11T05:19:03.608100", "lvl": "debug", "msg": {"sending": "root\n"}} - {"dt": "2017-09-11T05:19:03.864073", "lvl": "target", "msg": "(none) login: root"} - {"dt": "2017-09-11T05:19:03.865475", "lvl": "debug", "msg": "auto-login-action: Wait for prompt ['myiwg20m: # ']. 120 seconds"} - {"dt": "2017-09-11T05:19:03.868416", "lvl": "target", "msg": "root"} - {"dt": "2017-09-11T05:19:03.898283", "lvl": "target", "msg": ""} - {"dt": "2017-09-11T05:19:03.904742", "lvl": "target", "msg": "The programs included with the Debian GNU/Linux system are free software;"} - {"dt": "2017-09-11T05:19:03.911114", "lvl": "target", "msg": "the exact distribution terms for each program are described in the"} - {"dt": "2017-09-11T05:19:03.915433", "lvl": "target", "msg": "individual files in /usr/share/doc/*/copyright."} - {"dt": "2017-09-11T05:19:03.921821", "lvl": "target", "msg": "Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent"} - {"dt": "2017-09-11T05:19:03.923941", "lvl": "target", "msg": "permitted by applicable law."} - {"dt": "2017-09-11T05:19:03.927111", "lvl": "target", "msg": "login[816]: root login on 'ttySC0'"} - {"dt": "2017-09-11T05:19:03.928112", "lvl": "target", "msg": ""} - {"dt": "2017-09-11T05:19:03.933510", "lvl": "target", "msg": "BusyBox v1.22.1 (2017-09-01 01:37:39 UTC) built-in shell (ash)"} - {"dt": "2017-09-11T05:19:03.937734", "lvl": "target", "msg": "Enter 'help' for a list of built-in commands."} - {"dt": "2017-09-11T05:19:03.938979", "lvl": "debug", "msg": "Setting shell prompt(s) to ['myiwg20m: # ', 'lava-test: # ']"} - {"dt": "2017-09-11T05:19:03.939504", "lvl": "debug", "msg": {"sending": "export PS1=\"lava-test: # \"\n"}} - {"dt": "2017-09-11T05:19:05.310766", "lvl": "target", "msg": "myiwg20m: # [6nexport PS1=\\\"lava-test: # \\\""} - {"dt": "2017-09-11T05:19:05.311542", "lvl": "debug", "msg": "auto-login-action duration: 3.93"} - {"dt": "2017-09-11T05:19:05.312062", "lvl": "results", "msg": {"case": "auto-login-action", "definition": "lava", "duration": !!float "3.929234027862549", "extra": !!python/object/apply:collections.OrderedDict [[["success", "No kernel warnings or errors detected."]]], "level": "1.5.5", "result": "pass"}} - {"dt": "2017-09-11T05:19:05.313427", "lvl": "debug", "msg": "start: 1.5.6 expect-shell-connection (max 120s)"} - {"dt": "2017-09-11T05:19:05.313967", "lvl": "debug", "msg": "expect-shell-connection: Waiting for prompt myiwg20m: # , lava-test: # "} - {"dt": "2017-09-11T05:19:05.314522", "lvl": "debug", "msg": "expect-shell-connection: Wait for prompt ['myiwg20m: # ', 'lava-test: # ']. 300 seconds"} - {"dt": "2017-09-11T05:19:05.315249", "lvl": "target", "msg": "export PS1=\\\"lava-test: # \\\""} - {"dt": "2017-09-11T05:19:05.315963", "lvl": "debug", "msg": "expect-shell-connection duration: 0.00"} - {"dt": "2017-09-11T05:19:05.316851", "lvl": "debug", "msg": "start: 1.5.7 export-device-env (max 120s)"} - {"dt": "2017-09-11T05:19:05.317390", "lvl": "debug", "msg": "export-device-env duration: 0.00"} - {"dt": "2017-09-11T05:19:05.317890", "lvl": "debug", "msg": "Setting default test shell prompt"} - {"dt": "2017-09-11T05:19:05.318373", "lvl": "debug", "msg": ["myiwg20m: # ", "lava-test: # "]} - {"dt": "2017-09-11T05:19:05.318902", "lvl": "debug", "msg": "uboot-retry: Wait for prompt ['myiwg20m: # ', 'lava-test: # ']. 240 seconds"} - {"dt": "2017-09-11T05:19:05.339032", "lvl": "debug", "msg": "uboot-retry duration: 8.48"} - {"dt": "2017-09-11T05:19:05.339643", "lvl": "info", "msg": "uboot-action duration: 8.50"} - {"dt": "2017-09-11T05:19:05.340189", "lvl": "info", "msg": "start: 2 lava-test-retry (max 300s)"} - {"dt": "2017-09-11T05:19:05.340724", "lvl": "debug", "msg": "start: 2.1 lava-test-shell (max 300s)"} - {"dt": "2017-09-11T05:19:05.341253", "lvl": "info", "msg": "Executing test definitions using ShellSession"} - {"dt": "2017-09-11T05:19:05.341753", "lvl": "debug", "msg": {"sending": "#\n"}} - {"dt": "2017-09-11T05:19:05.442940", "lvl": "target", "msg": "lava-test: # [6n#"} - {"dt": "2017-09-11T05:19:05.443483", "lvl": "debug", "msg": "lava-test-shell: Wait for prompt ['myiwg20m: # ', 'lava-test: # ']. 300 seconds"} - {"dt": "2017-09-11T05:19:05.446189", "lvl": "target", "msg": "#"} - {"dt": "2017-09-11T05:19:05.469109", "lvl": "exception", "msg": "Traceback (most recent call last):\n File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py\", line 290, in run_actions\n new_connection = action.run(connection, args)\n File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/test/shell.py\", line 243, in run\n for running in xrange(stage + 1):\nTypeError: unsupported operand type(s) for +: 'NoneType' and 'int'\n"} - {"dt": "2017-09-11T05:19:05.470260", "lvl": "debug", "msg": "start: 3.1 power_off (max 5s)"} - {"dt": "2017-09-11T05:19:05.470796", "lvl": "info", "msg": "nice curl http://admin:<omitted>@192.168.11.68/set.cmd?cmd=setpower+p61=0"} - {"dt": "2017-09-11T05:19:05.534407", "lvl": "debug", "msg": !!python/unicode "command output % Total % Received % Xferd Average Speed Time Time Time Current\n Dload Upload Total Spent Left Speed\n\r 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0\r100 20 0 20 0 0 371 0 --:--:-- --:--:-- --:--:-- 377\n<html>p61=0</html>\r\n"} - {"dt": "2017-09-11T05:19:05.535945", "lvl": "debug", "msg": "power_off duration: 0.07"} - {"dt": "2017-09-11T05:19:05.536462", "lvl": "results", "msg": {"case": "power_off", "definition": "lava", "duration": !!float "0.06516695022583008", "extra": !!python/object/apply:collections.OrderedDict [[["status", "success"]]], "level": "3.1", "result": "pass"}} - {"dt": "2017-09-11T05:19:05.644487", "lvl": "error", "msg": "Status: Incomplete\nErrors ['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/test/shell.py\", line 243, in run for running in xrange(stage + 1):TypeError: unsupported operand type(s) for +: \\'NoneType\\' and \\'int\\'', 'Incomplete']"} - {"dt": "2017-09-11T05:19:05.646006", "lvl": "exception", "msg": "Traceback (most recent call last):\n File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py\", line 290, in run_actions\n new_connection = action.run(connection, args)\n File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/logical.py\", line 57, in run\n new_connection = self.internal_pipeline.run_actions(connection)\n File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py\", line 302, in run_actions\n raise RuntimeError(action.errors)\nRuntimeError: ['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/test/shell.py\", line 243, in run for running in xrange(stage + 1):TypeError: unsupported operand type(s) for +: \\'NoneType\\' and \\'int\\'']\n"} - {"dt": "2017-09-11T05:19:05.647870", "lvl": "debug", "msg": "start: 3.1 power_off (max 5s)"} - {"dt": "2017-09-11T05:19:05.648393", "lvl": "debug", "msg": "power_off duration: 0.00"} - {"dt": "2017-09-11T05:19:05.648864", "lvl": "results", "msg": {"case": "power_off", "definition": "lava", "duration": !!float "3.0994415283203125e-05", "extra": !!python/object/apply:collections.OrderedDict [[["status", "success"], ["duration", !!float "0.06516695022583008"], ["connection-timeout", !!float "300.0"], ["timeout", !!float "5.0"], ["level", "3.1"]]], "level": "3.1", "result": "pass"}} - {"dt": "2017-09-11T05:19:05.650619", "lvl": "error", "msg": "status: ['Incomplete']"} Any hint of what's going on? # One thing I don't understand is that even though I have set the "prompts" variable on the job, LAVA seems to force it to become "lava-test: #". Thanks, Daniel

7 years, 8 months

3
11
0 0

Using specific branch of a test definition repository

by Xu, Hongyu

Hi lava experts : The branch did not take effect when I specified the branch in my test-definition! (hxt-dev-br1) I use the local git repo , and my test-definition is in branch :hxt-dev-br1, not the master. Then I specified the branch, but it did not take effect. My test-definition: device_type: qemu job_name: health check job timeouts: job: minutes: 15 action: minutes: 5 connection: minutes: 2 priority: medium visibility: public # context allows specific values to be overridden or included context: # tell the qemu template which architecture is being tested # the template uses that to ensure that qemu-system-x86_64 is executed. arch: amd64 metadata: # please change these fields when modifying this job for your own tests. docs-source: first-job docs-filename: qemu-pipeline-first-job.yaml # ACTION_BLOCK actions: - deploy: timeout: minutes: 90 to: tmpfs images: rootfs: image_arg: -drive format=raw,file={rootfs} url: http://autotest002/tmp/stretch-2.img.gz compression: gz os: debian # BOOT_BLOCK - boot: timeout: minutes: 2 method: qemu media: tmpfs prompts: ["root@debian:"] auto_login: login_prompt: "login:" username: root - test: timeout: minutes: 30 definitions: - repository: ssh://1680141@10.5.20.24:29418/sw_test/test-definitions from: git path: ubuntu/smoke-tests-basic.yaml name: smoke-tests-basic branch: hxt-dev-br1 Log: Loading test definitionsstart: 1.3.3.1 git-repo-action (timeout 00:14:55)Using /lava-48 at stage 0Fetching tests from ssh://1680141@10.5.20.24:29418/sw_test/test-definitionsRunning '/usr/bin/git clone ssh://1680141@10.5.20.24:29418/sw_test/test-definitions /var/lib/lava/dispatcher/tmp/48/lava-overlay-Iw36n8/lava-48/0/tests/0_smoke-tests-basic'Tests stored (tmp) in /var/lib/lava/dispatcher/tmp/48/lava-overlay-Iw36n8/lava-48/0/tests/0_smoke-tests-basic/ubuntu/smoke-tests-basic.yamlUnable to open test definition 'ubuntu/smoke-tests-basic.yaml': [Errno 2] No such file or directory: '/var/lib/lava/dispatcher/tmp/48/lava-overlay-Iw36n8/lava-48/0/tests/0_smoke-tests-basic/ubuntu/smoke-tests-basic.yaml' Best Regards XuHongyu From: Lava-users [mailto:lava-users-bounces@lists.linaro.org] On Behalf Of Xu, Hongyu Sent: 2017年9月18日 18:07 To: Lava-users(a)lists.linaro.org Subject: [Lava-users] test-definitions Hi lava , Can I put test-definitions(.yaml script ) in locally on my worker server ? Don’t get them from the git-repo! Best Regards XuHongyu This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you. This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

7 years, 8 months

1
0
0 0

test-definitions

by Xu, Hongyu

Hi lava , Can I put test-definitions(.yaml script ) in locally on my worker server ? Don't get them from the git-repo! Best Regards XuHongyu This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

7 years, 8 months

1
0
0 0

lava-tool auth token

by Xu, Hongyu

Hi experts, It's error when I auth token with the lava-too, because my I deploy the lava 2017.7 with SSL Self-signed certificate. Now I can use the XML-RPC to auth the token with " ssl._create_unverified_context ". How can I do ? I want use the lava-tool . import ssl ssl._create_default_https_context = ssl._create_unverified_context import xmlrpclib username = "lavaadmin" token = "onku07n16r2uktjz40otgn0n9m7q1bp1b75dr4u0ph0juy7jnb8csi0u9x7fg3sf1mpgnxw00sq1otmzl3rqpdu4tl5fam45m5xyt25oin020ohkajzrx7ze0aaukkdt" hostname = "autotest001" protocol = "https" # http or preferably https server = xmlrpclib.ServerProxy("%s://%s:%s@%s/RPC2" % (protocol, username, token, hostname)) device_hostname = "qemu_test01" jinjia_string = " {% extends 'qemu.jinja2' %} {% set mac_addr = '52:54:00:12:34:60' %} {% set memory = '1024' %} " > lava-tool auth-add --token-file /home/lavaadmin/xuhy/qemu_test_token https://1680141@10.5.21.5/RPC2 > > ERROR: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate > verify failed (_ssl.c:661)> Best Regards XuHongyu -----Original Message----- From: Xu, Hongyu Sent: 2017年9月12日 14:47 To: 'Neil Williams' <neil.williams(a)linaro.org> Cc: Lava-users(a)lists.linaro.org Subject: RE: [Lava-users] auth token We deploy the lava on the Internal lan, an the domain names is private . But let's Encrypt can only issue certificates for valid public domain names. Are there any other Suggestions? Best Regards XuHongyu -----Original Message----- From: Neil Williams [mailto:neil.williams@linaro.org] Sent: 2017年9月11日 15:35 To: Xu, Hongyu <hongyu.xu(a)hxt-semitech.com> Cc: Lava-users(a)lists.linaro.org Subject: Re: [Lava-users] auth token On 11 September 2017 at 08:28, Xu, Hongyu <hongyu.xu(a)hxt-semitech.com> wrote: > Hi lava experts: > > > > I deploy the lava 2017.7 with SSL Self-signed certificate, then I > want to create the device-dictionary for the qemu devices, it’s error > when I add auth_token. Please give me some suggest! > > That needs to be fixed within your own SSL configuration. Lots of security packages have issues with self-signed certificates, so it is better to look at solutions like letsencrypt. Details of how this is configured are outside the scope of the lava-users mailing list, it's a general system admin task and a variety of guides are available online. > > lava-tool auth-add --token-file /home/lavaadmin/xuhy/qemu_test_token > --user-shortcut 1680141 --endpoint-shortcut qemu_test01 > https://1680141@10.5.21.5 > > ERROR: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate > verify failed (_ssl.c:661)> > > > > Best Regards > > > > XuHongyu > > > > From: Xu, Hongyu > Sent: 2017年9月4日 14:41 > To: 'Lava-users(a)lists.linaro.org' <Lava-users(a)lists.linaro.org> > Subject: Local Django user accounts > > > > > > Hi all, > > > > I have installed the lava-serer (2017.7) on my DEBIAN 9.10. But now > I can’t sign in with the local Django user, this is the error infomations: > > Forbidden (403) > > CSRF verification failed. Request aborted. > > You are seeing this message because this site requires a CSRF cookie > when submitting forms. This cookie is required for security reasons, > to ensure that your browser is not being hijacked by third parties. > > If you have configured your browser to disable cookies, please > re-enable them, at least for this site, or for 'same-origin' requests. > > More information is available with DEBUG=True. > > This is already covered in the documentation, it's a Django change. If you have tried to solve this by using a self-signed certificate on localhost, you should avoid trying to create https://localhost/ and just update the security settings: https://staging.validation.linaro.org/static/docs/v2/pipeline-debug.html?hi… > > Please give me some advices! > > > > root@hxtcorp:~# dpkg-query -l lava* > > Desired=Unknown/Install/Remove/Purge/Hold > > | > Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Tri > g-pend > > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > > ||/ Name Version Architecture > Description > > +++-=================================-=====================-========== > +++===========-======================================================= > +++================ > > ii lava-coordinator 0.1.7-1 all > LAVA Coordinator daemon > > un lava-dashboard <none> <none> > (no description available) > > un lava-dashboard-tool <none> <none> > (no description available) > > ii lava-dispatcher 2017.7-1~bpo9+1 amd64 > Linaro Automated Validation Architecture dispatcher > > un lava-scheduler <none> <none> > (no description available) > > un lava-scheduler-tool <none> <none> > (no description available) > > ii lava-server 2017.7-1~bpo9+1 all > Linaro Automated Validation Architecture server > > ii lava-server-doc 2017.7-1~bpo9+1 all > Linaro Automated Validation Architecture documentation > > ii lava-tool 0.21-1 all > command line utility for LAVA > > un lavapdu <none> <none> > (no description available) > > ii lavapdu-client 0.0.5-1 all > LAVA PDU client > > ii lavapdu-daemon 0.0.5-1 all > LAVA PDU control daemon > > > > add the local Django user: > > sudo lava-server manage createsuperuser --username $USERNAME > --email=$EMAIL > > sudo lava-server manage authorize_superuser --username $USERNAME > > > > root@hxtcorp:/etc/lava-server# lava-server manage users list > > List of users: > > * 1680077 > > * 1680141 > > * lava-health > > * xuhy > > > > Best Regards > > > > XuHongyu > > > > > > > This email is intended only for the named addressee. It may contain > information that is confidential/private, legally privileged, or > copyright-protected, and you should handle it accordingly. If you are > not the intended recipient, you do not have legal rights to retain, > copy, or distribute this email or its contents, and should promptly > delete the email and all electronic copies in your system; do not retain copies in any media. > If you have received this email in error, please notify the sender promptly. > Thank you. > > > > > _______________________________________________ > 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/ This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

7 years, 9 months

1
0
0 0

FYI: Problem updating device type

by Daniel Sangorrin

Just in case other users had the same problem I opened this issue: https://github.com/kernelci/lava-docker/issues/7 Cheers, Daniel

7 years, 9 months

1
0
0 0

pduclient

by Li, Xuelian

Hi，Neil： I want to control device power on/off by lavapdu.,but when I run pduclient --daemon autotest001 --hostname 10.5.142.6 --command off --port 10 ERROR : Error sending command, wrong daemon hostname? Can you help me solve this problem? Lava-server :IP 10.5.21.5 autotest001 Pdudaemon run on the lava-server Lavapdu.conf: { "daemon": { "hostname": "10.5.21.5", "port": 16421, "dbhost": "127.0.0.1", "dbuser": "pdudaemon", "dbpass": "pdudaemon", "dbname": "lavapdu", "retries": 5, "logging_level": "INFO" }, "pdus": { "192.168.10.2": { "driver": "apc9210" }, "192.168.10.3": { "driver": "apc7952", "telnetport": 5023 }, "192.168.10.4": { "driver": "apc7952" }, "192.168.10.5": { "driver": "apc8959", "this": "that", "something": "else" }, "192.168.25.52": { "driver": "apc7952" } } This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

7 years, 9 months

2
1
0 0

auth token

by Xu, Hongyu

Hi lava experts: I deploy the lava 2017.7 with SSL Self-signed certificate, then I want to create the device-dictionary for the qemu devices, it’s error when I add auth_token. Please give me some suggest! lava-tool auth-add --token-file /home/lavaadmin/xuhy/qemu_test_token --user-shortcut 1680141 --endpoint-shortcut qemu_test01 https://1680141@10.5.21.5 ERROR: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)> Best Regards XuHongyu From: Xu, Hongyu Sent: 2017年9月4日 14:41 To: 'Lava-users(a)lists.linaro.org' <Lava-users(a)lists.linaro.org> Subject: Local Django user accounts Hi all, I have installed the lava-serer (2017.7) on my DEBIAN 9.10. But now I can’t sign in with the local Django user, this is the error infomations: Forbidden (403) CSRF verification failed. Request aborted. You are seeing this message because this site requires a CSRF cookie when submitting forms. This cookie is required for security reasons, to ensure that your browser is not being hijacked by third parties. If you have configured your browser to disable cookies, please re-enable them, at least for this site, or for 'same-origin' requests. More information is available with DEBUG=True. Please give me some advices! root@hxtcorp:~# dpkg-query -l lava* 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-coordinator 0.1.7-1 all LAVA Coordinator daemon un lava-dashboard <none> <none> (no description available) un lava-dashboard-tool <none> <none> (no description available) ii lava-dispatcher 2017.7-1~bpo9+1 amd64 Linaro Automated Validation Architecture dispatcher un lava-scheduler <none> <none> (no description available) un lava-scheduler-tool <none> <none> (no description available) ii lava-server 2017.7-1~bpo9+1 all Linaro Automated Validation Architecture server ii lava-server-doc 2017.7-1~bpo9+1 all Linaro Automated Validation Architecture documentation ii lava-tool 0.21-1 all command line utility for LAVA un lavapdu <none> <none> (no description available) ii lavapdu-client 0.0.5-1 all LAVA PDU client ii lavapdu-daemon 0.0.5-1 all LAVA PDU control daemon add the local Django user: sudo lava-server manage createsuperuser --username $USERNAME --email=$EMAIL sudo lava-server manage authorize_superuser --username $USERNAME root@hxtcorp:/etc/lava-server# lava-server manage users list List of users: * 1680077 * 1680141 * lava-health * xuhy Best Regards XuHongyu This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

7 years, 9 months

2
2
0 0

adding a device dictionary in 2017.7

by Daniel Sangorrin

Hi, I upgraded to LAVA 2017.7 (for now I'm using https://github.com/kernelci/lava-docker) and managed to add my device-type and device as follows: # Note: I didn't know how to update to 2017.9 docker# lava-server manage device-types add renesas-iwg20m docker# lava-server manage devices add --device-type renesas-iwg20m --worker lava-docker iwg20m01 However, when I want to add the device dictionary I get an error. # Note: I am following https://validation.linaro.org/static/docs/v2/pipeline-admin.html First, I tried with "lava-server manage device-dictionary" as in the documentation, but I failed: docker# lava-server manage device-dictionary Unknown command: 'device-dictionary' Is this only available in the 2017.9 version? Then, I tried with " lava-tool device-dictionary localhost lava-docker --update myiwg20m.jinja2" but I get: Updating device dictionary for lava-docker on localhost ERROR: Endpoint URL not found in the authorization list: localhost [Note] my lava-tool is version 0.23-1 (the newest according to apt) Now, there is a section saying "Using the command line The device dictionary exists as a jinja2 file in /etc/lava-server/dispatcher-config/devices and can be updated by admins with the necessary access.". Is this equivalent to using lava-server o lava-tool to install a device dictionary?? Others: - I confirmed that Pipeline device? is checked. - Django administration > Devices: what is the meaning of Hostname? I have a value of iwg20m01 (the name of the device), there is no relation with the server/container's hostname, is there? - There is an authentication token for the user 'kernel-ci' Thanks, Daniel

7 years, 9 months

2
2
0 0

Manual testing in Lava

by Denis HUMEAU

Hello, My question looks pretty silly, but as Lava has a big set of features that I haven't discovered yet, I dare ask. Lava is designed for automatic testing. But everything cannot be fully automated, at least in a reasonable development time frame. More precisely, tests execution can be automated, but the test result needs to be given by a tester. This will happen for example in display or graphics tests. So, is there a simple way in Lava to let a tester give a manual test result, during or after the test execution? I already have in mind pretty complicated solutions based on Multinode, but simple is key here Thanks, Denis

7 years, 9 months

2
1
0 0

problems with initramfs in LAVA 2017-7

by Robert Marshall

Hi I have a locally built initramfs which worked with a beaglebone black health check in LAVA 2016-12 but with version 2017-7 the health check is failing. I've tried using an initramfs from http://images.validation.linaro.org/snapshots.linaro.org/components/lava/st… with 2017-7 and that works ok. The various sections of the yaml file are as below and a comparison of the 2 boots are at http://paste.baserock.org/iyuzakogez , a lot more noise from the local one but 2016-12 was happy with that. Is there something I'm missing with the update that I need to change in this case? ramdisk: # url: http://images.validation.linaro.org/snapshots.linaro.org/components/lava/st… # locally built version url: http://localhost:8010/initramfs/initramfs-local.cpio.gz compression: gz add-header: u-boot .... # BOOT_BLOCK - boot: method: u-boot commands: ramdisk prompts: - '$initramfs$' timeout: minutes: 2

7 years, 9 months

2
4
0 0

Switching LAVA to V2

by Dave Pigott

Hi everyone, As many of you may know, LAVA V2 has been in development and is now ready to roll out across all instances, and we have started this transition with most micro-instances now being predominantly V2. That leaves the main production instance, validation.linaro.org. Of the supported device types in V2 16 of the 21 have been fully switched over already. Most of these devices can accept V1 and V2 job submissions, but for underlying structural reasons some device types can *only* be V1 or V2, not both. This is to let you know that in the week following SFO17 we will be switching those devices (HiKey, Drangboard 410c, X15, IFC6410 and Mustang) to V2 only, and any job submissions that are in the old JSON format will be rejected by the LAVA scheduler. If you have bots that submit V1 jobs to those device types, or if you manually submit V1 jobs to those device types, you are strongly urged to switch those off and move to V2 submissions. The next release of LAVA software will not support V1 at all, so for anyone submitting V1 jobs to *any* device, you will need to move to V2 by the beginning of November at the latest. Many thanks Dave ---------------- Dave Pigott LAVA Lab Lead Linaro Ltd t: (+44) (0) 1223 400063

7 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users