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…
