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