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