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

by Neil Williams

LAVA, until now, has packaged SysVinit files to manage the various daemons but there have been longstanding problems with log rotation and the need to carry redundant code to manage the daemonize process for python scripts. This has allowed instances to support both SysVinit and systemd because systemd automatically converts the SysVinit files to systemd service files. Now that V1 has been removed, it has become possible and advantageous to drop SysVinit support and move to only systemd support. This is expected to mean that lava-dispatcher (and therefore lava-server) will depend on systemd-sysv, i.e. systemd needs to be the init system to be able to start the daemons upon which LAVA relies. A default install of Debian Jessie and Stretch already defaults to using systemd as the init system, so this does not necessarily involve any changes. If there are questions or issues with this, please reply to the lava-users mailing list. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

8 years, 11 months

1
0
0 0

Binary flashing test for Dragonboard 410

by Alfred Ziskind

Hi all, We are planning implementing a test that uses QDL (https://git.linaro.org/landing-teams/working/qualcomm/qdl.git/) for DragonBoard flashing. Scenario: after we flashed the binaries with QDL we want to check in the serial log if the boot sequence is correct. Can we develop this test in LAVA? If not, please recommend a test framework that can. Thank you, Alfred

8 years, 11 months

2
1
0 0

LAVA 2017.11 release

by Neil Williams

See https://lists.linaro.org/pipermail/lava-announce/2017-September/000037.html 2017.11 is the second release on the roadmap to the removal of V1. This is the single largest change ever made to the LAVA packages. * All dashboard URLs are permanently disabled in lava-server. * All devices which were not enabled for V2 are now hidden and unusable. * All V1 code has been removed from lava-dispatcher. * All V1 documentation has been removed from lava-server-doc. 2017.11 disables all access to any V1 test data - including V1 only devices. The data itself remains in the database but is not accessible via any API. If you have chosen to keep an archive of V1 test data and have not yet done so, you should do this before installing this upgrade. At the very least, you **must** have a backup of your postgresql database **before** you upgraded to 2017.11 in order to make a V1 test data archive later. 2017.11 requires that **all** workers and each associated master are upgraded to 2017.11 for test jobs to continue running. This is because there have been very large changes to the directories and file layout within both lava-server and lava-dispatcher associated with the removal of the V1 components. The LAVA software team have been checking ahead for the final stage of the roadmap and plans are on track, as described. http:// and https:// changes in django ====================================== A reminder, if you are accessing an instance using http:// (whether localhost or not), then the changes described in the documentation **must** be applied for the instance to operate correctly. This is a security change in Django, not a change in LAVA. https://staging.validation.linaro.org/static/docs/v2/pipeline-debug.html#us… Symptoms include HTTP500 errors but can also include the inability to login to an instance using LDAP or local django accounts, depending on your local apache configuration. Changes in 2017.11 ================== Changes in the 2017.11 release are described below, including the short git commit hash. Use the git commit hash to go directly to that commit using a URL like https://git.linaro.org/lava/lava-server.git/commit/?id=b19b9648a for lava-server or https://git.linaro.org/lava/lava-dispatcher.git/commit/?id=1451e3a4 for lava-dispatcher. Where the changelog message includes a story id like LAVA-552, that id can be added to the base URL: https://projects.linaro.org/browse/ to find out more about the change itself. e.g. https://projects.linaro.org/browse/LAVA-552 All LAVA stories are publicly available without requiring a login. 2017.11 also includes large changes to the packaging of both lava-server and lava-dispatcher. The prompts formerly used to configure a V1 remote worker have been removed. Packaging is maintained at https://github.com/Linaro/pkg-lava-server and https://github.com/Linaro/pkg-lava-dispatcher Packages for 2017.11 have been uploaded to Debian unstable and also the LAVA repositories (for jessie-backports and stretch-backports). lava-server =========== a799fc6c Fix links back to the main instance 5b9656b6 Fix broken plural in header b21f8c8f Fix crash in job_section_log c9526f01 Document the LOG_SIZE_LIMIT setting in settings.conf 63b57c94 Remove lava-mount-masterfs 75b403f4 Remove add_device script 8ddea823 Add description about the disc space requirement for pg_upgradecluster. 5c9dceb2 Remove TemporaryDevice imports 9b21ea48 Removed unused Worker functions 2accb4c3 Matching change to templates for directory change 1d384c4a Update docs regarding device-dictionary lava-server manage command. 32472fac Port 77fd10e2 to scheduler.devices.get_dictionary 114bbfa5 LAVA-1093 - Add a management command to drop all materialized views 8bc9d83a Update dashboard XML-RPC API help for api_version bb090e96 LAVA-552 - add system.api_version support 77fd10e2 LAVA-1092 support passing a context to device_config de7ad3aa Remove dashboard_app views and static files. 4bc68531 Remove templates from dashboard_app. 1a618c27 Remove unused functions d50deca7 api: limit the number of jobs returned 59880e14 Fix HTTP 500 on devicetype health history a39fecf5 Remove unused resources (css, js and images) a32ac3b6 Rename base-bootstrap and content-bootstrap 7c108de1 job: print lava.job result in case of failure b51c419f Remove old templates a9139c1f Use bootstrap template 7915f18f Remove unused resources 7331901a scheduler.api.jobs.show: add failure_comment 71233bff Fix print syntax for python3 compatibility 936d5eca Remove unused tags 4ebb2a39 Remove unused sources 21a7eb18 Save more sql queries by caching values 4d0d867e Remove non pipeline jobs support a6648dbd Retain docs on disabling V1 workers 8eac0d74 Revert "LAVA-950 set the master identity" 68573b1a Remove V1 dependencies a8151559 timing: handle new start/end line format 26cc3ad0 Remove unnecessary js lib beautify. c44009fa Simplify job view e1da85d4 Fix loading of description.yaml 7b41f7ef Add documentation for secondary media writer parameters 1b4d3dd5 LAVA-1081 migrate instance name to settings f3dc1987 Fix up typos from earlier changes faa24f59 LAVA-1079 - remove HIDE_V1 and HIDE_V2 doc options 942b84c3 Remove unused functions and imports e61a4831 LAVA-1056 Drop V1 documentation 126dce0c Fix crash introduced by 42451c9cc f0b28214 Remove v1 codebase 31bb1bf0 Fix notification exception when query is used for data comparison. a6cff700 Remove last references to lava_dispatcher v1 043690d9 Remove references to lava_dispatcher v1 4c9e493c Remove dashboard_app traces from rest of the codebase. c371b8ca drop link to removed page 1b1b638e LAVA-876 - Return empty data stubs for dashboard API calls. 919c10c2 Remove links to dashboard_app in the scheduler_app 1483e9fb Remove leftover from job wizard f7a1c976 docker: allow passing extra options 42451c9c Use all_jobs_with_custom_sort when applicable cc4ffd64 Fix broken links in example test job 0ca5d75c Drop the migration status page. b37fe944 Add a device-type config for the rpi-3b in armv7 32bit mode 9e904a18 Revert "LAVA-876 - Remove access to Dashboard" f07e0950 Fix warning regarding naive datetime e8348425 Remove more references to dashboard_app 103a44be LAVA-876 - Remove access to Dashboard d33c9c98 LAVA-876 - Remove access to Dashboard b6fc46aa Revert "LAVA-1038 add a settings to archive the instance" f75a333d Do not run dashboard test anymore d9163445 Remove references to v1 jobs addb61d9 bug 3268: fix lava-master crash with invalid logs febf91b1 Improve advice on api/help ac8b7df3 fix pep8 error 64025cf3 LAVA-1072 test all template connection syntax 10d5fbe1 Adjust U-Boot load addresses for tegra124 devices to allow bigger kernels f30ef936 LAVA-1065 - Remove dashboard_app urls server wide. 096a2f1c LAVA-1049 - Allow for .yml as well as .yaml for healthchecks 918f0bc7 Fix logic so addldapuser and mergeldapuser work for all LDAP configs 36fcb3c2 Documentation changes for multiple uarts b1de8acf Update instructions for migrating postgres 0ff08373 LAVA-1053 Results limit does not work for queries f9e64aa1 Fix SQL request storm when listing jobs 2d9c4757 No need to save after get_or_create or Create() 8988cb36 LAVA-896 fix level in result export 219fa3dd LAVA-1073 - support for a second UART on a device c934bbbe master: fix database reconnection 4f0e0e62 LAVA-950 set the master identity 316d77fb Expand the device integration guidance. lava-dispatcher =============== d91a5b99 Revert "Stop parsing kernel messages when the end of a panic has been found" 1451e3a4 LAVA-1098 unassigned variable in read_feedback 437d57ba Rationalise the devices directory structure bdffb3bf Add power control to pyocd d9553680 Add feedback check to test shell 06588ddf Receive the udev device directly from the udev rule d811b2a8 Fix license 65d6c6a6 Move arduino101 dfu example urls to images.v.l.o 61cff41c Only log when feedback content was found 0ba35392 Move juno removable URLs to images.validation.linaro.org cb983d97 Cleanup after pytest runs 997265c2 LAVA-1086 add handler to listen to feedback 29a60e38 Add ConfigObj dependency for TFTP check 70bd3fab Fix prospector warnings 6edb8ef9 Fix missing import and other pylint issues 6f7f5f05 Remove lava-lxc-device-* scripts which are unused. 578b054b Use py.test 65c03eca docker: allow passing extra options 7b7d920a device-info should be yaml ef8f7d4c Remove deprecated function 165e14f8 Fix linger period: set it to 10s instead of 5ms 49c500ac Fix double crash when the process crash early 7dbdc2b6 Add test case for secondary deployment writer tool parameters 969459c6 LAVA-1069 - migrate dispatcher device configs 9e8e5258 Use optargs to extend ci-run for python3 e1c1561b Fix python3 breakage in unit test 69277753 Read feedback when finalising connections 0fb44088 LAVA-1067 Refactor fastboot flash operations 9ac71872 Add missing import 94430958 Ensure finalize always finalises protocols 9d712364 Add option to not uniquify secondary image download paths cdfd5909 Fix master cert handling for lava-run and lxc helper 73548f7a Rename dd params to tool for removable media 1802c3e8 Handle master and slave certs as filenames only ed306477 Do not rely on SysV runlevel to ensure container is ready. 75b47c6a Remove loop mounts via guestfs, while applying overlay to sparse image. cd1152e3 Support archlinux and slackware rootfs 6fc024a5 Remove deprecated modules ddf5d2fc Remove v1 code 5561be23 LAVA-1074 - second UART support 758a41a6 Allow configurable writes for secondary storage deployment fb75db4a Add flag to disable uniquifying the download paths -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

8 years, 11 months

1
0
0 0

403: Forbidden - CSRF verification failed (2017.10-1)

by Dragos Iorgulescu

Hi everyone! I have recently upgraded our production server to 2017.10-1. Whenever anyone tries to login in the WEB UI, either the “403: Forbidden – CSRF verification failed” error is returned, or no error at all (for the latter, the default LAVA page is shown again, but with no login info). I also tried creating a new superuser from the CLI. That worked, but I can’t use it to logon via the WEB UI, so I guess this has nothing to do with the user accounts stored in LAVA. Is this triggered by a change in Django/LAVA? Kind regards, Dragoș

8 years, 11 months

2
2
0 0

[lava v2] charts and redefining X attribute

by Jonathan Guyot

Hello everybody, I am working with both Jenkins and lava and I thought it was possible to change X attributes in charts to use Jenkins build number instead of a date. In my job, I defined a metadata like this : job_name: quad-ssh-host device_type: ssh *metadata: {jenkins-build: 725, job-context: nightly}* timeouts: job: minutes: 10 action: minutes: 3 connection: seconds: 20 visibility: public […] and I made a query that can select these jobs using job-context as a filter. Then, in the chart, I wanted to use the jenkins-build value to group job instead of a simple date, but the chart does not seem to be able to do that. I made many tries on the lava 2017.2 version. I wonder whether I am misusing lava charts or if it is an issue that need a fix. Thanks in advance for any reply. Jonathan

8 years, 11 months

2
5
0 0

”502 Proxy Error” for large job log & details (in the WEB UI)

by Dragos Iorgulescu

Hello again! After managing to run a consistent series of tests on one of our boards, I came across a situation where the job log seems to be too big for LAVA to display. When clicking the ”Job details” button, the server eventually sends a ”502 Proxy Error” message. Is there a setting or a workaround to make LAVA serve the job log & details in ”chunks”? I did download the plain log (using, for example, http://LAVA_HOST/scheduler/job/JOB_ID/log_file/plain), and it is, indeed, huge (29 MB), but I was just curious if, maybe a ”log rotation”-like mechanism could be used in these situations (somehow). Thanks in advance! -- /Dragoş

8 years, 11 months

3
4
0 0

Git error after upgrading to 2017.10-1: "fatal: index-pack failed"

by Dragos Iorgulescu

Hi! Just upgraded from 2017.6 to 2017.10-1. Tried re-running some jobs that worked fine just before the upgrade and noticed that git checkouts can no longer pe performed. The encountered error is: fatal: The remote end hung up unexpectedly\nfatal: early EOF\nfatal: index-pack failed\n Tried checking out manualy on the host, using the same repo. It works. How could I proceed investigating this? Could this be related to some lava user configuration that got reset (I don't know if git-related configs are associated with LAVA)? Thanks in advance (again)! P.S: I have attached the plain job log -- /Dragoş

8 years, 11 months

2
3
0 0

LAB Notice: Planned maintenance

by Dave Pigott

[bcc’d to everyone to ensure we get full coverage. Please ignore if you have no interest in LAVA and the Lab] Hi all, Starting this week, we are finalising the transition of LAVA main production to LAVA V2. The main update and hopefully minor downtime, will commence at 09:00 UTC on Monday 6th November. Along with this we will also be upgrading all micro-instances to Debian Stretch and LAVA 2017.11. There will be a brief period on Monday morning, which should be less than an hour, when remote logins will be disabled as we upgrade the gateway server. Please note, that when validation.linaro.org <http://validation.linaro.org/> comes back online, LAVA V1 job submissions will be rejected, so if you have any bots which auto-submit V1 jobs, please work with us to transition them to V2. For future reference, for announcements about Lab availability, you should join the lava-users mailing list. Thanks Dave ---------------- Dave Pigott LAVA Lab Lead Linaro Ltd t: (+44) (0) 1223 400063

8 years, 11 months

1
1
0 0

Very long output line seems to interfere with board output/job run

by Dragos Iorgulescu

Good morning everyone! While running some tests using our Linux distro and a SuperMicro Intel D1521 board, we encounter a situation where a very long line (shown as a "broken line" in LAVA's logs - in the WEB UI) seems to interfere with the job run, in a sense that the job eventually ends in a timeout. This does not happen when that particular set of tests is not run and I am wondering if this might be a LAVA issue. -------------------- A bit of context, first. SuperMicro boards "make sure" your board connection options are limited to using SoL (serial-over-lan), IPMI and a serial port (but in a very limited manner). One is not able to do a "typical" image load, since you may not specify hardware addresses or properly interact with the bootloader. This led to an approach which is best illustrated in the attached diagram. For short: LAVA instantiates an LXC container, from where we run a series of scripts to prepare the board (copy some images & files on an already available Linux instance, altering the Grub menu and then rebooting the board, making it start the image we wish to test) and then run remote commands via SSH. So, basically, the LXC container runs each and every command on the board, acting as the middleman. ------------------- Now, we have the following: * https://paste.debian.net/993516/ -> plain log excerpt that contains the very long line I was talking about (please see line no. 90) * https://paste.debian.net/993517/ -> job definition * https://paste.debian.net/993518/ -> test definition Is there a way to further investigate if this type of output is "giving LAVA a hard time"? Is there a setting that limits interpreted output, somehow? May it be that this is a LAVA issue? Kind regards! -- /Dragoş

8 years, 12 months

2
4
0 0

"No such method: u'results.run_query'" when trying to access queries from a Python script

by Dragos Iorgulescu

Good morning everyone! I am trying to "play around" with user queries in LAVA2. After reading about them (https://validation.linaro.org/static/docs/v2/lava-queries-charts.html?highl… ), I downloaded the provided sample script (https://validation.linaro.org/static/docs/v2/examples/source/query-results.… ), made the required updates (user names, query name, hostname & the such) and gave it a try. The only thing I get stuck on is an XML-RPC lib error: "No such method: u'results.run_query'" (the whole traceback can be seen here: https://paste.debian.net/993833/ ) I have attached the modified script I am trying to run at the moment and a screenshot of the query settings. The API Help page is not reachable/present at the moment (nor on https://validation.linaro.org/static/api/help or on our own LAVA instance ), so I am unable to check whether or not the method's name has changed since the last doc update. What am I missing or doing wrong? Many thanks in advance! Have a great day! -- /Dragoş

8 years, 12 months

2
4
0 0

PXE Booting and flashing device

by Rees, Kevron

I have a minnowboard turbot device that I want lava to boot, flash, reboot to flashed image, and then run tests. I would like to boot the device via PXE networking to an initramfs where I will flash an image to permanent storage. I can use efibootmgr within the initramfs image to set next-boot to the permanent storage device. Once booted from the permanent storage device, lava tests will run as per normal. It appears that many of the ipxe examples I have found simply run tests on the initramfs itself. Is it possible to flash the device once the initramfs has booted? It seems like it would be simple for lava-dispatcher to run wget http://someurl/foo.img | dd of=/dev/sda once the initramfs has reached login. However, I do not know if there is such a deploy mechanism. Does anything already exist within lava to help achieve this model? Is there a better way? Any feedback would be appreciated. -Kevron

9 years

2
4
0 0

Truncated commands & output in LAVA2

by Dragos Iorgulescu

Hi all! We have been working on integrating a cn8304-based board (uses uboot). We noticed some strange behavior that might be related to LAVA2. On average, 2 out of 3 job runs end up with errors/timeouts. We use the same job definition and device each and every time. Looking through LAVA logs, it seems that commands and some output gets truncated, thus malforming the commands being sent or the prompts that LAVA expects. The prompt we expect is "EBB8304> ", but sometimes it gets truncated to "304>". Also, a command gets mixed up somehow, and instead of "setenv loadinitrd 'tftpboot 0x60000000 358/tftp-deploy-VLCRzw/ramdisk/ramdisk.ext4.gz.uboot'", the board receives "EBB8304> setenv loadkernel 'tftpboot 0x40setenv loadinitrd 'tftpboot 0x60000000 358/tftp-deploy-VLCRzw/ramdisk/ramdisk.ext4.gz.uboot'" Details: * The job definition: https://paste.debian.net/993349/ * An excerpt from the LAVA2 job log/output, showing what gets mixed up: https://paste.debian.net/993350/ * The plain job log is attached to this e-mail Many thanks in advance! -- /Dragoş

9 years

2
2
0 0

LAB Notice: Planned maintenance

by Dave Pigott

Hi all, Starting this week, we are finalising the transition of LAVA main production to LAVA V2. The main update and hopefully minor downtime, will commence at 09:00 UTC on Monday 6th November. Along with this we will also be upgrading all micro-instances to Debian Stretch and LAVA 2017.11. There will be a brief period on Monday morning, which should be less than an hour, when remote logins will be disabled as we upgrade the gateway server. Please note, that when validation.linaro.org comes back online, LAVA V1 job submissions will be rejected, so if you have any bots which auto-submit V1 jobs, please work with us to transition them to V2. Thanks Dave ---------------- Dave Pigott LAVA Lab Lead Linaro Ltd t: (+44) (0) 1223 400063

9 years

1
0
0 0

LAVA Error 503 Service Unavailable Error

by Tan, Jian Chern

Hey does anyone know why i'm getting an Error 503 Service Unavailable after installing LAVA on a new server? I have it installed on another system and i've never gotten this error on that system before. If it helps, i'm working behind a corporate proxy and here are the pertinent lines from lava-server.log in the apache log folder. [Fri Oct 06 20:01:57.729804 2017] [proxy:error] [pid 2887:tid 140627852187392] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:8000 (127.0.0.1) failed [Fri Oct 06 20:01:57.729851 2017] [proxy_http:error] [pid 2887:tid 140627852187392] [client *IP*:56521] AH01114: HTTP: failed to make connection to backend: 127.0.0.1 Thanks! Jian Chern

9 years

2
1
0 0

How to transfer a file from DUT to Server?

by Sathyamurthy, Raghuram

Hello, I working on a requirement for our project where I need to get some log from DUT and send back to Server. How can I achieve it? Thanks, Raghu

9 years

2
1
0 0

lava-tool auth-add problem

by Michael Chen

Hi lava users, We're trying to use lava-tool to automate the job submit process, but having problem on using "lava-tool auth-add" command. The error message is ERROR: Username provided but no token found. I tried the instructions from the following page, but without luck. https://validation.linaro.org/static/docs/v2/lava-tool-issues.html I am pretty sure the user name, token, server url are correct since we tested it with the example python script from above page's second paragraph, and we can submit job through it. The version of lava-tool is 0.23-1 and lava-server is 2017.10-1+jessie. Does anyone have similar issue? Thank you. Michael Chen

9 years

2
1
0 0

Test job failed due to uefi-menu-selector timeout

by Arthur She

Hi, I got a problem in LAVA v2. My test jobs failed due to uefi-menu-selector timeout occasionally. Like this one <https://staging.validation.linaro.org/scheduler/job/188583> and this one <https://staging.validation.linaro.org/scheduler/job/185376>. When it happened, I usually re-submit the test job and, sometimes, it got recovery and had the test job run successfully, like this <https://staging.validation.linaro.org/scheduler/job/185377>. However, we're working on our own CI loop now, the test job <https://staging.validation.linaro.org/scheduler/job/194340> is submitted automatically. It doesn't make sense to re-submit the test job. Any ideas? Thanks, Arthur

9 years

3
2
0 0

Board At Desk v1.0, a downstream of LAVA and kernelci, just released.

by Agustin Benito Bethencourt

Hi, CIP just released Board At Desk v1.0 which is based on LAVAv2 and kernelci. Link: https://www.cip-project.org/blog/2017/10/18/cip-launches-bd-v1-0 From those involved in this release, thanks to all of you who make these technologies possible and also to those involved in kernelci.org project. Thank you also for your support these past months. Best Regards -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito(a)codethink.co.uk

9 years

1
0
0 0

Re: [Lava-users] Help running an inline test

by Neil Williams

On 26 Sep 2017 2:59 am, "Daniel Sangorrin" <daniel.sangorrin(a)toshiba.co.jp> wrote: Hi Neil, > -----Original Message----- > From: Neil Williams [mailto:neil.williams@linaro.org] > Sent: Tuesday, September 12, 2017 5:49 PM > To: Daniel Sangorrin > Cc: Robert Marshall; Lava Users Mailman list > Subject: Re: [Lava-users] Help running an inline test > > On 12 September 2017 at 09:25, Daniel Sangorrin > <daniel.sangorrin(a)toshiba.co.jp> wrote: > > > >> -----Original Message----- > >> From: Neil Williams [mailto:neil.williams@linaro.org] > >> Sent: Tuesday, September 12, 2017 4:58 PM > >> To: Daniel Sangorrin > >> Cc: Robert Marshall; Lava Users Mailman list > >> Subject: Re: [Lava-users] Help running an inline test > >> > >> On 12 September 2017 at 08:50, Daniel Sangorrin > >> <daniel.sangorrin(a)toshiba.co.jp> wrote: > >> > Hi Neil, > >> > > >> > Thanks for your reply. > >> > > >> >> -----Original Message----- > >> >> From: Neil Williams [mailto:neil.williams@linaro.org] > >> >> Sent: Tuesday, September 12, 2017 4:16 PM > >> >> To: Daniel Sangorrin > >> >> Cc: Robert Marshall; Lava Users Mailman list > >> >> Subject: Re: [Lava-users] Help running an inline test > >> >> > >> >> On 12 September 2017 at 08:10, Daniel Sangorrin > >> >> <daniel.sangorrin(a)toshiba.co.jp> wrote: > >> >> > Robert, Neil: > >> >> > > >> >> > I managed to prepare a 2017.7 environment. The boot action still works fine. > >> >> > The test action still fails, but in a more 'sane' way I would say. > >> >> > There are strange things like 'None', no lava-test-runner, etc.. Please check the > >> >> > log attached. > >> >> > >> >> You haven't specified a deploy step, so there is no test shell > >> >> created. Boot just does the boot - to deploy the test environment > >> >> there must be a deploy action. > >> > > >> > As far as I understand, the deployment action occurs before the > >> > boot action and consists of preparing a kernel/filesystem in some > >> > media (e.g.: as a network filesystem). > >> > Ref: https://validation.linaro.org/static/docs/v2/actions-deploy.html > >> > > >> > For now, I wanted to run my tests with the kernel and filesystem > >> > that is already installed on the Flash memory. Is this impossible with LAVA? > >> > >> Such a system can only be booted, it cannot operate a Lava Test Shell > >> because there is no way to get the test shell onto the device without > >> a deploy. > >> > >> There is support for primary connections using SSH > >> https://validation.linaro.org/static/docs/v2/dispatcher- design.html#primary-connection > >> > >> See: Problems with simplistic testing in the documentation. > >> https://validation.linaro.org/static/docs/v2/simple-admin. html#problems-with-simplistic-testing > > > > Thanks a lot Neil. > > # I'm not against deployment, I just wanted to prepare the environment step by step. > > > > The primary connection could be a good solution but it looks like I wouldn't be able to use the PDU, > > or the autologin features from the u-boot action through the serial port. I will implement the > > deploy action instead. > > > > By the way, when you talk about "test shell" I am assuming that you mean a shell script or binary > > that is copied into the target filesystem and executed. Is that correct? > > My filesystem is very minimal: basically busybox using the ash shell. > > "test shell" == Lava Test Shell as defined by the test action block. > This relies on POSIX behaviour where the automation drives scripts > installed onto the system to execute the test operations themselves. > > To handle busybox ash compatibility, just set the Operating System as > Open Embedded. > > actions: > - deploy: > # ... rest of the deploy > os: oe > > https://validation.linaro.org/static/docs/v2/actions-deploy.html#index-18 Sorry, it took me a while but I finally got it working. I met several problems. Some of them were a matter of overriding variables. For example, I cannot use dhcp for the board so I had to change uboot_ipaddr_cmd and base_ip_args. There was one variable (SERVER_IP) I couldn't override, so I had to modify base-uboot.jinja2 for it. my jinja2: {% set uboot_serverip = '192.168.1.66' %} base-uboot.jinja2 # vi /etc/lava-server/dispatcher-config/device-types/base-uboot.jinja2 {% set base_uboot_tftp_bootcmd = uboot_tftp_bootcmd|default( " - setenv bootcmd '" + uboot_ipaddr_cmd|default('dhcp') + "; setenv serverip " + uboot_serverip|default('{SERVER_IP}') + "; run loadkernel; run loadinitrd; " + run_load_fdt + uboot_bootx_cmd|default('{BOOTX}') + "' - run bootcmd") -%} Note: I tried modifying LAVA_SERVER_IP and LAVA_NETWORK_IFACE in /etc/lava-dispatcher/lava-dispatcher.conf as well but it didn't work. Those settings are only relevant for V1, so V2 tests will ignore these. Setting the SERVER_IP in the device configuration is the wrong approach. This IP address is for the dispatcher, so it needs to be added to the dispatcher configuration. In V2, the dispatcher configuration is sent from the master. Setting a fixed IP address for the dispatcher is already supported. See /usr/share/lava-dispatcher/dispatcher.yaml for an example. See https://validation.linaro.org/static/docs/v2/pipeline-admin.html#extra-disp… You need a file named according to the hostname of the dispatcher as it appears in the dispatcher-master log file. If you consider it useful, please consider including it in the mainstream code. Thanks for your help, Daniel > >> >> >> -----Original Message----- > >> >> >> From: Lava-users [mailto:lava-users-bounces@lists.linaro.org] On Behalf Of Daniel Sangorrin > >> >> >> Sent: Monday, September 11, 2017 5:16 PM > >> >> >> To: 'Robert Marshall'; 'Lava Users Mailman list' > >> >> >> Subject: Re: [Lava-users] Help running an inline test > >> >> >> > >> >> >> > -----Original Message----- > >> >> >> > From: Lava-users [mailto:lava-users-bounces@lists.linaro.org] On Behalf Of Robert Marshall > >> >> >> > Sent: Monday, September 11, 2017 4:47 PM > >> >> >> > To: 'Lava Users Mailman list' > >> >> >> > Subject: Re: [Lava-users] Help running an inline test > >> >> >> > > >> >> >> > "Daniel Sangorrin" <daniel.sangorrin(a)toshiba.co.jp> writes: > >> >> >> > > >> >> >> > > Hi Neil, > >> >> >> > > > >> >> >> > > Thanks for your quick reply. > >> >> >> > > > >> >> >> > >> -----Original Message----- > >> >> >> > >> From: Neil Williams [mailto:neil.williams@linaro.org] > >> >> >> > >> Sent: Monday, September 11, 2017 3:23 PM > >> >> >> > >> > >> >> >> > >> On 11 September 2017 at 07:06, Daniel Sangorrin > >> >> >> > >> <daniel.sangorrin(a)toshiba.co.jp> wrote: > >> >> >> > >> > Hi, > >> >> >> > >> > > >> >> >> > >> > I have spent a few days learning LAVA with QEMU and the Beagle Bone black. > >> >> >> > >> > Now, I'm trying to setup a Renesas iwg20m board but I have some strange > >> >> >> > >> > problem. > >> >> >> > >> > # I'm using LAVA v2016.12. > >> >> >> > >> > >> >> >> > >> Updates are available - you should follow the LAVA documentation for > >> >> >> > >> the LAVA repositories and upgrade. > >> >> >> > >> > >> >> >> > >> https://staging.validation.linaro.org/static/docs/v2/ installing_on_debian.html#lava-repositories > >> >> >> > > > >> >> >> > > Thanks, I will try with the 2017.9 version then. > >> >> >> > > > >> >> >> > Daniel > >> >> >> > > >> >> >> > If you're doing the test within b@d [1] you should look at my > >> >> >> > https://gitlab.com/rajm/board-at-desk-single-dev/tree/ lava2017-fixes > >> >> >> > branch which has various fixes for our use of lava 2017-7, once that > >> >> >> > branch is merged - soon now! - it should 'just work' > >> >> >> > >> >> >> Wow Robert, just in time! Thanks. > >> >> >> > >> >> >> Daniel > >> >> >> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Lava-users mailing list > >> >> >> Lava-users(a)lists.linaro.org > >> >> >> https://lists.linaro.org/mailman/listinfo/lava-users > >> >> > > >> >> > _______________________________________________ > >> >> > 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/ > > > > > > > > > > -- > > Neil Williams > ============= > neil.williams(a)linaro.org > http://www.linux.codehelp.co.uk/

9 years, 1 month

2
1
0 0

Help running an inline test

by Daniel Sangorrin

Hi, I have spent a few days learning LAVA with QEMU and the Beagle Bone black. Now, I'm trying to setup a Renesas iwg20m board but I have some strange problem. # I'm using LAVA v2016.12. The actions in the job definition looks as follows (sorry pastebin is blocked by our proxy): actions: - boot: method: u-boot commands: msd type: uimage auto_login: login_prompt: '$none$ login: ' username: root prompts: - 'myiwg20m: # ' timeout: minutes: 2 failure_retry: 5 - test: timeout: minutes: 5 failure_retry: 3 name: kernel-version-singlenode definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: kernel-version-basic description: "check kernel version" run: steps: - lava-test-case linux-INLINE-uname --shell uname -a from: inline name: kernel-version-inline path: inline/kernel-version-basic.yaml So far LAVA has been successful at powering on the board, interrupting u-boot, sending the u-boot commands, recognizing the boot login prompt and auto-login in. In other words, the boot actions seems to be working fine. The problem comes with the 'test' action. I have mostly copied the code from the inline example included in the help but I get the following errors: (sorry again for not pasting it on pastebin) - {"dt": "2017-09-11T05:19:03.602576", "lvl": "target", "msg": "Debian GNU/Linux 8 (none) /dev/ttySC0"} - {"dt": "2017-09-11T05:19:03.605709", "lvl": "debug", "msg": "Matched prompt #6: \$none\$ login: "} - {"dt": "2017-09-11T05:19:03.606979", "lvl": "debug", "msg": "Sending username root"} - {"dt": "2017-09-11T05:19:03.608100", "lvl": "debug", "msg": {"sending": "root\n"}} - {"dt": "2017-09-11T05:19:03.864073", "lvl": "target", "msg": "(none) login: root"} - {"dt": "2017-09-11T05:19:03.865475", "lvl": "debug", "msg": "auto-login-action: Wait for prompt ['myiwg20m: # ']. 120 seconds"} - {"dt": "2017-09-11T05:19:03.868416", "lvl": "target", "msg": "root"} - {"dt": "2017-09-11T05:19:03.898283", "lvl": "target", "msg": ""} - {"dt": "2017-09-11T05:19:03.904742", "lvl": "target", "msg": "The programs included with the Debian GNU/Linux system are free software;"} - {"dt": "2017-09-11T05:19:03.911114", "lvl": "target", "msg": "the exact distribution terms for each program are described in the"} - {"dt": "2017-09-11T05:19:03.915433", "lvl": "target", "msg": "individual files in /usr/share/doc/*/copyright."} - {"dt": "2017-09-11T05:19:03.921821", "lvl": "target", "msg": "Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent"} - {"dt": "2017-09-11T05:19:03.923941", "lvl": "target", "msg": "permitted by applicable law."} - {"dt": "2017-09-11T05:19:03.927111", "lvl": "target", "msg": "login[816]: root login on 'ttySC0'"} - {"dt": "2017-09-11T05:19:03.928112", "lvl": "target", "msg": ""} - {"dt": "2017-09-11T05:19:03.933510", "lvl": "target", "msg": "BusyBox v1.22.1 (2017-09-01 01:37:39 UTC) built-in shell (ash)"} - {"dt": "2017-09-11T05:19:03.937734", "lvl": "target", "msg": "Enter 'help' for a list of built-in commands."} - {"dt": "2017-09-11T05:19:03.938979", "lvl": "debug", "msg": "Setting shell prompt(s) to ['myiwg20m: # ', 'lava-test: # ']"} - {"dt": "2017-09-11T05:19:03.939504", "lvl": "debug", "msg": {"sending": "export PS1=\"lava-test: # \"\n"}} - {"dt": "2017-09-11T05:19:05.310766", "lvl": "target", "msg": "myiwg20m: # [6nexport PS1=\\\"lava-test: # \\\""} - {"dt": "2017-09-11T05:19:05.311542", "lvl": "debug", "msg": "auto-login-action duration: 3.93"} - {"dt": "2017-09-11T05:19:05.312062", "lvl": "results", "msg": {"case": "auto-login-action", "definition": "lava", "duration": !!float "3.929234027862549", "extra": !!python/object/apply:collections.OrderedDict [[["success", "No kernel warnings or errors detected."]]], "level": "1.5.5", "result": "pass"}} - {"dt": "2017-09-11T05:19:05.313427", "lvl": "debug", "msg": "start: 1.5.6 expect-shell-connection (max 120s)"} - {"dt": "2017-09-11T05:19:05.313967", "lvl": "debug", "msg": "expect-shell-connection: Waiting for prompt myiwg20m: # , lava-test: # "} - {"dt": "2017-09-11T05:19:05.314522", "lvl": "debug", "msg": "expect-shell-connection: Wait for prompt ['myiwg20m: # ', 'lava-test: # ']. 300 seconds"} - {"dt": "2017-09-11T05:19:05.315249", "lvl": "target", "msg": "export PS1=\\\"lava-test: # \\\""} - {"dt": "2017-09-11T05:19:05.315963", "lvl": "debug", "msg": "expect-shell-connection duration: 0.00"} - {"dt": "2017-09-11T05:19:05.316851", "lvl": "debug", "msg": "start: 1.5.7 export-device-env (max 120s)"} - {"dt": "2017-09-11T05:19:05.317390", "lvl": "debug", "msg": "export-device-env duration: 0.00"} - {"dt": "2017-09-11T05:19:05.317890", "lvl": "debug", "msg": "Setting default test shell prompt"} - {"dt": "2017-09-11T05:19:05.318373", "lvl": "debug", "msg": ["myiwg20m: # ", "lava-test: # "]} - {"dt": "2017-09-11T05:19:05.318902", "lvl": "debug", "msg": "uboot-retry: Wait for prompt ['myiwg20m: # ', 'lava-test: # ']. 240 seconds"} - {"dt": "2017-09-11T05:19:05.339032", "lvl": "debug", "msg": "uboot-retry duration: 8.48"} - {"dt": "2017-09-11T05:19:05.339643", "lvl": "info", "msg": "uboot-action duration: 8.50"} - {"dt": "2017-09-11T05:19:05.340189", "lvl": "info", "msg": "start: 2 lava-test-retry (max 300s)"} - {"dt": "2017-09-11T05:19:05.340724", "lvl": "debug", "msg": "start: 2.1 lava-test-shell (max 300s)"} - {"dt": "2017-09-11T05:19:05.341253", "lvl": "info", "msg": "Executing test definitions using ShellSession"} - {"dt": "2017-09-11T05:19:05.341753", "lvl": "debug", "msg": {"sending": "#\n"}} - {"dt": "2017-09-11T05:19:05.442940", "lvl": "target", "msg": "lava-test: # [6n#"} - {"dt": "2017-09-11T05:19:05.443483", "lvl": "debug", "msg": "lava-test-shell: Wait for prompt ['myiwg20m: # ', 'lava-test: # ']. 300 seconds"} - {"dt": "2017-09-11T05:19:05.446189", "lvl": "target", "msg": "#"} - {"dt": "2017-09-11T05:19:05.469109", "lvl": "exception", "msg": "Traceback (most recent call last):\n File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py\", line 290, in run_actions\n new_connection = action.run(connection, args)\n File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/test/shell.py\", line 243, in run\n for running in xrange(stage + 1):\nTypeError: unsupported operand type(s) for +: 'NoneType' and 'int'\n"} - {"dt": "2017-09-11T05:19:05.470260", "lvl": "debug", "msg": "start: 3.1 power_off (max 5s)"} - {"dt": "2017-09-11T05:19:05.470796", "lvl": "info", "msg": "nice curl http://admin:<omitted>@192.168.11.68/set.cmd?cmd=setpower+p61=0"} - {"dt": "2017-09-11T05:19:05.534407", "lvl": "debug", "msg": !!python/unicode "command output % Total % Received % Xferd Average Speed Time Time Time Current\n Dload Upload Total Spent Left Speed\n\r 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0\r100 20 0 20 0 0 371 0 --:--:-- --:--:-- --:--:-- 377\n<html>p61=0</html>\r\n"} - {"dt": "2017-09-11T05:19:05.535945", "lvl": "debug", "msg": "power_off duration: 0.07"} - {"dt": "2017-09-11T05:19:05.536462", "lvl": "results", "msg": {"case": "power_off", "definition": "lava", "duration": !!float "0.06516695022583008", "extra": !!python/object/apply:collections.OrderedDict [[["status", "success"]]], "level": "3.1", "result": "pass"}} - {"dt": "2017-09-11T05:19:05.644487", "lvl": "error", "msg": "Status: Incomplete\nErrors ['Traceback (most recent call last): File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py\", line 290, in run_actions new_connection = action.run(connection, args) File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/test/shell.py\", line 243, in run for running in xrange(stage + 1):TypeError: unsupported operand type(s) for +: \\'NoneType\\' and \\'int\\'', 'Incomplete']"} - {"dt": "2017-09-11T05:19:05.646006", "lvl": "exception", "msg": "Traceback (most recent call last):\n File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py\", line 290, in run_actions\n new_connection = action.run(connection, args)\n File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/logical.py\", line 57, in run\n new_connection = self.internal_pipeline.run_actions(connection)\n File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py\", line 302, in run_actions\n raise RuntimeError(action.errors)\nRuntimeError: ['Traceback (most recent call last): File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py\", line 290, in run_actions new_connection = action.run(connection, args) File \"/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/actions/test/shell.py\", line 243, in run for running in xrange(stage + 1):TypeError: unsupported operand type(s) for +: \\'NoneType\\' and \\'int\\'']\n"} - {"dt": "2017-09-11T05:19:05.647870", "lvl": "debug", "msg": "start: 3.1 power_off (max 5s)"} - {"dt": "2017-09-11T05:19:05.648393", "lvl": "debug", "msg": "power_off duration: 0.00"} - {"dt": "2017-09-11T05:19:05.648864", "lvl": "results", "msg": {"case": "power_off", "definition": "lava", "duration": !!float "3.0994415283203125e-05", "extra": !!python/object/apply:collections.OrderedDict [[["status", "success"], ["duration", !!float "0.06516695022583008"], ["connection-timeout", !!float "300.0"], ["timeout", !!float "5.0"], ["level", "3.1"]]], "level": "3.1", "result": "pass"}} - {"dt": "2017-09-11T05:19:05.650619", "lvl": "error", "msg": "status: ['Incomplete']"} Any hint of what's going on? # One thing I don't understand is that even though I have set the "prompts" variable on the job, LAVA seems to force it to become "lava-test: #". Thanks, Daniel

9 years, 1 month

3
11
0 0

Using specific branch of a test definition repository

by Xu, Hongyu

Hi lava experts : The branch did not take effect when I specified the branch in my test-definition! (hxt-dev-br1) I use the local git repo , and my test-definition is in branch :hxt-dev-br1, not the master. Then I specified the branch, but it did not take effect. My test-definition: device_type: qemu job_name: health check job timeouts: job: minutes: 15 action: minutes: 5 connection: minutes: 2 priority: medium visibility: public # context allows specific values to be overridden or included context: # tell the qemu template which architecture is being tested # the template uses that to ensure that qemu-system-x86_64 is executed. arch: amd64 metadata: # please change these fields when modifying this job for your own tests. docs-source: first-job docs-filename: qemu-pipeline-first-job.yaml # ACTION_BLOCK actions: - deploy: timeout: minutes: 90 to: tmpfs images: rootfs: image_arg: -drive format=raw,file={rootfs} url: http://autotest002/tmp/stretch-2.img.gz compression: gz os: debian # BOOT_BLOCK - boot: timeout: minutes: 2 method: qemu media: tmpfs prompts: ["root@debian:"] auto_login: login_prompt: "login:" username: root - test: timeout: minutes: 30 definitions: - repository: ssh://1680141@10.5.20.24:29418/sw_test/test-definitions from: git path: ubuntu/smoke-tests-basic.yaml name: smoke-tests-basic branch: hxt-dev-br1 Log: Loading test definitionsstart: 1.3.3.1 git-repo-action (timeout 00:14:55)Using /lava-48 at stage 0Fetching tests from ssh://1680141@10.5.20.24:29418/sw_test/test-definitionsRunning '/usr/bin/git clone ssh://1680141@10.5.20.24:29418/sw_test/test-definitions /var/lib/lava/dispatcher/tmp/48/lava-overlay-Iw36n8/lava-48/0/tests/0_smoke-tests-basic'Tests stored (tmp) in /var/lib/lava/dispatcher/tmp/48/lava-overlay-Iw36n8/lava-48/0/tests/0_smoke-tests-basic/ubuntu/smoke-tests-basic.yamlUnable to open test definition 'ubuntu/smoke-tests-basic.yaml': [Errno 2] No such file or directory: '/var/lib/lava/dispatcher/tmp/48/lava-overlay-Iw36n8/lava-48/0/tests/0_smoke-tests-basic/ubuntu/smoke-tests-basic.yaml' Best Regards XuHongyu From: Lava-users [mailto:lava-users-bounces@lists.linaro.org] On Behalf Of Xu, Hongyu Sent: 2017年9月18日 18:07 To: Lava-users(a)lists.linaro.org Subject: [Lava-users] test-definitions Hi lava , Can I put test-definitions(.yaml script ) in locally on my worker server ? Don’t get them from the git-repo! 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. 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.

9 years, 1 month

1
0
0 0

test-definitions

by Xu, Hongyu

Hi lava , Can I put test-definitions(.yaml script ) in locally on my worker server ? Don't get them from the git-repo! 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.

9 years, 1 month

1
0
0 0

lava-tool auth token

by Xu, Hongyu

Hi experts, It's error when I auth token with the lava-too, because my I deploy the lava 2017.7 with SSL Self-signed certificate. Now I can use the XML-RPC to auth the token with " ssl._create_unverified_context ". How can I do ? I want use the lava-tool . import ssl ssl._create_default_https_context = ssl._create_unverified_context import xmlrpclib username = "lavaadmin" token = "onku07n16r2uktjz40otgn0n9m7q1bp1b75dr4u0ph0juy7jnb8csi0u9x7fg3sf1mpgnxw00sq1otmzl3rqpdu4tl5fam45m5xyt25oin020ohkajzrx7ze0aaukkdt" hostname = "autotest001" protocol = "https" # http or preferably https server = xmlrpclib.ServerProxy("%s://%s:%s@%s/RPC2" % (protocol, username, token, hostname)) device_hostname = "qemu_test01" jinjia_string = " {% extends 'qemu.jinja2' %} {% set mac_addr = '52:54:00:12:34:60' %} {% set memory = '1024' %} " > lava-tool auth-add --token-file /home/lavaadmin/xuhy/qemu_test_token https://1680141@10.5.21.5/RPC2 > > ERROR: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate > verify failed (_ssl.c:661)> Best Regards XuHongyu -----Original Message----- From: Xu, Hongyu Sent: 2017年9月12日 14:47 To: 'Neil Williams' <neil.williams(a)linaro.org> Cc: Lava-users(a)lists.linaro.org Subject: RE: [Lava-users] auth token We deploy the lava on the Internal lan, an the domain names is private . But let's Encrypt can only issue certificates for valid public domain names. Are there any other Suggestions? Best Regards XuHongyu -----Original Message----- From: Neil Williams [mailto:neil.williams@linaro.org] Sent: 2017年9月11日 15:35 To: Xu, Hongyu <hongyu.xu(a)hxt-semitech.com> Cc: Lava-users(a)lists.linaro.org Subject: Re: [Lava-users] auth token On 11 September 2017 at 08:28, Xu, Hongyu <hongyu.xu(a)hxt-semitech.com> wrote: > Hi lava experts: > > > > I deploy the lava 2017.7 with SSL Self-signed certificate, then I > want to create the device-dictionary for the qemu devices, it’s error > when I add auth_token. Please give me some suggest! > > That needs to be fixed within your own SSL configuration. Lots of security packages have issues with self-signed certificates, so it is better to look at solutions like letsencrypt. Details of how this is configured are outside the scope of the lava-users mailing list, it's a general system admin task and a variety of guides are available online. > > lava-tool auth-add --token-file /home/lavaadmin/xuhy/qemu_test_token > --user-shortcut 1680141 --endpoint-shortcut qemu_test01 > https://1680141@10.5.21.5 > > ERROR: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate > verify failed (_ssl.c:661)> > > > > Best Regards > > > > XuHongyu > > > > From: Xu, Hongyu > Sent: 2017年9月4日 14:41 > To: 'Lava-users(a)lists.linaro.org' <Lava-users(a)lists.linaro.org> > Subject: Local Django user accounts > > > > > > Hi all, > > > > I have installed the lava-serer (2017.7) on my DEBIAN 9.10. But now > I can’t sign in with the local Django user, this is the error infomations: > > 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. > > More information is available with DEBUG=True. > > This is already covered in the documentation, it's a Django change. If you have tried to solve this by using a self-signed certificate on localhost, you should avoid trying to create https://localhost/ and just update the security settings: https://staging.validation.linaro.org/static/docs/v2/pipeline-debug.html?hi… > > Please give me some advices! > > > > root@hxtcorp:~# dpkg-query -l lava* > > Desired=Unknown/Install/Remove/Purge/Hold > > | > Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Tri > g-pend > > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > > ||/ Name Version Architecture > Description > > +++-=================================-=====================-========== > +++===========-======================================================= > +++================ > > ii lava-coordinator 0.1.7-1 all > LAVA Coordinator daemon > > un lava-dashboard <none> <none> > (no description available) > > un lava-dashboard-tool <none> <none> > (no description available) > > ii lava-dispatcher 2017.7-1~bpo9+1 amd64 > Linaro Automated Validation Architecture dispatcher > > un lava-scheduler <none> <none> > (no description available) > > un lava-scheduler-tool <none> <none> > (no description available) > > ii lava-server 2017.7-1~bpo9+1 all > Linaro Automated Validation Architecture server > > ii lava-server-doc 2017.7-1~bpo9+1 all > Linaro Automated Validation Architecture documentation > > ii lava-tool 0.21-1 all > command line utility for LAVA > > un lavapdu <none> <none> > (no description available) > > ii lavapdu-client 0.0.5-1 all > LAVA PDU client > > ii lavapdu-daemon 0.0.5-1 all > LAVA PDU control daemon > > > > add the local Django user: > > sudo lava-server manage createsuperuser --username $USERNAME > --email=$EMAIL > > sudo lava-server manage authorize_superuser --username $USERNAME > > > > root@hxtcorp:/etc/lava-server# lava-server manage users list > > List of users: > > * 1680077 > > * 1680141 > > * lava-health > > * xuhy > > > > 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. > > > > > _______________________________________________ > 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/ 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.

9 years, 1 month

1
0
0 0

FYI: Problem updating device type

by Daniel Sangorrin

Just in case other users had the same problem I opened this issue: https://github.com/kernelci/lava-docker/issues/7 Cheers, Daniel

9 years, 1 month

1
0
0 0

pduclient

by Li, Xuelian

Hi，Neil： I want to control device power on/off by lavapdu.,but when I run pduclient --daemon autotest001 --hostname 10.5.142.6 --command off --port 10 ERROR : Error sending command, wrong daemon hostname? Can you help me solve this problem? Lava-server :IP 10.5.21.5 autotest001 Pdudaemon run on the lava-server Lavapdu.conf: { "daemon": { "hostname": "10.5.21.5", "port": 16421, "dbhost": "127.0.0.1", "dbuser": "pdudaemon", "dbpass": "pdudaemon", "dbname": "lavapdu", "retries": 5, "logging_level": "INFO" }, "pdus": { "192.168.10.2": { "driver": "apc9210" }, "192.168.10.3": { "driver": "apc7952", "telnetport": 5023 }, "192.168.10.4": { "driver": "apc7952" }, "192.168.10.5": { "driver": "apc8959", "this": "that", "something": "else" }, "192.168.25.52": { "driver": "apc7952" } } 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.

9 years, 1 month

2
1
0 0

auth token

by Xu, Hongyu

Hi lava experts: I deploy the lava 2017.7 with SSL Self-signed certificate, then I want to create the device-dictionary for the qemu devices, it’s error when I add auth_token. Please give me some suggest! lava-tool auth-add --token-file /home/lavaadmin/xuhy/qemu_test_token --user-shortcut 1680141 --endpoint-shortcut qemu_test01 https://1680141@10.5.21.5 ERROR: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)> Best Regards XuHongyu From: Xu, Hongyu Sent: 2017年9月4日 14:41 To: 'Lava-users(a)lists.linaro.org' <Lava-users(a)lists.linaro.org> Subject: Local Django user accounts Hi all, I have installed the lava-serer (2017.7) on my DEBIAN 9.10. But now I can’t sign in with the local Django user, this is the error infomations: 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. More information is available with DEBUG=True. Please give me some advices! root@hxtcorp:~# dpkg-query -l lava* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=================================-=====================-=====================-======================================================================= ii lava-coordinator 0.1.7-1 all LAVA Coordinator daemon un lava-dashboard <none> <none> (no description available) un lava-dashboard-tool <none> <none> (no description available) ii lava-dispatcher 2017.7-1~bpo9+1 amd64 Linaro Automated Validation Architecture dispatcher un lava-scheduler <none> <none> (no description available) un lava-scheduler-tool <none> <none> (no description available) ii lava-server 2017.7-1~bpo9+1 all Linaro Automated Validation Architecture server ii lava-server-doc 2017.7-1~bpo9+1 all Linaro Automated Validation Architecture documentation ii lava-tool 0.21-1 all command line utility for LAVA un lavapdu <none> <none> (no description available) ii lavapdu-client 0.0.5-1 all LAVA PDU client ii lavapdu-daemon 0.0.5-1 all LAVA PDU control daemon add the local Django user: sudo lava-server manage createsuperuser --username $USERNAME --email=$EMAIL sudo lava-server manage authorize_superuser --username $USERNAME root@hxtcorp:/etc/lava-server# lava-server manage users list List of users: * 1680077 * 1680141 * lava-health * xuhy 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.

9 years, 1 month

2
2
0 0

adding a device dictionary in 2017.7

by Daniel Sangorrin

Hi, I upgraded to LAVA 2017.7 (for now I'm using https://github.com/kernelci/lava-docker) and managed to add my device-type and device as follows: # Note: I didn't know how to update to 2017.9 docker# lava-server manage device-types add renesas-iwg20m docker# lava-server manage devices add --device-type renesas-iwg20m --worker lava-docker iwg20m01 However, when I want to add the device dictionary I get an error. # Note: I am following https://validation.linaro.org/static/docs/v2/pipeline-admin.html First, I tried with "lava-server manage device-dictionary" as in the documentation, but I failed: docker# lava-server manage device-dictionary Unknown command: 'device-dictionary' Is this only available in the 2017.9 version? Then, I tried with " lava-tool device-dictionary localhost lava-docker --update myiwg20m.jinja2" but I get: Updating device dictionary for lava-docker on localhost ERROR: Endpoint URL not found in the authorization list: localhost [Note] my lava-tool is version 0.23-1 (the newest according to apt) Now, there is a section saying "Using the command line The device dictionary exists as a jinja2 file in /etc/lava-server/dispatcher-config/devices and can be updated by admins with the necessary access.". Is this equivalent to using lava-server o lava-tool to install a device dictionary?? Others: - I confirmed that Pipeline device? is checked. - Django administration > Devices: what is the meaning of Hostname? I have a value of iwg20m01 (the name of the device), there is no relation with the server/container's hostname, is there? - There is an authentication token for the user 'kernel-ci' Thanks, Daniel

9 years, 1 month

2
2
0 0

Manual testing in Lava

by Denis HUMEAU

Hello, My question looks pretty silly, but as Lava has a big set of features that I haven't discovered yet, I dare ask. Lava is designed for automatic testing. But everything cannot be fully automated, at least in a reasonable development time frame. More precisely, tests execution can be automated, but the test result needs to be given by a tester. This will happen for example in display or graphics tests. So, is there a simple way in Lava to let a tester give a manual test result, during or after the test execution? I already have in mind pretty complicated solutions based on Multinode, but simple is key here Thanks, Denis

9 years, 1 month

2
1
0 0

problems with initramfs in LAVA 2017-7

by Robert Marshall

Hi I have a locally built initramfs which worked with a beaglebone black health check in LAVA 2016-12 but with version 2017-7 the health check is failing. I've tried using an initramfs from http://images.validation.linaro.org/snapshots.linaro.org/components/lava/st… with 2017-7 and that works ok. The various sections of the yaml file are as below and a comparison of the 2 boots are at http://paste.baserock.org/iyuzakogez , a lot more noise from the local one but 2016-12 was happy with that. Is there something I'm missing with the update that I need to change in this case? ramdisk: # url: http://images.validation.linaro.org/snapshots.linaro.org/components/lava/st… # locally built version url: http://localhost:8010/initramfs/initramfs-local.cpio.gz compression: gz add-header: u-boot .... # BOOT_BLOCK - boot: method: u-boot commands: ramdisk prompts: - '$initramfs$' timeout: minutes: 2

9 years, 1 month

2
4
0 0

Switching LAVA to V2

by Dave Pigott

Hi everyone, As many of you may know, LAVA V2 has been in development and is now ready to roll out across all instances, and we have started this transition with most micro-instances now being predominantly V2. That leaves the main production instance, validation.linaro.org. Of the supported device types in V2 16 of the 21 have been fully switched over already. Most of these devices can accept V1 and V2 job submissions, but for underlying structural reasons some device types can *only* be V1 or V2, not both. This is to let you know that in the week following SFO17 we will be switching those devices (HiKey, Drangboard 410c, X15, IFC6410 and Mustang) to V2 only, and any job submissions that are in the old JSON format will be rejected by the LAVA scheduler. If you have bots that submit V1 jobs to those device types, or if you manually submit V1 jobs to those device types, you are strongly urged to switch those off and move to V2 submissions. The next release of LAVA software will not support V1 at all, so for anyone submitting V1 jobs to *any* device, you will need to move to V2 by the beginning of November at the latest. Many thanks Dave ---------------- Dave Pigott LAVA Lab Lead Linaro Ltd t: (+44) (0) 1223 400063

9 years, 1 month

1
0
0 0

Start a flashed board and launch tests

by Philippe BEGNIC

Hello Lava team, I am trying to test a flashed board that does'nt require to upload tests images ( uImage dtb, rootfs). The images have been previously flashed on the board under test, by an external Flasher. To do that, I am using the boot method "minimal" that we have been using for other cases. In my test, I power on the board, and wait for the kernel prompt ("root@"). When I got the prompt, LAVA try to mount the test partition (previously prepared in deploy phase), but it fails. I get the following message "No connection retrieved from namespace data". * Is it possible to do this operation with the boot method "minimal" ? * Do you have jobs example that do the same operations ? Find below the boot and test phase I am using : ( In the deploy phase, I have downloaded images that I don't use. ) - boot: method: minimal failure_retry: 2 prompts: - 'root@' timeout: minutes: 2 - test: timeout: minutes: 5 namespace: flash_to_sd definitions: - from: git repository: /local/dev/frq93151/dispatcher/lava-tests path: tests-def/ddr_test_definition.yaml name: ddr_tests BR Philippe

9 years, 1 month

1
0
0 0

Local Django user accounts

by Xu, Hongyu

Hi all, I have installed the lava-serer (2017.7) on my DEBIAN 9.10. But now I can't sign in with the local Django user, this is the error infomations: 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. More information is available with DEBUG=True. Please give me some advices! root@hxtcorp:~# dpkg-query -l lava* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=================================-=====================-=====================-======================================================================= ii lava-coordinator 0.1.7-1 all LAVA Coordinator daemon un lava-dashboard <none> <none> (no description available) un lava-dashboard-tool <none> <none> (no description available) ii lava-dispatcher 2017.7-1~bpo9+1 amd64 Linaro Automated Validation Architecture dispatcher un lava-scheduler <none> <none> (no description available) un lava-scheduler-tool <none> <none> (no description available) ii lava-server 2017.7-1~bpo9+1 all Linaro Automated Validation Architecture server ii lava-server-doc 2017.7-1~bpo9+1 all Linaro Automated Validation Architecture documentation ii lava-tool 0.21-1 all command line utility for LAVA un lavapdu <none> <none> (no description available) ii lavapdu-client 0.0.5-1 all LAVA PDU client ii lavapdu-daemon 0.0.5-1 all LAVA PDU control daemon add the local Django user: sudo lava-server manage createsuperuser --username $USERNAME --email=$EMAIL sudo lava-server manage authorize_superuser --username $USERNAME root@hxtcorp:/etc/lava-server# lava-server manage users list List of users: * 1680077 * 1680141 * lava-health * xuhy 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.

9 years, 1 month

2
1
0 0

help:Adding pipeline workers to the master

by kingboli

Hi all, I used LAVA V1 before and I want to migrate to LAVA V2 following the guide " First steps installing LAVA V2" . I had a problem when adding pipeline workers to the master. After input the command " sudo lava-server manage workers add <HOSTNAME>", I got error "Unknown command: 'workers'" and I failed to find help by typing "lava-server -h manage". Can anybody help me on this step? BTW, I want to know whether multiple workers can have the same hostname ? Thanks in advance.

9 years, 2 months

2
5
0 0

Licenses in test-definitions

by Robert Marshall

Hi, The tests in https://git.linaro.org/qa/test-definitions.git in some cases have license in the subdirectories but there's no top level licence file covering the whole repository. Would you like a PR submitting to cover this or do you envisage the maintainers making this change themselves? We're hoping to use some of these and so wanted licences to be consistent. We'd also be prepared to review licences in future repository changes. The licenses that I've found all seem to be GPL v2 so I assume that is the license flavour which should be covering the whole repos. Robert

9 years, 2 months

4
5
0 0

[results error]constants section not present in the device config.

by Michael Chen

Hi Lava users, I just updated lava from 2016.12 to 2017.6-1. And I found my health-check job failed(uncomplete) after the update. Here is the result logs before: https://pastebin.com/KWAnYQvD and after: https://pastebin.com/mqXDfR3H I checked the log and think the cause for the issue is: ``` case: job definition: lava error_msg: constants section not present in the device config. error_type: Configuration result: fail ``` What I have done: * Try to find the "constants section" with no luck. * Looked at the logs in /var/lava-server/ and didn't find the log specific for the reason of this. * Asked IRC channel and ask, answered by codehelp(thanks:)). Then tried to replace my device-type config in /etc/lava-server/dispatcher-config/device-types with x86.jinja2 and the error message is the same. Any input would by much appreciated, thank you. Regards, -Michael Chen

9 years, 2 months

2
2
0 0

Lava debian stretch repo

by Sharma, Varun

Hi Lava Team, I am using Lava image on debian stretch from https://images.validation.linaro.org/production-repo stretch-backports main & in It chart/query api is working. Then I took latest code from lava release branch https://github.com/Linaro/lava-server/commits/release to my local branch Tag taken :- c0b431f1b56227f6b97ba0e7859bfcc3fb29b62f refs/tags/2017.7 & build it but Lava charts is not coming when I run lava server["python manage.py runserver"] using latest code from git?? Can you please share where is latest code being used in debian stretch located? Thanks, Varun

9 years, 2 months

2
1
0 0

Is it possible to request a device by using device name

by Arthur She

Hi, In LAVA v1, as I remember, I can use either "device" or "device_type" to request a device for the test. If I use "device", for example "device": "beaglebone-black03", then the specific device, beaglebone-black03, will be used for the test. Can I do the same thing in LAVA v2? To request a device by using device name? Thanks, Arthur

9 years, 2 months

3
9
0 0

Jobs stuck in canceled mode and blocking queue

by Robert Marshall

Hi, I've got 2 jobs stuck in canceled mode which are preventing any other job from running. I'm running lava (2017-7) in a VM and have tried rebooting the VM to clear the issue but without success (ie the jobs still block the queue). an extract from /var/log/lava-server/django.log is attached I get this 500 error when viewing the results for the job Is there a manual way of clearing this? The health check has notification associated with it (and set to verbose) and every time I reboot I get an email and irc saying that it's finished! Robert

9 years, 2 months

2
6
0 0

NFSroot problems

by Benjamin Auclair

Hi everyone, I'm implementing the nfsroot for my devices but it seems that when extracting my rootfs.tar.xz lava keep the parent folder rootfs and didn't extract all the files in extract-nfsrootfs-XXXXX so that the lava test overlay is putting outside of rootfs folder and raises an error during execution. Is there a way in job definition to ask lava to put the test overlay in the rootfs folder ? Thanks Benjamin AUCLAIR -- - Confidential -

9 years, 2 months

2
1
0 0

Stuck in lava-test-shell

by Benjamin Auclair

Hi everyone, hope you're fine ! I'm quite stuck in my platform development: indeed, I succedded in adding my own device type, I'm able to boot on linux by TFTP and to perform auto-login actions. However, I face difficulties with test-shell. I have the following error: https://pastebin.com/grPcvb14 And the definition of stage is: https://pastebin.com/ArV11Gbb Stage value seems to be none and I also realized that my test shell isn't downloaded from git during server processing. Thus I think, that stage is empty because the test shell definition isn't in the temporary files. Am I wrong ? Even if I think I found my problem, I don't know how to solve it, may it be due to my device-type config ? Thanks a lot and have a nice day ! Benjamin AUCLAIR -- - Confidential -

9 years, 3 months

3
5
0 0

Could not set UBOOT_AUTOLOAD_MESSAGE variable while Adding BBB on LAVA server

by ankit gupta

Hi All, I am adding BBB board on LAVA server I want to change "UBOOT_AUTOLOAD_MESSAGE" in constant.py, I used "interrupt_prompt" parameters in job submission but it took the message written in constant.py. If I changed the message in constant.py its working but I know this is not the right way to do that, Please suggest if any one has idea what is the problem with me. Below is the my Job: device_type: beaglebone-black # NFS fails on panda and arndale. job_name: BBB smoke test timeouts: job: minutes: 240 action: minutes: 240 connection: minutes: 2 priority: medium visibility: public metadata: source: https://git.linaro.org/lava-team/refactoring.git path: health-checks/beaglebone-black-health.yaml build-readme: http://images.validation.linaro.org/snapshots.linaro.org/components/lava/st… build-console: https://ci.linaro.org/view/lava-ci/job/lava-debian-armmp-armhf/1/console build-script: http://images.validation.linaro.org/snapshots.linaro.org/components/lava/st… actions: - deploy: timeout: minutes: 40 to: tftp kernel: url: file:////home/pi/lava/dl/vmlinuz ramdisk: url: file:////home/pi/lava/dl/initramfs.cpio.gz compression: gz # the bootloader needs a u-boot header on the modified ramdisk add-header: u-boot modules: url: file:////home/pi/lava/dl/modules.tar.gz compression: gz nfsrootfs: url: file:////home/pi/lava/dl/jessie-armhf-nfs.tar.gz compression: gz os: debian dtb: url: file:////home/pi/lava/dl/am335x-boneblack.dtb - boot: method: u-boot commands: nfs parameters: shutdown-message: 'INIT: Sending processes the TERM signal' interrupt_prompt: 'Press SPACE to abort autoboot in 10 seconds' interrupt_char: ' ' send_char: False type: bootz auto_login: login_prompt: 'beaglebone login: ' username: root prompts: - 'root@jessie:' timeout: minutes: 10 - test: timeout: minutes: 50 definitions: - repository: git://git.linaro.org/qa/test-definitions.git from: git path: ubuntu/smoke-tests-basic.yaml name: smoke-tests

9 years, 3 months

3
6
0 0

mount worker host directory to LXC instance

by Chetan Sharma

Hi Lava Team I am trying to mount a directory of worker (host computer) to LXC instance running on it with job. I have added this entry in lxc default configuration file of worker computer. Default Configuration file path is : /etc/lxc/default.conf Entry is :- lxc.mount.entry = /var/lib/nfsdir var/nfsmnt none bind,create=dir 0 0 After restart lxc service. I executed lava job then this directory "/var/lib/nfsdir" of worker machine is not mounting on LXC instance in directory "/var/nfsmnt". But if i manually create and start lxc instance on worker, then this directory "/var/lib/nfsdir" of worker machine is mounted on LXC instance. Can anyone assist me on this issue, that how i can resolve this issue. -- Thanks & Regards Chetan Sharma

9 years, 3 months

2
3
0 0

LXC share data with DUT

by Chetan Sharma

Hi Lava Team Can you assist me on this usecase that how i can share LXC data with DUT. We have LXC and DUT TEST defined in a Job. LXC Tests generates some data and logs which is required to be accessed by DUT TEST. -- Thanks & Regards Chetan Sharma

9 years, 3 months

4
3
0 0

Installing LAVA on Stretch

by Neil Williams

There are delays getting packages into stretch-backports, as expected. In the meantime, this is a reminder of how to use backports: first start with stable. So when installing LAVA on Stretch, even if what you want is the latest release from production-repo or staging-repo (currently 2017.7), then your first step is to install 2016.12 from Stretch. # apt -y install lava-server # apt -y install vim # wget http://images.validation.linaro.org/production-repo/production-repo.key.asc # apt-key add production-repo.key.asc # vim /etc/apt/sources.list.d/lava.list # # edit the file to specify: deb http://images.validation.linaro.org/production-repo jessie-backports main Yes, that is jessie-backports - we don't have packages in stretch-backports at this time. # apt update # apt upgrade If you specify backports too early, you'll get a range of other packages from backports - you don't actually need jessie-backports or stretch-backports from Debian at this time. Packages for jessie-backports are built on jessie. Packages for stretch-backports are built on stretch. It's the same source code in each case. Right now, there aren't any problems with installing from jessie-backports on stretch - particularly if you install lava-server from stretch in the first place so that the majority of your packages come from stretch. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

9 years, 3 months

2
2
0 0

Facing issue while installing LAVA 2016.6

by ankit gupta

Hello LAVA Users, I want to install LAVA version 2017.6 or 2017.7 on debian-9 (Stretch), I followed the instruction given on https://staging.validation.linaro.org/static/docs/v2/installing_on_debian.h… For this I added production repo in my *sources.list* file, the content of my sources.list is given below. *deb http://ftp.us.debian.org/debian/ <http://ftp.us.debian.org/debian/> stretch main* *deb-src http://ftp.us.debian.org/debian/ <http://ftp.us.debian.org/debian/> stretch main* *deb http://security.debian.org/debian-security <http://security.debian.org/debian-security> stretch/updates main* *deb-src http://security.debian.org/debian-security <http://security.debian.org/debian-security> stretch/updates main* *deb http://ftp.us.debian.org/debian/ <http://ftp.us.debian.org/debian/> stretch-updates main* *deb-src http://ftp.us.debian.org/debian/ <http://ftp.us.debian.org/debian/> stretch-updates main* *deb http://ftp.fr.debian.org/debian <http://ftp.fr.debian.org/debian> stretch-backports main* *deb https://images.validation.linaro.org/production-repo <https://images.validation.linaro.org/production-repo> sid main* After this I run *"apt-get update" & "apt-get install lava-server"*, This command is given me error as given below. *root@debian:/home/debian# apt-get install lava-server* *Reading package lists... Done* *Building dependency tree * *Reading state information... Done* *Some packages could not be installed. This may mean that you have* *requested an impossible situation or if you are using the unstable* *distribution that some required packages have not yet been created* *or been moved out of Incoming.* *The following information may help to resolve the situation:* *The following packages have unmet dependencies:* * lava-server : Depends: lava-dispatcher (>= 2017.5) but it is not going to be installed* * Recommends: lava-coordinator but it is not going to be installed* * Recommends: lava-server-doc but it is not going to be installed* *E: Unable to correct problems, you have held broken packages.* I tried *staging repo* as well and also *jassie-backports* but couldn't proceed, Please anyone have some ide what going wrong in my case and how I can resolve this issue. My main objective is to install *LAVA 2017.6/2017.7* on my debian stretch. Thanks, Ankit

9 years, 3 months

2
1
0 0

Enable interface in LXC to access internet inside LXC

by Chetan Sharma

Hi Lava Team, Can anyone assist me with these 2 quires as 1. Can we enable interface inside LXC to access host network, so that we can access any device on network of host machine and can access internet inside LXC to execute script. 2. Can we pass Params in Lava job, which can propagate to lava-test-action job or yaml. If possible can you guide me with process to perform this action ? share a reference job which perform this task. -- Thanks & Regards Chetan Sharma

9 years, 3 months

2
1
0 0

Lava V2: Multinode with Linux PC?

by Denis HUMEAU

Dear all, Do you have any example or recommendation on the way to implement the following use case in Lava? DUT under Linux A PC under Linux to use as a "server" for VLC or iPerf test cases I guess Multinode can be used to manage these use cases, but I don't know how to deal with the constraints linked to the PC: no reboot, no dedicated test kernel. Thanks, Denis

9 years, 3 months

3
2
0 0

Re: [Lava-users] how to start QEMU environment variables

by Jan-Simon Möller

Hi Neil, Kevin ! > On 20 July 2017 at 02:57, Kevin Hilman <khilman at baylibre.com> wrote: > > Hello, > > > > There are many configurable options when starting QEMU that are > > controlled by environment variables, and I'm trying to figure out how to > > pursuade LAVA v2 to set them. > > It's not something which should be done with the QEMU device type > because that is installed on the worker - it is not a device that can > be reconfigured to suit test writers and much of the functionality of > QEMU must remain off-limits when QEMU is running on the worker. > > > As an example, configuring the host audio driver used by QEMU is set by > > running QEMU with: QEMU_AUDIO_DRV=<option> qemu-system-x86_64. > > The worker is typically a server, it might not have any audio support. > Even if it does, that functionality is off-limits to test writers. The > available options to QEMU must be tightly constrained to protect other > tasks on the worker. A see. There is a valid point here in that there should not be control of the environment from the 'outside' though a job description. > > > Unfortunately, device-types/qemu.jinja2 doesn't provide anyway to > > override the qemu-system binary used (it's conditional based on arch), > > This is deliberate, to protect the worker from aberrant processes and > to give the admins sufficient control over how the worker behaves. Now for the above case: QEMU_AUDIO_DRV=<option> qemu-system-* I see this as a *very valid env var* for a server-side deployment - exactly as you said - a server does not have a sound card and QEMU_AUDIO_DRV=none is what we need to use there to prevent qemu from looking for a host sound card. We should even set this by default - we don't expect any sound to reach the worker - do we ;) ? I don't think so. IMHO this should be an option set on the worker node in the lava- dispatcher.conf (e.g. LAVA_EXTRA_QEMU_ENV="QEMU_AUDIO_DRV=none"). Enable the admins to choose this. > > No. This is not something that the worker can support. It needs to > happen only on a test device. The worker is not itself a test device. As I said, I think this belongs to the worker setup and we should enable the admins to make their choice. Dipl.-Ing. Jan-Simon Möller jansimon.moeller(a)gmx.de

9 years, 3 months

3
6
0 0

how to start QEMU environment variables

by Kevin Hilman

Hello, There are many configurable options when starting QEMU that are controlled by environment variables, and I'm trying to figure out how to pursuade LAVA v2 to set them. As an example, configuring the host audio driver used by QEMU is set by running QEMU with: QEMU_AUDIO_DRV=<option> qemu-system-x86_64. Unfortunately, device-types/qemu.jinja2 doesn't provide anyway to override the qemu-system binary used (it's conditional based on arch), but even a quick hack to allow it to be overriden[1], and adding the env as a prefix didn't because LAVA assumes the first item is an actual binary expected in $PATH. My attempt led to: Invalid job definition Cannot find command 'QEMU_AUDIO_DRV=none qemu-system-x86_64' in $PATH Seems like there should be a more general way to pass enviornment variables to QEMU that I must be missing. If there's not, would be the recommended way to add this feature? Kevin [1] diff --git a/lava_scheduler_app/tests/device-types/qemu.jinja2 b/lava_scheduler_app/tests/device-types/qemu.jinja2 index 786f53bdb30d..e7c265a3048b 100644 --- a/lava_scheduler_app/tests/device-types/qemu.jinja2 +++ b/lava_scheduler_app/tests/device-types/qemu.jinja2 @@ -41,7 +41,7 @@ actions: {% elif arch == 'arm' %} qemu-system-arm {% elif arch == 'amd64' or arch == 'x86_64' %} - qemu-system-x86_64 + {{ qemu_command|default('qemu-system-x86_64') }} {% elif arch == 'i386' %} qemu-system-i386 {% endif %} With that change, I added context: qemu_command: "QEMU_AUDIO_DRV=none qemu-system-x86_64" to the job definition

9 years, 3 months

2
1
0 0

How to expose device path like '/dev/ttyUSB0' to LAVA-LXC?

by Li, Yifan2

Hello LAVA experts, Is it possible to expose a device path like '/dev/ttyUSB0' to lxc in job definition or device definition? I have a feature requirement to control a relay card inside LAVA lxc. I have got clues for device_info and read https://validation.linaro.org/static/docs/v2/lava-scheduler-device-dictiona… and https://validation.linaro.org/static/docs/v2/admin-lxc-deploy.html?highligh…. However I did not know how to use it to expose '/dev/ttyUSB0' to LXC. Thanks and Best Regards, Yifan

9 years, 3 months

2
3
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users