lava-users

lava-users@lists.lavasoftware.org

2 participants
944 discussions

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, 11 months

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, 11 months

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, 12 months

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, 12 months

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

9 years

$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

9 years, 2 months

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

9 years, 2 months

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.

9 years, 2 months

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>

9 years, 3 months

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

9 years, 3 months

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users