Lava-users February 2018

lava-users@lists.linaro.org

20 participants
30 discussions

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

6 years, 2 months

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.

6 years, 2 months

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.

6 years, 2 months

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

6 years, 2 months

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…

6 years, 2 months

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

6 years, 2 months

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

6 years, 2 months

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

6 years, 2 months

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/

6 years, 2 months

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.

6 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Lava-users February 2018