Hi,
I'm trying to run a job which reboots the board. The reboot is
controlled with interactive shell. After issuing 'reboot' I try to run
a 'boot' action with download overlay. This unfortunately fails. If
there is 'transfer_overlay' lava complains there is no overlay
available to download. When I remove 'transfer_overlay' lava complains
there are no tests to run. I guess I need to add 'deploy' action
before the second boot, but I don't know how to do it properly. The
DUT should be left on it's own and not reflashed. Here is my job
definition:
actions:
- deploy:
namespace: before
timeout:
minutes: 10
to: flasher
images:
image:
....
- boot:
namespace: before
prompts:
- "root@imx8mmevk"
timeout:
minutes: 10
auto_login:
login_prompt: 'login:'
username: fio
password_prompt: "Password:"
password: "fio"
login_commands:
- sudo su
- fio
method: minimal
transfer_overlay:
download_command: cd /home ; wget
unpack_command: tar -C / -xzf
- test:
namespace: before
timeout:
minutes: 5
definitions:
- repository:
metadata:
format: Lava-Test Test Definition 1.0
name: prepare-upgrade
description: "OTA upgrade"
os:
- debian
scope:
- functional
run:
steps:
...
from: inline
name: prepare-upgrade
path: inline/prepare-upgrade.yaml
- test:
namespace: before
timeout:
minutes: 1
interactive:
- name: reboot
prompts: ['root@imx8mmevk',]
script:
- command: reboot
name: reboot
- boot:
namespace: after
connection-namespace: before
prompts:
- "root@imx8mmevk"
timeout:
minutes: 10
auto_login:
login_prompt: 'login:'
username: fio
password_prompt: "Password:"
password: "fio"
login_commands:
- sudo su
- fio
method: minimal
transfer_overlay:
download_command: cd /home ; wget
unpack_command: tar -C / -xzf
- test:
namespace: after
connection-namespace: before
timeout:
minutes: 5
definitions:
- repository:
metadata:
format: Lava-Test Test Definition 1.0
name: verify-rollback
description: "OTA upgrade"
os:
- debian
scope:
- functional
run:
steps:
...
from: inline
name: verify-rollback
path: inline/verify-rollback.yaml
I removed the test steps as they're not relevant. The 'before' and
'after' namespaces are required. Without namespaces LAVA will only run
last boot and test sections and ignores the ones in 'before'
namespace.
To conclude - does anyone know how to make this job working? Either by
adding a 'dummy deploy' to the 'after' namespace or by getting rid of
namespaces so all tests are executed in the defined order?
Best Regards,
Milosz
Hey,
Yesterday a kernel message was printed during a LAVA Signal. Lava therefore got a test named '0-mytest-cutoff[', the [ being the beginning of the timestamp of a kernel message.
Afterwards several web views like the result overview were broken due to some filter not being able to deal with '0-mytest-cutoff['. We fixed this by taking lava offline and doing a search&replace on the database to rename the test.
It seems to be the default to have the full kernel log on the LAVA serial output. Is this an expected behaviour and is there a good way to prevent those issues?
Best regards, Olli
Hi All,
We are hitting a bug with LAVA 2021.08: email notifications seem to be broken.
We believe this is due to a bug between eventlet 0.26.0 and dnspython.
Visibly, this is fixed in eventlet 0.32.0: https://github.com/eventlet/eventlet/issues/619
Did you face the same bug?
Any idea about how to fix that?
Thanks a lot,
Philippe
Trace below:
ERROR:lava_scheduler_app:[Errno -3] Lookup timed out
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 435, in resolve
return _proxy.query(name, rdtype, raise_on_no_answer=raises,
File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 391, in query
return end()
File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 370, in end
raise result[1]
File "/usr/lib/python3/dist-packages/eventlet/support/greendns.py", line 351, in step
a = fun(*args, **kwargs)
File "/usr/lib/python3/dist-packages/dns/resolver.py", line 1089, in query
return self.resolve(qname, rdtype, rdclass, tcp, source,
File "/usr/lib/python3/dist-packages/dns/resolver.py", line 1043, in resolve
timeout = self._compute_timeout(start, lifetime)
File "/usr/lib/python3/dist-packages/dns/resolver.py", line 950, in _compute_timeout
raise Timeout(timeout=duration)
dns.exception.Timeout: The DNS operation timed out after 5.104917526245117 seconds
Hi Lava Users,
I'm working on a LAVA test that is not very chatty (little to no output
during execution). I'm looking for a way to set expected silence time in
that test and break its execution in case it's exceeded.
I thought Connection timeout [1] would be my solution but by setting:
timeouts:
connections:
lava-test-shell:
seconds: 5
I was unable to get any difference in the job execution. I intentionally
made timeout ridiculously small to see how it would affect the job.
Please let me know if using Connection timeout for this purpose is a
dead end. I'm also open for any solution suggestions (wrapping test with
a script that would emit checkpoints on serial?)
[1]
https://lava.readthedocs.io/en/latest/technical-references/job-definition/t…
Thanks,
Paweł Wieczorek
Hi,
We are working on integrating NXP Layerscape boards in LAVA. On Layerscape boards, we have a mechanism of having multiple banks. This is done mainly to protect board from getting bricked if wrong images gets flashed on board.
Board is set to boot from a Bank 1 by default (controlled by switches). Now you use this bank also to flash your images, but in case the images are corrupt, board will get bricked and you will need to connect JTAG to recover the board.
So here concept of Alternate Bank boot comes to help. By default board boots from Bank 1, but we will not flash the images on Bank 1, instead we will flash images on Bank 2. After flashing the images, we will boot from Bank 2 with a certain command on u-boot "qixis_reset altbank". With this command, Board boots from the Bank 2 and now we can boot up kernel on board. Since in this case, we have flashed the images on Bank 2 and even if images are corrupt, Bank 2 will get bricked, but since we have set board to boot from Bank 1 by default, Board will still be usable and you can flash the correct images on Bank 2 and get that working.
So this was the concept and why we are using it. Now when we try to replicate the same behavior with LAVA, we are facing some issues. When we issue command "qixis_reset altbank" on u-boot, it just prints "=>", which lava takes as a success and issue next command and then starts waiting for the "Starting Kernel", which will not happen.
Infact what should happen is that, after "qixis_reset altbank" is issued, lava should wait for some time and let board boot from Bank 2 (On Bank 2 board again will boot the u-boot only). and wait for "Hit Any key to stop autoboot" and then interrupt the board.
Here is job.yaml for your reference. https://git.lavasoftware.org/lava/lava/uploads/2a530894990eca6c69648e6ad637…
Please help me on this, how can i achieve this way of booting the board.
Thanks
Sahil Malhotra
Hi, guys,
When I call `results.get_testcase_results_yaml`, there is a small probability that I will get the error:
Post https://xiaotian:***@lava.sw.nxp.com/RPC2: EOF
What does "EOF" here mean, what could be the possible root cause? Thanks.
Hi, guys,
In lava, if we define e.g. "imx8mm-evk-sh01.jinja2" device dict, and run a job on this device, if possible we could get the name (imx8mm-evk-sh01) of this device directly in test shell?
I don't want to define environment again and again in jinja2 file something like "{% set environment = {'DEVICE_NAME': " imx8mm-evk-sh01"} %}"..., there possible fault & mismatch when define this.
Thanks.
Hi, guys,
We have a scenario like next:
action:
- test
definitions:
- from: inline
name: test1
- test
definitions:
- from: inline
name: test2
For some reasons, we have to use 2 tests here, everything is ok now.
But, if `test1`, that is ` /lava-3102/0/tests/0_test1/run.sh` finished with non-zero, from web we can see the suite fail.
Then, we want to exit the job at once, not continue to run `test2`. If possible here?
Regards,
Larry
Hi everybody,
I'm trying to figure out how to set boot parameters (nfsroot) for a x86 board (Intel NUC10 ).
>From this job definition I understand it's possible using iPXE:
https://lkft.validation.linaro.org/scheduler/job/2959364/definition
But I can't understand what interface is being used to get terminal output and remote control: https://lkft.validation.linaro.org/scheduler/device/x86-01/devicedict
Look's like is using UART, I'm not sure I can get terminal console on boot time on my board (NUC).
The options I can get from the information found are the following (please add any corrections or suggestions):
1) iPXE + terminal console: PXE alone can't get nfsroot settings dynamically. PXE + iPXE should be added to the chain and LAVA should have access to terminal console.
2) iPXE + environment variables: LAVA sets environment variables and PXE + iPXE gets nfsroot settings from environment variables. No terminal console needed.
3) PXE + static folder: LAVA fetches and extract rootfs always to the same folder. PXE reads static configuration file.
4) PXE + dynamic folder: LAVA sets the nfsroot folder name directly on the PXE configuration file (file is machine specific).
5) PXE + INITRAMFS: fetches root file system from file server and extracts to memory.
Let me know your thoughts!
Best Regards
Fabiano
