Hi!
I'm seeing the following issue with lavasoftware/lava-server:2019.04:
http://localhost/static/docs/v2/ gives "Forbidden". Apache log shows the
following:
[Mon May 06 17:57:42.206713 2019] [autoindex:error] [pid 766:tid 140404225701632] [client 172.18.0.1:46780] AH01276: Cannot serve directory /usr/share/lava-server/static/docs/v2/: No matching DirectoryIndex (index.html,index.cgi,index.pl,index.php,index.xhtml,index.htm) found, and server-generated directory index forbidden by Options directive, referer: http://localhost/
The easiest way to reproduce is to run:
$ docker run --rm -p 80:80 -it lavasoftware/lava-server:2019.04
And load http://localhost/static/docs/v2/
Change 2019.04 to 2019.03 and it works fine.
I didn't see anything about this mentioned in the release announcement.
I guess the apache config needs some update?
Thanks!
Dan
The name of the action for http download uses a hyphen, not an
underscore. Fix the typos.
Signed-off-by: Kevin Hilman <khilman(a)baylibre.com>
---
doc/v2/timeouts.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/v2/timeouts.rst b/doc/v2/timeouts.rst
index c330f9d89548..50070766abe0 100644
--- a/doc/v2/timeouts.rst
+++ b/doc/v2/timeouts.rst
@@ -259,7 +259,7 @@ block override.
timeouts:
actions:
- http_download:
+ http-download:
minutes: 2
.. _individual_connection_timeout_overrides:
@@ -275,7 +275,7 @@ specific connection timeout which can be longer or shorter than the default.
timeouts:
connections:
- http_download:
+ http-download:
minutes: 2
.. _action_block_timeout_overrides:
--
2.21.0
Hello everyone,
the current LAVA version in stretch-backports is still 2018-11. Is there a reason why it has not been updated since then?
Will newer releases go into buster only? Or will there be updates in stretch-backports in the future?
For stretch users, do you recommend using the LAVA repositories to upgrade to the latest version?
Or should production systems keep using 2018-11 at this moment?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com<http://www.garz-fricke.com/>
WE MAKE IT YOURS!
[cid:image001.jpg@01D4FF4A.A2ED9910]
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hello,
as said in the previous email, that's currently not possible to see kernel
crashes outside of the boot action.
That's something we want to improve. I will soon create an issue in our
gitlab instance where you would be able to comment.
Rgds
Le jeu. 11 avr. 2019 à 14:33, Frank, Matthias <Matthias.Frank(a)tq-group.com>
> a écrit :
>
> Hi lava users,
>
>
>
> sometimes I how in memory allocator stress tests a kernel panic. How can I
> evaluate this? Is it possible to set a testcase or job to fail if a kernel
> panic occurs?
>
>
>
> Matthias
>
>
>
> Sometimes a test triggers a kernel panic and the dut will reboot to U-Boot
> and stuck because there is no boot process. Lava waits until timeout and
> stop the job.
>
>
>
--
Rémi Duraffort
LAVA Team, Linaro
Hi,
I'd like to know is this site official? https://github.com/kernelci/lava-docker
Does this project same as the one in dockerhub, lavasoftware/lava-server?
I attach a tag on one of my device, and when submit job I will add "tags:" to my job, it's ok.
But, when others submit their job with same device-type which same as my device, as they did not specify "tags", they will have chance to run their job on my device.
How to avoid it? I want the job not be scheduled to the device which have a tag if the job did not specify any tag.
I tried to set the device as private, but then only me can use this device, I have other guys in groupA which want to use the device, while I hae another some guys in groupB which didid not want to use these devices as some modules on the device is not same.
Hi,
There is an idea of device type 'alias' in LAVA. I don't quite
understand what the use case for the current implementation was [1]. I
tried using it but it wasn't very useful. My use case is that I need
to submit jobs to a device type with different device type name. This
is used to align device type naming between different labs in a bigger
project (kernelci.org in this case). So the questions I have about
current implementation:
- is there anyone using current implementation?
- if current implementation is used, how much trouble would it cause
to change the behaviour?
Change in behaviour is quite intrusive and will require database migration.
[1] https://master.lavasoftware.org/static/docs/v2/glossary.html#term-alias
Regards,
milosz
Hi lava users,
sometimes I how in memory allocator stress tests a kernel panic. How can I evaluate this? Is it possible to set a testcase or job to fail if a kernel panic occurs?
Matthias
In case that 'systemd' is one of the ptest to run and to avoid some
test cases failure in the systemd ptest, we need to export the proper
directory that contains the needed systemd test data.
This patch exports the needed test data directory.
Signed-off-by: Khouloud Touil <ktouil(a)baylibre.com>
---
automated/linux/ptest/ptest.yaml | 1 +
automated/linux/ptest/set-systemd-test-data.sh | 18 ++++++++++++++++++
2 files changed, 19 insertions(+)
create mode 100755 automated/linux/ptest/set-systemd-test-data.sh
diff --git a/automated/linux/ptest/ptest.yaml b/automated/linux/ptest/ptest.yaml
index 6205c11..85f6893 100644
--- a/automated/linux/ptest/ptest.yaml
+++ b/automated/linux/ptest/ptest.yaml
@@ -21,5 +21,6 @@ params:
run:
steps:
- cd ./automated/linux/ptest
+ - ./set-systemd-test-data.sh $TESTS
- PYTHONIOENCODING=UTF-8 ./ptest.py -o ./result.txt -t ${TESTS} -e ${EXCLUDE}
- ../../utils/send-to-lava.sh ./result.txt
diff --git a/automated/linux/ptest/set-systemd-test-data.sh b/automated/linux/ptest/set-systemd-test-data.sh
new file mode 100755
index 0000000..0a26b4b
--- /dev/null
+++ b/automated/linux/ptest/set-systemd-test-data.sh
@@ -0,0 +1,18 @@
+#!/bin/bash
+#------------------------
+# Some systemd tests needs systemd test data
+# to pass.
+# This script test when there is systemd tests
+# and set the systemd test data
+#------------------------
+tests="$*"
+test_dirs=['/usr/lib/systemd/ptest/tests/test', '/usr/lib64/systemd/ptest/tests/test', '/usr/lib32/systemd/ptest/tests/test']
+for t in $tests; do
+ if [ "$t" == "systemd" ]; then
+ for dir in test_dirs ; do
+ if [ -e "$dir" ]; then
+ export SYSTEMD_TEST_DATA=$dir
+ fi
+ done
+ fi
+done
\ No newline at end of file
--
2.17.1
Hi lava users,
I have tested lava-os-build on my ptxdist root images and I got this output:
root@MBa6x:/lava-557/bin ./lava-os-build
_____ ___ ____ _
|_ _/ _ \\ / ___| _ _ ___| |_ ___ _ __ ___root@MBa6x:/lava-557/bin
Maybe it's better to look for other files first, like /etc/os-release (or /usr/lib/os-release) for systemd systems.
This file is (more) standardized way to detect with os/build is running by evaluating the keys NAME,PRETTY_NAME etc.
What is the exact function of lava-os-build? Only diagnostic purpose to find out with os is running? Does something else rely on lava-os-build? What could break if I change that script?
Matthias
[0] https://www.freedesktop.org/software/systemd/man/os-release.html
Hi,
Are the Ansible playbook for setting up LAVA available somewhere? There is
an old migrated issue on GitLab [1] which is closed, but the link to an
implementation in there is dead. Is that playbook only internally available
for Linaro? Is there anything you could share?
It looks like many people are moving to Docker in the moment, but that's
not an option for us (at least not for dispatchers), as we need LXC for
Android testing.
Cheers,
Karsten
[1] https://git.lavasoftware.org/lava/lava/issues/27
Hi all,
The LAVA docs mention that it's possible to enable template caching via
settings.conf [1]. However, doing so leads to a key error when starting the
LAVA gunicorn server and in `lava-server manage check --deploy`:
...
File "/usr/lib/python3/dist-packages/lava_server/settings/distro.py",
line 185, in <module>
("django.template.loaders.cached.Loader",
TEMPLATES[0]["OPTIONS"]["loaders"])
KeyError: 'loaders'
The LAVA git history shows that this dictionary key was removed in commit
6705ec870[2], "Refresh the setting files".
Is this just a bug in LAVA, is Django template caching not supported
anymore with LAVA, or are other Debian/pip packages required to be
installed to enable to cache?
I'm currently testing that on Debian buster, which ships Django version
1.11.
Cheers,
Karsten
[1]
https://validation.linaro.org/static/docs/v2/advanced-installation.html?hig…
[2]
https://git.lavasoftware.org/lava/lava/commit/6705ec870c1f30ea0b7f78f05a322…
Hi lava-users,
I upgrade my lava-server package (from backports) to 2019-03 on debian stretch. After this is get an django error:
ERROR 2019-04-04 08:24:16,694 exception Invalid HTTP_HOST header: '<my-host-name>'. You may need to add '<my-host-name>' to ALLOWED_HOSTS.
The browser reports a Bad Request (400)
So I added <my-host-name> and "*" to ALLOWED_HOSTS in /usr/lib/python3/dist-packages/lava_scheduler_app/settings.py and /usr/lib/python3/dist-packages/django/conf/global_settings.py but the error is still present. Are these the wrong file or what could be the problem?
Matthias
Job definition & Detailed log in attachment
发件人: Xiaomingwang (Steve)
发送时间: 2019年4月4日 10:29
收件人: lava-users(a)lists.lavasoftware.org
抄送: Yewenzhong (jackyewenzhong) <jack.yewenzhong(a)huawei.com>; Chenchun (coston) <chenchun7(a)huawei.com>; liucaili (A) <liucaili2(a)huawei.com>
主题: 转发: Lava Issue: API-Error-server.scheduler.all_devices
发件人: liucaili (A)
发送时间: 2019年4月4日 10:24
收件人: Xiaomingwang (Steve) <xiaomingwang1(a)huawei.com<mailto:xiaomingwang1@huawei.com>>
主题: Lava Issue: API-Error-server.scheduler.all_devices
Dear Sir/Madam,
If possible could you please help us analyze the problems encountered in recent Lava tests?
Job definition & Detailed log in the attachment.
lava-dispatcher version: 2018.11+stretch.
The key information is as follows:
python /usr/local/bin/module_deploy.py --DUT cloudgame4_01
Traceback (most recent call last):
File "/usr/local/bin/module_deploy.py", line 37, in <module>
main(args)
File "/usr/local/bin/module_deploy.py", line 30, in main
module = get_module(dut)
File "/usr/local/bin/module_deploy.py", line 14, in get_module
devices_list = server.scheduler.all_devices()
File "/usr/lib/python2.7/xmlrpclib.py", line 1243, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python2.7/xmlrpclib.py", line 1602, in __request
verbose=self.__verbose
File "/usr/lib/python2.7/xmlrpclib.py", line 1283, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib/python2.7/xmlrpclib.py", line 1316, in single_request
return self.parse_response(response)
File "/usr/lib/python2.7/xmlrpclib.py", line 1493, in parse_response
return u.close()
File "/usr/lib/python2.7/xmlrpclib.py", line 800, in close
raise Fault(**self._stack[0])
xmlrpclib.Fault: <Fault -32603: "Internal Server Error (contact server administrator for details): 'NoneType' object has no attribute 'pk'">
Is it a lava bug? We look forward to your reply. Thank you for your assistance.
Best Regards,
Caili Liu
Hi,
I want to measure some output values of test cases. I have a shell script which run stress-ng, parse it's output and exports some measurement variables.
How can I record theses variables? I tried to use lava-test-case -shell myscript.sh -result pass -measurement $VAR1 -unit unit but no values are recorded. Maybe this is the wrong approach, but how can I do this in the correct way?
Matthias
Hello lava users,
how can I run a multinode job on specific devices instead of (a possible set) of device_types? I plan to run CAN or RS485 communication tests which requires a wired connection between duts. Is is possible to submit a job to theses special duts or should is have device_types with only on device instance?
Greetings,
Matthias
Hi Sirs,
Does LAVA support MCU like system? Which usually using a debugger to download image to a MCU internal flash, and get uart result?
Regards,
Hake
How can you have more than one LAVA user have the same token secret
(e.g. for a notify callback.)?
Example use case:
- LAVA job with notify callbacks using token names
- submited as user "bob", token names of "bob" map to actual token secrets
- job fails
- user "lab-admin" fixes some lab issues, re-submits job
- job passes, but callbacks fail because tokens are associated with user "bob"
Since the re-submitted job runs as user "lab-admin", the same token
names and corresponding secrets don't exist.
Naively, user "lab-admin" tries to copy the token secrets from user
"bob" keeping the same token names, but this fails saying that "secret
already exists".
Why can't different users have the same secrets?
I haven't looked at the code, but this limitation kind of suggests that
the secret itself is the key in the db, which would prevent multiple
secrets of the same.
Kevin
Hello lava users,
I use in a test job linuximage, rootfs and dtb from file server location retrieved via http. These files are nightly build from Jenkins. The file links are static so I can use new images within the same test job definition.
Jenkins generates also a build information text file with commit IDs an so on.
How can I integrate the content of this file in the job metadata or job result log? Using metadata: build-readme: <link> in the job definition is not possible because the link is stable over different build, but the file content is changing.
The DUT has no access to the file location because it is in an isolated network. Is there a way to cat the file content on the worker to metadata or job result?
Greetings,
Matthias
Hello lava users,
my lava 2019.01 shows me a device with Health == Bad. The Transitions log give that message:
March11, 3:02p.m.
lava-health
Good → Bad (Invalid device configuration)
Where can I found information about a misconfigured device? The log files did not provide (in my eyes) sufficient information.
As Health checks I use the smoke-tests.
Kinds Regards,
Matthias
I use lxc-mocker in docker container, everything is ok.
Just if the package did not install in advance, then next command will hang in web:
lxc-create -t ubuntu -n test_lava -- --release xenial --mirror http://mirror.bytemark.co.uk/debian --packages systemd,systemd-sysv --arch amd64
I enter the container, see:
root@df67cf292479:/# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 17:20 pts/0 00:00:00 /usr/bin/python3 /usr/bin/lava-slave --level DEBUG --log-file - --master tcp://192.168.1.10:5556 --socket-a
root 8 0 0 17:20 pts/1 00:00:00 /bin/bash
root 13 1 0 17:20 pts/0 00:00:00 lava-run [job: 837]
root 19 13 0 17:20 pts/0 00:00:00 /bin/bash /usr/bin/lxc-create -q -t ubuntu -n test_lava -- --release xenial --mirror http://mirror.bytemark.c
root 261 19 1 17:20 pts/0 00:00:00 apt-get -q install -y systemd systemd-sysv
root 473 8 0 17:21 pts/1 00:00:00 ps -ef
Seems "apt-get install" hang, but if I pre-install the systemd,etc, then everything will ok, the lxc-create will not hang. The same for lxc-attach mocker etc, all will hang if do "apt-get install" & no pakcage preinstall.
Please suggest, thanks.
I started playing with the official lava images today and wanted to
share my work in progress, in case others are doing something similar or
have feedback. My goal is to deploy a lava lab locally. My architecture
is a single host (for now) that will host both the lava server and one
dispatcher. Once it's all working, I'll start deploying a qemu worker
followed by some actual boards (hopefully).
So far, I have the following docker-compose.yml:
version: '3'
services:
database:
image: postgres:9.6
environment:
POSTGRES_USER: lavaserver
POSTGRES_PASSWORD: mysecretpassword
PGDATA: /var/lib/postgresql/data/pgdata
volumes:
- ${PWD}/pgdata:/var/lib/postgresql/data/pgdata
server:
image: lavasoftware/amd64-lava-server:2018.11
ports:
- 80:80
volumes:
- ${PWD}/etc/lava-server/settings.conf:/etc/lava-server/settings.conf
- ${PWD}/etc/lava-server/instance.conf:/etc/lava-server/instance.conf
depends_on:
- database
dispatcher:
image: lavasoftware/amd64-lava-dispatcher:2018.11
environment:
- "DISPATCHER_HOSTNAME=--hostname=dispatcher.lava.therub.org"
- "LOGGER_URL=tcp://server:5555"
- "MASTER_URL=tcp://server:5556"
With that file, settings.conf, and instance.conf in place, I run 'mkdir
pgdata; docker-compose up' and the 3 containers come up and start
talking to each other. The only thing exposed to the outside world is
lava-server's port 80 at the host's IP, which gives the lava homepage as
expected. The first time they come up, the database isn't up fast enough
(it has to initialize the first time) and lava-server fails to connect.
If you cancel and run again it will connect the second time.
A few things to note here. First, it doesn't seem like a persistent DB
volume is possible with the existing lava-server container, because the
DB is initialized at container build time rather than run-time, so
there's not really a way to mount in a volume for the data. Anyway,
postgres already solves this. In fact, I found their container
documentation and entrypoint interface to be well done, so it may be a
nice model to follow: https://hub.docker.com/_/postgres/
The server mostly works as listed above. I copied settings.conf and
instance.conf out of the original container and into ./etc/lava-server/ and
modified as needed.
The dispatcher then runs and points to the server.
It's notable that docker-compose by default sets up a docker network, allowing
references to "database", "server", "dispatcher" to resolve within the
containers.
Once up, I ran the following to create my superuser:
docker-compose exec server lava-server manage users add --staff --superuser --email dan.rue(a)linaro.org --passwd foo drue
Now, for things I've run into and surprises:
- When I used a local database, I could log in. With the database in a
separate container, I can't. Not sure why yet.
- I have the dreaded CSRF problem, which is unlikely to be related to
docker, but the two vars in settings.conf didn't seem to help. (I'm
terminating https outside of the container context, and then proxying
into the container over http)
- I was surprised there were no :latest containers published
- I was surprised the containers were renamed to include the
architecture name was in the container name. My understanding is
that's the 'old' way to do it. The better way is to transparently
detect arch using manifests. Again, see postgres/ as an example.
- my pgdata/ directory gets chown'd when I run postgres container. I see
the container has some support for running under a different uid,
which I might try.
- If the entrypoint of server supported some variables like
LAVA_DB_PASSWORD, LAVA_DB_SERVER, SESSION_COOKIE_SECURE, etc, I
wouldn't need to mount in things like instance.conf, settings.conf.
I pushed my config used here to
https://github.com/danrue/lava.home.therub.org. Git clone and then run
'docker-compose up' should just work.
Anyway, thanks for the official images! They're a great start and will
hopefully really simplify deploying lava. My next step is to debug some
of the issues I mentioned above, and then start looking at dispatcher
config (hopefully it's just a local volume mount).
Dan
Hi,
In most cases, we don't need multiple node job as we can control AOSP
DUT from lxc via adb over USB. However, here is the use case.
CTS/VTS tradefed-shell --shards option supports to split tests and run
them on multiple devices in parallel. To leverage the feature in LAVA,
we need multinode job, right? And in multinode job, master-node lxc
needs access to DUTs from salve nodes via adb over tcpip, right?
Karsten shared a job example here[1]. This probably is the most
advanced usage of LAVA, and probably also not encouraged? To make it
more clear, the connectivity should look like this.
master.lxc <----adb over usb----> master.dut
master.lxc <----adb over tcpip ---> slave1.dut
master.lxc <----adb over tcpip ---> slave2.dut
....
I see two options for adb over tcpip.
Option #1: WiFi. adb over wifi can be enabled easily by issuing adb
cmds from lxc. I am not using it for two reasons.
* WiFi isn't reliable for long cts/vts test run.
* In Cambridge lab, WiFi sub-network isn't accessible from lxc
network. Because of security concerns, there is no plan to change
that.
Option #2: Wired Ethernet. On devices like hikey, we need to run
'pre-os-command' in boot action to power off OTG port so that USB
Ethernet dongle works. Once OTG port is off, lxc has no access to the
DUT, then test definition should be executed on DUT, right? I am also
having the following problems to do this.
* Without context overriding, overlay tarball will be applied to
'/system' directory and test job reported "/system/bin/sh:
/lava-247856/bin/lava-test-runner: not found"[2].
* With the following job context, LAVA still runs
'/lava-24/bin/lava-test-runner /lava-24/0' and it hangs there. It is
tested in my local LAVA instance, test job definition and test log
attached. Maybe my understanding on the context overriding is wrong, I
thought LAVA should execute '/system/lava-24/bin/lava-test-runner
/system/lava-24/0' instead. Any suggestions would be appreciated.
context:
lava_test_sh_cmd: '/system/bin/sh'
lava_test_results_dir: '/system/lava-%s'
I checked on the DUT directly, '/system/lava-%s' exist, but I cannot
really run lava-test-runner. The shebang line seems problematic.
--- hacking ---
hikey:/system/lava-24/bin # ./lava-test-runner
/system/bin/sh: ./lava-test-runner: No such file or directory
hikey:/system/lava-24/bin # cat lava-test-runner
#!/bin/bash
#!/bin/sh
....
# /system/bin/sh lava-test-runner
lava-test-runner[18]: .: /lava/../bin/lava-common-functions: No such
file or directory
--- ends ---
I had a discussion with Milosz. He proposed the third option which
probably will be the most reliable one, but it is not supported in
LAVA yet. Here is the idea. Milosz, feel free to explain more.
**Option #3**: Add support for accessing to multiple DUTs in single node job.
* Physically, we need the DUTs connected via USB cable to the same dispatcher.
* In single node job, LAVA needs to add the DUTs specified(somehow) or
assigned randomly(lets say both device type and numbers defined) to
the same lxc container. Test definitions can take over from here.
Is this can be done in LAVA? Can I require the feature? Any
suggestions on the possible implementations?
Thanks,
Chase
[1] https://review.linaro.org/#/c/qa/test-definitions/+/29417/4/automated/andro…
[2] https://staging.validation.linaro.org/scheduler/job/247856#L1888
Dear All,
I'm currently trying to check and implement a complete validation of my
PSCI solution.
The standard behavior for PSCI is to manage shutdown, reset and low
power mode.
I'm wondering to find the best way to manage it through LAVA.
So two questions:
- Is there a proper way to check the reboot behavior on a target (soft
reboot)? Using shell command is not possible as the is no return from
reboot.
- Shutdown? I'm wondering to test the shutdown command and trig an
automatic wake up after x seconds. My wish is to check that no watchdog
occurred during that time (which is the only way to know if the shutdown
was properly working). So it will be a similar behavior that the reboot
command.
Thanks for your support,
BR
Lionel
Hi Remi
Thanks for the quick reply. Attached please find the document(the raw job log and the job definition).
Hello,
that's in fact maybe a bug in LAVA. To help me reproduce the error, could you send:
* the raw job log (click on "actions / plain logs" in the job page)
* the job definition
Thanks
Le jeu. 21 févr. 2019 à 04:05, Chenchun (coston) <chenchun7(a)huawei.com<mailto:chenchun7@huawei.com>> a écrit :
Dear Sir/Madam,
could you please help us analyze the problems encountered in recent Lava tests?
Detailed log in the attachment.
lava-dispatcher version: 2018.11+stretch.
The key information is as follows: Bug error: argument of type 'NoneType' is not iterable
Chase Qi preliminary positioning is a lava bug. We look forward to your reply.
Thank you for your assistance.
Best Regards,
Caili Liu
_______________________________________________
Lava-users mailing list
Lava-users(a)lists.lavasoftware.org<mailto:Lava-users@lists.lavasoftware.org>
https://lists.lavasoftware.org/mailman/listinfo/lava-users
--
Rémi Duraffort
LAVA Team, Linaro
Hello everyone,
I know from the LAVA documentation how to add metadata to jobs and test suites. When I look at test results, I see that test cases have metadata, too. E.g. https://validation.linaro.org/results/testcase/9759970 shows the following metadata:
case: linux-linaro-ubuntu-lscpu
definition: 0_smoke-tests-lxc
result: pass
Is there a possibility to add custom metadata to test cases?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz
Hi.
To make customized performance regression test job, I need to change
Lava job status as I want.
When I run test like kselftest, Lava dispatcher run test program under DUT.
And after finishing lava test job, Job state is always 'Complete'
whatever result(pass/fail) each test return.
Attached image file is about kselftest result from lava test job.
I want to make lava job status as 'Fail' or 'Canceled' when certain test
return fail.
I would like to ask your advice.
Best regards
Seoji Kim
Dear Sir/Madam,
could you please help us analyze the problems encountered in recent Lava tests?
Detailed log in the attachment.
lava-dispatcher version: 2018.11+stretch.
The key information is as follows: Bug error: argument of type 'NoneType' is not iterable
Chase Qi preliminary positioning is a lava bug. We look forward to your reply.
Thank you for your assistance.
Best Regards,
Caili Liu
Hi all,
Yesterday, we faced a weird issue with LAVA.
A job was running and returned an error saying "metadata is too long".
Right after that, the worker that was running the job went offline, and the
lava-master
raised an "unknown exception", making it crash.
In attachement, you will find the full job error saying metadata is too
long,
the full job log, and the lava-master.log when the exception occured.
Hope this helps.
Axel
I use next command to start lavadispatcher:
docker run -idt --net=host --privileged -v /dev:/dev -v /var/lib/lava/dispatcher/tmp:/var/lib/lava/dispatcher/tmp -e "DISPATCHER_HOSTNAME=--hostname=myname" -e "LOGGER_URL=tcp://master_ip:5555" -e "MASTER_URL=tcp://master_ip:5556" --name test_lava lavasoftware/lava-dispatcher:2019.01
In container, I start tftp and nfs. But the nfs always cannot be start successfully. I use "service nfs-kernel-server start" to start it, also before that I did "rpcbind".
The start shows below seems ok:
# service nfs-kernel-server start
[ ok ] Exporting directories for NFS kernel daemon....
[ ok ] Starting NFS kernel daemon: nfsd mountd.
But if do next we can see the nfs still not start.
# service nfs-kernel-server status
nfsd not running
Any suggestion?
Hello,
We've been using uboot-ums for WaRP7 but we've been having intermittent failures when it tried to run dd to flash the image.
Provided we need to look better into the root cause of this issue, we'd like to make the flashing phase a little more reliable.
I have few questions, coming from different angles:
* LAVA uses dd command to flash the image. Is there a way to specify the usage of bmap-tools?
* let's say dd times out (this is what usually happen). Is there a mechanism to restart the actions (deploy and boot) in case of timeout?
If you have any other suggestion, let me know!
Cheers
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi,
I have a test step that requires user input to a defined prompt.
Is there a way I can automate this in LAVA ?
I can see how we do this for Boot Actions and I've looked at interactive jobs that communicate to U-boot but these don't seem to fit my use case.
Thanks.
Pete
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi All,
I am new to Android testing, I am using standard board *i.mx6/rpi3* and
flashed Android on it, I can connect with these board using "adb" tool.
I want to do some system test using LAVA framework, and I don't want to
reflash image every time(wants to test on the existing system). Can someone
please let me know how I can do Android testing on existing flashed image?
Thanks,
Ankit
Dear Lava users,
Our embedded SW offers 3 boot modes, selectable from u-boot.
When booting, u-boot offers the possibility to select the boot mode:
Select the boot mode
1: <boot mode 1>
2: <boot mode 2>
3: <boot mode 3>
Enter choice: 1: <boot mode 1>
<boot mode 1> is a default value, used after a counter has expired.
All this is done using the extlinux feature.
We have scripts that allow to select the boot mode, using Kermit. Now, we'd like to integrate this boot mode selection in a Lava job, and our current solution is not compatible.
In Lava we may boot the kernel, modify the extlinux configuration and reboot, but do you know a direct way (with interactive mode maybe) to select the boot mode from u-boot?
Best regards,
Denis
Hello everyone,
I am having problems with timeouts when using the LAVA multinode protocol. Assume the following minimal pipeline with two nodes (device = DUT, remote = some kind of external hardware interfacing with the DUT):
- deploy:
role: device
- boot:
role: device
- deploy:
role: remote
- boot:
role: remote
- test:
role: remote
- test:
role: device
What I would expect: The device is booted first, then the remote is booted. Afterwards, the tests run on both nodes, being able to interact with each other.
The pipeline model seems to be implemented in a way that each node has its own pipeline. This kind of makes sense, because the tests of course have to run simultaneously.
However, in my case booting the device takes a lot more time than booting the remote. This makes the 'test' stage on the remote run a lot earlier than the 'test' stage on the device.
My problem: How do I define a useful timeout value for the 'test' stage on the remote? Obviously I have to take the boot time difference between the two nodes into account. This seems counter-intuitive to me, since the timeout value should affect the actual test only. What happens if I use an image on the device which takes even a lot more time to boot? Or if I insert more testcases on the device which do not need the remote before? In both cases I would have to adjust the timeout value for the remote 'test' stage.
Is this a design compromise? Or are there any possibilities of synchronizing pipeline stages on different nodes? I am thinking of some mechanism like "do not start 'test' stage on remote before 'boot' stage on device has finished".
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hi,
Is there a way to specify an arbitrary parameter, that is board
specific, in device dictionary? The parameter should be available from
test shell. The use case is as follows: DUT is connected to test
supporting hardware (chamelium board in this case). Tests access
supporting hardware using IP address. IP address is 'static' and the
supporting hw is assumed to be always turned on. Supporting hardware
is dedicated to specific DUT and can't be shared (because of HW
connections) between other boards of the same type (similar to energy
probes). Tests run directly on DUT and access supporting hardware from
there.
I found 'exported parameters' in device dictionary docs:
https://master.lavasoftware.org/static/docs/v2/lava-scheduler-device-dictio….
But they only list device_ip, device_mac and storage_info. Is there a
way to extend this list? If not, is there any other way to provide
device specific information to test shells?
milosz
Hi everyone,
I'm writing this email after discussion with Neil.
I'm working at NXP and he told me Linaro wanted to run functional tests on
imx8m
with the new u-boot support.
He told me it requires full open access, no license click-through or
passwords.
Philippe Mazet is more qualified to answer this type of question as I only
use Android atm. He will follow up the discussion.
Here you have the Yocto source code :
https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-l…
You can get the latest GA release with this :
repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b
imx-linux-sumo -m imx-4.14.78-1.0.0_ga.xml
You can build these sources like this :
DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source ./fsl-setup-release.sh -b
build
But, this will redirect you to a license click-through.
However, you can bypass the license click-through, like "auto accept it"
with this command :
EULA=1 DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source
./fsl-setup-release.sh -b build
We use this bypass to automate builds.
So, let us know if this would be suitable for Linaro's needs.
Best regards,
Axel
Hello Lava-users,
Do we have support in LAVA for deploying to target the SWUpdate images
directly if target supports the swupdate image deployment(
http://sbabic.github.io/swupdate/).
Thanks,
Hemanth.
Hi all,
We're planning to use TI AM4378 IDK in the board farm for testing (http://www.ti.com/tool/TMDSIDK437X) but it seems there is not device-type for this board. I tried to search from these links:
- https://git.lavasoftware.org/lava/lava/tree/master/lava_scheduler_app/tests…
- https://git.linaro.org/lava/lava-lab.git/tree/shared/device-types
Did I just miss it, or is it missing from the device-types? If it is missing, are there any templates available / what template could be used as a base for the device
Br
Olli Väinölä
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi All,
I have a Rpi3 board with android install on it, it can be accessed using
adb from my Linux PC.
I am successfully able to use Lava-LXC for testing a device.
Can someone please share the steps how I can use LAVA to test an android
device and how the setup will look like. If anyone can share a test job
with some basic android tests would be very helpful.
Thanks,
Ankit