lava-users

lava-users@lists.lavasoftware.org

1 participants
942 discussions

Re: [Lava-users] Evaluating return value of user_commands

by Tim Jaacks

Oh, the action indeed DOES cause an infrastructure error if it fails, my command simply did not return an error in case of a failure. Sorry for the noise! 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 -----Ursprüngliche Nachricht----- Von: Tim Jaacks Gesendet: Donnerstag, 30. April 2020 16:32 An: lava-users(a)lists.lavasoftware.org Betreff: Evaluating return value of user_commands Hello everyone, I am using a command action with pre-defined user_commands in the device dictionary for switching relays, as described here: https://master.lavasoftware.org/static/docs/v2/actions-command.html The return value does not seem to be evaluated, though. The test continues even if my user_command fails. I would assume that this causes an infrastructure failure, resulting in an incomplete job. Why is this not the case? 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

5 years, 10 months

Evaluating return value of user_commands

by Tim Jaacks

Hello everyone, I am using a command action with pre-defined user_commands in the device dictionary for switching relays, as described here: https://master.lavasoftware.org/static/docs/v2/actions-command.html The return value does not seem to be evaluated, though. The test continues even if my user_command fails. I would assume that this causes an infrastructure failure, resulting in an incomplete job. Why is this not the case? 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

5 years, 10 months

Unable to register IRC channel for #linaro-lava

by Nagendra Singamsetti

Hi team, i am trying to login IRC channel for #linaro-lava. https://webchat.freenode.net/#linaro-lava But , There is no register option for new user. It takes me to the group as Unregistered user. Please share the proper link to complete the registration for #linaro-lava. thanks Regards Nagendra S

5 years, 10 months

/etc/qemu-ifup: no bridge for guest interface found

by Nagendra Singamsetti

Hi team, I am new to lava-server. I have written and uploaded the job description for QEMU-arm64 to boot. But I can see in logs both kerenl Image-qemuarm64.bin and rootfs core-image-minimal-qemuarm64.ext4 files are downloaded in /var/lib/lava/dispatcher/tmp/* directory. But i am getting following error . auto-login-action: Wait for prompt ['Linux version [0-9]'] (timeout 00:02:00) *W: /etc/qemu-ifup: no bridge for guest interface foundqemu-system-aarch64: -kernel /var/lib/lava/dispatcher/tmp/27/deployimages-otsvre77/kernel/Image-qemuarm64.bin: Could not open 'format=raw,file=/var/lib/lava/dispatcher/tmp/27/deployimages-otsvre77/rootfs/core-image-minimal-qemuarm64.ext4': No such file or directoryConnection closed* *Attaching .yaml file for job discription.* Please let me know if i miss anything. Note : LAVA-SERVER version:version: 2019.01-5 QEMU boot command:sudo qemu-system-aarch64 -kernel Image-qemuarm64.bin -netdev tap,id=net0,ifname=tap1,script=no,downscript=no -device virtio-net-device,netdev=net0 -machine virt -cpu cortex-a57 -drive id=disk0,file=core-image-minimal-qemuarm64.ext4,if=none,format=raw -device virtio-blk-device,drive=disk0 -no-reboot -nographic -m 512 --append "root=/dev/vda rw console=ttyAMA0,38400 mem=512M highres=off ip=192.168.7.4: :192.168.7.3:255.255.255.0 rootfstype=ext4 console=ttyS0" Tested and working fine on my debian machine(with out lava server) thanks Regards Nagendra S

5 years, 10 months

Support for lauterbach-trace32 debugger

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

5 years, 10 months

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

5 years, 10 months

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

5 years, 10 months

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?

5 years, 10 months

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

5 years, 10 months

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

5 years, 10 months

← Newer
1
...
27
28
29
30
31
32
33
...
95
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users