lava-users

lava-users@lists.lavasoftware.org

1 participants
912 discussions

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/

7 years, 8 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.

7 years, 8 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

7 years, 9 months

$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

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

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

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

8 years

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

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

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

← Newer
1
...
83
84
85
86
87
88
89
...
92
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users