lava-users

lava-users@lists.lavasoftware.org

2 participants
949 discussions

2026.01 release is out

by Milosz Wasilewski

Hi, 2026.01 release was tagged yesterday. Here are the release notes: https://gitlab.com/lava/lava/-/wikis/releases/2026.01 Please report any issues you find during the deployment or when using. Best Regards, Milosz

5 months, 1 week

Sudden 100% Increase in Test Execution Time on Device i.MX6SOLO rev1.4 996 MHz

by pawanKumar

Hello Everyone, I am seeking assistance with a performance regression observed on an i.MX6SOLO rev 1.4 (996 MHz) board in our LAVA farm. The Issue: A test suite containing 90 test cases, which previously took 10 minutes to complete, is now consistently taking 20 minutes. This issue is unique to this one specific board; other boards of the same type are still completing the run in 10 minutes using the same build/firmware. Observations: - I'm not using any test_character_delay externally in my YAML. - Identical Logs: The "Fast" and "Slow" jobs produce identical serial output. - Recent Hangs: The test run has recently started to get stuck/hang mid-run, even though CPU usage is not at 100%. Debugging Performed: - Verified that CPU thermal throttling is not active. - Network latency and DNS resolution times appear normal. - No hardware errors are reported in dmesg. - Swapped power supplies and network cables with no improvement. Questions: 1. What is the best way to debug "dead time" between lava-test-case signals? 2. Could the LAVA worker be experiencing serial buffer delays on this specific node that don't appear in the logs? Thank you for your time. Best Regards Pavan Kumar

5 months, 3 weeks

Dropping support for debian 11

by Milosz Wasilewski

Hello LAVA users! Debian 11 bullseye is nearing close to EOL (August 2026). We're planning to retire LAVA support for it in the 2026.03 release. If that breaks your setup and there is a good reason to keep the support for longer, please respond to this message. Dropping debian 11 will allow to remove a few workarounds in LAVA that are currently included in the code. Best Regards, Milosz

6 months

Passing runtime parameters to user_commands in device configuration

by מור נגלי

Hello LAVA community, I'm working with LAVA for automated testing of embedded systems with BMC (Baseboard Management Controller) and I've encountered a limitation that I'd like to ask about. My Use Case I'm testing devices that support Redfish API for power management. I need to execute various Redfish commands (forceoff, poweron, forcerestart, etc.) from the dispatcher during test jobs. Currently, I define these as user_commands in my device dictionary: jinja2 {% set user_commands = { 'redfish_forceoff': { 'do': '/opt/lava-lab/shared/lab-scripts/dispatcher_command.sh 192.168.17.111 forceoff' }, 'redfish_poweron': { 'do': '/opt/lava-lab/shared/lab-scripts/dispatcher_command.sh 192.168.17.111 poweron' }, # ... more commands} %} Then in my job file: yaml - command: name: redfish_forceoff The Problem Every time I need to add a new Redfish action, I must modify the device dictionary (Jinja file) to add a new user_command entry. I'd like users to be able to specify the action dynamically from the job file without requiring device configuration changes. *What I want to achieve:* yaml # In job file - specify action dynamicallycontext: redfish_action: forceoff actions: - command: name: redfish_command # Generic command that uses context variable What I've Investigated 1. *Deploy actions* support variable substitution (e.g., {IMAGE}), but this is hardcoded for deploy actions only 2. *Job context variables* can override device dictionary values, but only at device configuration rendering time (job parsing), not at action execution time 3. *user_commands* are static strings with no runtime parameter substitution mechanism 4. *Test definitions* support parameters, but they run on the DUT, not the dispatcher I understand from the documentation that dispatcher commands are intentionally restricted for security reasons, which makes sense. My Current Workaround I'm using Jinja2 loops to auto-generate commands from a list: jinja2 {% set redfish_actions = ['auth_test', 'forceoff', 'poweron', 'forcerestart'] %}{% set user_commands = {} %}{% for action in redfish_actions %} {% set _ = user_commands.update({'rf_' + action: {'do': rf_script + ' ' + action}}) %}{% endfor %} This reduces the pain (just add one word to a list), but still requires device configuration edits. My Questions 1. *Is there any mechanism I've missed* that allows passing runtime parameters from job files to user_commands? 2. *Is this a known limitation* that others have encountered? 3. *Would it be feasible* to add support for parameter substitution in user_commands (similar to how deploy actions work with {IMAGE}), while maintaining security constraints? 4. *Are there alternative approaches* within LAVA's architecture that I should consider? Any guidance or suggestions would be greatly appreciated. If this is a feature that doesn't exist but would be useful, I'd be happy to discuss potential implementation approaches or contribute to a feature request. Thank you for your time and for maintaining LAVA! Best regards, Mor

8 months

Configure SSL certifcate

by Gregory Machin

Hi, can you point me to a document for the configuration of SSL certificate on the Lava Docker image ? Thank you. Greg

9 months, 1 week

Call for LAVA maintainers

by Remi Duraffort

Hello LAVA users and developers, LAVA has been around and useful for a lot of people for a long time. For some years now, the list of LAVA maintainers as been shrinking down to 2 or even 1 developer (payed by Linaro). In order to review all the patches that the LAVA developers are pushing, we are looking for developers that want to become maintainer. The idea would be to delegate some part of the maintenance of LAVA sub-systems to some developers. If you are interested, please reach out to me in the lava-users ML, privately or in the new LAVA discord server at https://discord.gg/4dVatqyw Thanks for your attention. -- Rémi Duraffort Principal Tech Lead LAVA Tech Lead Automation Software Team Linaro

9 months, 1 week

Connect a device through serial without PDU

by Ali Tariq

Hello, I am trying to connect a RISC-V VisionFive 2 device with the LAVA web server. I do not have a PDU at the moment and I do not know which one will be appropriate for this device setup. The LAVA master and worker are running on the same machine, so I have localhost set up. I added the following device dictionary for VisionFive 2. {% extends 'jh7100-visionfive.jinja2' %} {% set console_backend = 'serial' %} {% set serial_port = '/dev/ttyUSB0' %} {% set serial_baud_rate = 115200 %} The dictionary template, which is extended for VisionFive 2, is from the VisionFive 1 device type. As I won't be needing initramfs and other uboot env variables, I am using visionfive 1's dictionary template just for getting the setup to work. Following is the VisionFive 1 dictionary template. {% extends 'base-uboot.jinja2' %} {% set uboot_mkimage_arch = 'riscv' %} {% set console_device = console_device|default('ttyS0') %} {% set baud_rate = baud_rate|default(115200) %} {% set booti_kernel_addr = '0x84000000' %} {% set booti_dtb_addr = '0x88000000' %} {% set booti_ramdisk_addr = '0x88300000' %} {% set uboot_initrd_high = '0xffffffffffffffff' %} {% set uboot_fdt_high = '0xffffffffffffffff' %} {% set bootloader_prompt = 'VisionFive#' %} {% set uboot_tftp_commands = [ "tftpboot {KERNEL_ADDR} {KERNEL}", "tftpboot {RAMDISK_ADDR} {RAMDISK}", "tftpboot {DTB_ADDR} {DTB}"] -%} I was able to run a job on QEMU. But the VisionFive 2 is not detected by the LAVA web server. The physical connection is complete because I can use picocom on my computer to attach to the VisionFive 2 using the command sudo picocom -b 115200 /dev/ttyUSB0. I created several job definitions just for testing the setup but they all are just loading. The device health check is bad. Following is the simplest job that I am trying to run and see if it completes. job_name: simple-uboot-test device_type: visionfive2 priority: medium visibility: public timeouts: job: minutes: 5 actions: - deploy: timeout: minutes: 1 to: u-boot - boot: method: bootloader bootloader: u-boot connection: serial commands: - printenv But all the jobs are on infinite loading. This is my first time connecting a physical device with the LAVA web server, so I would appreciate it if someone could tell me what the issue is here. Regards, Ali

9 months, 1 week

Maintainership help request

by Igor Ponomarev

Hello, I recently saw the "Call for LAVA maintainers" lava-announcement email and I am willing to help. I am pretty active in LAVA's gitlab. By the way, your discord link is expired. Nobody will be able to join until a new link is created. (you can make it without expiration timer) -- Igor Ponomarev Consultant Software Engineer Collabora Ltd. Unit 106 St Johns Innovation Centre, Cowley Road, Cambridge CB4 0WS, UK Registered in England & Wales, no. 5513718

9 months, 1 week

email notifications not using correct url. issue with absolute_url?

by Michael Peddie

As the subject says, email notifications in lava aren't using the correct url when linking to a job. They use the example.com url, and even after changing the value under Sites in the admin settings, it still does. Looking at the notification template for emails, it uses the job.absolute_url, but I can't quite figure out how it constructs example.com, there shouldn't be anything anywhere that it pulls that from. Any help on this would be appreciated, even if it's just insight and not a solution.

9 months, 2 weeks

Is there any job using the ssh.jinja2 template as a learning example?

by 93831920＠qq.com

Is there any job using the ssh.jinja2 template as a learning example? Thank you

10 months, 3 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users