Hi Lava users,
I am facing some issues while using the interactive test method, for testing u-boot reset function. In v2019.11 this worked perfectly but currently while using v2020.07 and this features seems to be broken. Or am I missing something here.
Here detailed description of the issue:
We are testing the u-boot reset command below is the snippet of the job definition
...
...
...
- name: mmcinfo
command: mmcinfo
successes:
- message: "Erase Group Size:"
failures:
- message: "Unknown command "
error: "Unknown command "
- name: reset
command: reset
successes:
- message: "Hit any key to stop autoboot"
failures:
- message: "Unknown command "
error: "Unknown command "
So in v2019.11 once the "Hit any key to stop autoboot" string was matched the target switched off (check screenshot "reset-snippet-v2019-11.PNG").
But this is not working in v2020.07, after the success message is matched the target is not switched off (check screenshot "reset-snippet-v2020-07.PNG").
Regards,
Bhargav
Hi, all,
I want to do a job search with owner, E.g. in https://validation.linaro.org/scheduler/alljobs 's search box, I input next:
owner_query=qa-reports-bot
But, it return nothing to me, all jobs filtered out.
I wonder what's the correct input in this search box for "Custom query text"?
Regards,
Larry
Hello Lava-Users,
When we try to add new device we are facing the error
500 Internal Server Error
maximum recursion depth exceeded in comparison
Oops, something has gone wrong!
Recently we had updated the LAVA instance server to Debian10. The LAVA server version presently running on the instance is
lava_admin@svr-ies-ce-lava:~$ dpkg -l | grep lava
ii lava 2020.07.0002.g44e83009c+10+buster all Linaro Automated Validation Architecture metapackage
ii lava-common 2020.07.0002.g44e83009c+10+buster all Linaro Automated Validation Architecture common
ii lava-coordinator 2020.07.0002.g44e83009c+10+buster all LAVA coordinator daemon
ii lava-dev 2020.07.0002.g44e83009c+10+buster all Linaro Automated Validation Architecture developer support
ii lava-dispatcher 2020.07.0002.g44e83009c+10+buster all Linaro Automated Validation Architecture dispatcher
ii lava-dispatcher-host 2020.07.0002.g44e83009c+10+buster all LAVA dispatcher host tools
ii lava-server 2020.07.0002.g44e83009c+10+buster all Linaro Automated Validation Architecture server
ii lava-server-doc 2020.07.0002.g44e83009c+10+buster all Linaro Automated Validation Architecture documentation
ii lavacli 0.9.5-1 all LAVA XML-RPC command line interface
As specified in https://stackoverflow.com/questions/3323001/what-is-the-maximum-recursion-d… should we try to increase python recursion limit to overcome this?
Thanks,
Hemanth.
Hi Lava users,
I am trying to use the u-boot-ums deploy method.
I have taken reference from this job : https://staging.validation.linaro.org/scheduler/job/277518/definition
While submitting the job I am getting the following error:
Job error: 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" downloads: "to" parameter is not "downloads" qemu-nfs: "nfs" is not in the device configuration deploy methods images: "to" parameter is not "tmpfs" iso: "to" was not in parameters, or "to" was not "iso-installer" fastboot: "to" parameter is not "fastboot" flasher: 'flasher' not in the device configuration deploy methods fvp: 'to' was not fvp lxc: "to" parameter is not "lxc" nbd: "to" parameter is not "nbd" nfs: "to" parameter is not "nfs" removable: "media" was not "sata", "sd", or "usb" vemsd: "to" parameter is not "vemsd" mps: "mps" was not in the device configuration deploy methods musca: "musca" was not in the device configuration deploy methods ssh: "to" parameter is not "ssh" tftp: "to" parameter is not "tftp" uboot-ums: "u-boot-ums" was not in the device configuration deploy methods" recovery-mode: 'recovery' not in the device configuration deploy methods uuu: "to" parameter is not "uuu"
Please check the attached yaml file (u-boot-ums-def.yaml).
?
Regards,
Bhargav
Hi,
I saw something like "LAVA_HARD_RESET_COMMAND" was added to environment.
Yes, the test action could use this command to reboot the device now, it's useful.
But, after the command sent, the code in container still need to handle something like next:
"Expect press any key to continue"
"Press any key"
"Expect login prompt"
"Login"
Etc......
But, this exactly the same code what lava have do in a lots of python files located in "lava_dispatcher/actions/boot".
My question is: do you think it's possible for user code in "docker-test-shell" action directly send any command or use any protocol to tell lava code(maybe a listener or something else) to help to do these things, then after done, the user code in docker test shell continue to execute its own stuff?
You know, this could reuse existed lava code as much as possible. I just want to know if you have plan for this? Thanks.
Hi,
I have some questions about the fastboot/adb in docker support I hope you can help with.
Use case is for android 10 aosp testing with LAVA 2020.05.
Thanks to Antonio's presentation and draft documentation I have simple fastboot host to
DUT communication working for a u-boot based arm64 board. I am now trying to apply an
existing flash process, which uses a script on the host to send fastboot cmds, into a LAVA job.
I can see how fastboot --set-active, reboot and flash commands all have equivalent controls
in a 'deploy to fastboot docker' LAVA job section. Do equivalents exist for the fastboot
oem format, oem erase, format and erase commands or is there a way to insert them
in the deploy?
Expecting that will take some engineering work, in parallel I wanted as a stop gap to try
running the flash script from a LAVA job. So people could work on the testing side whilst
I resolved the deploy section. Antonio suggested trying to do that from the test section
I recall.
To do that I face two issues:
1) The build artifacts are on a local volume rather than an artifact server so I need to
get them into the docker container in an automated way. Is there a way to either mount
a local volume or file list into the container without asking LAVA to deploy them?
As an experiment I tried using the docker image manipulation added in 2020.04 to do
this. There I hit a problem with the current implementation. It seems the 'deploy to
downloads' implementation does not check for a local image first, as the other docker
support does, before trying to pull the image. So I get an error when the pull fails:
https://lava.genivi.org/scheduler/job/961#L24
2) The job needs to be able to boot the DUT, interrupt u-boot and start fastboot
so the host has something to communicate with once the test section is reached.
I can achieve that in a horrible hacky way by having a deploy section with a simple
single flash image (dtbo say) and using the reboot controls to get the board to reboot into
fastboot to await the flash script being run from the test section, but I expect there
is a better way. Any ideas?
Regards
Steve
Hi,
Taking the current master branch head (0f6e89e3) I find my health checks
that use u-boot tftboot support are now failing with the following:
start: 2.2 bootloader-overlay (timeout 00:05:00) [common]
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/lava_dispatcher/action.py", line 245, in run_actions
new_connection = action.run(connection, action_max_end_time)
File "/usr/lib/python3/dist-packages/lava_dispatcher/actions/boot/__init__.py", line 454, in run
tee_addr = self.job.device["parameters"][self.bootcommand]["tee"]
KeyError: 'tee'
Example job:
https://lava.genivi.org/scheduler/job/1160
I've not combed through the code in detail but it looks like it is related
to the recent tee merge:
https://git.lavasoftware.org/lava/lava/-/commit/f18ca091e61da31159cd72a0030…
That appeared to introduce an optional feature which my jobs do not
make use. Am I missing something?
Regards
Steve
