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

Re: [Lava-users] LAVA 2018

by Conrad Djedjebi

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

7 years, 2 months

3
3
0 0

Re: [Lava-users] LAVA 2018

by Magnus Olsson

7 years, 2 months

1
0
0 0

Re: [Lava-users] LAVA 2018

by Magnus Olsson

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

7 years, 2 months

1
0
0 0

LAVA 2018

by Conrad Djedjebi

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

7 years, 2 months

2
1
0 0

CSV export on LAVA 2018.2

by magnus＠minimum.se

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

7 years, 2 months

2
1
0 0

Django CSRF Token cookies

by Bill Fletcher

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

7 years, 2 months

2
1
0 0

Django CSRF Token cookies

by Conrad Djedjebi

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

7 years, 2 months

2
1
0 0

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

by Conrad Djedjebi

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

7 years, 2 months

3
4
0 0

Does LAVA v2 support test image dummy deployed

by Arthur She

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

7 years, 2 months

2
1
0 0

Re: [Lava-users] set up issue

by Christopher McClellan

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

7 years, 2 months

2
1
0 0

User notifications in LAVA

by Xu, Hongyu

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

7 years, 2 months

2
1
0 0

Re: [Lava-users] set up issue

by Tim Jaacks

This is a django configuration issue. I don’t understand why this case (it is very common, obviously) is not handled in the LAVA documentation explicitly. There is a short hint, though, here: https://validation.linaro.org/static/docs/v2/pipeline-debug.html#using-loca… You have to add these two variables to /etc/lava-server/settings.conf: "CSRF_COOKIE_SECURE": false, "SESSION_COOKIE_SECURE": false I achieved this using the following commands: sudo apt-get install jq jq '.CSRF_COOKIE_SECURE=false | .SESSION_COOKIE_SECURE=false' /etc/lava-server/settings.conf > /tmp/settings.conf && mv /tmp/settings.conf /etc/lava-server/settings.conf sudo chown root:root /etc/lava-server/settings.conf sudo service lava-server-gunicorn restart Mit freundlichen Grüßen / Best regards Tim Jaacks DEVELOPMENT ENGINEER Garz & Fricke GmbH Tempowerkring 2 21079 Hamburg Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 tim.jaacks(a)garz-fricke.com www.garz-fricke.com SOLUTIONS THAT COMPLETE! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz

7 years, 2 months

1
0
0 0

set up issue

by Hemanth K V

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

7 years, 2 months

1
0
0 0

x86 sample job

by Hemanth K V

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

7 years, 2 months

3
8
0 0

LAVA V2 hangs over non-existent job!

by Zoran S

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

7 years, 2 months

2
7
0 0

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

by Anibal Limon

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

7 years, 2 months

2
3
0 0

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

by Zoran S

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

7 years, 2 months

2
6
0 0

Re: [Lava-users] Integrating a custom bootloader

by Tim Jaacks

Hi Neil, thanks for your reply. >Why do you need an in-house bootloader? (Hint: Just because you can / have >is the worst possible reason.) Honestly, just find some other way to do it >- it will likely be much quicker. We have developed our own bootloader for our hardware, for various reasons, and want our OS to be tested in combination with it. Our devices do not support any other bootloader except our own anyway, so there is no other possibility. This is what we have, and we need to automate testing somehow. So I am trying to figure out whether LAVA is suitable for this task. >Supporting a new bootloader is a very complex and time-consuming process >for any test framework. It typically takes several months. Once done, there >is an ongoing maintenance burden as the code for the supported bootloaders >continues to advance. This is not a problem generally. We are planning long-term and want a future-proof solution. >You need a new Strategy Class, as per the documentation. You must not >overload the "method: u-boot" support for anything except U-Boot. You must >create a new boot method. Why? What is wrong with using the u-boot method for a bootloader which works similarly? As far as I can see right now, I would only remove stuff from the u-boot method and set a bunch of already existing variables to new values. I do not see the need for a completely new boot method. Is there any hard reason for this, except that it would be neater? Mit freundlichen Grüßen / Best regards Tim Jaacks DEVELOPMENT ENGINEER Garz & Fricke GmbH Tempowerkring 2 21079 Hamburg Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 tim.jaacks(a)garz-fricke.com www.garz-fricke.com SOLUTIONS THAT COMPLETE! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz

7 years, 2 months

2
1
0 0

Integrating a custom bootloader

by Tim Jaacks

Hello, I am evaluating LAVA as a candidate for software release testing on our devices. I have already set up a LAVA instance with a Beaglebone Black board running regular health checks. Our own devices do not use a standard bootloader, but a custom one developed by our team. It has the following characteristics: * Always boots to a shell (no interruption needed) * OS is installed on internal eMMC by calling an installation script * Installation script and OS images are deployed to the device via TFTP by calling a bootloader command sequence * Installed OS is booted via a bootloader command sequence So LAVA has already implemented TFTP as a deployment method, which I can re-use. As far as I understand, this deployment method copies the files to the machine's TFTP server directory, so that they are available to the device for download. However, the actual download (from TFTP server to device) is implemented as a command sequence in the boot method. Is that correct? At least, this is what I see in the base-uboot.jinja2 device type template. I thought that it should be possible to re-use the "u-boot" bootloader class for our own bootloader, since the basic concepts (calling bootloader commands for TFTP download, calling bootloader commands for OS execution) are similar. The only difference might be that we don't need interruption, but that seems to be handled by the "needs_interrupt" parameter, which I could set to False. Are these assumptions correct from an experienced LAVA point of view? Would this be a reasonable approach for getting LAVA to work with our own bootloader? Or is it necessary to implement our own bootloader python class in lava_dispatcher/actions/boot/? Mit freundlichen Grüßen / Best regards Tim Jaacks DEVELOPMENT ENGINEER Garz & Fricke GmbH Tempowerkring 2 21079 Hamburg Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 tim.jaacks(a)garz-fricke.com www.garz-fricke.com SOLUTIONS THAT COMPLETE! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz

7 years, 2 months

2
1
0 0

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

by Neil Williams

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

7 years, 2 months

3
2
0 0

deploying to secondary media

by Hemanth K V

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

7 years, 2 months

2
1
0 0

Error while submitting a Test Definition | Standalone LAVA Master installation

by Conrad Djedjebi

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

7 years, 2 months

2
2
0 0

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

by mayuri mohite

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

7 years, 2 months

2
1
0 0

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

by Zoran S

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

7 years, 2 months

1
0
0 0

Test execution without creating images

by Hemanth K V

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

7 years, 2 months

2
3
0 0

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

by Zoran S

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

7 years, 2 months

3
16
0 0

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

by Zoran S

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

7 years, 2 months

3
6
0 0

Regarding LXC Job

by Chetan Sharma

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

7 years, 2 months

2
1
0 0

user logins via http and https

by Kevin Hilman

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

7 years, 3 months

2
1
0 0

how to achieve sync among multi-node in job definition

by Liao, Guoqi

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

7 years, 3 months

2
3
0 0

Minimal Boot: manage additional parameters

by Philippe BEGNIC

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

7 years, 3 months

3
7
0 0

request: disable LXC support, or make it optional

by Kevin Hilman

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

7 years, 3 months

4
5
0 0

Enabling ZMQ authentication leads to lava-logs offline

by Chase Qi

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

7 years, 3 months

2
2
0 0

IOZone test to measure performance of DUT

by Florence ROUGER JUNG

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

7 years, 3 months

5
11
0 0

Using power-on command with pyocd boot method

by Andrei Narkevitch

Hi, our boards are powered via PDU and before flashing with pyocd, they need to be powered up first. I defined power_on_command in the device dictionary, but it is ignored. It looks like an only limited set of methods add ResetDevice action to the pipeline and pyocd is not among them. Contrarily, if defined, power_off command always gets invoked because it is added by FinalizeAction to every test. I'm wondering if there is any way to issue the power-on command without modifying the dispatcher pipeline source code. Thanks, Andrei Narkevitch, Cypress Semiconductor This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

7 years, 3 months

2
2
0 0

Request to know one example on prepare-scp-overlay

by Chetan Sharma

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

7 years, 3 months

2
7
0 0

Procedure to install lava-coordinator setup

by Chetan Sharma

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

7 years, 3 months

3
4
0 0

lava-tool wait-job-events

by Loys Ollivier

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

7 years, 3 months

3
13
0 0

Booting with Coreboot/Depthcharge

by Guillaume Tucker

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

7 years, 4 months

2
17
0 0

LAB Notice: LAVA Instance downtime

by Dave Pigott

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

7 years, 4 months

1
2
0 0

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

by Robert Marshall

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

7 years, 4 months

1
0
0 0

No result coming when job submitted in lava

by Gumansingh, Smita

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

7 years, 4 months

2
1
0 0

Better bootloader failure detection

by Matt Hart

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

7 years, 4 months

3
2
0 0

Job stuck

by Thomas Petazzoni

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

7 years, 4 months

3
2
0 0

LXC device not working in multinode jobs

by Andrei Gheorghiu

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

7 years, 4 months

2
1
0 0

Help: using custom script - run.sh error

by Mylene JOSSERAND

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

7 years, 4 months

2
4
0 0

Need Help With Simplistic Testing Over SSH

by Tan, Jian Chern

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

7 years, 4 months

1
0
0 0

Unpacking tar.bz2 root filesystems seems to malfunction

by Dragos Iorgulescu

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

7 years, 4 months

4
13
0 0

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

by Aníbal Limón

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

7 years, 4 months

2
2
0 0

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

by Tomeu Vizoso

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

7 years, 4 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users