Hi
I setup a LAVA server few years ago, on Debian 9.5 Stretch(with Python
3.5), and it works correctly.
Recently I update the Python to 3.6, but the lava-server not able to
work correctly. eg. the HTTP server does not work.
So I fall back to Python 3.5 and re-install the LAVA server at the same
time, but unfortunately the device does not work this time.
The device status is set to "Bad (Invalid device configuration)" by the
lava-health without any real check.
The device was work correctly, and only change to 'BAD' when health
check job get fail.
Is there any device related option was set to mandatory instead of
optional which cause this issue? How can I identify this issue? I can't
see any Error in the log file at /var/log/lava-server
Thanks,
- Kever
> I actually didn?t upgrade anything myself: I am using your
> docker-compose solution, on a Ubuntu 18.04 host.
Just as a sidenote as I noticed this as well:
We also use the docker-compose setup and while I did not investigate the reasons yet, I can confirm that our mailed notifications are broken since the recent update. I didn't care to much as we check manually either way, but I can confirm from my last e-mail that the "breaking change" was simply a rebuild of the docker compose setup with the latest updates, but no host changes.
- Olli
Hello,
Le lun. 27 sept. 2021 à 17:14, Philippe Mazet (OSS) <
philippe.mazet(a)oss.nxp.com> a écrit :
> I actually didn’t upgrade anything myself: I am using your docker-compose
> solution, on a Ubuntu 18.04 host.
>
> But your image in dockerhub (lavasoftware/lava-server:2021.08) upgraded to
> bullseye, yes.
>
Have you tried creating your own derivative of the
lavasoftware/lava-server:2021.08 image and installing eventlet from pypi?
Rgds
>
>
> Thanks,
>
>
>
> Philippe
>
>
>
>
>
> *From:* Lava-users <lava-users-bounces(a)lists.lavasoftware.org> *On Behalf
> Of *Remi Duraffort
> *Sent:* Monday, September 27, 2021 5:05 PM
> *To:* Philippe Mazet (OSS) <philippe.mazet(a)oss.nxp.com>
> *Cc:* lava-users(a)lists.lavasoftware.org <lava-users(a)lavasoftware.org>
> *Subject:* Re: [Lava-users] Email notifications broken in LAVA 2021.08 ?
>
>
>
> Hello,
>
>
>
>
>
> Le jeu. 23 sept. 2021 à 13:54, Philippe Mazet (OSS) <
> philippe.mazet(a)oss.nxp.com> a écrit :
>
> 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?
>
>
>
> I guess you upgraded to bullseye? Because LAVA 2021.08 hasn't changed
> anything regarding it's requirements.
>
>
>
>
>
> Any idea about how to fix that?
>
>
>
> Depending on which debian version you are using. Either ask a DD to upload
> python-eventlet 0.32 and to upload it to bullseye-backports.
>
>
>
>
>
>
>
> 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
>
> _______________________________________________
> Lava-users mailing list
> Lava-users(a)lists.lavasoftware.org
> https://lists.lavasoftware.org/mailman/listinfo/lava-users
>
>
>
>
> --
>
> Rémi Duraffort
>
> TuxArchitect
>
> Linaro
>
--
Rémi Duraffort
TuxArchitect
Linaro
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
