feat!: install the qcom-next kernel package from QLI APT - #595
Open
Christopher Obbard (obbardc) wants to merge 7 commits into
Open
feat!: install the qcom-next kernel package from QLI APT#595Christopher Obbard (obbardc) wants to merge 7 commits into
Christopher Obbard (obbardc) wants to merge 7 commits into
Conversation
Christopher Obbard (obbardc)
force-pushed
the
wip/obbardc/install-kernel-qli
branch
from
August 22, 2026 00:30
b21a689 to
fd3c2fa
Compare
Christopher Obbard (obbardc)
changed the title
Christopher Obbard (obbardc)
force-pushed
the
wip/obbardc/install-kernel-qli
branch
from
August 27, 2026 23:28
fd3c2fa to
203fee5
Compare
Christopher Obbard (obbardc)
force-pushed
the
wip/obbardc/install-kernel-qli
branch
from
September 3, 2026 10:37
203fee5 to
c2a0286
Compare
Christopher Obbard (obbardc)
changed the title
Christopher Obbard (obbardc)
marked this pull request as ready for review
September 3, 2026 10:39
Christopher Obbard (obbardc)
force-pushed
the
wip/obbardc/install-kernel-qli
branch
from
September 3, 2026 16:55
752efef to
a60b288
Compare
The Qualcomm Linux kernel is now published to the QLI APT repository as linux-image-qcom-next, packaged from https://github.com/qualcomm-linux/kernel by its own packaging repository https://github.com/qualcomm-linux/pkg-linux-qcom. It carries additional hardware support for Qualcomm devices on top of the kernel in the Debian archive, so make it the kernel the recipes install out of the box. Default $kernelpackages to linux-image-qcom-next in the rootfs recipe and in the reusable debos workflow, and document the new default in the README. The image workflows no longer have to ask for a kernel of their own: they overrode kernelpackages to install the ephemeral packages which the "qcom-next linux build" workflow publishes to EFS, and the new default supersedes that, so drop the override from build.yml, build-on-pr.yml and build-on-push.yml. The workflows which build their own kernel are unchanged. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
The singular kernelpackage variable was superseded by kernelpackages, a comma-separated list, and has warned about its removal since. Nothing in the recipes, the workflows or the documentation passes it any more, so drop it along with the deprecation warning. BREAKING CHANGE: the kernelpackage debos variable is gone; pass kernelpackages instead. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
Now that the kernel is installed from the QLI APT repository, the image build no longer consumes the debs which the "qcom-next linux build" workflow publishes to EFS, so it does not need to chain onto it with workflow_run. Run it from the same daily schedule as that workflow instead, which also drops the need for the zizmor dangerous-triggers exemption. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
The QLI Debian images install the linux-image-qcom-next package from the QLI APT repository, maintained in its own packaging repository, so nothing consumes the packages this workflow publishes any more and it is no longer part of the image pipeline. It is still worth keeping to compare the kernel built straight from the qcom-next tree against the packaged one QLI ships, so adjust it to that role rather than removing it: - record the deprecation at the top of the file, pointing at https://github.com/qualcomm-linux/pkg-linux-qcom, so that the workflow isn't mistaken for part of the image pipeline. - comment the daily schedule out. With nothing waiting for the packages, a daily run only spends builder time and LAVA capacity, so run it by hand when the comparison is wanted. - drop the pinned --ref so that build-linux-deb.py resolves the latest dated qcom-next tag on every run, as it already does for linux-next. No image installs this kernel anymore, so there is no version to keep in lockstep with and no tag to bump by hand. - drop skip_image_build, which stopped the workflow once the packages were published to EFS because the "Build" workflow picked them up from there. It builds and boots an image of its own again, like the other standalone kernel builds, so that the kernel doesn't go untested. - report the LAVA results of that image in the job summary only, by setting lava_report_test_results_externally to false, so that a failure of this reference build doesn't gate qcom-deb-images work. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
The unstripped vmlinux is published alongside the image so that oops and panic backtraces can be symbolised, but so far it only came from EFS, where the kernel workflow copies it next to the packages it builds. Images whose kernel is installed from an APT repository, as the default linux-image-qcom-next one is, shipped no vmlinux at all. Every kernel packaging ships the unstripped image in a -dbg package instead, so take it from there in all three cases an image gets its kernel from: - kernels built by linux.yml with deb-pkg and staged in EFS, whose packages are copied to the local APT repo: the -dbg package sits right next to the linux-image one the image is built from, so no download is needed. - the Qualcomm Linux kernel installed from the QLI APT repository, e.g. linux-image-qcom-next. - Debian's own kernel installed from the Debian archive, e.g. linux-image-arm64. The latter two have to fetch the debug package first, which needs the APT configuration and the exact kernel version of the root filesystem, so a debos helper recipe unpacks the root filesystem tarball built by the rootfs recipe, asks dpkg for the highest-version installed linux-image package and downloads the -dbg package matching its version. The root filesystem tarball itself is left untouched. The extraction is common to all three and needs neither a chroot nor a root filesystem, so it lives in a shell script the recipe hands its downloaded package to and which the workflow calls directly for EFS kernels. Given the name of a linux-image package it picks up the -dbg package next to it, reconstructing its file name rather than globbing the directory for a -dbg package, which would also match unrelated copies of it. Only vmlinux is extracted from the package: the debug information of every module is of no use here and amounts to gigabytes of data. Debian and the upstream deb-pkg target disagree on where they install it, so both layouts are matched, exactly one result is required and its path is checked against the version of the kernel the package is named after. Not every kernel has a debug package available. Both callers pass --optional, which reports a missing one and carries on rather than failing the build, as the publishing step already copes with a missing vmlinux. The kernel workflow no longer publishes vmlinux next to the packages it builds: the image build now gets it from the debug package in every case, so there is no need to copy hundreds of megabytes of it into the artifacts of every kernel build. Both files are CI helpers rather than something an image is built from, so they live together under ci/ rather than next to the product recipes in debos-recipes/ and the scripts shared by them. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
The images built by default carry the Qualcomm Linux additions: the qcom-next kernel and the Qualcomm Linux APT repository, which stays configured in the image so it can be upgraded from later on. Document how to opt out of both, by installing linux-image-arm64 from the Debian archive and setting qliaptrepo to false and note the reduced hardware support that comes with it. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
The CI status table had a column for the kernel build and one for the image build and boot test, which only ever applied to the two image variants. The reference and project-specific kernel builds compile the kernel, build an image and boot test it in a single workflow, so their image column carried a footnote pointing back at the kernel one. Collapse the two columns into a single "Image build & test status", so that every row reports the workflow which builds and tests it, and drop the footnote along with them. The Qualcomm Linux row loses its kernel badge in the process. The images install linux-image-qcom-next from the QLI APT repository, so the qcom-next workflow no longer builds the kernel they ship and its status says nothing about them; its link definitions go too, as nothing references them any more. Name every badge after the images it reports on, and consistently: QLI, Debian, linux-next, mainline and Arduino images. The column reports one thing per row now, so the badges shouldn't be the place where a reader has to work out whether a row is about a kernel or an image. Signed-off-by: Christopher Obbard <chris.obbard@oss.qualcomm.com>
Christopher Obbard (obbardc)
force-pushed
the
wip/obbardc/install-kernel-qli
branch
from
September 3, 2026 17:48
a60b288 to
30336c8
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Install the qcom-next kernel from the QLI APT repository, instead of from the debs which the
qcom-next linux buildworkflow publishes to EFS.This decouples the image builds from the kernel build: the images become reproducible from APT alone, the "Build" workflow no longer has to chain onto another workflow to get a kernel and the kernel tag no longer has to be bumped by hand in this repository.
vmlinux extractor
Issues with kernel package in APT
-dbgpackage is unstripped (need to retest vmlinux helper recipe)kgsl,camx,iris-vpu,audioreachDKMS module not included (also: perhaps we need to disable them (denylist?) in non-multimedia images)Validation
Custom kernel package is installed (CI and locally-built images; both trixie and forky).
Locally built image (trixie):
Locally built image (forky):
CI-built image (trixie) Job 385329 on qcs6490-rb3gen2:
CI-built image (forky):
Fixes: #386