Debian support by mwasilew · Pull Request #30 · qualcomm-linux/lava-test-plans

Milosz Wasilewski (mwasilew) · 2026-03-06T13:50:02Z

Add support for qcom-deb-images project:

define project specific devices
change the flashing procedure for debian images
add test plans for qcom-deb-images

Milosz Wasilewski (mwasilew) · 2026-03-09T13:08:27Z

I based it on top of #31 which should be merged first.

Robie Basak (basak-qcom) · 2026-03-09T13:39:10Z

+
+{% block auto_login_commands %}
+      login_commands:
+        - "debian"


FYI, this might get stepped on by qualcomm-linux/qcom-deb-images#316

I guess you should send a patch when you expect it to be merged.

Fine for now.

Loïc Minier (lool)

Unrelated to your PR, but FYI there's a typo in the filename: lava_test_plans/testcases/pre-merge-dispaly-gfx.yaml (dispaly instead of display)

Left a few other comments from a quick pass on the changes

Loïc Minier (lool) · 2026-03-09T13:49:43Z


 {% block test_target %}
+  {% for test in all_tests %}
+  {% if (test.name not in EXCLUDED_TESTS) and (test.include|default(true)) %}


Not sure why all_tests is lowercased, and EXCLUDED_TESTS is uppercased

Uppercase variables can be overwritten from user input. Lower case variables are internal to the tool.

Loïc Minier (lool) · 2026-03-09T13:50:24Z

-{% extends "devices/qcs615-ride" %}
+{% extends "devices/qcs615-ride" %}
+
+{% set EXCLUDED_TESTS = ['BT_FW_KMD_Service', 'BT_SCAN'] %}


These changes seem unrelated to Debian support

BT doesn't work on qcs615 devices we have in the LAB. I can remove it, but then BT tests that are included in the pre-merge set will fail.

I see; I guess this could be indicative of these changes belonging into a separate PR

I'll move it to a separate commit.

Loïc Minier (lool) · 2026-03-09T13:50:53Z

 def _submit_to_lava(lava_job, lava_url_base, lava_username, lava_token):
    if not (
-        lava_url_base.startswith("http://")
-        or lava_url_base.startswith("https://")


This should be squashed into the earlier commit that makes these changes

Loïc Minier (lool) · 2026-03-09T13:53:24Z

+{% set PROJECT = PROJECT|default("") %}
+{% extends PROJECT+"flasher.jinja2" %}
+
+{% set BOOT_OS_PROMPT = BOOT_OS_PROMPT|default("root@iq-8075-evk") %}


Yocto uses machine-specific prompts, but qcom-deb-images does not; right now, it's always debian@debian; we'd like to change this in the future (Ubuntu support, device-specific hostnames), but for now I think you should hardcode debian@debian for qcom-deb-images.

This is a common file though; perhaps this should be an OS specific template instead, with a meta-qcom version and a qcom-deb-images version.

ACK. I can move it one level up - project setting, not a device-in-a-project setting

Loïc Minier (lool) · 2026-03-09T13:54:25Z

+
+{% set rootfs_label = 'rootfs' %}
+
+{% set FLASHER_DEVICE_TYPE = "debian-monaco-arduino-monza_emmc" %}


Could we avoid requiring a per-device template file? They are all following the same naming convention and structure

I'm not so sure. There is qrb2210-arduino-imola but monaco-arduino-monza. It should be either agatti-arduino-imola or qcs8300-arduino-monza. On top of that device specific files are used to exclude tests and amend flashing instructions.

Loïc Minier (lool) · 2026-03-09T13:56:05Z

+
+{% block auto_login_commands %}
+      login_commands:
+        - "debian"


I was expecting:

debian

debian

debian

new password

new password

The first two being login + password, the third one being password again before changing password, and the new password lines being the one + confirmation.

login+password (initial login) is handled by auto_login section. So this part only takes care of changing the password on 1st login.

Think this is OK, can you resolve if so Milosz Wasilewski (@mwasilew) ?

I'm sure this is OK. It works. Example: https://lava.infra.foundries.io/scheduler/job/155823#L1521

Milosz Wasilewski (mwasilew) · 2026-03-27T11:37:46Z

Unrelated to your PR, but FYI there's a typo in the filename: lava_test_plans/testcases/pre-merge-dispaly-gfx.yaml (dispaly instead of display)

Thanks. This is now fixed.

Christopher Obbard (obbardc)

This looks good shape to me so far - but needs care to make sure we include all boards/tests from https://github.com/qualcomm-linux/qcom-deb-images/tree/main/ci/lava

I didn't review in too much detail as Milosz Wasilewski (@mwasilew) said he will rebase first.

A board can need a named device command run once it has been flashed and before the OS is booted - bringing up the lab network switch port, for instance. There was no way to ask for one: pre_boot_commands.jinja2 only knows the fixed pre_os_command and pre_power_command names, and both are rendered by the flasher path, not the qdl one. Add user_pre_boot_commands, a list of device command names rendered after the flashing stages. It defaults to empty, so nothing changes for a device that does not set it. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>

Becoming the super user was hardcoded as su, which assumes the root account has a password of its own to ask for. An image can instead give the login user sudo and leave root locked, and there was no way to say so. Take the command from AUTO_LOGIN_SU_COMMAND, defaulting to su, so nothing changes for an image that does not set it. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>

An image can ship an expired password and make the first login set a new one before it gives out a shell. Nothing here could drive that exchange: auto_login_commands.jinja2 only knows how to become root, so a project had to override the whole block and spell the prompts out in its own BOOT_OS_PROMPT. Answer it here instead. AUTO_LOGIN_NEW_PASSWORD, when set, replies with the current password and then the new one twice, and boot_os_prompt adds the three prompts that exchange has to be matched on. Both are skipped when it is unset, so nothing changes for an image that does not force a change. The rendered jobs of every other project are byte identical. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>

The project rendered its jobs through include/flasher.jinja2. Move to native LAVA qdl deploymen which allows multi storage flashing. Render the same deployment here. include/qdl.jinja2 already carries the multi-stage flashing logic and the common devices already carry each board's firehose programmer, rawprogram/patch lists and stages, so the project template only has to add what is specific to a debian image: the authenticated download, the <suite>[-<variant>]-flash-<storage>.tar.gz tarball name, the disk-{ufs,sdcard}.img2 rootfs image, and the answers to the password change the first login forces. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>

Only the build URL was recorded, so a job could not be traced back to the pull request or the workflow run that produced the image under test. Emit the same named keys meta-qcom does. They are always rendered, empty when unset, which keeps a query written against one of them meaningful whichever project rendered the job; anything further a caller wants to record still rides along in EXTRA_METADATA. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>

The project had a single flat boot.yaml and no functional testing at all: not one qcom-linux-testkit test ran against a debian image. Lay the plans out as <project>/<distro>/<plan>, the structure every other project uses and the one the test-distro workflow expects, and add a pre-merge plan alongside boot. The pre-merge plans are the existing testcases, the same ones meta-qcom runs: basic, bluetooth and display. A test plan is resolved by file name, so linking them is enough to render them, and the tests a board cannot run report SKIP rather than FAIL. The bluetooth, audio and display plans are then excluded on every board. They ask for a lab fixture through a LAVA tag, and a job whose tag no device carries does not fail, it waits: it sits queued until the workflow gives up on it, on every board, every run. Excluding them per board rather than leaving them unlinked keeps the entry to delete in view of whoever gives a board the hardware. Note that pre-merge-basic still names the Ethernet suite as one test, which qcom-linux-testkit split into seven after testkit-2026.08.23. A caller has to pin a revision no newer than that until the testcase is updated. Signed-off-by: Milosz Wasilewski <milosz.wasilewski@oss.qualcomm.com>

Milosz Wasilewski (mwasilew) force-pushed the debian-support branch from 4cd8358 to 0291167 Compare March 9, 2026 13:06

Robie Basak (basak-qcom) reviewed Mar 9, 2026

View reviewed changes

Loïc Minier (lool) reviewed Mar 9, 2026

View reviewed changes

Milosz Wasilewski (mwasilew) force-pushed the debian-support branch from a6a95e1 to 11a9999 Compare March 11, 2026 11:11

Milosz Wasilewski (mwasilew) force-pushed the debian-support branch from 11a9999 to b8f7021 Compare March 27, 2026 10:40

Milosz Wasilewski (mwasilew) force-pushed the debian-support branch 4 times, most recently from 73db89c to 7e6e142 Compare April 13, 2026 12:20

Milosz Wasilewski (mwasilew) force-pushed the debian-support branch 2 times, most recently from ea8bbe1 to da6b5d9 Compare May 6, 2026 13:56

Milosz Wasilewski (mwasilew) mentioned this pull request May 26, 2026

Investigate validation with qcom-linux-testkit qualcomm-linux/qcom-deb-images#67

Open

Christopher Obbard (obbardc) reviewed Aug 12, 2026

View reviewed changes

Milosz Wasilewski (mwasilew) force-pushed the debian-support branch from 021584c to eb386be Compare August 12, 2026 16:16

Christopher Obbard (obbardc) mentioned this pull request Aug 12, 2026

ci: migrate to reusable test workflow qualcomm-linux/qcom-deb-images#405

Draft

Milosz Wasilewski (mwasilew) added 6 commits September 16, 2026 13:30

Milosz Wasilewski (mwasilew) force-pushed the debian-support branch from eb386be to 2d1bd5d Compare September 16, 2026 17:52


		{% set rootfs_label = 'rootfs' %}

		{% set FLASHER_DEVICE_TYPE = "debian-monaco-arduino-monza_emmc" %}

Uh oh!

Conversation

Milosz Wasilewski (mwasilew) commented Mar 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Milosz Wasilewski (mwasilew) commented Mar 9, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Loïc Minier (lool) left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Milosz Wasilewski (mwasilew) Mar 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Milosz Wasilewski (mwasilew) commented Mar 27, 2026

Uh oh!

Christopher Obbard (obbardc) left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Milosz Wasilewski (mwasilew) commented Mar 6, 2026 •

edited

Loading

Milosz Wasilewski (mwasilew) Mar 9, 2026 •

edited

Loading