lava-users

lava-users@lists.lavasoftware.org

1 participants
950 discussions

Board @ Desk: LAVAv2 + KernelCI in a single VM to test a kernel in a board connected to your laptop

by Agustin Benito Bethencourt

Hi, warning: long mail CIP is a Linux Foundation[1] initiative to create a commodity Linux based platform for train railway control systems, power plants, etc which needs to be maintained for a very long time. In extreme cases, for 50 years. The first outcome is the CIP-kernel, based on 4.4 LTS and maintained for now by Ben Hutchings, a colleague of mine. This week, within the CIP (Civil Infrastructure Platform) project, we have published a VM where we have integrated LAVAv2 and KernelCI on Debian so any developer can test a specific kernel in a board attached to his/her laptop[2]. You have probably read in this mailing list some questions coming from some colleagues of mine from Codethink. Since the project is initially focused on the CIP kernel, it was natural to select LAVA and KernelCI as our default tools. We would like to see in the near future our CIP kernel as part of kernelci.org We move slowly though since CIP is still a young project with very limited resources but for now, and due to the very unique requirements CIP needs to address[3], safety critical requirements among them, we need to get absolute control of the testing infrastructure/service we will use. As a previous step towards building our own testing/reporting infrastructure and service, understanding LAVAv2 and promoting it among the developers involved in this initiative is essential. I think that B@D will be useful for this purpose, allowing us to start testing and sharing the results among CIP devs. Codethink has invested a significant amount of effort in creating a step by step deployment-configure-test guide[4]. Any feedback is welcome. B@D is meant to significantly reduce the entry level effort to use both, LAVA and KernelCI. We consider B@D as a downstream project of LAVAv2 and KernelCI. Hopefully, once we start using it within CIP we will be able to provide meaningful feedback on this list. The team behind B@D, is subscribed to this list and the #linaro-lava IRC channel. We have our own mailing list cip-dev for general support of CIP related topics, so B@D too, but our idea is to route users here for LAVA specific questions that are unrelated with the set up of the environment and participate in supporting them up to the the best of our knowledge, if you think that is a good idea. We are unsure yet about the level of success we will get with this effort though. Since probably for many of you this is the first news you get about CIP and B@D, feel free to ask me or my colleagues. We will do our best to answer your questions. You can get all the technical information about B@D at feature page[5]. Feel free to download it[6]. The integration scripts are located in gitlab.com under AGPLv3 license[7]. Our cip-dev mailing list is obviously an open one[8]. I would like to finish thanking the devs for the great work done in LAVA and to those of you who have helped the Codethink guys to get to this point. LAVAv2 and KernelCI are complicated beasts, hard to swallow without support, and at the same time, very useful. I guess that is part of the beauty. [1] https://www.cip-project.org/about [2] https://www.cip-project.org/news/2017/05/30/bd-v0-9-1 [3] https://wiki.linuxfoundation.org/_media/cip/osls2017_cip_v1_0.pdf [4] https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingboar… [5] https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingboar… [6] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipdownload [7] https://gitlab.com/cip-project/cip-testing/board-at-desk-single-dev [8] https://lists.cip-project.org/mailman/listinfo/cip-dev Best Regards -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito(a)codethink.co.uk

9 years, 2 months

File permissions in /etc/lava-server

by Guillaume Tucker

Hi, I've hit an issue after upgrading LAVA on Debian Stretch from 2017.5-6486.59742fe-1 to 2017.5-6509.d71f267-1, trying to add or update device dictionaries using the "lava-tool device-dictionary" command then always failed. Between these two revisions, the following change was introduced: commit ae4d4776ca7b7454f5406159226e3c9327dd207f Author: Rémi Duraffort <remi.duraffort(a)linaro.org> Date: Tue May 2 15:22:33 2017 +0200 LAVA-757 Move device dictionaries to file system The device dictionaries are now saved in: /etc/lava-server/dispatcher-config/devices which was previously installed with the root user. The LAVA server instance is running under the "lavaserver" user, which didn't have write access to this directory. So I had to manually change the permissions, and then it all worked. Could you please add a step in the Debian package installation to change the permissions and ownership of the files in /etc/lava-server/ to fix this issue? Note: It may also be a good idea to propagate the IOError into the xmlrpclib.Fault error message rather than replacing it with a rather mysterious "Unable to store the configuration for %s on disk". I had to do this to find out the root cause of the error; I can send a patch, let me know. Best wishes, Guillaume

9 years, 2 months

Overridding lava_test_{results_,}dir

by Sjoerd Simons

Hey all, I'm currently hitting an interesting issue; We're deploying debian- based images in our tests which have most of / mounted read-only. Unfortunately the default deployment data for Debian indicates that the various lava-test-shell related directories show live in /lava-xxxxx to which in our booted image ofcourse nothing can write. It would be good to give test writers the freedom to specify a sensible base-path for lava's usage to avoid these types of issues. The option to add a Debian variant to deployment data on our setup is somewhat less attractive as that requires server configuration. (Changing the images to mount / as read-write is not an option as that would defeat the point of the test). -- Sjoerd Simons Collabora Ltd.

9 years, 2 months

Execute next test after a timout

by Florence ROUGER JUNG

Hi, With delivery of May, we can now defined timer for each test of a job. Some of our tests are not correctly executed and then timeout expired. But we want to execute next test and not stop the job with an incomplete verdict How can we configure this behavior in yaml ? See following example of yaml used Thanks in advance for your answer Regards [Description: Description: Description: Description: Description: Description: logo_big5] Florence ROUGER-JUNG | TINA: 166 7356 | Tel: +33 2 44 02 73 56 | Mobile: +33 6 13 49 38 02 STMicroelectronics | MCD Auriga Building | 9-11, rue Pierre-Félix Delarue | 72100 Le Mans | FRANCE

9 years, 2 months

lava-publisher Issue

by Duran, Randy G

I currently have an issue with starting lava-publisher. Whenever I run python manage.py lava-publisher I get output log: 2017-05-22 20:10:28,061 INFO publisher Dropping priviledges 2017-05-22 20:10:28,061 ERROR publisher Unable to lookup the user or the group 2017-05-22 20:10:28,062 ERROR publisher Unable to drop priviledges I currently Have the same binaries in my own workstation and I am able to successfully connected to lava-publisher my output log gets: 2017-03-27 19:34:43,909 INFO publisher Dropping priviledges 2017-03-27 19:34:43,909 DEBUG publisher Switching to (lavaserver(126), lavaserver(133)) 2017-03-27 19:34:43,909 INFO publisher Creating the input socket at ipc:///tmp/lava.events 2017-03-27 19:34:43,910 INFO publisher Creating the publication socket at tcp://*:5500 2017-03-27 19:34:43,910 INFO publisher Creating the additional sockets: 2017-03-27 19:34:43,910 INFO publisher Starting the proxy I followed same steps to install from same repository on both machines. I somehow think this has to do with user or group not stored in database but I am not sure. BTW: lava server/dispatcher both work well on both machines I just want to have an event notification client working on my second machine. Thank you. - Randy

9 years, 2 months

Android LAVA tests

by Philippe BEGNIC

Hello, I am trying to setup Android tests on a B2260 board using LAVA V2 ( version 2017-05 ). I have read LAVA documentation about Android tests and investigate about existing Android jobs and devices that have developed Android tests. My questions: * Is it essential to use linux container to perform Androids tests ? * Do you have device-type, devices and jobs that would help me to achieve my android tests ? Best regards Philippe

9 years, 2 months

Package installation

by Denis HUMEAU

Hello, Until then I've installed extra test packages from embedded test scripts. Using the latest V2 version, I'm trying to manage this in my test jobs. e.g.: install: deps: - python-pytest - python-lxml - packagegroup-core-buildessential - phoronix-test-suite At execution time, I get a Error: OPKG package manager not found in the path. Does this mean that OPKG is the only installer supported? Or is this the default one meaning that I can select DPKG or aptitude instead? Best regards, Denis

9 years, 2 months

static ip support for lava

by guru moorthi

Hello Team, This is just the request as a lava user. It would be better if lava supports static ip configuration to deploy and etc stuff with target board. The user who dont have dhcp setup means this will be very useful to work with target locally. I hope you will consider this request and will support static ip also for lava users. Regards, Guru

9 years, 2 months

lava test licences

by Robert Marshall

The lava documentation has various example test scripts e.g. https://validation.linaro.org/static/docs/v2/examples/test-jobs/qemu-kernel… these have no licence information, we've adapted them for a Linux Foundation project, what licence should apply to these files? Robert

9 years, 3 months

Generating initramfs for boot testing

by Don Brown

Hi Everyone, In the Beaglebone-Black Health Check, `bbb_debian_ramdisk_test.yaml`, located in the Linaro master repository (https://git.linaro.org/lava-team/refactoring.git), there are the following lines in the "action:" block: --- kernel: url: http://snapshots.linaro.org/components/lava/standard/debian/jessie/armhf/4/… ramdisk: url: http://snapshots.linaro.org/components/lava/standard/debian/jessie/armhf/4/… compression: gz # the bootloader needs a u-boot header on the modified ramdisk add-header: u-boot modules: url: http://snapshots.linaro.org/components/lava/standard/debian/jessie/armhf/4/… compression: gz --- How is the `initramfs.cpio.gz` generated? KernelCI's build.py script doesn't generate it. None of the Lava scripts generate it, yet it is required to perform the boot test of a kernel on the Beaglebone Black. I can't find it mentioned anywhere in the documentation either. How did you generate this so it is compatible with the BBB? We want to follow Linaro's standards, guidelines and recommendations as close as we can, but this particular part seems to be missing. Any help you can offer would be greatly appreciated. Thank you! -- Don Brown Codethink, Ltd. Software Engineering Consultant Indianapolis, IN USA Email: don.brown(a)codethink.co.uk Mobile: +1 317-560-0513

9 years, 3 months

← Newer
1
...
85
86
87
88
89
90
91
...
95
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users