Differences between revisions 14 and 15
Revision 14 as of 2016-02-06 14:17:42
Size: 6850
Editor: NeilWilliams
Revision 15 as of 2016-02-06 14:18:06
Size: 6871
Editor: NeilWilliams
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
LAVA is now available in Debian unstable: DebPkg:lava-server LAVA is now available in Debian unstable and jessie-backports: DebPkg:lava-server

LAVA is now available in Debian unstable and jessie-backports: lava-server


LAVA is a continuous integration system for deploying operating systems onto physical and virtual hardware for running tests. Tests can be simple boot testing, bootloader testing and system level testing. Extra hardware may be required for some system tests. Results are tracked over time and data can be exported for further analysis.

LAVA has a long history of supporting continuous integration of the Linux kernel on ARM devices (ARMv7 & ARMv8). So if you are testing a Linux kernel image on armhf or arm64 devices, you will find a lot of similar tests already running on the other LAVA instances.

Linaro Cambridge lab


This is the master instance for Linaro. To use devices on this instance, community members can register with Linaro


This is the test instance for the LAVA software team, generally running release candidates for the next upstream release of the LAVA packages.



Deprecated Distributed Deployment support

The former content of this page relates to the deprecated installation methods and submission formats. This content is now at Deprecated Distributed Deployment support and has particular information related to the Collabora instance.

The Debian LAVA instance

http://lava.debian.net is a LAVA instance intended to help Debian Developers. This instance uses the pipeline dispatcher over python-zmq. This allows local devices to be shared amongst developers for LAVA testing.

The goal is that Debian developers can do more testing on a variety of ARM devices using the automation provided by LAVA. By harnessing local devices, including developer boards behind NAT connections and firewalls, LAVA can make testing more visible, easier to access and simple to track over time.

LAVA includes documentation which is updated with each upload.

The advantage of the pipeline design is that it is a lot easier to setup LAVA and use LAVA in a distributed manner. The new design is still evolving and not all devices supported by the old dispatcher have been ported to the new dispatcher but any U-Boot device should be supportable.

Adding devices to the Debian LAVA instance

One of the strengths of LAVA is providing access to a wide range of hardware. With the Debian LAVA instance, this includes individual developers configuring a local machine to serve as a slave, managing a range of local devices.

An advantage of the pipeline model is that the devices remain on the desk of the developer. This does allow for developers to choose to be hands-on to allow a wider range of testing. For example, the developer with physical access to the device can take on management of the bootloader on the board. Although this isn't fully automated bootloader testing, it can support this step which a fully automated LAVA lab cannot.

To add one of your devices to the Debian LAVA instance, follow the steps below:

  • email NeilWilliams to register a new slave with the debian instance - the current slave name will be the fully qualified domain name of the device running lava-dispatcher.

    • This may be a problem for laptops - work is planned upstream to help with this.
    • Ensure that the email is GPG signed with your Debian key
    • Include some details of the type of device(s) the slave can support.
    • Include details of whether this slave will be permanently available or only at times decided by you.
  • Install lava-dispatcher locally.

  • Configure /etc/init.d/lava-slave to point at http://lava.debian.net

    • Keep the default port numbers.
  • Once the slave shows up on http://lava.debian.net/scheduler/allworkers, the full details of device connectivity need to be declared. These are expected to include local hostnames but this is fine as the commands will be run by the slave itself, not from lava.debian.net.

    • The device specific details form a Device Dictionary which is what LAVA will use to select devices, schedule jobs and start jobs on the relevant slave.

    • All device dictionaries include an  extends  field which is a python-jinja2 template supported by LAVA containing the detail of the device-specific commands for this device. The templates exist in the lava-server source, lava_scheduler_app/tests/device-types/. For the 2016.2 release, the supported files are visible here

    • All device dictionaries need to specify  set exclusive = 'True'  to isolate these devices from the deprecated LAVA support which is not usable on lava.debian.net.

Requirements for a LAVA device

Particular types of device will have different details in the device dictionary. For example, a QEMU device will want to limit the amount of memory allocated and a beaglebone-black device will need a connection command to allow the slave to connect to the serial console over a USB FTDI connection. Documentation exists in the lava-server-doc package with examples of the dictionaries of known devices.

Different developers will be able to offer different levels of service, depending on the hardware configuration of their local lab. In particular, not all developers will be able to offer devices on a 24/7 basis as this requires some custom hardware, like a PDU.

Example for a panda device

{% extends 'panda.yaml' %}
{% set exclusive = 'True' %}
{% set hard_reset_command = '/usr/bin/pduclient --daemon tweetypie --hostname pdu --command reboot --port 07' %}
{% set power_off_command = '/usr/bin/pduclient --daemon tweetypie --hostname pdu --command off --port 07' %}
{% set connection_command = 'telnet droopy 4003' %}
{% set power_on_command = '/usr/bin/pduclient --daemon tweetypie --hostname pdu --command on --port 07' %}

This is the Jinja format of the data visible in the UI. Only superusers can export or update this data directly from the database.


There are a number of issues and questions which come to mind when considering how to offer devices to a service like LAVA. Please contact NeilWilliams and use the LAVA support mailing lists.