The process I expect is:
1. test board restart
2. catch the bootup log by serial port
3. deploy the test suit (test script) by ssh
4. run test case by ssh or uart (ssh is better)
5. These are concentrated in one yaml and all logs are captured.
Now I try to restart the test board by below code, it works, board reboot successfully
device:
actions:
deploy:
methods:
{% if flasher_reset_commands %}
flasher:
commands: {{ flasher_reset_commands }}
{% endif %}
test yaml
- deploy:
timeout:
minutes: 30
to: flasher
images:
kernel:
url: http://10.19.207.190/static/docs/v2/contents.html#contents-first-steps-using
But if I add ssh to deploy in the device file, the yaml remains unchanged and I will be prompted with device BAD.
device as blow:
{# device_type: orinnew #}
{% extends 'base.jinja2' %}
{% block body %}
actions:
deploy:
methods:
{% if flasher_reset_commands %}
flasher:
commands: {{ flasher_reset_commands }}
{% endif %}
ssh:
options:
{{ ssh_options }}
# primary connections get this from the device dictionary.
# secondary connections get this from the lava-multinode protocol support.
host: "{{ ssh_host|default('') }}"
port: {{ ssh_port|default(22) }}
user: "{{ ssh_user|default('root') }}"
identity_file: "{{ ssh_identity_file }}"
boot:
connections:
serial:
methods:
ssh:
minimal:
{% endblock body %}
1. Where did I go wrong to cause this problem?
2. Every time you paste code, there will be formatting problems. How to paste code in this mail list? It has an effect similar to markdown.
Hey all,
I am currently trying to add a raspberry pi device to my lava installation however it keeps saying that I have an invalid device configuration.
This is the device dictionary
{% extends 'bcm2711-rpi-4-b.jinja2' %}
{% set connection_list = ['uart0']%}
{% set connnection_commands = {'uart0': 'telnet 10.60.2.209 7002'}%}
{% set connection_tags = {'uart0': ['primary','telnet']}%}
{% set power_off_command = 'python /hbus_power.py off' %}
{% set hard_reset_command = 'python /hbus_power reboot' %}
{% set power_on_command = 'python /hbus_power on' %}
Is there anything I'm doing wrong with this? or any other ideas as to what could be wrong?
Hi,
I have started trying to connect my DUT and run tests via serial. I'm not sure if it's a me issue, or a documentation issue, but I can't seem to puzzle it together.
My DUT is connected to my worker via serial, and I've configured my ser2net.yaml file (docs say it's a .config, but I found no such thing) with both the provided example and something based on what was already in there. The problems arise in the job definition, and device dictionary. I've made a (pretty much) blank device template which extends base-uboot, and does nothing else.
The device dictionary defines power_off_command, power_on_command, soft_reboot, and the connection_(list, commands, and tags). There is also the baud rate and console device
However, I've also seen some device templates use a root device instead or alongside console device, what's the difference?
Whenever I use my worker IP for the telnet command, I get connection refused, but if I use the DUT IP the connection times out after 2 minutes.
I can connect to the device using minicom, so I don't think the serial connection is bad, and I have no problems using SSH on the device and other systems connected to my network.
The only information I have on the device is that it's ARMv5TEJ, it has a custom kernel and runs on otherwise custom hardware.
Below is my device dict:
{% extends 'test-template.jinja2' %}
{% set power_off_command = 'python /power.py off' %}
{% set soft_reboot_command = 'reboot' %}
{% set power_on_command = 'python /power.py on' %}
{% set connection_list = ['uart0'] %}
{% set connection_commands = {'uart0': 'telnet dispatcher01 7001'} %}
{% set connection_tags = {'uart0': ['primary', 'telnet']} %}
{% set console_device = 'ttyUSB0' %}
{% set baud_rate = 115200 %}
My questions are:
- Difference between root_device and console_device in device dictionary/template?
- Do I set the telnet command to use my worker IP or my DUT IP?
- Is there something other than telnet I'm meant to or can use?
- How am I actually meant to configure the ser2net.yaml?
- How do I define the test job for serial to execute commands on the DUT?
Regards,
Michael
Hi all,
Recently I updated device dictionary for my devices in lava server machine.
I added {% set user_commands = {'start_tpm': {'do': 'cmd1',
'undo': 'cmd2' }%}
in the following file /etc/lava-server/dispatcher-config/devices/qemu-01.jinja2
After updating I was successfully able to use these user defined commands in my job definitions using command action where ever i needed them.
But a strange thing is happening after I made the above mentioned changes is I am unable to start the job where it is throwing Infrastructure error: Cannot find command '' in $PATH` when I use minimal boot action in my job.
I cross checked this in 2 ways,
1. I removed my user command device dictionary related changes from my lava server and my job is starting and is completed successfully even if i have minimal boot action in my job.
2. I changed my boot action from ( method: minimal ) to (method: qemu , media: tmpfs ), and i retained user command device dictionary changes in my device template.. In this case also the job started and is completed successfully.
So is there some conflict between adding commands to device dictionary and using minimal boot action in our job ?
I am not sure how these two are related. My use-case badly requires minimal boot actions in my job as well as some user defined commands in device template. Please have a look at my job definition and run log https://lava.ciplatform.org/scheduler/job/1089996. I needed minimal boot action to finish the boot action only if i get a particular shutdown-message or else I want it to timeout and be incomplete.
Can anyone please help me how to resolve this issue ?
Hi All
I am trying to sort out using queries to make charts and I am running into two problems.
1. Even after adding conditions I can not run queries as the button is disabled. I can get around this by changing it to a live query but I would prefer to be able to use the actual button.
2. I can't view a chart.
When I try to do this I just get a loading screen that won't end. According to the Console, the error is either undefined properties or functions not existing.
My query selects all jobs with a test suite with a name equal to 0_smoke-tests and then my graph is Type: pass/fail, Representation: bar, X-axis attribute: none.
I am wondering if these are bugs or if I am doing something wrong.
If anyone can help that would be greatly appreciated
Thanks
Daniel
Hi,
As stated in the subject, I was wondering if it is at all possible to use a repo on Azure DevOps instead of a GitHub one.
I have been using a GitHub repo thus far, and it works just fine, but I need to move my files over to DevOps.
According to the docs here: https://docs.lavasoftware.org/lava/actions-test.html only git is supported at the moment, with URL and tar planned for. Would URL work for this if support came in at any point? Or would azure need its own support?
Or should git work and there is something wrong with the repo URL I am using? Because the particular error I get is that the password could not be read (I'm using a PAT in the link, like I did for GitHub)
Best Regards.
Michael
Hello Team,
I was trying to flash a binary on the device and run the tests on the
device by using lava overlay.
Board flashes successfully but while booting the device in the boot log
there is a word "*** Invalid partition 3 ***" lava catches the key word
and throws an error message.
For the other devices it is not catching this error with the same boot log.
Only on one device I'm observing this issue.
Please let me know How to ignore the keyword and move on to run the tests.
matched a bootloader error message: 'Invalid partition' (17)
boot log:
*U-Boot SPL 2022.04 (Nov 30 2023 - 20:10:15
+0000)power_bd71837_initDDRINFO: start DRAM initDDRINFO: DRAM rate
1600MTSDDRINFO:ddrphy calibration doneDDRINFO: ddrmix config doneNormal
BootTrying to boot from MMC1hab fuse not enabledAuthenticate image from DDR
location 0x401fcdc0...NOTICE: BL31:
v2.6(release):lf-5.15.32-2.0.0-0-gc6a19b1a3-dirtyNOTICE: BL31: Built :
06:37:22, Jun 7 2022U-Boot 2022.04 (Nov 30 2023 - 20:10:15 +0000)CPU:
i.MX8MMD rev1.0 1600 MHz (running at 1200 MHz)CPU: Industrial temperature
grade (-40C to 105C) at 44CReset cause: PORModel: DRAM: 224
MiBboard_initCore: 61 devices, 21 uclasses, devicetree: separateMMC:
FSL_SDHC: 0Loading Environment from nowhere... OKIn: serialOut:
serialErr: serialSEC0: RNG instantiated BuildInfo: - ATF c6a19b1facmod
value is 1!pulse number is 0�flash target is MMC:0Fastboot: NormalNormal
BootHit any key to stop autoboot: 2 end: 3.4.2 bootloader-interrupt
(duration 00:00:05) [common]start: 3.4.3 bootloader-commands (timeout
00:02:52) [common]Setting prompt string to ['=>']bootloader-commands: Wait
for prompt ['=>'] (timeout 00:02:52) 0 Setting prompt string to
['=>']Sending with 5 millisecond of delaysetenv factorymode 1u-boot=>
setenv factorymode 1bootloader-commands: Wait for prompt ['=>'] (timeout
00:02:51)setenv factorymode 1Sending with 5 millisecond of
delaybootu-boot=> bootboot** Invalid partition 3 **Couldn't find partition
mmc 0:3Can't set block deviceuEnv not found in mmcpart3, checking
mmcpart1Failed to load '/boot/system/uEnv'uEnv not found in mmcpart 1
either!Booting from mmc ...## Error: \"w\" not definedmatched a bootloader
error message: 'Invalid partition' (17)end: 3.4.3 bootloader-commands
(duration 00:00:02) [common]case: bootloader-commandscase_id:
204071definition: lavaduration: 1.52extra: ...level: 3.4.3namespace:
commonresult: fail*
Best Regards
Pavan Kumar
Hello everyone,
I am trying to implement a test case scenario in which I need to confirm partition scheme, environment variables after the reboot which is triggered by the watchdog I am using. So basically I need to be able to successfully login to the image after the reboot triggered by the watchdog.
It feels like the link between the test Job and the Linux image is lost after the reboot done by the watchdog. Whatever actions present after that reboot ( boot or test actions ) are not working.
Below is the template of my Job definition:
job details...
device_type: qemu
#### (timeouts)
###(priority)
##(notify, context etc.)
actions
- deploy
images: ###
firmware: ###
- boot
auto_login:
login_prompt: "###"
username: "##"
password_prompt: "###"
password: "##"
- test:
definitions: ###
repository: ####
metadata: ###
run:
steps:
- swupdate -i ####
- reboot
-------------------------------------------------
At this stage I introduced a service which causes kernel panic during the reboot (by the command explicitly given by me above in the job). So after 'X' seconds of watchdog timeout , a second reboot is triggered by the watchdog. During that reboot done by watchdog, the kernel booted successfully, all the services were set up fine, but the test stopped at the login stage.
I think it did not get the "login_prompt" and ''password_prompt" from the boot action I wrote after the above test action ( i.e after reboot done by watchdog ).
- boot
auto_login:
login_prompt: "###"
username: "##"
password_prompt: "###"
password: "##"
So Is there a way to add boot and test actions in such a way that the test job can be continued after reboot is done by a watchdog ?
Note: When I explicitly provide "reboot" in steps section in test action, then the link did not break and I was able to reboot, login and run test action steps successfully no matter how many times I wanted.
This query is specifically for cases in which reboot happened out of test writer's scope. (i.e like reboot triggered by a watchdog)
Hello everyone,
I would like to open thread of discussion to understand about LAVA test framework support for some of the use cases where I’m facing issues.
While testing a reboot scenario in CIP (https://gitlab.com/cip-project/cip-core/isar-cip-core) where reboot is triggered by watchdog. LAVA is unable to do successful reboot.
Following are the steps:
device_type: qemu
job_name: qemu x86_64 software update testing
timeouts:
job:
minutes: 20
action:
minutes: 10
actions:
power-off:
seconds: 60
priority: high
visibility: public
notify:
criteria:
status: finished
recipients:
- to:
method: email
email: sai.sathujoda(a)toshiba-tsip.com
context:
arch: x86_64
lava_test_dir: '/home/lava-%s'
# ACTION BLOCK
actions:
- deploy:
timeout:
minutes: 15
to: tmpfs
images:
system:
image_arg: '-drive file={system},discard=unmap,if=none,id=disk,format=raw -m 1G -serial mon:stdio -cpu qemu64 -smp 4 -machine q35,accel=tcg -global ICH9-LPC.noreboot=off -device ide-hd,drive=disk -nographic'
url: ######.wic.xz
compression: xz
firmware:
image_arg: '-drive if=pflash,format=raw,unit=0,readonly=on,file={firmware}'
url: ######
# BOOT BLOCK
- boot:
timeout:
minutes: 5
method: qemu
media: tmpfs
prompts: ["root@demo:~#"]
auto_login:
login_prompt: "demo login:"
username: "root"
password_prompt: "Password:"
password: "root"
# TEST_BLOCK
- test:
timeout:
minutes: 5
definitions:
- repository:
metadata:
format: Lava-Test Test Definition 1.0
name: sample-test
description: "check reboot version"
run:
steps:
- lava-test-case uname --shell uname -a
- cd /home
- wget --no-check-certificate ####
- lsblk
- swupdate -i cip-core-*
- reboot
from: inline
name: sample-test-1
path: inline/sample-test.yaml
- boot:
timeout:
minutes: 5
method: qemu
media: tmpfs
prompts: ["root@demo:"]
auto_login:
login_prompt: "demo login:"
username: "root"
password_prompt: "Password:"
password: "root"
- test:
timeout:
minutes: 5
definitions:
- repository:
metadata:
format: Lava-Test Test Definition 1.0
name: sample-test
description: "check partition switch"
run:
steps:
- lsblk
from: inline
name: sample-test-2
path: inline/sample-test.yaml
context:
arch: x86_64
lava_test_results_dir: '/home/lava-%s'
A reboot is triggered by watchdog following the reboot done in the test action due to failed case. The reboot triggered by watchdog failed with timeout error at login stage which can be interpreted that last boot action in the above job definition failed to give the assigned login prompts.
I have already received some opinion about this from LAVA users community that LAVA does not support the board being rebooted outside it’s control ( whether by a watchdog or a package ).
However, CIP extensively uses LAVA as test framework to regressively perform many kinds of tests on CIP supported hardware.
Testing the watchdog is an important use case in CIP. Since LAVA is supposed to be test framework which can help to test many type of hardware.
We as CIP project member would like to understand LAVA community future plan to support this use case.
Thanks and Regards,
Sai Ashrith
Hi,
During last couple of weeks I had at least 2 occasions when
lava-publisher stopped working. There is nothing in the logs that
suggest a failure. The only symptom was that no events were published.
Restarting the service fixes the issue. Is this a known bug? I'm
running 2023.10 release.
Best Regards,
Milosz