LAVA V2 as used on the Debian instance is now available in Debian unstable, stretch 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.

This page exists as a supplement to the LAVA documentation, to outline where the Debian instance differs from other LAVA instances. If this page and the packaged documentation disagree, the packaged documentation is correct. Where errors exist or where the documentation is unclear, please file bugs, submit patches and generally let us know. Bugs can be filed in the Debian BTS against lava-server or lava-dispatcher or in the upstream bugtracker linked from the bottom of each page of the UI, whichever you prefer.

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 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.

Submitting jobs to the Debian LAVA instance

  1. The Debian LAVA instance uses DebianSingleSignOn and if you do not have an account in django for the instance, an account will be created for you. As an automatically created account, this account does not automatically give you permission to submit jobs. Email NeilWilliams or ping me on IRC and you can be added to the relevant group which allows you to submit jobs.

  2. The Debian LAVA instance is LAVA V2 only which means that jobs are written in YAML. Currently, all job submissions to the Debian instance are done using XMLRPC or lava-tool. For this, you will need to create an API token.

  3. Follow the LAVA Documentation on submitting your first job.

  4. LAVA supports restricting submissions to particular users and groups and this can be used on the Debian instance to support devices which are not continuously available or which need manual intervention to do a hard reset. Restricted devices are shown in the LAVA UI, including details of who is allowed to submit jobs. Unlike other LAVA instances, the reasons for such restrictions on the Debian instance are likely to be practical rather than issues or privacy or secrecy. Allowing devices to be used under full automation requires an extra investment of hardware and configuration. Not everyone who offers devices to LAVA is able to offer this kind of support.

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.

LAVA supports restricting submissions to particular users and groups and this can be used on the Debian instance to support devices which are not continuously available or which need manual intervention to do a hard reset. Other instances use this support to restrict access to sensitive data like benchmarks. On the Debian instance, the same support is used for a more practical need to avoid jobs failing simply because the device is not completely automated.

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

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

This is an example of a device available on the Debian LAVA instance. This device is attached to a slave which is permanently available and the device is configured in LAVA to provide access to PDU control.

{% 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.

LAVA V1 and V2

LAVA is in the midst of a lengthy migration from V1 to the pipeline V2 model used in the Debian LAVA instance. Not all devices supported by V1 are yet supported in V2 and the methods of support will change dramatically when support in V2 is added. The V1 model is completely unsuited to how the Debian instance needs to operate, so do keep this in mind when comparing device support in the Debian instance to other LAVA instances which are using V1.