Hello all,
I am preparing a pull request in LAVA and would like to know which
filesystems people are using. The PR aims to drop libguestfs and
eventually move to e2fsprogs-based tooling.
LAVA officially supports ext4, but unofficially, are people using
anything else? Could you let me know if any users are using XFS, BTRFS
(or other variants)?
Any feedback would be appreciated!
Regards,
Ben
Hi,
When LAVA introduced REST framework, it allowed for cross model
filtering using djangorestframework-filters package. v0.2 LAVA API
still allows that. Unfortunately the package has been unmaintained for
the last 5 years:
https://pypi.org/project/djangorestframework-filters/#history
Without updates it will soon become incompatible with DRF and Django
itself. In fact Debian has to carry patches to make it still working.
On top of that there are performance issues with queries made by the
DFR-filters.
For these reasons it was decided that DRF-filters will be removed as
LAVA dependency starting with version 0.3 of the API. v0.2 will remain
supported for now. There is no end of life date agreed yet. In
practice this means cross-model queries won't be supported any more in
v0.3. As a tradeoff performance of single model queries should
improve.
If there are any concerns regarding this change, please reply to this thread.
Best Regards,
Milosz
Hi,
Starting from 2026.02 worker autoregistration will be disabled by
default. Details can be found in this merge request:
https://gitlab.com/lava/lava/-/merge_requests/2081
This may break some setups, so please be aware when upgrading. Local
setting can still overwrite the default if needed.
Best Regards,
Milosz
Hi,
As of now the default retry for download action is set to 3 (three).
This is an outlier as all other actions have retry set to 1. Some time
ago I complained about it in the list. There is also a MR posted to
address the problem:
https://gitlab.com/lava/lava/-/merge_requests/3012
I just rebased it on top of 2026.01 and I'm planning to merge it in
2026.02 release. It will still be possible to set retry to 3 in
download action with addition of failure_retry in a test job:
- deploy:
failure_retry: 2
images:
image:
url: 'https://example.com/foo.tgz'
timeout:
minutes: 20
to: downloads
Please reply here if this change is going to fundamentally break your
setup. IMHO the worst that can happen is the download timeouts
increase 3x which in my experience should not cause problems. I don't
know all potential setups, so please reply if this is a breaking
change for you.
Best Regards,
Milosz
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
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
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
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
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
