Hello lava users,
I have to deal with a board with a very limited storage size. Overall capacity is 64 MB, with about 30 MB remaining.
This is a clear limitation for Lava usage. Hence my questions:
* Is there a possibility to configure Lava tests installation on an external storage, such as an USB drive?
* In Lava recent versions, is it possible to optimize the overlay tests structure?
* Today, assuming that tests are stored in a git repo, for each test the complete repo is copied in each overlay
* A balance has to be made between one git containing all the tests and one git per test (extreme configurations)
* Is there a better way to manage this? In a ideal world, that would mean copy only what is needed and not more
Thanks, have a nice day
Hello,
While testing 2020.10 with https enabled, we have noticed the following problem:
In /etc/lava-dispatcher/lava-worker, if we set WS_URL="--ws-url http://<master's address>/ws/" (or do not this variable at all), we get the following error on worker:
2020-11-19 15:14:57,751 INFO PING => server
SSL error in data received
protocol: <asyncio.sslproto.SSLProtocol object at 0x7f9a0d704160>
transport: <_SelectorSocketTransport fd=8 read=polling write=<idle, bufsize=0>>
Traceback (most recent call last):
File "/usr/lib/python3.7/asyncio/sslproto.py", line 526, in data_received
ssldata, appdata = self._sslpipe.feed_ssldata(data)
File "/usr/lib/python3.7/asyncio/sslproto.py", line 207, in feed_ssldata
self._sslobj.unwrap()
File "/usr/lib/python3.7/ssl.py", line 767, in unwrap
return self._sslobj.shutdown()
ssl.SSLError: [SSL: KRB5_S_INIT] application data after close notify (_ssl.c:2609)
Still, even with those errors the worker is fully functional.
Now, the only way to get rid of such errors is to explicitly specify the port, 8001:
WS_URL="--ws-url http://<master's address>:8001/ws/"
Have you experienced similar problems? Did we miss something on our setup?
Thanks a lot,
Philippe
Hi All,
Since 2020.09 it appears that workers using a version different than the master are refusing to start.
Would it be possible to relax this constraint?
With workers spread all over the world in different places, it is hard to synchronize master and slaves upgrades.
Also, we have always run with workers versions <= master version, without a single problem.
So it would be great to allow version mismatch, and maybe print a simple warning when version differs?
Thanks,
Philippe
Hi All,
this is the first time I am communicating with the lava community.
I am facing a problem with the lava installation.
I need step by step installation procedure and after installation one
example demo for the understanding purpose.
(send all steps because I am first time using the lava )
in that, I am facing a problem when I type the command
$sudo apt-get install lava-server
then getting the following error message :
---------------------------------------------------------------------------------------------------------------------------------------------------------
File "/usr/lib/python3/dist-packages/lava_rest_app/v02/routers.py", line 22
from import views
^
SyntaxError: invalid syntax
migration
dpkg: error processing package lava-server (--configure):
installed lava-server package post-installation script subprocess returned
error exit status 1
Errors were encountered while processing:
lava-server
E: Sub-process /usr/bin/dpkg returned an error code (1)
-------------------------------------------------------------------------------------------------------------------------------------------------------------
please send the information from the first command of installation to the
last command of installation which I need to use.
Note: I am using Ubuntu 18.04.5 LTS.
Thank You.
Hi Stevan,
I have followed the steps mentioned in the pages provided by you i.e "
https://docs.lavasoftware.org/lava/installing_on_debian.html#lava-repositor…
"
Still my version is same i.e "2019.01-5"
You can find my complete log at https://justpaste.me/id5P .
Only the thing is that I followed below steps
1. Install Debain buster
2. Run #sudo apt install lava
3. Run #sudo apt install lava-dispatcher
4. #wget https://apt.lavasoftware.org/lavasoftware.key.asc
5. #sudo apt-key add lavasoftware.key.asc
6. #sudo apt update
appreciated any suggestions.
Regards,
Koti
>
> ------------------------------
>
> Message: 3
> Date: Fri, 27 Nov 2020 08:57:14 +0100
> From: Stevan Radakovi? <stevan.radakovic(a)linaro.org>
> To: lava-users(a)lists.lavasoftware.org
> Subject: Re: [Lava-users] How can I upgrade my Lava software to latest
> version (may be 2020.10)
> Message-ID: <6c0c9fb0-069b-142c-59d1-2ff229f37031(a)linaro.org>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Hello,
>
> There's everything regarding releases documented here:
>
> https://docs.lavasoftware.org/lava/installing_on_debian.html#lava-repositor…
> <
> https://docs.lavasoftware.org/lava/installing_on_debian.html#lava-repositor…
> >
> You will need to add LAVA signing key prior as described here:
>
> https://docs.lavasoftware.org/lava/installing_on_debian.html#lava-archive-s…
> <
> https://docs.lavasoftware.org/lava/installing_on_debian.html#lava-archive-s…
> >
>
> Cheers,
>
>
> On 11/27/20 8:31 AM, koti koti wrote:
> > Hi,
> >
> > Recently I have installed Lava-Master and Lava-Dispatcher using the
> > steps mentioned below in the corresponding servers.
> >
> > ??????????????? Server:
> > ???????????????? ######
> > ?????????????????????? ?? 1. #sudo install lava
> > ???????????????? Worker (Dispatcher)
> > ???????????????? ###################
> > ????????????????????????? 1. #sudo install lava-dispatcher
> >
> > But the installeve Lava software version is the old version
> (*2019.01-5*).
> >
> > Now I want to upgrade to latest (*may be 2020.10*) lava
> > (https://git.lavasoftware.org/lava/lava/-/tags
> > <https://git.lavasoftware.org/lava/lava/-/tags>)
> >
> > Please can someone let me know the steps to upgrade my lava version to
> > the latest?
> >
> >
> > Regards,
> > Koti
> >
> > _______________________________________________
> > Lava-users mailing list
> > Lava-users(a)lists.lavasoftware.org
> > https://lists.lavasoftware.org/mailman/listinfo/lava-users
>
> --
> Stevan Radakovi? | LAVA Engineer
> Linaro.org <www.linaro.org> ? Open source software for ARM SoCs
>
>
Hi,
Recently I have installed Lava-Master and Lava-Dispatcher using the steps
mentioned below in the corresponding servers.
Server:
######
1. #sudo install lava
Worker (Dispatcher)
###################
1. #sudo install lava-dispatcher
But the installeve Lava software version is the old version (*2019.01-5*).
Now I want to upgrade to latest (*may be 2020.10*) lava (
https://git.lavasoftware.org/lava/lava/-/tags)
Please can someone let me know the steps to upgrade my lava version to the
latest?
Regards,
Koti
Hi,
Recently I have installed "LAVA-Master" on Server and "LAVA-Worker (On
Remote location)" on Raspberrypi-4 (8GB).
Installation steps:
###############################
###############################
Server:
######
1. #sudo install lava
Worker (Raspberrypi-4)
###################
1. #sudo install lava-dispatcher
Add worker to Master
###############################
###############################
1. sudo lava-server manage device-types add qemu
2. sudo lava-server manage devices add --device-type
qemu --worker raspberrypi qemu-02
3. Now I am able to see "raspberrypi" worker in green
colour state in the master under "LAVA--->Scheduler-->workers".
Problem/issue:
############
1. My QEMU job(Health-check) is still in running state even after 2 days
(Attached the screenshot) even though it is working if my dispatcher is
from the same master server. I feels something I missed here and may be
extra setups to establish proper communication between "Master" and
"Remote-Worker"
Please can someone suggest me as what am I missing to complete my QEMU
job(Health-check) while it running in "Remote-Worker" ?
Regards,
Koti
Dear all,
I have one issue when use one qualcomn's development board:
- test:
definitions:
- from: inline
name: auto_test
path: inline/auto_test.yaml
repository:
metadata:
description: run
format: Lava-Test
name: run
run:
steps:
- lava-test-case "Android_Serial_Case" --shell "./test.py"
docker:
image: myimage
local: true
timeout:
minutes: 1600
The test.py is from our customer, when run it, it show the error:
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/serial/serialposix.py", line 265, in open
self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
FileNotFoundError: [Errno 2] No such file or directory: '/dev/ttyUSB0'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.7/site-packages/serial/serialutil.py", line 240, in __init__
self.open()
File "/usr/local/lib/python3.7/site-packages/serial/serialposix.py", line 268, in open
raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg))
serial.serialutil.SerialException: [Errno 2] could not open port /dev/ttyUSB0: [Errno 2] No such file or directory: '/dev/ttyUSB0'
I have linked the board to pc, and can see the "/dev/ttyUSB0" in my pc, what happened here?
Hi,
We have a test which may need /dev/fuse when run in docker test shell, something like next:
docker run -it --cap-add SYS_ADMIN --device /dev/fuse --security-opt apparmor:unconfined hello
What's the suggestion for this case? Thanks.
Hey,
I would like some advice on properly cleaning up my lava jobs. Following some examples, I now have job definitions that work for me. Each job definition contains a path to all images and the full list of boot commands, which are specific to our image setup and therefore ~40 lines, examples below. I would like to separate the boot commands into the device definition as those should stay stable and we only want to test the image files in the job. I've tried to move the -boot section to both the device definitions or the device type definition, but I did not manage to get a working boot out of that setup. If you would like to know what exactly I tried or need additional debug info, let me know.
I've added @larry.shen@nxp.com as to my understanding he implemented the UUU actions, so maybe he has some good advice on best practices?
Looking forward for some feedback and of cause thanks for the awesome piece of software to the developers!
Best regards, Olli
Example:
actions:
- deploy:
to: uuu
images:
boot:
url: file:///network-share/imx-boot.uuu
initrd:
url: file:///network-share/fitImage-fsl-image-mfgtool.bin
[4 more image files]
- boot:
method: uuu
commands:
# Load SPL and U-Boot
- SDP: boot -f {boot}
- SDPU: delay 1000
- SDPU: write -f {boot} -offset 0x57c00
- SDPU: jump
# run mfgtool ramdisk
- FB: ucmd setenv fastboot_buffer ${loadaddr}
- FB: download -f {initrd}
[ 30 more commands ]