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

if i can add the device_tags by the cmdline ?

by Xu, Hongyu

Hi , I known can add the device_tags by the web , and if i can add the device_tags by the cmdline ? 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.

8 years, 4 months

2
1
0 0

deploy a x86 device

by Li, Xuelian

Hello，Neil： 1.Can you give me a deploy flow for a x86 device . 2．I want to use web UI submit job for one time N jobs. (N>10) How can I do it? Thanks. Amanda 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.

8 years, 4 months

3
7
0 0

Can be used multi database in the lava ?

by Xu, Hongyu

Hi all, Can be used multi database in the lava ? And is there any introduction to this ? 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.

8 years, 4 months

2
1
0 0

LAVA installation in jessie and jessie-backports

by Senthil Kumaran S

Hi, Someone with the nickname "Nurav" pinged in #linaro-lava IRC channel last week regarding installation problem to install lava in jessie using the jessie-backports repository. The person also diligently followed up with me to check what is wrong with his/her installation on private messages. I did find sometime to do the testing today. Since, I do not know any contact details of 'Nurav' I am writing my findings here, based on lava installation I did on fresh jessie containers, hopefully the person is available in this mailing list and will see this message. The fresh installation went fine with both jessie and also using jessie backports and LAVA production-repo. I ve put up the complete log of the installations I tried in the following files: * Fresh installation of lava from jessie-backports - http://people.linaro.org/~senthil.kumaran/logs/lava-jessie-bp-installation.… * Installing 2017.5 lava from jessie to jessie-backports to production-repo - http://people.linaro.org/~senthil.kumaran/logs/lava-jessie-bp-installation-… HTH. Thank You. -- Senthil Kumaran http://www.stylesen.org/ http://www.sasenthilkumaran.com/

8 years, 4 months

1
0
0 0

[LAVA V2] how to submit job to one specified device

by wangbo

In LAVA V1, we can use `target: {device hostname}` to submit job to one specified device, but I find V2 does not support this. ------------------ Best Regards. Bo Wang

8 years, 4 months

2
1
0 0

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

8 years, 4 months

1
0
0 0

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

8 years, 4 months

2
2
0 0

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.

8 years, 5 months

3
3
0 0

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

8 years, 5 months

3
2
0 0

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

8 years, 5 months

2
3
0 0

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

8 years, 5 months

2
1
0 0

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

8 years, 5 months

2
2
0 0

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

8 years, 5 months

2
1
0 0

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

8 years, 5 months

2
1
0 0

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

8 years, 5 months

2
1
0 0

Storage issue due to accumulation of test results

by Don Brown

Hi Everyone, This week one of my teammates discovered that storage was very low on our LAVA Server. After he investigated, he found that /var/lib/lava/dispatcher gradually increases in size. He realized that when a test is run, the files are accumulated in /var/lib/lava/dispatcher/slave/tmp for each job. However, they are never removed. Does LAVA have a setting or does it have some kind of automation that will remove tests, say, after X days or by some other criteria or, do we need to remove them manually? I appreciate any guidance you can offer. Thank you! -- Don Brown Codethink, Ltd. Software Engineering Consultant Indianapolis, IN USA Email: don.brown(a)codethink.co.uk Mobile: +1 317-560-0513

8 years, 5 months

2
1
0 0

device-type aliases: please add lava-server manage command

by Kevin Hilman

Feature request: Please add an option to "lava-server manage device-types" to add an alias. Currently this can be done from the django interface, but the command-line interface is much more automation friendly and administrator friendly. Thanks, Kevin

8 years, 5 months

2
1
0 0

using lava-ci to submit tests

by Robert Marshall

Hi , we're attempting to use lava-ci to submit a test to lava, I've cloned it from https://github.com/kernelci/lava-ci.git But when I attempt to submit a simple test ../lava-job-runner.py --username lavauser --token ... --server http://localhost:8080/RPC2 I get Connecting to Server... Connection Successful! connect-to-server : pass Gathering Devices... Gathered Devices Successfully! Gathering Device Types... Gathered Device Types Successfully! Submitting Jobs to Server... but I don't see any submitted jobs in the lava2 web interface, is there anything obvious elsewhere I should be checking? - or does the absence of a 'Submitted Jobs successfully', if there should be one, means nothing has been submitted? Robert

8 years, 5 months

1
0
0 0

Adding login commands in LAVA v2

by Guillaume Tucker

Hi, In LAVA v1, one could declare login commands to be run after logging in and before starting any of the tests. For example: "actions": [ { "command": "deploy_image", "parameters": { "image": "https://some-url-to-a-rootfs.ext4.img.gz", "bootfstype": "ext2", "login_commands": [ "sudo su" ], "login_prompt": "login:", "username": "username", "password_prompt": "Password:", "password": "password" } }, In this case, "sudo su" is needed to open a regular user session and inherit the user's environment while also having root privileges. In LAVA v2, there isn't the possibility to do anything like this directly. One could define a test with inline commands, but this is not ideal. The login commands are not a test but part of how the job sets up the environment in which the tests are run - i.e. it's part of the initial conditions. Also it's quite a convoluted and lengthy way of running some commands, and it relies on the side effects of that "login commands test" to persist when running subsequent tests. So I've made a couple of patches to see how this could be implemented in LAVA v2 with an extra parameter in auto_login: https://review.linaro.org/#/q/topic:T5703-login-commands For example: - boot: method: qemu auto_login: login_prompt: 'login:' username: user password_prompt: 'Password:' password: password login_commands: - sudo su Essentially, this makes auto_login more flexible. At the moment, after logging in auto_login sets the shell prompt: this is already some kind of hard-coded login command. Some jobs need to run other things such as "sudo su" to stick to the same example. Another login command we've used is "systemctl --failed" to show if any systemd units (services) failed to load during boot. Notes from the Gerrit reviews: * The login commands can't be part of a device definition as they are not related to the device hardware or the boot configuration. For example, when running Android, one would not want to run "sudo su" but maybe "setprop ..." or something else - to be defined in each job. * The login commands should not be fixed in a given distro / userspace configuration as each job may need to set up a different initial environment. For example, some jobs may need to be run with a regular user and would not use the "sudo su" login command. * Some documentation and unit tests would need to be added for this to be merged. This is to first discuss the idea and review the code changes. Any thoughts? Would it make sense to add this feature or maybe implement it differently? Best wishes, Guillaume

8 years, 6 months

3
6
0 0

Help: lava-ci vs. lava-tool

by Don Brown

Hi Everyone, I have a co-worker who wants to use our Kernel CI & Lava Virtual Machine. He says he wants to boot the VM, log in, and run a command that downloads a kernel and then tests multiple defconfig's and multiple versions of the Linux kernel. What is the best tool to do this (lava-ci, lava-tool, or a different tool)? Can you point me to some examples of the tool you recommend? Any help you can offer would be greatly appreciated. -- Don Brown Codethink, Ltd. Software Engineering Consultant Indianapolis, IN USA Email: don.brown(a)codethink.co.uk Mobile: +1 317-560-0513

8 years, 6 months

2
1
0 0

One time out per test issue

by Denis HUMEAU

Hello, I'm trying to set one timeout per test in a job. To do so I'm declaring one test block per test. Unfortunately, it seems that only the first timeout declaration is taken into account. Did I miss something in my job definition? Best regards, Denis

8 years, 6 months

2
4
0 0

Package installation from Lava job

by Denis HUMEAU

Dear all, This is my first post on the mailing list, I hope I'm at the right place. Using Lava V2, I'm trying to install packages in the DUT following the guidelines from https://validation.linaro.org/static/docs/v2/writing-tests.html#test-defini… My job looks like this: metadata: (...) install: sources: - http://<local_network_package_server>/sti - http:// <local_network_package_server>/all - http:// <local_network_package_server>/cortexa9hf-neon deps: - python-pytest - python-lxml - packagegroup-core-buildessential* run: steps: - step1 - step2 parse: pattern: "^(?P<test_case_id>\\w+) RESULT:(?P<result>(pass|fail|unknown))" fixupdict: FAILED: fail SUCCESS: pass ABORTED: unknown Running this test, I get the following error: <LAVA_TEST_RUNNER>: started<LAVA_TEST_RUNNER>: looking for work in /lava-3715/0/lava-test-runner.conf-1484266027 <LAVA_TEST_RUNNER>: running 0_TC_BENCH_DISK_AIO_STRESS under lava-test-shell... <LAVA_TEST_RUNNER>: running 0_TC_BENCH_DISK_AIO_STRESS installer ... /lava-3715/0/tests/0_TC_BENCH_DISK_AIO_STRESS/install.sh: line 5: lava-add-sources: command not found /lava-3715/0/tests/0_TC_BENCH_DISK_AIO_STRESS/install.sh: line 6: lava-add-sources: command not found /lava-3715/0/tests/0_TC_BENCH_DISK_AIO_STRESS/install.sh: line 7: lava-add-sources: command not found Error: OPKG package manager not found in the path. It seems lava-add-sources is not copied to the target. Do I understand the log correctly? Best regards, Denis

8 years, 6 months

2
8
0 0

Fwd: LAVA BBB setup support

by guru moorthi

Hello Team, My name is guru. i am very new to lava and i am very much interested using lava concept for embedded linux boards for auto deployment and testing concepts. I tried to setup the lava for bbb device. i have followed below steps for that. > 1. installed debian on vm machine and lava-server and its component (jessie-backport) 2016. > 2. just for understanding purpose i tried to add kvm job it was loaded successfully. > 3. Now i am trying to add the BBB device on lava. > 4. For that i have added the bbb device to dispatcher. find the conf file below > name: beaglebone-black01.conf > content : > device_type = beaglebone-black > hostname = beaglebone-black01 > connection_command = telnet localhost 2003 > hard_reset: /usr/bin/reset.sh > power_off: /usr/bin/off.sh > power_on: /usr/bin/on.sh > Note : i am not using pduclient. i am using my own script for control commands > but it is not working while executing the hard_reset command on lava.. find the log for more details. > > 5. My current setup is like i am controlling the bbb using serial controlled relay from VM host machine(debian). > > for that i made my own custom script to on.off,reset serial python code for controlling the relay. > 6. after that i tried to submit the below json test job. Find My definition job attached. > I have taken the below json for reference. > https://git.linaro.org/lava-team/lava-functional-tests. git/tree/lava-test-shell/single-node/armmp-bbb-daily.json > 7. after that i have submitted the job . find the job log for more details. > 8. i have no idea what is going on and what went wrong on my setup. > Help me out to boot the BBB using lava. Regards, Guru

8 years, 6 months

2
1
0 0

Re: [Lava-users] Booting x86 device via TFTP and iPXE

by Neil Williams

On 27 March 2017 at 14:54, Ковалёв Сергей <SKovalev(a)ptsecurity.com> wrote: > Thank you Neil for you reply. Please keep the list in CC: > >> Compare with: https://staging.validation.linaro.org/scheduler/job/168802 > > I have tried https://staging.validation.linaro.org/scheduler/job/168802/definition but iPXE stuck on it. I have amd64 machine with UEFI. "stuck" ? This is a standard amd64 Debian kernel with modules and initramfs. It is already UEFI-aware. Does the machine run Debian natively? Is there a Debian kernel you can use in your LAVA submissions (with modules and ramdisk)? >> First step is to replace these files with images which work on the x86 DUT on staging.validation.linaro.org > > I perform kernel development with my colleagues so I have to load our kernels. Yes, however, to debug what is going on, you should switch to known working files so that you have a valid comparison with known working test jobs. Once debugging has produced some results, then switch back to the locally built kernels. Change one thing at a time. >> That just isn't going to work. The initrd needs to come via TFTP but this is an absolute path. > > 'initrd' is come via TFTP. In context I supply additional kernel boot options. Your original email quoted: context: extra_kernel_args: initrd=/rootfs.cpio.gz root=/dev/ram0 rootfs.cpio.gz does not exist when the machine boots. The initramfs will have been downloaded by TFTP and loaded directly into memory, it simply does not exist as a cpio.gz any longer. /dev/ram0 shouldn't be needed with modern kernels. At best, it would seem that these options are ignored. Debian initramfs log: Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... done. Warning: fsck not present, so skipping unknown file system mount: can't find /root in /etc/fstab done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... mount: mounting /dev on /root/dev failed: No such file or directory mount: mounting /dev on /root/dev failed: No such file or directory done. mount: mounting /run on /root/run failed: No such file or directory run-init: current directory on the same filesystem as the root: error 0 Target filesystem doesn't have requested /sbin/init. run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 No init found. Try passing init= bootarg. BusyBox v1.22.1 (Debian 1:1.22.0-19) built-in shell (ash) Enter 'help' for a list of built-in commands. Matched prompt #5: $initramfs$ > This boot option have been detected before effort to automate the process with LAVA. Without it we could see kernel panic. With it we successfully load kernel and rootfs (from Buildroot). May be in Linaro you embed that boot options in compile time? No, we do not embed anything in V2 (it's one of the key changes from V1, we don't hid magic like that anymore.) The files were prepared with: https://git.linaro.org/lava-team/refactoring.git/tree/scripts/x86_64-nfs.sh You can also see the build log for the original Debian kernel package if relevant. https://tracker.debian.org/pkg/linux-signed https://buildd.debian.org/status/fetch.php?pkg=linux-signed&arch=amd64&ver=… Running x86_64-nfs.sh in an empty directory will provide access to the config of the kernel itself as well as the initramfs and supporting tools. It's possible these context arguments are hiding some other problem in the kernel but, as described so far, the options seem to make no sense. The command line used in our tests is simply: Command line: ip=dhcp console=ttyS0,115200n8 lava_mac={LAVA_MAC} (where LAVA_MAC does not need to be defined for these devices.) -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

8 years, 6 months

3
13
0 0

Booting x86 device via TFTP and iPXE

by Ковалёв Сергей

Hello. I need help to load Linux kernel with rootfs via LAVA (2017.2) job. My job definition fails with kernel panic "provide correct 'root=' option": === device_type: x86 job_name: x86-pipeline timeouts: job: minutes: 15 action: minutes: 5 actions: bootloader-action: minutes: 5 bootloader-retry: minutes: 5 bootloader-interrupt: minutes: 5 extract-nfsrootfs: seconds: 90 priority: medium visibility: public metadata: source: https://git.linaro.org/lava-team/refactoring.git path: ipxe.yaml actions: - deploy: timeout: minutes: 2 modules_compression: xz to: tftp kernel: url: http://192.168.0.1:8000/x86-64/bzImage ramdisk: url: http://192.168.0.1:8000/x86-64/rootfs.cpio.gz compression: gz os: debian - boot: method: ipxe commands: ramdisk prompts: - 'root@debian:~#' - '/ #' - test: timeout: minutes: 5 definitions: - repository: git://git.linaro.org/qa/test-definitions.git from: git path: ubuntu/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 === After then I have added kernel boot options (after metadata section) which lead to "Failed to load file: rootfs.cpio.gz" from iPXE: === context: extra_kernel_args: initrd=/rootfs.cpio.gz root=/dev/ram0 === But at the same time I could successfully load it manual from iPXE console: === iPXE> dhcp net0 Configuring (net0 7c:05:07:0d:37:c9)...... ok iPXE> set console console=ttyS0,115200n8 lava_mac={LAVA_MAC} iPXE> set extraargs initrd=/rootfs.cpio root=/dev/ram0 ip=dhcp iPXE> kernel http://192.168.0.1:8000/x86-64/bzImage ${extraargs} ${console} http://192.168.0.1:8000/x86-64/bzImage... ok iPXE> initrd http://192.168.0.1:8000/x86-64/rootfs.cpio http://192.168.0.1:8000/x86-64/rootfs.cpio... ok iPXE> imgstat bzImage : 6762544 bytes [EFI] [SELECTED] "initrd=/rootfs.cpio root=/dev/ram0 ip=dhcp console=ttyS0,115200n8 lava_mac={LAVA_MAC}" rootfs.cpio : 43977216 bytes iPXE> boot === Best regards Sergey Kovalev.

8 years, 7 months

2
2
0 0

Network config issue on pandaboard in LAVA V2

by Lisa Nguyen

Hi, I'm learning to create a job to boot a mainline kernel on the pandaboard with debian rootfs in LAVA V2, but I keep running into these network related errors: https://staging.validation.linaro.org/scheduler/job/168134#L625 https://staging.validation.linaro.org/scheduler/job/168134#L642 Here's my job definition: https://staging.validation.linaro.org/scheduler/job/168134/definition Am I missing something to get the network working? I'd like to be able to run basic smoke tests as a start. Regards, Lisa

8 years, 7 months

4
7
0 0

$HOME not set on LXC machine

by Rafael Gago Castano

Hello. I'm trying to start LXC Debian hacking sessions on our V2 LAVA server. This is the related configuration: http://pastebin.com/index/DNGpJfc6 And I'm mostly doing what's in here: https://git.linaro.org/lava-team/hacking-session.git The problem I'm facing is that inside a script the environment seems to be broken, so there is no way to copy to ~/.ssh. Regarding the environment I get this output: $ echo $HOME $ echo $USER $ cat /etc/passwd | grep root root:x:0:0:root:/root:/bin/bash $ ls -al /root total 16 drwx------ 2 root root 4096 Dec 16 15:33 . drwxrwxrwx 19 root root 4096 Dec 23 13:18 .. -rw-r--r-- 1 root root 570 Jan 31 2010 .bashrc -rw-r--r-- 1 root root 148 Aug 17 2015 .profile $ env TESTRUN_ID=1_hacksession-debian SHLVL=4 OLDPWD=/ container=lxc _=defs/hacksession-debian/setup_session COLUMNS=80 PATH=/lava-248/1/../bin:/usr/local/bin:/usr/local/sbin:/bin:/usr/bin:/usr/sbin:/sbin LAVA_RESULT_DIR=/lava-248/1/results/1_hacksession-debian-1482499502 LANG=C LC_ALL=C.UTF-8 PWD=/lava-248/1/tests/1_hacksession-debian LINES=24 If I mimic the lava LXC machine creation commands (lxc-create) and I attach to the machine I get a sane environment. Is this expected behavior? BR, Rafael Gago

8 years, 9 months

3
2
0 0

Failed to schedule a QEMU job - if 'image' not in device['actions']['deploy']['methods']

by Milo Kim

Hi, I've installed LAVA and created 'qemu' device type. $ sudo lava-server manage add-device-type '*' $ sudo lava-server manage add-device --device-type qemu qemu01 Then, I downloaded an example of yaml to submit a job for the qemu image. $ wget https://staging.validation.linaro.org/static/docs/v2/examples/test-jobs/qem… ./ $ lava-tool submit-job http://<name>@localhost qemu-pipeline-first-job.yaml The error is found during running 'image.py'. (http://woogyom.iptime.org/scheduler/job/15) Traceback (most recent call last): File "/usr/bin/lava", line 9, in <module> load_entry_point('lava-tool==0.14', 'console_scripts', 'lava')() File "/usr/lib/python2.7/dist-packages/lava/tool/dispatcher.py", line 153, in run raise SystemExit(cls().dispatch(args)) File "/usr/lib/python2.7/dist-packages/lava/tool/dispatcher.py", line 143, in dispatch return command.invoke() File "/usr/lib/python2.7/dist-packages/lava/dispatcher/commands.py", line 216, in invoke job_runner, job_data = self.parse_job_file(self.args.job_file, oob_file) File "/usr/lib/python2.7/dist-packages/lava/dispatcher/commands.py", line 265, in parse_job_file env_dut=env_dut) File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/parser.py", line 165, in parse test_action, counts[name]) File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/parser.py", line 66, in parse_action Deployment.select(device, parameters)(pipeline, parameters) File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/logical.py", line 203, in select willing = [c for c in candidates if c.accepts(device, parameters)] File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/deploy/image.py", line 116, in accepts if 'image' not in device['actions']['deploy']['methods']: KeyError: 'actions' Traceback (most recent call last): File "/usr/bin/lava", line 9, in <module> load_entry_point('lava-tool==0.14', 'console_scripts', 'lava')() File "/usr/lib/python2.7/dist-packages/lava/tool/dispatcher.py", line 153, in run raise SystemExit(cls().dispatch(args)) File "/usr/lib/python2.7/dist-packages/lava/tool/dispatcher.py", line 143, in dispatch return command.invoke() File "/usr/lib/python2.7/dist-packages/lava/dispatcher/commands.py", line 216, in invoke job_runner, job_data = self.parse_job_file(self.args.job_file, oob_file) File "/usr/lib/python2.7/dist-packages/lava/dispatcher/commands.py", line 265, in parse_job_file env_dut=env_dut) File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/parser.py", line 165, in parse test_action, counts[name]) File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/parser.py", line 66, in parse_action Deployment.select(device, parameters)(pipeline, parameters) File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/logical.py", line 203, in select willing = [c for c in candidates if c.accepts(device, parameters)] File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/deploy/image.py", line 116, in accepts if 'image' not in device['actions']['deploy']['methods']: KeyError: 'actions' It seems no 'methods' is found under actions->deploy block on parsing the yaml file but I'm not sure this error means wrong yaml usage or not. Best regards, Milo

8 years, 9 months

2
3
0 0

Help on lava-tool

by kingboli

Hi Williams, I want to get lava job submitter by lava-tool. And when I use command "lava-tool job-details", the submitter info is displayed as "submitter_id". How can I convert the submitter id to submitter username? Thanks.

8 years, 10 months

2
1
0 0

How to change the default 80 port of lava ?

by Zechao Wang

The gitweb (depend apache2) and lava is installed on same host. But the 80 port is used by lava, so gitweb cannot be visited with browser. So i want to change the lava‘s port to another one, such as 8088, but after changed the file: /etc/apache2/sites-enabled/lava-server.conf, lava can not works. Does anyone know how to make lava-server use another port ? Btw, i can not find out the "DocumentRoot" of lava-server . The config file is defined the "DocumentRoot" is "/usr/share/lava-server/static/lava-server/", but i can not see the default index.html. ( Only see the templates file in /usr/lib/python2.7/dist-packages/lava_server/templates/index.html ) Could someone tell me where is the lava-server's default index page ? -- 王泽超 TEL: 13718389475 北京威控睿博科技有限公司 <http://www.ucrobotics.com>

8 years, 10 months

2
2
0 0

Results bundle missing due to bundle checksum error

by Lisa Nguyen

Hi folks, I haven't had any issues running Workload Automation on the dragonboard410c with Debian until recently. I encountered this error: "PM ERROR: Unable to submit result bundle checksum to coordinator". I can see the results clearly at the end of the kvm log[1], but they're not saved to a bundle stream. I also have the links to the db410c log[2] and the multinode job definition[3]. Has anyone run into this issue before? Any ideas of what would cause this to happen? I tried looking in the mailing list archives but didn't find anything. Regards, Lisa [1] https://pmwg.validation.linaro.org/scheduler/job/483.0/log_file#L_284_5 [2] https://pmwg.validation.linaro.org/scheduler/job/484/log_file#L_258_2 [3] https://pmwg.validation.linaro.org/scheduler/job/483/multinode_definition

8 years, 10 months

1
0
0 0

Help: Standalone Lava Server Issues

by Don Brown

Hi Everyone, I am trying to set up a standalone Lava V2 Server by following the instructions on the Linaro website and so far things have gone smoothly. I have Lava installed, a superuser created and I can access the application through a web browser. But, I have the following issues: ISSUE #1: - When I tried to submit a simple Lava V2 test job, I got an error message stating that the "beaglebone black" device type is not available. - I found the directory where the .jinja2 files were stored including the beaglebone-black.jinja2 file, but regardless of what I tried, I couldn't get the web application to see the device type definitions. - It seems like the application isn't pointing to the directory where those device type files are stored. - What do I need to do to make the Lava Server "see" those device type files? ISSUE #2: - When I tried to submit a job, I pasted a small .yaml file and the validation failed because it didn't recognize the data['run'] in the job. I tried a few others and then I tried a V1 .json file and it validated just fine. - What do I have to do to allow Lava to accept V2 .yaml files? Am I missing something simple? As always, I greatly appreciate any feedback you may have to help me out. Thank you in advance! -- Don Brown Codethink, Ltd. Software Engineering Consultant Indianapolis, IN USA Email: don.brown(a)codethink.co.uk Mobile: +1 317-560-0513

8 years, 10 months

2
1
0 0

About job submitted time displayed on LAVA web page.

by kingboli

Hi Williams, The submitted time is 8 hours behind my local time. How to change job submitted time displayed on LAVA web page? I have tried to modify TIMEZONE of the file "/usr/lib/python2.7/dist-packages/lava_server/settings/common.py" and "/usr/lib/python2.7/dist-packages/django/conf/global_settings", and then restarted the LAVA server, but it seemed nothing changed. Thanks.

8 years, 10 months

2
1
0 0

LDAP authentication problem

by Rafael Gago Castano

Hello. I have configured a LAVA server and I set up a local Django account to start configuring things: sudo lava-server manage createsuperuser --username <user> --email=<mail> Then I want to add LDAP support by adding the relevant fields to /etc/lava-server/settings.conf: "AUTH_LDAP_SERVER_URI": "ldaps://server.domain.se:636", "AUTH_LDAP_BIND_DN": "CN=company_ldap,OU=Service Accounts,OU=Resources,OU=Data,DC=domain,DC=se", "AUTH_LDAP_BIND_PASSWORD": "thepwd", "AUTH_LDAP_USER_ATTR_MAP": { "first_name": "givenName", "email": "mail" }, "DISABLE_OPENID_AUTH": true I have restarted both apache2 and lava-server. I was expecting to get a Sign In page like this one: https://validation.linaro.org/static/docs/v1/_images/ldap-user-login.png Unfortunately I'm not familiar with neither django (and Web development) and LDAP and I don't know how to debug this. I have tried to grep for ldap|LDAP in /var/log/lava-server but nothing pops up. Unfortunately I couldn't find a way to browse the mailing list for previous answers. GMANE search doesn't work today. How should I proceed?

8 years, 10 months

2
2
0 0

Fwd: mailing list

by Neil Williams

On 9 December 2016 at 04:58, ajay m <ajayopensource25(a)gmail.com> wrote: > Hai Neil williams, > > Thanks for the response, > > i wanted to confirm whether lava supports every target board like jetson tk1 > and amd64 boards also ? or is there any list specifically it? LAVA gains support for specific boards when someone does the (often complex) work of automating the board and integrating it into LAVA. Some boards need expensive or unusual hardware to support automation, some need hardware modification. https://validation.linaro.org/static/docs/v2/first-devices.html#adding-new-… To see the current level of support, you can look at some of the LAVA instances. The scheduler status page shows which device-types are in use. https://validation.linaro.org/scheduler/ You can also check the codebase for V2 support. https://git.linaro.org/lava/lava-server.git/tree/lava_scheduler_app/tests/d… There have been people looking at the jetson tk1 but as yet the board has not been integrated into LAVA. There is support for iPXE booting x86 servers, as long as those machines all have real serial ports. > if it not supports every target board, is there any specific reason or admin > can modify the code? LAVA cannot support every possible board ever built. There are specific requirements for automation and it may not be possible to automate every board, whether you are using LAVA or something else. https://validation.linaro.org/static/docs/v2/simple-admin.html https://validation.linaro.org/static/docs/v2/devicetypes.html https://staging.validation.linaro.org/static/docs/v2/first-devices.html#add… -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

8 years, 10 months

1
0
0 0

lava-wait-all in 2016.11

by James Oakley

I have a multi-node test involving 13 roles that is no longer syncing properly after upgrading to 2016.11 this morning. It seems that 2 or 3 nodes end up waiting for a specific message while the other ones finish the message and move on to the next. Looking at the dispatcher log, I don't see any errors, but it's only logging that it's sending to some of the nodes. For example, I see a message like this for the nodes that work in a run: 2016-11-10 13:10:37,295 Sending wait messageID 'qa-network-info' to /var/lib/lava/dispatcher/slave/tmp/7615/device.yaml in group 2651c0a0-811f-4b77-bc07-22af31744fe5: {"/var/lib/lava/dispatcher/slave/tmp/7619/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7613/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7623/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tm p/7620/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7611/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7621/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7622/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7617/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7618/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7614/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7615/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7616/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7612/device.yaml": {}} 2016-11-10 13:10:37,295 Sending wait response to /var/lib/lava/dispatcher/slave/tmp/7615/device.yaml in group 2651c0a0-811f-4b77-bc07-22af31744fe5: {"message": {"/var/lib/lava/dispatcher/slave/tmp/7619/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7613/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7623/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7620/ device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7611/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7621/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7622/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7617/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7618/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7614/device.yaml": {}, "/var/l ib/lava/dispatcher/slave/tmp/7615/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7616/device.yaml": {}, "/var/lib/lava/dispatcher/slave/tmp/7612/device.yaml": {}}, "response": "ack"} For the nodes that get stuck, there is no message like above. All of the nodes are qemu type, all on the same host. The nodes that fail are not consistent, but there seems to be always 2 or 3 that fail in every run I tried. Is there anything I can look at here to figure out what is happening? -- James Oakley james.oakley(a)multapplied.net

8 years, 11 months

2
3
0 0

Re: [Lava-users] Change in lava/lava-dispatcher[master]: Add support for the depthcharge bootloader

by Tomeu Vizoso

[Moving to lava-users as suggested by Neil] On 11/07/2016 03:20 PM, Neil Williams (Code Review) wrote: > Neil Williams has posted comments on this change. > > Change subject: Add support for the depthcharge bootloader > ...................................................................... > > > > Patch Set 3: > > (1 comment) > > https://review.linaro.org/#/c/15203/3/lava_dispatcher/pipeline/actions/depl… > > File lava_dispatcher/pipeline/actions/deploy/tftp.py: > > Line 127: def _ensure_device_dir(self, device_dir): >> Cannot say that I have fully understood it yet. Would it be correct >> if the > > The Strategy classes must not set or modify anything. The accepts > method does some very fast checks and returns True or False. Anything > which the pipeline actions need to know must be specified in the job > submission or the device configuration. So either this is restricted > to specific device-types (so a setting goes into the template) or it > has to be set for every job using this method (for situations where > the support can be used or not used on the same hardware for > different jobs). > > What is this per-device directory anyway and how is it meant to work > with tftpd-hpa which does not support configuration modification > without restarting itself? Jobs cannot require that daemons restart - > other jobs could easily be using that daemon at the same time. So each firmware image containing Depthcharge will also contain hardcoded values for the IP of the TFTP server, and for the paths of a cmdline.txt file and a FIT image. The FIT image containing a kernel and a DTB file, and optionally a ramdisk. Because the paths are set when the FW image is flashed, we cannot use the per-job directory. Thus we add a parameter to the device that is to be set in the device-specific template of Chrome devices. If that parameter is present, then a directory in the root of the TFTP files tree will be created with the value of that parameter. The TFTP server doesn't need to be restarted because its configuration is left unchanged, we just create a directory where depthcharge will look for the files. Thanks, Tomeu > I think this needs to move from IRC and gerrit to a thread on the > lava-users mailing list where the principles can be checked through > more easily. > >

8 years, 11 months

2
3
0 0

correct way to do ci with lava?

by alfonso

Hi everyone, As I have probably mentioned in previous emails, Im using the yocto project to generate some linux images that I want to test using lava as part of the continuous integration development. So far so good, i can submit the job description to lava using lava-tool and it will start the tests. I'm happy so far with all the results. Now my question is to ask you what would be the correct way do this procedure. Do you think it is reasonable to have a lava-tool submit-job followed by a waiting step using lava-tool job-status to report the final build result? or there is a nicer way to do this? Thanks a lot for your help in advance :) Best, Alfonso

9 years

2
1
0 0

[PATCH] device-types: add TI da850-lcdk

by Kevin Hilman

Signed-off-by: Kevin Hilman <khilman(a)baylibre.com> --- .../lava-dispatcher/device-types/da850-lcdk.conf | 45 ++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 lava_dispatcher/default-config/lava-dispatcher/device-types/da850-lcdk.conf diff --git a/lava_dispatcher/default-config/lava-dispatcher/device-types/da850-lcdk.conf b/lava_dispatcher/default-config/lava-dispatcher/device-types/da850-lcdk.conf new file mode 100644 index 000000000000..dd10b0da0f80 --- /dev/null +++ b/lava_dispatcher/default-config/lava-dispatcher/device-types/da850-lcdk.conf @@ -0,0 +1,45 @@ +client_type = bootloader + +bootloader_prompt = U-Boot +send_char = False + +uimage_only = True +uimage_xip = True +append_dtb = True +# don't add u-boot header to ramdisk +ramdisk_raw = True + +u_load_addrs = + 0xc1000000 + 0xc2000000 + 0xc1f00000 + +z_load_addrs = + 0xc1000000 + 0xc2000000 + 0xc1f00000 + +boot_cmds_ramdisk = + setenv autoload no, + setenv kernel_addr_r "'{KERNEL_ADDR}'", + setenv initrd_addr_r "'{RAMDISK_ADDR}'", + setenv loadkernel "'tftp ${kernel_addr_r} {KERNEL}'", + setenv loadinitrd "'tftp ${initrd_addr_r} {RAMDISK}; setenv initrd_size ${filesize}'", + setenv bootargs "'console=ttyS2,115200n8'", + setenv bootcmd "'dhcp; setenv serverip {SERVER_IP}; run loadkernel; run loadinitrd; setenv bootargs ${bootargs} initrd=${initrd_addr_r},0x${initrd_size}; printenv bootargs; bootm ${kernel_addr_r}'", + boot + +boot_cmds_nfs = + setenv autoload no, + setenv kernel_addr_r "'{KERNEL_ADDR}'", + setenv initrd_addr_r "'{RAMDISK_ADDR}'", + setenv loadkernel "'tftp ${kernel_addr_r} {KERNEL}'", + setenv bootargs "'console=ttyS2,115200n8 root=/dev/nfs rw nfsroot={SERVER_IP}:{NFSROOTFS},tcp,hard,intr ip=dhcp'", + setenv bootcmd "'dhcp; setenv serverip {SERVER_IP}; run loadkernel; printenv bootargs; bootm ${kernel_addr_r}'", + boot + +boot_options = + boot_cmds + +[boot_cmds] +default = boot_cmds_ramdisk -- 2.5.0

9 years

1
1
0 0

[PATCH] bootloader: add ramdisk_raw option

by Kevin Hilman

By default, a uboot header is automatically added to the ramdisk image. For bootloaders without INITRD_ATAG support, the ramdisk needs to be passed on the command line and cannot have the uboot header added. To enable this feature, add a "ramdisk_raw" option that device files can set so that a uboot header is not added. Signed-off-by: Kevin Hilman <khilman(a)baylibre.com> --- Patch applies on 2016.9 lava_dispatcher/config.py | 1 + lava_dispatcher/device/bootloader.py | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/lava_dispatcher/config.py b/lava_dispatcher/config.py index 66a9e70021fa..c91c5634280d 100644 --- a/lava_dispatcher/config.py +++ b/lava_dispatcher/config.py @@ -312,6 +312,7 @@ class DeviceSchema(schema.Schema): uimage_xip = schema.BoolOption(default=False) append_dtb = schema.BoolOption(default=False) prepend_blob = schema.StringOption(default=None) + ramdisk_raw = schema.BoolOption(default=False) # for dynamic_vm devices dynamic_vm_backend_device_type = schema.StringOption(default='kvm') diff --git a/lava_dispatcher/device/bootloader.py b/lava_dispatcher/device/bootloader.py index 634d22ef3311..c88fba8937e6 100644 --- a/lava_dispatcher/device/bootloader.py +++ b/lava_dispatcher/device/bootloader.py @@ -208,7 +208,7 @@ class BootloaderTarget(MasterImageTarget): decompress=False) extract_overlay(overlay, ramdisk_dir) ramdisk = create_ramdisk(ramdisk_dir, self._tmpdir) - if self._is_uboot(): + if self._is_uboot() and not self.config.ramdisk_raw: # Ensure ramdisk has u-boot header if not self._is_uboot_ramdisk(ramdisk): ramdisk_uboot = ramdisk + ".uboot" -- 2.5.0

9 years

1
1
0 0

Help: job email notification log and deivce state change command

by kingboli

Hello everyone, Can you help me on below two questions? 1. I did email notification settings for sending emails after job complete or incomplete. How can I get whole logs (where are logs?) about email sending process? I need to debug email sending. 2. I want to use script to control device state periodically. How can I set device to maintenance state using command, like lava-tool command? Thanks in advance.

9 years

2
3
0 0

lava-dispatcher and lava-tool

by alfonso

Hello everyone, just a simple question. I might be wrong but I understand that submitting a job through lava-dispatch and lava-tool should lead to the same process. Now, with the dispacher you can already specify an specific target device encoded in yaml format. Does the lava-tool at some point reach a similar target configuration? does it generate it or it is stored somewhere? in the latter case, where is it stored? thanks in advance :) Best, Alfonso

9 years

2
1
0 0

test zipped qemu image

by alfonso

Hello everyone, just a quick question. I am trying to run a job to test a qemu image which is stored remotely. The image is packed in a tar.xz file with both the kernel and the file system. is there a way to specify in the job description json file that before the deploy action it must open this tar.xz file and then use the kernel and filesystem? Thanks a lot :) Best, Alfonso

9 years

2
1
0 0

Installing on Ubuntu 16.04

by Alfonso Ros Dos Santos

Hello guys, I am currently trying to install the lava-server/dispatcher on my local pc with Ubuntu 16.04. Unfortunately, I had little success installing the source projects from github.com/linaro. I just wanted to ask if you could recommend me what would be the best approach for me. Thanks for your help. Best regards, Alfonso

9 years

2
1
0 0

matching results to requested tests

by Milosz Wasilewski

Hi, I'm trying to get the proper relationship between requested tests and results in LAVA v2. Here is example job: https://validation.linaro.org/scheduler/job/1109234 and results for this job: https://validation.linaro.org/results/1109234 How can I tell: - which result matches which test? - if there are multiple occurrences of the same test with different parameters, how to recognize the results? In LAVA v1 the matching was a very arduous process. One had to download the job definition, look for lava-test-shell actions, pull the test definition yaml sources and match yaml ID and to ID found in result bundle. How does this work in v2? milosz

9 years, 1 month

2
8
0 0

Latest Tradefed version for Android Testing

by Sandeep Chawla

Hello, Google has release the latest version of Tradefed with the Android N release. https://source.android.com/devices/tech/test_infra/tradefed/index.html Lots of dispatcher/slave features which LAVA already supports. Given this update, is LAVA exploring to adopt the new mechanism or continue developing its own architecture ? Thanks Sandeep

9 years, 2 months

3
3
0 0

Local lava-test-shell

by Milosz Wasilewski

Hi, Chase did an excellent job and put together a piece of code that allows us local execution of lava-test-shell. This means we can use our 'lava' test definitions on the boards that are not deployed in any LAB. There are 2 main reasons for doing that: - prototyping tests for LAVA - semi-automated execution of tests on targets that are not deployed in any LAB Major part of this code is taken directly from lava dispatcher. There are slight modifications but I would like to keep them to minimum or remove at all (if possible). So the question follows - is there a way to achieve the same goal with only LAVA code? One of the biggest problems was requirement for ACKing that lava-test-shell requires. This makes the tests 'interactive' which isn't best for semi-automated execution. This bit was removed and now we're able to use test shell locally in non-interactive mode. The README file describes the use cases we're covering. Any comments are welcome. Code can be found here: https://git.linaro.org/qa/lava-local-test.git milosz

9 years, 2 months

5
8
0 0

error - lava-android-test has not been installed

by Umamaheswara Rao Lankoti

Hi I created algiz device type as : client_type = fastboot fastboot_driver = fastboot adb_command = adb fastboot_command = fastboot and algiz01 device as: device_type = algiz adb_command = adb fastboot_command = fastboot created job as below: ---------------------------------------------- { "actions": [ { "command": "lava_android_test_run", "parameters": { "test_name": "ls /sdcard/" } }, { "command": "submit_results", "parameters": { "server": "http://192.168.100.84/RPC2/", "stream": "/anonymous/ulankoti/" } } ], "device_type": "algiz", "health_check": false, "job_name": "test-job-run", "logging_level": "DEBUG", "timeout": 18000 } ---------------------------------------------- Below error is coming when the job run: -------------------------------------------------------------------- Section 0<http://localhost/scheduler/job/5/log_file#L_0> 0.0<http://localhost/scheduler/job/5/log_file#L_0_0> <LAVA_DISPATCHER>2016-08-08 09:45:20 AM DEBUG: [ACTION-B] Single node test! 0.1<http://localhost/scheduler/job/5/log_file#L_0_1> <LAVA_DISPATCHER>2016-08-08 09:45:20 AM DEBUG: lmp modules default init data is [] 0.2<http://localhost/scheduler/job/5/log_file#L_0_2> <LAVA_DISPATCHER>2016-08-08 09:45:20 AM DEBUG: lmp modules final init data is [] 0.3<http://localhost/scheduler/job/5/log_file#L_0_3> <LAVA_DISPATCHER>2016-08-08 09:45:20 AM INFO: [ACTION-B] lava_android_test_run is started with {'timeout': 18000, u'test_name': u'ls /sdcard/'} 0.4<http://localhost/scheduler/job/5/log_file#L_0_4> <LAVA_DISPATCHER>2016-08-08 09:45:20 AM WARNING: pexpect timed out with status fail 0.5<http://localhost/scheduler/job/5/log_file#L_0_5> <LAVA_DISPATCHER>2016-08-08 09:45:20 AM DEBUG: finally status fail 0.6<http://localhost/scheduler/job/5/log_file#L_0_6> <LAVA_DISPATCHER>2016-08-08 09:45:20 AM WARNING: [ACTION-E] lava_android_test_run is finished with error (lava-android-test has not been installed). Section 1<http://localhost/scheduler/job/5/log_file#L_1> 1.0<http://localhost/scheduler/job/5/log_file#L_1_0> ErrorMessage: lava-android-test has not been installed 1.1<http://localhost/scheduler/job/5/log_file#L_1_1> Lava failed at action lava_android_test_run with error:lava-android-test has not been installed Section 2<http://localhost/scheduler/job/5/log_file#L_2> 2.0<http://localhost/scheduler/job/5/log_file#L_2_0> Traceback (most recent call last): 2.1<http://localhost/scheduler/job/5/log_file#L_2_1> File "/usr/lib/python2.7/dist-packages/lava_dispatcher/job.py", line 385, in run 2.2<http://localhost/scheduler/job/5/log_file#L_2_2> action.run(**params) 2.3<http://localhost/scheduler/job/5/log_file#L_2_3> File "/usr/lib/python2.7/dist-packages/lava_dispatcher/actions/lava_android_test.py", line 57, in run 2.4<http://localhost/scheduler/job/5/log_file#L_2_4> self.check_lava_android_test_installed() 2.5<http://localhost/scheduler/job/5/log_file#L_2_5> File "/usr/lib/python2.7/dist-packages/lava_dispatcher/actions/lava_android_test.py", line 34, in check_lava_android_test_installed 2.6<http://localhost/scheduler/job/5/log_file#L_2_6> raise OperationFailed('lava-android-test has not been installed') 2.7<http://localhost/scheduler/job/5/log_file#L_2_7> OperationFailed: lava-android-test has not been installed --------------------------------------------------------------------------------- I have installed lava-android-test on the host PC from git.linaro.org/lava/lava-android-test.git Device is attached to the host PC via usb and 'adb devices' lists the device. Still getting "lava-android-test has not been installed" error. Can someone help how to resolve this issue? thanks, uma..

9 years, 2 months

3
4
0 0

Re: [Lava-users] LAVA setup for continuous integration validation of Android builds

by Senthil Kumaran S

Hi Mahesh, On Tuesday 19 July 2016 05:58 PM, Umamaheswara Rao Lankoti wrote: > I am Umamaheswara Rao working for Innominds and I am trying to evaluate > LAVA framework as part of Continuous Integration job. Nice to know. > I am looking at automating the smoke tests with LAVA, downloading a > newly generated build from Jenkins, flash it on android phone, boot into > home screen and run a minimal set of usecases, report success/failure > for the test cases, etc.. There is no direct integration such as plugins which does this in LAVA. But you can submit jobs to LAVA via scripts, once the builds are ready in Jenkins. This is already done as part of many jenkin based CI loops used within Linaro and elsewhere. > Looking at the documentation, I came to know that Ubuntu support is > stopped. Would Debian Jessie be supported in future? Yes you are right Ubuntu is deprecated. Debian will be supported in future. We support Debian Jessie and Testing as of today. PS: I ve added lava-users mailing list, so that you would get more inputs on this topic, in case if I ve missed anything. Thank You. -- Senthil Kumaran S http://www.stylesen.org/ http://www.sasenthilkumaran.com/

9 years, 3 months

5
11
0 0

No GUI Environment After Lava Installation

by Luís Matallui

Hi, I've just made a fresh Debian (Jessie) installation. Then, I've added jessie-backports and installed lava-server from there. Once the installation completed, I've rebooted and the GUI desktop environment doesn't come up. This happened twice already, so it's definitely the Lava installation that's breaking something there. Is this a known issue? Any suggestions? Regards, matallui

9 years, 3 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users