> From: wangbo <wangbo.hfut(a)qq.com>
> Date: Thu, 28 Jan 2016 20:39:25 +0800
> Subject: LAVA uninstall and upgrade, build method from the source code
> Hi all,
>
> I installed LAVA on Ubuntu 14.04 in our lab, but later we plan to upgrade the system to Ubuntu 15.10, so what should I do now?
I'm afraid the only long term option is to migrate to Debian Jessie,
possibly using a VM, and then using jessie-backports. It is uncertain
whether it will be possible to support LAVA on the upcoming Ubuntu
Xenial 16.04LTS and support for Trusty has already been frozen. There
have been problems upgrading from 14.04 - these issues have already
been discussed on the lists.
https://lists.linaro.org/pipermail/lava-announce/2015-November/000003.html
The next upload of LAVA should be able to migrate into Ubuntu ahead of
the cut off for the Xenial release but that is outside our control. It
is also unknown whether it will be possible to maintain a system based
on Xenial - the LAVA software team will be unable to maintain such
support and users would need to be proactive in fixing problems that
may arise.
> Because I have already installed LAVA, so should I uninstall it firstly, and then use apt-get install to reinstall LAVA? But I can't find more information about this in the website, can you give me some advice, thanks very much.
https://staging.validation.linaro.org/static/docs/installing_on_debian.html…
The main problems will be with the database, so building in any way
will have the same difficulties. Trusty is, sadly, a dead end at the
moment.
> And, how to install LAVA from the source code?
Not supported - installation is only supported as Debian packages.
LAVA is much more than a pip install / virtualenv can ever manage.
> LAVA includes different parts, like lava-server, lava-dispatcher, lava-tool, etc. So which one should be installed firstly? By the way in the Git, for example "https://git.linaro.org/lava/lava-server.git/tree", there is no document about the install method. Now, I will modify some code to meet our demands in our lab, and then replace the corresponding file. We plan to manage the code with Git too. So if we know the install method from the source code, it will be better to build the code.
There is no documentation for installing from git because the
installation method has moved to using packages. We abandoned the old
install from git methods a long time ago due to interminable bugs and
insolvable dilemmas.
During the migration to the new dispatcher, things are too complex to
support more than Debian Jessie (and the next Debian release,
Stretch). Once the migration is complete (in 2017), the advantages of
the new design should also make it easier to support other operating
systems. We are a long way from that at the moment.
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
Hi Neil et al.
I'd like to have the host record power measurements during a job, or
during a unit-test.
browsing the lava manual, I came across the shell-hooks which seem to
enable what I want to do.
Suppose I want to call a script "capture-start.sh" at the top of the
job, and "capture-stop.sh" at the end, is this the proper way to do stuff:
In the job json:
-------------------
```
{
"command": "lava_test_shell",
"parameters": {
"testdef_repos": [
{
"git-repo": "https://github.com....
/lava-test-definitions.git",
"testdef": "capture-start.yaml"
}
],
"timeout": 1800
}
},
.... dispatcher actions of interest ....
{
"command": "lava_test_shell",
"parameters": {
"testdef_repos": [
{
"git-repo": "https://github.com....
/lava-test-definitions.git",
"testdef": "capture-stop.yaml"
}
],
"timeout": 1800
}
},
```
In the yaml, do I need to override all the handlers ? If I don't need
end_case or postprocess_test_result do I need to fill them, and point to
a "nop.sh" script "?
I assume that I need to provide at lest one step to be done on the
target, even if I am only interested in the host-side commands, would
the following yaml make sense:
```
metadata:
format: Lava-Test Test Definition 1.0
name: power-capture-start
run:
steps:
- lava-test-case pass-test --shell echo starting power measurements
handler:
handler-name: shell-hooks
params:
device_config_vars:
DEVICE_TYPE: device_type
handlers:
start_testcase: capture-start-start-hook.sh
end_testcase: nop.sh
postprocess_test_result: nop.sh
```
Thanks and Regards,
Marc.
Hi all,
I have a basic practical question: I'm trying to reset a panda-es board
with a suitable master image for lava to use with the default
device-types confs, namely with:
lava-dispatcher/device-types/panda-es.conf:bootloader_prompt = U-Boot
so I wrote panda-master-20150303.img.tgz (linaro master-images) to the
sdcard I'm using.
I'd expect u-boot.bin on the boot partition to being compatible with the
expected lava prompt and u-boot command set ('bootz' supported for
instance), but I keep having an incompatible config of u-boot ("Panda"
as a prompt, bootz not supported, etc...), what am I missing?
Thanks and Regards,
Marc.
