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
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
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
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
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
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
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
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
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