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

by Nagendra Singamsetti

Hi Team, Hi Team, Thanks for giving kind support. We are booting *ARM-cortexM targets* using lauterbach - trace32 debugger. http://www.embeddedindia.com/lauterbach-gmbh.html I would like to know *lauterbach** -trace32 debugger support* in lava If support is available, Please share me the supported Device-type jinja file or share me the reference file. Please let me know anything required from my side. I am looking forward your kind support thanks Regards Nagendra S

6 years, 1 month

2
3
0 0

Default lava-slave went offline

by Nagendra Singamsetti

Hi Team, Today i have started working with remote worker. But In Lava-server Admin page i have noticed that default lava-worker went office where as remote worker operations are working fine as expected. 1. Is this expected behavior ?? On command prompt i can see lava-slave status as Online [image: default_worker_onserver_command_line showing_online.png] Where as On webpage it is showing offline: [image: default_worker_onserver_webpage_status_offline.png] The devices connected to default worker also showing offline. 2. Can we rename hostname for remote worker?? Thanks !! Regards Nagendra S

6 years, 1 month

1
0
0 0

Question about Docker feature for Android testing.

by Larry Shen

Hi, guys, I have a question after listen Docker feature for Android testing<https://linarotechdays.sched.com/event/ZZFc/ltd20-103-improved-android-test…>, and the question is a little long. 1. I want to say sorry that I haven't ever tried it on android because currently not urgent for us to switch from lxc to docker. But my real question is related to this feature at least I think. 2. The whole story is: We have a device which use the "tftpboot(deploy) -> nfs(boot) -> shell(test)" mode to test, that's ok. But now we have a team which for their testcases, they need to define other logic which behavior totally different with current lava solution. There is legacy code on pc which we want to reuse, so the quicker way for us is to use docker device, in it we could do anything to control the device. What we tried is: - Deploy (to: docker) - Boot (method: docker) - Test It's ok, as you see we could use the connection from boot in test. But as you know, not all device type accepts docker actions. Then, I find the option after you give the presentation in linaro tech share, use docker test. 3. I tried the v2020.02 release, it's ok to use next with any device type in our job to do my things. - test: docker: image: ubuntu:18.04 Although some android related log printed like "- ANDROID_SERIAL='xxx'", but I can bear. 4. Things broken when you improve this feature in v2020.04, you add next in pipeline: WaitDeviceBoardID(self.get_board_id() Then, the pipeline will have to wait for a udev event, but in our case, we don't have, we control device with "remote telnet device", then job hang. 5. So, my question here is: "What's the roadmap of this docker test action"? a) Is it just for android scenario? b) Why we can't make it works for more common scenario? My opinion here is: with this docker test action, we even no longer need the old "docker deploy + docker boot"? c) For this docker test, most of docker operation was written fixed in docker test, if possible to add in some place which user could configure? Like, if I want to add "-t", I can't control that although you define the interface in "DockerRun" with "def tty(self):", and others like more docker bind mounts etc? 6. BTW, a side question related to android (As definitely someday we need to switch from lxc to docker, I use this chance to ask the question). What will happened if there is adbd restart or pdu reboot in "docker test"? You add "-device" for the usb bus (I'm not sure, just think it same way as lxc), but during adbd restart or pdu reboot, the usb bus will surely changes. I didn't see docker has such kinds of ability to renew the "-device". How would that happen? Sorry again, I haven't tired, just want to know the mechanism. 7. Anyway, currently what I care about is the roadmap of "docker test". If your final direction is to make the "docker test" more common, then we are OK currently "STICK ON 2020.02". If just for android & "WaitDeviceBoardID" had to be here without any control by user, then we will give up this solution & try to find another way to reuse the device in LAVA? Your direction matters our next step! 8. Finally, Any other suggestion for our scenario which I described in item 2? Regards, Larry

6 years, 1 month

2
6
0 0

Question about uboot action retry and timeout?

by Larry Shen

Hi, I have a question related to uboot boot action's retry settings, our job is: - boot: failure_retry: 2 namespace: test_suite_1 connection-namespace: burning-uboot_1 method: u-boot commands: nfs auto_login: login_prompt: '(.*) login:' username: root prompts: - 'root@(.*):~#' timeout: minutes: 10 1. From the code: "UBootAction" extends from a RetryAction, while in its internal pipeline, there is action named "UBootRetry" which also extends from RetryAction. If we define a "retry", when exception happened in "RetryAction", it will first cause "UbootRetry" to retry, then "UBootAction" to retry again. Sounds confuse, I wonder for what reason we should had a nested retry here? 2. In fact the real issue here for us is next: Let's suppose we define failure_retry: 2, our situation is: 1) First boot timeout for some random block issue. 2) Then, it start Retrying: 4.4 uboot-retry (599 sec), but timeout again. 3) Then, it start Retrying: 4 uboot-action (599 sec), but timeout again. 4) Then, it start Retrying: 4.4 uboot-retry (599 sec), this time a lucky boot here, but before we are happy, it finish the last action "export-device-env" in uboot-retry. Then, looks like "UBootAction" timeout resume, then the lucky boot becomes useless although it's in fact successfully boot. The log is: start: 4.4.5 expect-shell-connection (timeout 00:07:23) [test_suite_1] Forcing a shell prompt, looking for ['root@(.*):~#'] root@imx8mnevk:~# expect-shell-connection: Wait for prompt ['root@(.*):~#'] (timeout 00:10:00) Waiting using forced prompt support. 299.9747439622879s timeout end: 4.4.5 expect-shell-connection (duration 00:00:00) [test_suite_1] start: 4.4.6 export-device-env (timeout 00:07:23) [test_suite_1] end: 4.4.6 export-device-env (duration 00:00:00) [test_suite_1] uboot-action timed out after 727 seconds end: 4.4 uboot-retry (duration 00:02:07) [test_suite_1] I'm not sure, but looks like: for second "uboot-action", there is two "uboot-retry" inside it because of "retry", which will make when "uboot-action" timeout resume, the time diff becomes less than 0, which directly raise exception? Is it a bug or I misunderstand it? duration = round(action_max_end_time - time.time()) if duration <= 0: signal.alarm(0) parent.timeout._timed_out(None, None) Any suggestion for this?

6 years, 1 month

2
4
0 0

v2020.02: job definition for fastboot on the host via docker

by Stephen Lawrence

Hi, I have some questions about the new adb/fastboot support in LAVA 2020.02 described in the recent Tech Days LAVA presentation [1]. Main initial use cases are Android boot test, before moving on to running Android tests. Android is AOSP 9/10. [1] https://connect.linaro.org/resources/ltd20/ltd20-304/ Taking the boot test use case I was looking at Antonio's Example 1 from his presentation for fastboot deploy, boot and test. I found doc for test in the 2020.02 release note but nothing I could see for deploy or boot. In the LXC approach a typical job definition would have had target and host namespaces, with deploy and boot for the host space to create and boot the LXC container. Looking at Example 1 deploy from the presentation it looks like that is a largely a target fragment as it contains the image binary etc. A host deploy no longer being required as the Docker container is now created outside lava. Similarly the Example 1 boot looks like a target fragment and host boot fragment is not required as LAVA simply needs to run the specified Docker container. Then finally in Example 1 test the scope is the specified docker container so no namespace is required. Is my interpretation of the Example 1 slides correct? I tried some fragments that were causing fundamental errors that caused me to check here. Although as is often the case writing it out helps you get it straighter in your mind. If you have reasons to want to control fastboot for the flashing on the host is that possible? For example if you had the host side process scripted. Does the fastboot Docker OS need to be specified? I'm running 2020.02 on the Worker via lava-docker, with Docker support within the Worker container by sharing the host Docker socket to gain access to the Docker daemon. Regards Steve

6 years, 1 month

2
1
0 0

job error with new fastboot in docker support

by Stephen Lawrence

Hi, I'm trialling the fastboot support in Docker introduced in LAVA v2020.02 and getting a fundamental job error about the deploy action of the job definition. I've checked against the examples from the recent Linaro Tech Day LAVA presentation but I can't see the source of the error. Could someone familiar with this new support please take a look at the job definition please? I'm thinking it must be something obvious. Error snippet: error_msg: None of the deployment strategies accepted your deployment parameters, reasons given: overlay: "to" parameter is not "overlay" docker: 'docker' not in the device configuration deploy methods download: "to" parameter is not "download" qemu-nfs: Full error: https://lava.genivi.org/scheduler/job/718 Job definition: https://lava.genivi.org/scheduler/job/718/definition One possible cause I can think of is that the LAVA Worker is running 2020.02, whilst the Server is running 2019.03+stretch. My assumption is that the job definition parsing occurs in the dispatcher but maybe that is not correct? The Server will be upgraded to match the Worker of course, but we took a two step approach whilst we first looked into Android support. Thanks for any help, Steve

6 years, 1 month

2
4
0 0

Lava Server setup Issue

by Nagendra Singamsetti

Hi Team, I have recently installed lava server (master) in my Debian machine. My goal is to configure lava-server with *master- multiple workers* *Lava-server : Master* *[PFA] Debian configuration *: root@LavaServer:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster Now i am trying to setup multiple workers on other machine: Q : *Can i configure/Install the worker on different Operating System other than Debian ??* If [No], please describe the process or share the useful Doc thanks Regarding Nagendra S

6 years, 1 month

3
3
0 0

Lava-Lab "Master" and "Dispatcher" servers configuration details

by koti koti

Hi, initially we have plan to connect 5 boards to my lava-master and lava-dispatchers. Please can some let me know servers configurations for this setup as mentioned below? a. Can you let me know the LAVA master server configuration ? ( Processor/DDR/memory etc... configurations details) b. Can you let me know the Dispatcher server configuration ? (Processor/DDR/memory etc...configuration details) . ( I guess Dispatcher server configuration may be less than Master server configuration) c. PDU (I guess initial we have plan to connect 5 targets) . (If possible please can you share me the Amazon link to orfer) d. Serial port hub . (I guess initial we have plan to connect 5 targets) . (If possible please can you share me the Amazon link to order) Regards, Koti

6 years, 1 month

2
3
0 0

Audit log for user action?

by Larry Shen

Hi, there, If lava in some place possible to find who cancel a job? Or use lavacli or manual cancel a job? Or for which detail reason, the job was canceled? We are struggling to find why my job canceled sometimes, not sure someone not carefully do it or our external program by chance do it, especially when there are many people used the same master. Regards, Lary

6 years, 1 month

2
5
0 0

Question about send delay for serial.

by Larry Shen

Sometimes for some device, when lava enter "/lava-55904/bin/lava-test-runner /lava-55904/0" It looks it will print: -sh: /lava-55904/bin/lava-test-runnera-55904/0: No such file or directory Looks some character miss. We increases the test_character_delay, looks useful, but I'm interested about the details, so for next which you mentioned in the code: What exactly "slow serial problems(iPXE)" mean, could you explain more about it or any reference materteral I can had a look? Then I could know: yes, it's exactly the same problem I have. >>> Extends pexpect.sendline so that it can support the delay argument which allows a delay between sending each character to get around slow serial problems (iPXE). pexpect sendline does exactly the same thing: calls send for the string then os.linesep.

6 years, 1 month

2
2
0 0

About health check behavior?

by Larry Shen

Hi, there, Frequently, I found when a job becomes incomplete there will immediately a health check job on that device happen automatically to check the status of the device. But strange, some times I won't see that healthy check job. So, my question is: when I see that healthy check job, is it just by chance? Or it really designed that there will be a healthy check after incomplete job? Thanks. Regards, Larry

6 years, 1 month

2
4
0 0

"Where're my failed tests, dudes?"

by Paul Sokolovsky

Hello, I hope that the mail subject set up an easy, cheerful background for this discussion ;-). This definitely goes into the "stupid questions" department. My plan was to collect "evidence"/feedback from my colleagues, then at the Connect BUD20, crash into LAVA/QA rooms and ask what I/we are doing wrong. As circumstances changed, but the "testing debt" only builds up, there's little choice but to try figure out these matters over a much narrower pipe. So, before proceeding to the question per se, let me theorize that the reasons why such questions come up at all, are sufficient differences in the intended LAVA usage patterns. In other words, how I'd like to use LAVA on the LITE team side may differ from how LAVA team intends it to be used, or how QA team uses (the biggest user would it be). The issue? How I'd intend to use it is IMHO one the most basic ways to use a test system. So, what's that usage? Well, I'm not much interested in "interactive" use (submit jobs manually from my machine). Our interest is in unattended automated CI, of which the testing system is the second half after the build system. So let me remind how our build system, Jenkins, works. Normally, it just builds binaries and uploads them to a publishing server. It's invisible to me in this phase, and my engineering work goes uninterrupted. But when a build fails, I get an email with details about a failure. And I'll continue to get them while it continues to fail. So, the only option I have is to go see the failure, investigate, and fix it. When I arrive at Jenkins, I can easily see which jobs failed and which not, then within each job, see which builds failed and which succeeded. That's very easy, because failed things are red, and successful things are green. So, we've now arrived at the main question of this email - Why I don't seem to be able to use LAVA in the same way? Why LAVA offers only "Incomplete" and "Complete" job statuses? "Incomplete" is understood - it's an infrastructure failure, such a job is definitely "failed". But "Complete" doesn't give me any useful information whether the job succeeded or failed. Because a "Complete" job may still have any number of tests failed. And that's exactly the "last mile" LAVA misses to go: for any test job, I want to see a cumulative number of test cases which failed, straight at the page like https://lite.validation.linaro.org/scheduler/alljobs . Then, I'd like to filter out jobs which has this number >0. Then I'd like to receive a notification only for "failed" jobs, "failed" defined as "status != Complete OR failed_testcases > 0". So, what am I missing and how to make LAVA work like the above? Thanks, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

6 years, 2 months

4
15
0 0

2020.02: docker in docker support for fastboot docker deploy

by Stephen Lawrence

Hi, After the recent Linaro Tech Day LAVA presentation I have been looking into the new support in LAVA v2020.02 for deploying fastboot on the host to docker rather than lxc. I am running my lava worker in a docker image derived from the linaro lava docker images and so wanted to ask if the new feature supported docker in docker for the fastboot containerisation? Regards Steve

6 years, 2 months

2
2
0 0

Submit Job

by Nikolina nici_nigel

Hello, I just started working with hardware, firmware and lava. You have a big documentation, but for me it's sometimes difficult to find something. I wanted to submit a job on just one device like my "bbb-03" and not on every beaglebone-black. Is there a device-tag to choose a device like "device_type: "? My next question is if there is also a worker tag for a job submit? For example I just want to run all "beaglebone-black" on my "worker2". Is there also a list of all job submissions tags with examples? I just found the one for the "actions" part. I'm sorry for disturbing and maybe the stupid question. But thank you for your answer in advance. I wish you a nice day

6 years, 2 months

2
1
0 0

Delaying LAVA Release

by Remi Duraffort

Hello, As you know, we are trying to release a new version of LAVA every month. We are delaying this month release (2020.03) due to some issues and crashes that we found in the last days. Issues where found on staging.vlo, lavafed and meta-lava, proving that the CI is working. Where are currently working on fixing the issues and proving that LAVA is ready for release. The next release should be ready for the end of next week and would be called 2020.04. Rgds -- Rémi Duraffort LAVA Architect Linaro

6 years, 2 months

1
0
0 0

Confusion between LAVA job definition "name" vs UI "description"

by Paul Sokolovsky

Hello, I recently went "on a spree" to submit a number of LAVA UI issues either accumulated in my mind or just caught on exhaustive search for a feature I miss. They are at https://git.lavasoftware.org/lava/lava/-/issues?scope=all&author_username=p… and I believe all of them worth fixing (and don't bring in concerns like backward compatibility). So, they're up for triaging by the maintainers and feedback from the community to confirm they're indeed such. (Then, I'd be able to help with addressing them, as much as I can). There're more issues, about which I'm less sure. So, instead of submitting such as bugs, let me ask for a feedback in the email, starting with this one: When you prepare a job definition YAML to submit to LAVA, in it you something like: job_name: 'zephyr-net-ping #823-2ac65a24' It may be not immediately obvious, but what you had as a "job name" in the YAML, ends up as a "description" when you visit job list in the LAVA UI (E.g. at https://validation.linaro.org/scheduler/alljobs). "Is it that much of a difference? Most people wouldn't even notice!" you may think, and I can only second that. I for one never paid attention to that for on-and-off, mostly very light usage of LAVA for some 10 years (i.e. I started yet with the previous version which might look different at all). And indeed, it won't make any difference until may want to start querying job results. And I would like to share a story of what that difference costed me. Here's a patch I submitted in June 2017: https://git.linaro.org/ci/job/configs.git/commit/lite-aeolus/lava-job-defin… with a commit message and inline comment of: "For some reason, LAVA doesn't allow to query by real job name, so we need to duplicate it as metadata." Here's another patch which I submitted based on the analysis I present here: https://review.linaro.org/c/ci/job/configs/+/34677 So, for almost 3 years I lived with a misconception that LAVA can't query by a job name. Call it an extreme case. Call me dumb. Say that there's autocompletion for field names and any person with some agility of mind would type different characters and would notice "description" as available field. Yeah, I did all that. But I'm with me from 3 years ago: for me, "job name" is "zephyr-net-ping #823-2ac65a24". "job description" would be something like "Ping Zephyr dumb_http_server sample with packets of different size and interval". To the best of my knowledge, there's no such a field in jobdef YAML to include such a description, and I definitely don't include it in my jobs, so never would I try to search anything in "description", for the lack thereof in my jobs. Unless I have too much time to apply random "genetic algorithms" to LAVA UI or just do exhaustive search thru it. Which I usually don't have time for (I'm not a test engineer, but a developer, with "test that code" always in backlog). Until recently, when testing debt has really become pressing, and I decided to face all "skeletons in closed" I had with LAVA ;-). So, even 3 years haven't passed until I "did my homework" on searching jobs by name. But my point would be that there should be no need for any "homework" regarding these matters, it all should just work right away without double-thinking and guesswork. And I would consider this a genuine bug. I'm less sure about fixing though. Because it's not a matter of just changing a few UI labels. It's more pervasive, as e.g. this URL shows: https://lite.validation.linaro.org/results/query/+custom?entity=testjob&con… And seeing that URL, one can actually conjecture how that "description" appeared in the UI: it's actually name of the database table. Which just bled into system public interface. Too bad, because another public interface uses "job name" for that field, and internal naming like db fields shouldn't prevail. Anyway, I'm not going to argue that DB should be migrated, and it won't help, as we definitely don't want to break existing queries, etc. So, the only way to fix that would be to alias existing "description" to clearer "name" (or "jobname", "job_name"), and perform mapping on DB access. I'm note sure if it's worth. Based on my experience, I'd go for it, and it doesn't sounds like rocker science. But only maintainers could imagine how kludgy it would be in the actual LAVA database and if it's worth it, taking into account other tasks and priorities. Thanks for reading the story (rant?). -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

6 years, 2 months

3
3
0 0

Sample docker-compose.yml file to detect adb devices in "lava-dispatcher"

by koti koti

Hi, I am facing the issue while porting Host's "adb-devices" to lava-dispatcher docker. Please can some one provide the right steps to detect "adb-devices" in "lava-dispatcher" docker? Current steps: (still my lava-dispatcher fail to detect the Host's "adb-devices") ########### 1. Lauch the LAVA-lab using "docker-compose up" from the repo " https://github.com/danrue/lava-docker-compose.git" 2. add "/dev/bus/usb" , "/etc/udev/rules.d" and "privileged: True" to "lava-dispatcher" i.e " dispatcher: image: lavasoftware/lava-dispatcher:2019.12 container_name: lava_dispatcher privileged: True devices: - /dev/kvm # needed for QEMU - /dev/net/tun # needed for QEMU - /dev/bus/usb cap_add: - NET_ADMIN # needed for QEMU environment: - "DISPATCHER_HOSTNAME=--hostname=dispatcher" - "LOGGER_URL=tcp://server:5555" # url to send logs - "MASTER_URL=tcp://server:5556" # url of lava master volumes: - '/boot:/boot:ro' - '/lib/modules:/lib/modules:ro' - '/dev/bus/usb:/dev/bus/usb' - '/etc/udev/rules.d:/etc/udev/rules.d'" 3. Run the command #docker-compose up 4. Login to lava-dispatcher #docker exec -it <dispatcher-name" bash #apt-get update;apt-get install android-tools-adb android-tools-fastboot usbutils #adb devices Can some one let me know the steps to detect my host's "adb-devices" in lava-dispatcher's docker? Regards, Koti

6 years, 2 months

3
8
0 0

test/tests execution on provision (booted) board with out "-boot" section. (Basically I am skipping deploy and boot sections)

by koti koti

Hi, I am able to boot and run the tests with Provisioned(booted) board using attached YAML i.e "working_yaml.yaml". But, I am facing the issue while running the tests on Provisioned (booted) board with out "-boot" section. (you can see my YAML file as mentioned below which I have used now) Please can some one help me for the same? 1. Basically I am facing the connection issue with out "-boot" section. 2. Why this dependency to connect terminal for boot section ? ( I am able to connect serial port when I use "-boot" section in yaml file) 3. Please can some one provide me right YAML to run my tests with out "-boot" section. ( to resolve serial connection issue with out "-boot" section) " device_type: beaglebone-black job_name: begalbone healthcheck timeouts: job: minutes: 30 action: minutes: 15 connection: minutes: 5 priority: medium visibility: public context: test_character_delay: 10 actions: #- boot: # timeout: # minutes: 15 # method: minimal ## reset: false ## auto_login: ## login_prompt: '.* login:' ## username: root # prompts: # - root@dragonboard-410c:~# - test: interactive: - name: reset prompts: ["#"] script: - name: reset command: reset " Regards, Koti

6 years, 2 months

3
8
0 0

Re: [Lava-users] LAVA RESTful API feedback and plans (Stevan Radakovi?)

by Larry Shen

Interesting topic, one question: What will the new LAVA rest api look? a) or b) ? I wish it could b), then we could ease our master's pressure... a) Django-rest-framework alike, synchronous b) Tornado alike, asynchronous -----Original Message----- From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> On Behalf Of lava-users-request(a)lists.lavasoftware.org Sent: Wednesday, March 11, 2020 8:00 PM To: lava-users(a)lists.lavasoftware.org Subject: [EXT] Lava-users Digest, Vol 19, Issue 2 Caution: EXT Email Send Lava-users mailing list submissions to lava-users(a)lists.lavasoftware.org To subscribe or unsubscribe via the World Wide Web, visit https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lav… or, via email, send a message with subject or body 'help' to lava-users-request(a)lists.lavasoftware.org You can reach the person managing the list at lava-users-owner(a)lists.lavasoftware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Lava-users digest..." Today's Topics: 1. LAVA RESTful API feedback and plans (Stevan Radakovi?) ---------------------------------------------------------------------- Message: 1 Date: Wed, 11 Mar 2020 09:17:00 +0100 From: Stevan Radakovi? <stevan.radakovic(a)linaro.org> To: "lava-users(a)lists.lavasoftware.org" <lava-users(a)lists.lavasoftware.org> Subject: [Lava-users] LAVA RESTful API feedback and plans Message-ID: <34b9c19d-b0eb-2d85-0c85-a4e536a1812e(a)linaro.org> Content-Type: text/plain; charset="utf-8"; Format="flowed" Hello community, With the LAVA release of 2020.02 we now have a REST API framework that we fell covers all the functionalities of the already existing XMLRPC API. Since the long-term plan is to drop the XMLRPC support, we now encourage everyone to use REST and we also would like to hear feedback about any additional features that you'd like to see as part of the REST API. Our plan is to slowly move lavacli <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.lava…> project to use REST API exclusively, after that we will schedule the deprecation of the XMLRPC API. Cheers, -- Stevan Radakovi? | LAVA Engineer Linaro.org <https://eur01.safelinks.protection.outlook.com/?url=www.linaro.org&data…> ? Open source software for ARM SoCs

6 years, 2 months

3
4
0 0

How to change defalut "soft reboot" commands in LAVA

by koti koti

Hi, Right now I am trying to run tests on Provisioned(booted) board with out using physical Power switches . But, I am seeing below soft reboot lines while using the attached YAML file, " start: 1 minimal-boot (timeout 00:15:00) [common] start: 1.1 connect-device (timeout 00:15:00) [common] [common] connect-device Connecting to device using 'telnet ser2net 5001' end: 1.1 connect-device (duration 00:00:01) [common] start: 1.2 reset-device (timeout 00:14:59) [common] start: 1.2.1 send-reboot-commands (timeout 00:14:59) [common] No soft reboot command defined in the test job. Using defaults. reboot reboot reboot -n reboot -n reboot -nf reboot -nf " I want to change my soft reboot command as "reset" instead of "reboot"/"reboot -n"/"reboot -nf". Please can some one let me know as how can I change default soft reboot command to "reset" ? Regards, Koti

6 years, 2 months

3
8
0 0

LAVA tests execution on already provisioned (boot) begalbone board

by koti koti

Hi, I have successfully booted the Beagelbone board from " https://github.com/danrue/lava.therub.org" . (corresponding ymal is https://github.com/danrue/lava.therub.org/blob/master/server-overlay/etc/la… ) But, now I am trying to run one more scenario (may be new scenario and not sure is it supported by LAVA lab?) i.e 1. Run the tests on already provisioned (boot) beagelbone board. (Basically I am skipping the booting mentioned and trying to run on the already provisioned/boot board) a) boot the target b) Connect Board to LAVA lab c) Just check the login prompt ("#") is available or not? c) Run the using below test definition file (Basically this test definition file runs "ls"/"ifconfig" commands in the already provisioned(boot) board). " device_type: beaglebone-black job_name: beaglebone-black healthcheck timeouts: job: minutes: 10 action: minutes: 5 priority: high visibility: public actions: - test: interactive: - name: ls test prompts: ["#"] echo: discard script: - name: ls command: ls successes: - message: "ls simple test successes" failures: - message: "TIMEOUT" exception: InfrastructureError error: "ls command failed" - name: ifconfig command: ifconfig - name: wait for the prompt command: " I have tried to run this. But, my test failed with the error ""Connection closed"" (Attached screenshot) Can some one let me know solution to fix this error? Regards, koti

6 years, 2 months

3
3
0 0

LAVA RESTful API feedback and plans

by Stevan Radaković

Hello community, With the LAVA release of 2020.02 we now have a REST API framework that we fell covers all the functionalities of the already existing XMLRPC API. Since the long-term plan is to drop the XMLRPC support, we now encourage everyone to use REST and we also would like to hear feedback about any additional features that you'd like to see as part of the REST API. Our plan is to slowly move lavacli <https://docs.lavasoftware.org/lavacli/> project to use REST API exclusively, after that we will schedule the deprecation of the XMLRPC API. Cheers, -- Stevan Radaković | LAVA Engineer Linaro.org <www.linaro.org> │ Open source software for ARM SoCs

6 years, 3 months

1
0
0 0

Reboot inside test

by Ilya Fedusiv

Hi, lava team! First question: I'm working with fastboot device, is it possible after test part put device again to fastboot mode, run some fastboot command ( not to flash ), boot again, run test. job steps: 1. deploy lxc 2. boot lxc 3. test lxc 4. deploy fastboot ( put to fastboot ) 5. boot fastboot device 6. run test 7. reboot and put device to fastboot mode 8. run fastboot commands 9. continue run test. Can you give any advice how to do it? Better to able reboot device inside test. I tried to reboot device from test part, lava just stuck and wait when reboot action will end. But looks like it does not recognize end. Second question: In job have lxc namespace and device namespace, how to run command_action from host os, not lxc? Best regards, Ilya Feduisv

6 years, 3 months

2
1
0 0

Use user commands

by Ilya Fedusiv

Hi, Lava Team! Want to use user_commands as written here : https://validation.linaro.org/static/docs/v2/actions-command.html Device dictionary has : {% set user_commands = {'switch_mode' : {'do': './usr/local/scripts/switch_mode.sh'}} %} Job https://pastebin.com/hhWbC207 I have lxc and custom script to set device flash-mode. But have error error_msg: 'common' is a reserved namespace that should not be present with other namespaces To fix it I added namespace to command: - command: namespace: tlxc name: switch_to_qdl But error again in validate before submit Invalid definition: extra keys not allowed @ data['actions'][3]['command']['namespace'] I have fastboot and custom flash methods. pre_power_command in deploy I use for fastboot. Need to use somehow custom script to switch to another mode, that's why I decided to use -command action. Please help how to fix error with namespaces or suggest another solution. Best regards, Ilya Fedusiv

6 years, 3 months

2
3
0 0

Using "command" actions in multinode jobs

by Ryan Harkin

Hi LAVA folks, I'm trying to create a multinode job based on iperf.yaml: https://github.com/Linaro/test-definitions/blob/master/automated/linux/iper… (note, this iperf.sh test doesn't actually work as intended, but that's a problem I'm debugging). The full job definition is at the bottom of this email. Anyway, I'm adding my own deploy and boot sections, as per working single node jobs. However, my deploy uses "command" actions, like this: - command: role: - host - guest namespace: dfu-firmware name: set_boot_to_nand These give error messages like this: Invalid definition: extra keys not allowed @ data['actions'][1]['command']['role'] And if I remove the "role" settings, I get a different error: Valid definition with warnings: Every action of a multinode job should have roles So it seems like I'm in a loop. Any suggestions?? Thanks, Ryan. ------------------------------------------------------ JOB DEFINITION ------------------------------------------------------ job_name: lces2-iperf timeouts: job: minutes: 60 action: minutes: 3 connection: minutes: 5 priority: medium visibility: public metadata: iperf-version: v3 protocols: lava-multinode: roles: host: device_type: rzn1d count: 1 timeout: minutes: 30 guest: device_type: rzn1d count: 1 timeout: minutes: 30 actions: #################### # Deploy QSPI images #################### - deploy: role: - host - guest namespace: dfu-firmware to: tmpfs images: sf_fsbl: image_arg: --alt sf_fsbl --download {sf_fsbl} url: https://snapshots.linaro.org/openembedded/schneider/linaro-warrior-4.9/rzn1… sf_trustedfw: image_arg: --alt sf_trustedfw --download {sf_trustedfw} url: https://snapshots.linaro.org/openembedded/schneider/linaro-warrior-4.9/rzn1… sf_uboot0: image_arg: --alt sf_uboot0 --download {sf_uboot0} url: https://snapshots.linaro.org/openembedded/schneider/linaro-warrior-4.9/rzn1… sf_uboot1: image_arg: --alt sf_uboot1 --download {sf_uboot1} url: https://snapshots.linaro.org/openembedded/schneider/linaro-warrior-4.9/rzn1… - command: namespace: dfu-firmware role: - host - guest name: set_boot_to_nand - boot: namespace: dfu-firmware role: - host - guest method: dfu timeout: minutes: 10 - command: namespace: test role: - host - guest name: set_boot_to_qspi ############### # TFTP/NFS ############### - deploy: namespace: test-nfs role: - host - guest timeout: minutes: 5 to: tftp os: oe kernel: url: https://snapshots.linaro.org/openembedded/schneider/linaro-warrior-4.9/rzn1… type: zimage dtb: url: https://snapshots.linaro.org/openembedded/schneider/linaro-warrior-4.9/rzn1… nfsrootfs: url: https://snapshots.linaro.org/openembedded/schneider/linaro-warrior-4.9/rzn1… compression: bz2 - boot: namespace: test-nfs role: - host - guest connection-namespace: dfu-firmware timeout: minutes: 20 method: u-boot commands: - setenv autoload no - dhcp - dhcp - env print - setenv serverip {SERVER_IP} - tftp {KERNEL_ADDR} {KERNEL} - tftp {DTB_ADDR} {DTB} - setenv bootargs 'console=ttyS0,115200n8 root=/dev/nfs rw nfsroot={NFS_SERVER_IP}:{NFSROOTFS},tcp,hard,intr,vers=3 rootwait coherent_pool=2M ip=dhcp' - '{BOOTX}' auto_login: login_prompt: 'login:' username: root prompts: - 'root@snarc-soca9:' - 'root@rzn1-snarc:' - test: namespace: test-nfs role: - host timeout: minutes: 30 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: run-iperf3-server description: "Run iperf3 in server mode" run: steps: - apt-get -y update - apt-get -y install iperf3 - if iperf3 -s -D; then lava-test-case run-iperf3-server --result 'pass'; else lava-test-raise 'Failed to run ipef3 server'; fi - lava-send server-ready ipaddr=$(lava-echo-ipv4 eth0) - lava-wait client-done - pkill iperf3 from: inline name: run-iperf3-server path: inline/run-iperf3-server.yaml - test: namespace: test-nfs role: - guest timeout: minutes: 30 definitions: - repository: https://git.linaro.org/people/chase.qi/test-definitions.git from: git path: automated/linux/iperf/iperf.yaml name: iperf3-test parameters: SERVER: lava-host-role # The MSG ID and KEY should be the same as the ones sent by lava-send above MSG_ID: server-ready MSG_KEY: ipaddr

6 years, 3 months

2
3
0 0

Re: [Lava-users] Unable to boot target via ipxe using nfs and tftp protocol via lava-docker container

by admirer mishra

Hi, I found the solution, we have to mount dispatcher.yaml file from lava-server in lava-master container as well beacuse lava-master is the one who communicate with DUT and run the job. regards admirer mishra

6 years, 3 months

1
0
0 0

Re: [Lava-users] Unable to boot target via ipxe using nfs and tftp protocol via lava-docker container

by admirer mishra

Hi Stevan, I am using latest lava-docker containers 2020.01 so using rest api I set the dispatcher ip and post it, which creates a dispatcher.yaml file with the content dispatcher_ip: '141.64.81.191' (not my ip) I checked it's there in the directory (/etc/lava-server/dispatcher.d/lava-dispatcher/dispatcher.yaml), but still no change in SERVER_IP or NFS_SERVER_IP (everything is same) while running the job, due to which not able to do tftp. I even tried with restarting the lava-server but still no change. Thanks for your time. regards, admirer mishra

6 years, 3 months

2
1
0 0

Unable to boot target via ipxe using nfs and tftp protocol via lava-docker container

by admirer mishra

Hi there, Yesterday, while going through the mail, I found about the docker-compose file provided by lava. The script is amazing it gives even more understanding of how actual lava-server and dispatcher work. I am a complete beginner just working on lava and docker from last 20 days. So, I am trying to boot a x86 device via ipxe using nfs and tftp protocol. In normal lava server running on host everything works fine because the host ip and target ip are on same local network so tftp and nfs works fine. But docker uses internal network and target is on local network so how to configure so that it works? I also used the docker compose file but the problem still persists. Is there any other configuration in the containers that I have to do make it work? Please help I am complete newbie in this field. Thanks for your time admirer mishra

6 years, 3 months

2
1
0 0

Lava Dispatcher Docker container tftp issue

by ROSHAN KUMAR

Hi, I am using the docker-compose file provided by lava community. I don't understand why there is a separate tftpd container and also how my device who is on host local network will communicate with it. Also same things I don't understand for nfs container. Please let me know Thanks and regards ROSHAN KUMAR

6 years, 3 months

3
3
0 0

Lava Server Docker container not working as Dispatcher

by ROSHAN KUMAR

Hi, I created a lava server docker container on amd64 machine using lavasoftware/lava-server docker image present on docker hub. But after running the container I didn't find any Dispatcher online except lava-logs. Did the current version of lava server docker container doesn't work as dispatcher similar to normal lava server. Please let me know. Thanks and regards ROSHAN KUMAR

6 years, 3 months

2
1
0 0

Mix device's type

by Ilya Fedusiv

Hi! I want to mix two flashing types for device : fastboot and custom ( run custom script ) I already did both types separately using deploy methods : fastboot and flasher How I can mix both types? And in web gui in device panel what does mean that error? Configuration Error: missing or invalid template. Jobs requesting this device type (mix-type) will not be able to start until a template is available on the master. Best regards, Ilya

6 years, 3 months

2
1
0 0

Dropping apache2 from lava-server container

by Remi Duraffort

Hello everyone, if you follow the latest developments, you might have seen that LAVA is now using whitenoise to allow gunicorn to serve static files. In the current releases (2020.01 and before), apache2 is forwarding dynamic requests to gunicorn and serving static files himself. In the next release, apache2 will forward all the requests to gunicorn that will serve both dynamic and static content. If you use the debian packages, apache2 will still be installed and configured automatically. We are proposing to drop the apache2 packages from the lava-server docker container. In fact, if you use the docker container, you have anyway to setup a reverse proxy to make the container visible to the outside world and to do the SSL termination. What do you think about this? Rgds -- Rémi Duraffort LAVA Architect Linaro

6 years, 3 months

2
3
0 0

Re: [Lava-users] Upgrade LAVA

by Remi Duraffort

The slaves/worker logs are in /var/log/lava-dispatcher/lava-slave.log Le mar. 11 févr. 2020 à 12:37, dhanu msys <dhanuskd.palnati(a)gmail.com> a écrit : > Hi Remi, > > After upgrading the LAVA Package , I have seen Worker Status show > "Offline". > > As per Earlier Experience , I have check the Lava-Logs and Lava-Master > Logs under /var/log/lava-server/lava-logs.log and > /var/log/lava-server/lava-master.log , it seems both are running fine > without any error. > > And also I have checked the Encryption in the both lava-master & lava-logs > under /etc/lava-server/lava-logs & /etc/lava-server/lava-master. PFA. > > Please check the attachment logs once and let me know if any changes need > to be done specific to the latest lava package. > > Thanks & Regards, > Dhanunjaya. P > > > On Wed, Feb 5, 2020 at 6:59 PM dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > >> Hi Remi, >> >> Thanks for sharing the Information. >> >> I can able to update the LAVA Package. >> >> Please find the latest packages list in below. >> >> doclava-aosp/stable 6.0.1+r55-1 all >> klavaro/stable 3.03-2 amd64 >> lava-common/unknown,now 2020.01+10+buster all [installed] >> lava-coordinator/unknown 2020.01+10+buster all [upgradable from: 0.1.7-1] >> lava-dev/unknown 2020.01+10+buster all [upgradable from: 2019.01-5] >> lava-dispatcher-host/unknown,now 2020.01+10+buster all >> [installed,automatic] >> lava-dispatcher/unknown,now 2020.01+10+buster all [installed] >> lava-lxc-mocker/unknown 2020.01+10+buster all >> lava-server-doc/unknown 2020.01+10+buster all [upgradable from: 2019.01-5] >> lava-server/unknown,now 2020.01+10+buster all [installed] >> lava-tool/stable,now 0.25-2 all [installed] >> lava/unknown,now 2020.01+10+buster all [installed] >> lavacli/unknown 0.9.7+buster all [upgradable from: 0.9.5-1] >> lavapdu-client/stable,now 0.0.5-1 all [installed] >> lavapdu-daemon/stable,now 0.0.5-1 all [installed] >> r-cran-lava/stable 1.6.4-1 all >> r-cran-lavaan/stable 0.6.3-1 all >> >> Thanks for immediate support. >> >> Regards, >> Dhanunjaya. P >> >> >> On Wed, Feb 5, 2020 at 3:55 PM Remi Duraffort <remi.duraffort(a)linaro.org> >> wrote: >> >>> Hello, >>> >>> add the apt lavasoftware depository. >>> >>> See >>> https://lava.readthedocs.io/en/latest/admin/basic-tutorials/instance/instal… >>> This will create a new source >>> "deb https://apt.lavasoftware.org/release buster main" >>> >>> >>> Rgds >>> >>> Le mer. 5 févr. 2020 à 05:59, dhanu msys <dhanuskd.palnati(a)gmail.com> a >>> écrit : >>> >>>> Hi Team, >>>> >>>> How to get the Latest Version changes in the LAVA Package for Single >>>> Instance? >>>> >>>> What is the Latest version released ? >>>> >>>> Please let me know the "How to Upgrade the Lava package without >>>> disturbing the existing test setup. >>>> >>>> Here I have attached the Lava packages list in my current setup to run >>>> the lava for reference. PFA. >>>> >>>> Thanks & Regards, >>>> Dhanunjaya. P >>>> _______________________________________________ >>>> Lava-users mailing list >>>> Lava-users(a)lists.lavasoftware.org >>>> https://lists.lavasoftware.org/mailman/listinfo/lava-users >>>> >>> >>> >>> -- >>> Rémi Duraffort >>> LAVA Architect >>> Linaro >>> >> -- Rémi Duraffort LAVA Architect Linaro

6 years, 3 months

2
1
0 0

Upgrade LAVA

by dhanu msys

Hi Team, How to get the Latest Version changes in the LAVA Package for Single Instance? What is the Latest version released ? Please let me know the "How to Upgrade the Lava package without disturbing the existing test setup. Here I have attached the Lava packages list in my current setup to run the lava for reference. PFA. Thanks & Regards, Dhanunjaya. P

6 years, 4 months

2
2
0 0

Re: [Lava-users] [EXT] Re: Test jobs to boot the target through JLink

by dhanu msys

Hi Andrei, Thanks for suggestion, I too had a same doubt before proceeding with the upgrade. I will try to setup the latest version in new system or i will take a backup of existing setup and run the test. Thanks & Regards, Dhanunjaya. P On Mon, Jan 27, 2020 at 2:24 PM Andrei Gansari <andrei.gansari(a)nxp.com> wrote: > Hello Dhanunjaya, > > > > These are the instructions on installing lava, you have to do something > similar to this in order to upgrade: > > https://docs.lavasoftware.org/lava/installing_on_debian.html > > > > I’m not sure if it will break or not your current setup, so be cautious > when upgrading, better backup if you have a live setup that is testing > other boards. > > > > I’m not a currently maintaining a LAVA server so I don’t have experience > updating from one version to another. > > Better you search the mailing list, ask on the mailing list or tryout on a > virtual machine. > > > > > > Andrei > > > > *From:* dhanu msys <dhanuskd.palnati(a)gmail.com> > *Sent:* Friday, January 24, 2020 12:44 PM > *To:* Andrei Gansari <andrei.gansari(a)nxp.com> > *Subject:* Re: [EXT] Re: [Lava-users] Test jobs to boot the target > through JLink > > > > *Caution: *EXT Email > > Hi Andrei, > > > > Can you please share the procedure to upgrade to the latest lava version. > > > > Thanks in advance. > > > > Regards, > > Dhanunjaya. P > > > > > > On Thu, Jan 23, 2020 at 7:33 PM Andrei Gansari <andrei.gansari(a)nxp.com> > wrote: > > From the screenshot it looks like you have a version of LAVA that does not > support jlink boot method. > > JLink was added in version 2019.10-1 > > > > Andrei > > > > *From:* dhanu msys <dhanuskd.palnati(a)gmail.com> > *Sent:* Thursday, January 23, 2020 3:13 PM > *To:* Andrei Gansari <andrei.gansari(a)nxp.com> > *Cc:* Kumar Gala <kumar.gala(a)linaro.org>; Andrei Gansari < > andrei.gansari(a)linaro.org>; lava-users <lava-users(a)lists.lavasoftware.org> > *Subject:* Re: [EXT] Re: [Lava-users] Test jobs to boot the target > through JLink > > > > *Caution: *EXT Email > > Hi Andrei, > > > > I run the test job based on the references shared by you. > > > > But , facing the error , while running the test job. > > > > Here I have attached the device template & device configuration files > along with the error. > > > > Please find the attachments & please provide me the inputs. > > > > Thanks in Advance. > > > > Regards, > > Dhanunjaya. P > > > > > > On Tue, Jan 21, 2020 at 5:29 PM Andrei Gansari <andrei.gansari(a)nxp.com> > wrote: > > Hello Dhanunjaya. P, > > > > You need to create a yaml file in > lava/lava_dispatcher/tests/sample_jobs/fpga_a64-jlink.yaml … assuming you > have already created the device fpga_a64. > > > > You have an example of FRDM-K64F booting cmsis-dap here: > > > https://github.com/Linaro/lite-lava-docker-compose/blob/lite/example/lava.j… > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> > > You need to replace “method: cmsis-dap” -> “method: jlink” > > > > I didn’t run a clean lava environment, so I maybe missing something. > > > > > > Andrei G. > > > > *From:* dhanu msys <dhanuskd.palnati(a)gmail.com> > *Sent:* Tuesday, January 21, 2020 12:31 PM > *To:* Andrei Gansari <andrei.gansari(a)nxp.com> > *Cc:* Kumar Gala <kumar.gala(a)linaro.org>; Andrei Gansari < > andrei.gansari(a)linaro.org>; lava-users <lava-users(a)lists.lavasoftware.org> > *Subject:* Re: [EXT] Re: [Lava-users] Test jobs to boot the target > through JLink > > > > *Caution: *EXT Email > > Hi Andrei, > > > > Based on the information shared earlier , i have tried to configure the > device type to make use of jlink based boot method test job , but i have > faced an issue "Configuration Error: missing or invalid template*.* Jobs > requesting this device type (fpga_a64) will not be able to start until a > template is available on the master." > > > > Can you please check once and share the updated Device-Type Template also. > > > > Thanks & Regards, > > Dhanunjaya. P > > > > > > On Tue, Jan 21, 2020 at 3:28 PM dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > > Hi Andrei , > > Hi Kumar, > > > > Can you please share some of the Test Job definition references to check > the Jlink-based test jobs configurations. > > > > Thanks & Regards, > > Dhanunjaya. P > > > > > > On Tue, Nov 26, 2019 at 2:36 PM Andrei Gansari <andrei.gansari(a)nxp.com> > wrote: > > I’ve tested lava+jlink on Cortex M with both onboard debugger and external > debugger, like the one you referenced. > > You should change the following if needed: > > > > address: > > *0x00000000* > > options: > > - '-device *MK64FN1M0xxx12'* > > - '-if SWD' > > - '-speed 4000' > > > > The interface SWD is supported, not JTAG, that can be easily changed if > you need to. > > > > Regards, > > Andrei > > > > *From:* Lava-users <lava-users-bounces(a)lists.lavasoftware.org> *On Behalf > Of *dhanu msys > *Sent:* Tuesday, November 26, 2019 7:49 AM > *To:* Kumar Gala <kumar.gala(a)linaro.org> > *Cc:* Andrei Gansari <andrei.gansari(a)linaro.org>; lava-users < > lava-users(a)lists.lavasoftware.org> > *Subject:* [EXT] Re: [Lava-users] Test jobs to boot the target through > JLink > > > > *Caution: *EXT Email > > Hi Kumar, > > > > Thanks for sharing the reference. > > > > It's better to have some references for the test jobs submission also. > > > > Currently we are in initial phase to make use of LAVA , so we wants to > check the feasibility to deploy through JLink based test jobs. > > > > Here I have provided the JLink Interface , which we are going to use for > the development. > > > > > https://www.thingbits.net/products/segger-j-link-base-jtag-swd-debugger?utm… > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.thing…> > > > > > Regards, > > Dhanunjaya. P > > > > > > On Sat, Nov 23, 2019 at 9:37 PM Kumar Gala <kumar.gala(a)linaro.org> wrote: > > > > > On Nov 21, 2019, at 11:06 PM, dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > > > > Hi Team, > > > > Can you please share some reference test jobs to run the tests using > J-Link boot method. > > Here’s a reference to the board cfg side change for J-Link: > > > https://github.com/agansari/lite-lava/blob/35a5bcbc01780638e6fd5e126bdfe180… > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> > > Andrei, > > Did you have a test job example to go along with this? > > - k > >

6 years, 4 months

1
1
0 0

lava-run crash after submitting a job

by Alexander Moore

Hello, Our internal LAVA setup has been hitting this crash intermittently (it reproduces about one out of every 30 job submissions). The below log snippet is from the 2019.07 LAVA docker images, but we updated to the 2019.12 images and the crash still occurs with the same error signature. lava-master | 2019-10-22 15:37:17,539 DEBUG |--> [523] scheduling lava-master | 2019-10-22 15:37:17,854 INFO [523] START => lava-dispatcher (CY8CKIT_062-01) lava-master | 2019-10-22 15:37:17,969 INFO [523] lava-dispatcher => START_OK lava-master | 2019-10-22 15:37:22,981 INFO [523] lava-dispatcher => END (lava-run crashed, mark job as INCOMPLETE) lava-master | 2019-10-22 15:37:23,038 ERROR [523] Unable to dump 'description.yaml' lava-master | 2019-10-22 15:37:23,038 ERROR [523] Compressed data ended before the end-of-stream marker was reached lava-master | Traceback (most recent call last): lava-master | File "/usr/lib/python3/dist-packages/lava_server/management/commands/lava-master.py", line 337, in _handle_end lava-master | description = lzma.decompress(compressed_description) lava-master | File "/usr/lib/python3.5/lzma.py", line 340, in decompress lava-master | raise LZMAError("Compressed data ended before the " lava-master | _lzma.LZMAError: Compressed data ended before the end-of-stream marker was reached Please let me know if I can provide any other info to help debug. Thanks, Alex This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 4 months

2
9
0 0

Device node in LXC is not accessible in hacking session

by Tim Jaacks

Hey everyone, I have a problem where a physical hardware device on my worker passed through to an LXC container cannot be read from or written to when I am connected to the LXC in a hacking session via SSH. I have registered the device in my static_info: {% set static_info = [ {"board_id": "GO31472"}, ] %} LAVA starts the LXC and attaches the device to it correctly: start: 2.2 lxc-add-static (timeout 00:04:50) [remote] Adding /dev/ttyUSB16, /dev/serial/by-id/usb-GFL_M_504_G_GO31472-if00-port0, /dev/bus/usb/004/008, /dev/serial/by-path/pci-0000:00:1d.3-usb-0:1:1.0-port0 nice lxc-device -n lxc-remote-10577 add /dev/ttyUSB16 nice lxc-device -n lxc-remote-10577 add /dev/serial/by-id/usb-GFL_M_504_G_GO31472-if00-port0 nice lxc-device -n lxc-remote-10577 add /dev/bus/usb/004/008 nice lxc-device -n lxc-remote-10577 add /dev/serial/by-path/pci-0000:00:1d.3-usb-0:1:1.0-port0 end: 2.2 lxc-add-static (duration 00:00:00) [remote] When I connect to the LXC via SSH using a hacking session, the device is there, but I cannot access it: root@lxc-remote-10577:~# ls -la /dev/ttyUSB16 crw-r--r-- 1 root root 180, 0 Aug 27 11:26 /dev/ttyUSB16 root@lxc-remote-10577:~# cat /dev/ttyUSB16 cat: /dev/ttyUSB16: Operation not permitted However, when I attach to the LXC directly from the worker using "lxc-attach", I can access it: root@lxc-remote-10577:~# ls -la /dev/ttyUSB16 crw-r--r-- 1 root root 180, 0 Aug 27 11:26 /dev/ttyUSB16 root@lxc-remote-10577:~# cat /dev/ttyUSB16 ��^C root@lxc-remote-10577:/# Did anybody else encounter such a problem before? Any hints on what might be the difference between lxc-attach and the SSH connection? Mit freundlichen Grüßen / Best regards Tim Jaacks DEVELOPMENT ENGINEER Garz & Fricke GmbH Schlachthofstrasse 20 21079 Hamburg Direct: +49 40 791 899 - 183 Fax: +49 40 791899 - 39 tim.jaacks(a)garz-fricke.com www.garz-fricke.com WE MAKE IT YOURS! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun

6 years, 4 months

1
0
0 0

Test jobs to boot the target through JLink

by dhanu msys

Hi Team, Can you please share some reference test jobs to run the tests using J-Link boot method. Thanks & Regards, Dhanunjaya. P

6 years, 4 months

3
8
0 0

Creating a multinode job

by Ryan Harkin

Hi folks, I'm struggling to create a working multinode job and wondered if someone could help? Here's the sample job I've submitted to try to get a handle on how multinode works: https://validation.linaro.org/scheduler/job/1963418.1#L1745 The main problem happens when LAVA executes this command on the shell: /lava-1963419/bin/lava-test-runner /lava-1963419/1 But there is no "/lava-1963419/1" directory, so then it can't find lava-common-functions and fails like this because the path is relative to a path that doesn't exist: /lava-1963419/bin/lava-test-runner: line 18: /lava-1963419/1/../bin/lava-common-functions: No such file or directory When I run a similar definition on a single node, it uses zero for the lava sub-dir, not 1, and it works: https://validation.linaro.org/scheduler/job/1963236#L2065 I tried to work out what was running here, to see if I could debug the scripts to work out where the "1" comes from. I cloned the LAVA repo and I cannot see the script "environment", and the lava-test-runner sources lava-common-functions from line 16, not 18. So now I'm curious where LAVA gets its scripts from. Another minor point, I'm following the instructions on this link: https://docs.lavasoftware.org/lava/writing-multinode.html And there are some dead links in there, eg. https://docs.lavasoftware.org/lava/examples/test-jobs/first-multinode-job.y… https://docs.lavasoftware.org/lava/examples/test-jobs/second-multinode-job.… https://docs.lavasoftware.org/lava/examples/test-jobs/bbb-lxc-ssh-guest.yaml Thanks, Ryan.

6 years, 4 months

2
3
0 0

grub boot

by Hemanth K V

Hello Lava Users, Trying to boot a target in LAVA based on base-grub device type.The LAVA version installed is 2019.11. >From the GRUB command line when I manually enter following commands for network setting ,it is getting executed successfully. grub> insmod efinet grub> net_ls_cards efinet2 20:87:56:b6:74:cd efinet1 20:87:56:f1:cf:21 efinet0 20:87:56:f1:cf:22 grub> net_add_addr test efinet0 134.86.62.99 grub> net_ls_addr test 20:87:56:f1:cf:22 134.86.62.99 But when I am sending same thing via LAVA , *net_add_addr test efinet0 134.86.62.99* [H[J[1;1Hgrub> net_add_addr test efinet0 134.86.62.99 bootloader-commands: Wait for prompt ['grub>'] (timeout 00:09:38) [1;7Hn[1;8H[1;8He[1;9H[1;9Ht[1;10H[1;10H_[1;11H[1;11Ha[1;12H[1;12Hd[1;13H[1;13Hd[1;14H[1;14H_[1;15H[1;15Ha[1;16H[1;16Hd[1;17H[1;17Hd[1;18H[1;18Hr[1;19H[1;19H [1;20H[1;20Ht[1;21H[1;21He[1;22H[1;22Hs[1;23H[1;23Ht[1;24H[1;24H [1;25H[1;25H [1;26H *error: three arguments expected.* The above error will come when we don't pass 3 parameters to net_add_addr grub> net_add_addr test efinet0 error: three arguments expected. I am getting this error even though 3 arguments are getting passed. Attached is the screen shot of the Job execution log. Thanks, Hemanth.

6 years, 4 months

3
4
0 0

Re: [Lava-users] Job Failure-Infrastructure error for qemu arm64

by Remi Duraffort

Hello, I ran the same job on staging (debian buster) and it's working fine: https://staging.validation.linaro.org/scheduler/job/266192 Something wrong on your system. Difficult to know. Could you send the full logs. Rgds Le mar. 14 janv. 2020 à 07:35, dhanu msys <dhanuskd.palnati(a)gmail.com> a écrit : > Hi Remi, > > Can you please check the logs and let me know what was the changes i need > to make to run the LAVA QEMU arm based test jobs. > > Thanks & Regards, > Dhanunjaya. P > > > On Mon, Dec 23, 2019 at 5:47 PM dhanu msys <dhanuskd.palnati(a)gmail.com> > wrote: > >> Hi Remi, >> >> Can you able to check the below mentioned the Log Files & Job related >> configurations along with the Job failure logs. >> >> Thanks & Regards, >> Dhanunjaya. P >> >> >> On Thu, Nov 28, 2019 at 6:01 PM dhanu msys <dhanuskd.palnati(a)gmail.com> >> wrote: >> >>> Hi Remi, >>> >>> Here I have attached the test job definition , test summary details & >>> qemu device configuration file along with device template for qemu arm64 >>> architecture. PFA. >>> >>> Regards, >>> Dhanunjaya. P >>> >>> >>> On Tue, Nov 26, 2019 at 5:19 PM dhanu msys <dhanuskd.palnati(a)gmail.com> >>> wrote: >>> >>>> Hi Remi, >>>> >>>> Here I have attached the Host Information. >>>> >>>> root@Dhanu:~# uname -a >>>> Linux Dhanu 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) >>>> x86_64 GNU/Linux >>>> >>>> root@Dhanu:~# lsb_release -a >>>> No LSB modules are available. >>>> Distributor ID: Debian >>>> Description: Debian GNU/Linux 10 (buster) >>>> Release: 10 >>>> Codename: buster >>>> >>>> root@Dhanu:~# df -h >>>> Filesystem Size Used Avail Use% Mounted on >>>> udev 1.9G 0 1.9G 0% /dev >>>> tmpfs 383M 18M 365M 5% /run >>>> /dev/sda1 289G 23G 252G 9% / >>>> tmpfs 1.9G 375M 1.6G 20% /dev/shm >>>> tmpfs 5.0M 4.0K 5.0M 1% /run/lock >>>> tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup >>>> tmpfs 383M 5.7M 377M 2% /run/user/1000 >>>> >>>> And also I have attached the CPU Info & MemInfo related information for >>>> your reference. >>>> >>>> Regards, >>>> Dhanunjaya. P >>>> >>>> >>>> On Tue, Nov 26, 2019 at 3:17 PM Remi Duraffort < >>>> remi.duraffort(a)linaro.org> wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>>> https://staging.validation.linaro.org/scheduler/device/staging-qemu03 >>>>>> >>>>>> >>>>>> This should work, unless your system is way too old. what host are >>>>> you using? >>>>> >>>>> >>>>> Rgds >>>>> >>>>> -- >>>>> Rémi Duraffort >>>>> LAVA Architect >>>>> Linaro >>>>> >>>> -- Rémi Duraffort LAVA Architect Linaro

6 years, 4 months

2
4
0 0

Lava dispatcher compatible question.

by David

Hello, all, Recently I heard from somebody said, lava will drop stretch support from 2020.01 release, I didn't find related information, is it true? I also want to know if I remain on stretch, but still use 2019.12 release just for slave, but maybe later just upgrade master to for example 2020.06 release on buster. Will 2019.12 slave on stretch be compatible with 2020.06(Just a example version) master on buster? Will you promise it? Best Regards, David

6 years, 5 months

2
2
0 0

Lava dispatcher compatible question.

by David

Hello, all, Recently I heard from somebody said, lava will drop stretch support from 2020.01 release, I didn't find related information, is it true? I also want to know if I remain on stretch, but still use 2019.12 release just for slave, but maybe later just upgrade master to for example 2020.06 release on buster. Will 2019.12 slave on stretch be compatible with 2020.06(Just a example version) master on buster? Will you promise it? Best Regards, David

6 years, 5 months

1
0
0 0

lavacli cannot fetch big logs.

by Larry Shen

Hi, there, We have one job to do some stress test, the final log is about 270MB. We use `lavacli -i production jobs logs --raw 30686` to fetch the log, it gives me next: ``` $ time lavacli -i production jobs logs --raw 30686 /usr/lib/python3/dist-packages/lavacli/__init__.py:101: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details. config = yaml.load(f_conf.read()) Unable to call 'jobs.logs': <ProtocolError for http://larry.shen:xxx@xxx.nxp.com/RPC2: 500 ('Connection broken: IncompleteRead(0 bytes read)', IncompleteRead(0 bytes read))> real 0m39.006s user 0m0.989s sys 0m0.191s ``` I check the gunicorn log, it give me: [2020-01-08 08:11:12 +0000] [188] [CRITICAL] WORKER TIMEOUT (pid:11506) Any suggestion?

6 years, 5 months

3
8
0 0

docker dispatcher qemu mount problem since 2019.11

by Dan Rue

I tried updating my lava-docker-compose repo to the latest but hit a problem mounting the overlay filesystem in qemu as of 2019.11 (2019.10 and earlier works, 2019.11 and later do not). To reproduce, clone https://github.com/danrue/lava-docker-compose/ and run "make"; observe the qemu health-check time out. The health check job can be found at https://github.com/danrue/lava-docker-compose/blob/master/server-overlay/et… The problem seems to occur when it tries to mount the overlay filesystem for the test job. I see in the release notes that the containers moved to buster in 2019.11 - related? Raw output below. Thanks, Dan / # mkdir /lava-2 mkdir /lava-2 mount /dev/disk/by-uuid/16786250-75bd-4703-9d57-7cfa618c725e -t ext2 /lava-2 / # mount /dev/disk/by-uuid/16786250-75bd-4703-9d57-7cfa618c725e -t ext2 /lava-2 mount /dev/disk/by-uuid/16786250-75bd-4703-9d57-7cfa618c725e -t ext2 /lava-2 mount: mounting /dev/disk/by-uuid/16786250-75bd-4703-9d57-7cfa618c725e on /lava-2 failed: No such file or directory ls -la /lava-2/bin/lava-test-runner / # ls -la /lava-2/bin/lava-test-runner ls -la /lava-2/bin/lava-test-runner ls: /lava-2/bin/lava-test-runner: No such file or directory Using /lava-2 export SHELL=/bin/sh / # export SHELL=/bin/sh export SHELL=/bin/sh . /lava-2/environment / # . /lava-2/environment . /lava-2/environment /bin/sh: .: can't open '/lava-2/environment' /lava-2/bin/lava-test-runner /lava-2/0 / # /lava-2/bin/lava-test-runner /lava-2/0 Test shell timeout: 10s (minimum of the action and connection timeout) /lava-2/bin/lava-test-runner /lava-2/0 /bin/sh: /lava-2/bin/lava-test-runner: not found

6 years, 5 months

3
2
0 0

Implement new deployment method

by Ilya Fedusiv

Hi! I'm trying to implement new method to lava. As a reference I took fastboot. Now I can job with my new implemented method. I want to work with lxc container as with fastboot. But same job as for fastboot with lxc, doesn't create lxc container and miss step with image validation. Only start methods which are described in /lava_dispatcher/actions/deploy/qdl.py What I miss? Kind regards, Ilya

6 years, 5 months

2
1
0 0

Job Failure-Infrastructure error for qemu arm64

by dhanu msys

Hi Team, I have tried to run the QEMU related jobs for arm64 with the below configurations , throwing an error. Can you please let me know the what was the Infrastructure missing on this job. Thanks & Regards, Dhanunjaya. P

6 years, 5 months

2
6
0 0

ACME Cape support in LAVA

by Milosz Wasilewski

Hi, I'm trying to change the way LAVA searches for and passes USB devices to LXC containers. Current code depends on arbitrary variables present in the static_info dictionary that is part of the device dictionary. This seems to be a problem for some users [1]. So the proposal was made to get rid of the arbitrary variables entirely and use udev variables (starting with ID_). The change was pretty simple to implement but when I started changing the docs I realized there were other classes of devices supported with static_info. Docs list ACME Cape that can be connected over LAN [2]. I'm not aware of any users of this code but I don't want to break the feature if there is anyone using it. So if you're users of LAVA who connect ACME Cape using static_info please reply to this thread. If I don't hear any replies I will remove this support. [1] https://git.lavasoftware.org/lava/lava/issues/335 [2] https://github.com/ARM-software/lisa/wiki/Energy-Meters-Requirements#user-c… Best Regards, milosz

6 years, 6 months

2
2
0 0

Re: [Lava-users] Deploy RTOS Based Application Image

by Remi Duraffort

What kind of command do you run to flash over usb? Le jeu. 28 nov. 2019 à 13:26, dhanu msys <dhanuskd.palnati(a)gmail.com> a écrit : > Hi Remi, > > We were flashing through USB otg cable. > > USB deploy method supported by lava right? > > Regards, > Dhanunjaya > > On Thu, Nov 28, 2019, 17:52 Remi Duraffort <remi.duraffort(a)linaro.org> > wrote: > >> Hello, >> >> you should give more information if you want to have a proper answer. >> >> How do you flash the board? is it fully automatic? >> Is this method already supported by LAVA? >> >> >> Rgds >> >> Le jeu. 28 nov. 2019 à 07:48, dhanu msys <dhanuskd.palnati(a)gmail.com> a >> écrit : >> >>> Hi Team, >>> >>> How can i deploy RTOS based Application Image on target. >>> >>> Notes : >>> Target HW : STM32F429I-DISC1. >>> RTOS : Open source RTOS >>> Application Image (RTOS + Application specific code). >>> >>> We are able to flash the Developed Application Firmware (.out/.bin) >>> through IAR IDE via USB, so we are in plan to make use of LAVA and run test >>> applications automatically. >>> >>> So , Can you please provide some references to deploy this test >>> scenarios in LAVA. >>> >>> Thanks & Regards, >>> Dhanunjaya. P >>> _______________________________________________ >>> Lava-users mailing list >>> Lava-users(a)lists.lavasoftware.org >>> https://lists.lavasoftware.org/mailman/listinfo/lava-users >> >> >> >> -- >> Rémi Duraffort >> LAVA Architect >> Linaro >> > -- Rémi Duraffort LAVA Architect Linaro

6 years, 6 months

3
6
0 0

RFC: when to drop stretch support?

by Remi Duraffort

Hello everyone, Summary: We would like to drop the support for stretch in the (near) future. Details: Currently lava-server and lava-dispatcher are supported on both debian stretch and debian buster. Since LAVA 2019.11, the lava-server and lava-dispatcher docker images are based on debian buster and not stretch. Unittest are still running on stretch, buster and bullseye but integration tests (lavafed and meta-lava mainly) are using the docker container so they run only on buster. Dropping the support for stretch will: * simplify testing * allow to use more recent version of python and django * remove some issues with old dependencies in stretch But before dropping the support we need to ensure that users/admins had some time to migrate to buster or to docker-based installations. In an ideal world, I would drop the support for stretch on the 1st of January 2020. But please answer to this mail so we can device of the right date all together. Thanks -- Rémi Duraffort LAVA Architect Linaro

6 years, 6 months

3
8
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users