[Christopher Obbard (obbardc)]

kernel-configs/ in qcom-deb-images is the upstream source of truth for these fragments and has moved on since the last sync, so the kernels built here lack options the images rely on.

Add two fragments that were missing locally:

incus.config namespaces, cgroups, KVM, vhost, VFIO and virtio
options for an Incus host running containers and VMs
watchdog.config build QCOM_WDT in so the already-running apps
watchdog is picked up before it resets the board
mid initramfs

Refresh qcom-laptops.config with the options added upstream since: DRM_SIMPLE_BRIDGE for the T14s Gen6, the QCOM_SPEL powercap driver, the OV02C10 sensor and HID_ASUS for Zenbooks, Bluetooth LE, RFCOMM and BNEP support, UHID and UINPUT, and DMABUF_DEBUG disabled so the libcamera GPU backend works.

Update the fragment table in debian/README.md to match, and drop its claim that squashfs.config is local to this repository: upstream has carried an identical copy since def7d2e7.

Synced from qcom-deb-images main at 6523955f.

[Robie Basak (basak-qcom)]

This lgtm thanks.

Should you close #164 in the commit message? Although we also don't want to forget:

There is also a longer-term question of how to keep the two in sync, that belongs in another issue which I will create, though.

I'll leave it up to you how to manage this :)

[Robie Basak (basak-qcom)]

Ah, the kgsl build failed? Here's what Claude says as to why, in the hope that it's helpful:

Why the build failed

It's not the kernel, and it's not this commit. The kernel compiled fine. The failure is in the out-of-tree kgsl (Adreno GPU) DKMS module, built afterwards during override_dh_auto_install:

ERROR: modpost: msm_kgsl.ko: symbol 'msm_adreno_tz_init' undefined!
ERROR: modpost: msm_kgsl.ko: symbol 'devfreq_gpubw_exit' undefined!
ERROR: modpost: msm_kgsl.ko: symbol 'devfreq_gpubw_init' undefined!

→ dkms exits 10 → bundle-dkms "Refusing to ship kgsl-modules… without kgsl" → debian/rules:435 override_dh_auto_install → binary-arch → dpkg-buildpackage error.

Root cause

Those three symbols are defined in two source files inside the kgsl module itself — governor_msm_adreno_tz.c and governor_gpubw_mon.c (the Adreno thermal-zone and GPU-bandwidth devfreq governors). The kgsl Kbuild compiles those two files conditionally, gated on downstream kernel config symbols (CONFIG_DEVFREQ_GOV_QCOM_ADRENO_TZ / CONFIG_DEVFREQ_GOV_QCOM_GPUBW_MON).

Those symbols do not exist in this kernel's config at all. The devfreq governors the kernel actually built were only the generic ones:

drivers/devfreq/built-in.a ← governor_simpleondemand.o governor_remote.o governor_userspace.o

So the governor object files were skipped, but kgsl_pwrscale.o (which calls msm_adreno_tz_init / devfreq_gpubw_init) was still compiled → unresolved references at modpost. It's a kgsl-1.0.17-vs-this-kernel-tree mismatch, not a packaging regression.

It is not caused by the config-fragment sync

Checked both directions:

• The gating symbols (DEVFREQ_GOV_QCOM_ADRENO_TZ, QCOM_GPUBW, etc.) appear nowhere in the log — not in defconfig, not in any fragment, not in the merge output. So nothing in this build turned them off; they were simply never present.
• The three changed fragments (incus.config, watchdog.config, qcom-laptops.config) touch no devfreq / PM / GPU / kgsl symbol. The only occurrences of "GPU" in them are prose in comments. merge_config/olddefconfig therefore couldn't have dropped a devfreq governor.

A build of this same kernel tree without this commit would fail at exactly the same spot.

What to actually fix

The GPU devfreq governor config the kgsl DKMS module expects is missing from the kernel config. Options, roughly in order of correctness:

1. Add the governor config to the kernel — enable CONFIG_DEVFREQ_GOV_QCOM_ADRENO_TZ / CONFIG_DEVFREQ_GOV_QCOM_GPUBW_MON (as a fragment) if qcom-next at ae2606baf50f actually defines them. Given the generic-only devfreq list above, this tree likely doesn't carry those downstream governors — so this may not be available.
2. Bump/patch the kgsl DKMS module so its kgsl_pwrscale references are guarded by the same #ifdef as the governor compilation (i.e. the module should build cleanly when those governors are absent). This is the real bug — kgsl 1.0.17 is out of sync with this kernel.
3. If the GPU module isn't needed for this debug kernel, drop kgsl from DKMS_MODULES (the manifest lists kgsl camx iris-vpu audioreach) so bundle-dkms doesn't gate the build on it.

Worth confirming which qcom-next commit kgsl 1.0.17 was last known to build against — the pr165 tag suggests this tree is ahead of what the module targets.

[Bjordis Collaku (bjordiscollaku)]

Ah, the kgsl build failed? Here's what Claude says as to why, in the hope that it's helpful:

Why the build failed

It's not the kernel, and it's not this commit. The kernel compiled fine. The failure is in the out-of-tree kgsl (Adreno GPU) DKMS module, built afterwards during override_dh_auto_install:

ERROR: modpost: msm_kgsl.ko: symbol 'msm_adreno_tz_init' undefined!
ERROR: modpost: msm_kgsl.ko: symbol 'devfreq_gpubw_exit' undefined!
ERROR: modpost: msm_kgsl.ko: symbol 'devfreq_gpubw_init' undefined!

→ dkms exits 10 → bundle-dkms "Refusing to ship kgsl-modules… without kgsl" → debian/rules:435 override_dh_auto_install → binary-arch → dpkg-buildpackage error.

Root cause

Those three symbols are defined in two source files inside the kgsl module itself — governor_msm_adreno_tz.c and governor_gpubw_mon.c (the Adreno thermal-zone and GPU-bandwidth devfreq governors). The kgsl Kbuild compiles those two files conditionally, gated on downstream kernel config symbols (CONFIG_DEVFREQ_GOV_QCOM_ADRENO_TZ / CONFIG_DEVFREQ_GOV_QCOM_GPUBW_MON).

Those symbols do not exist in this kernel's config at all. The devfreq governors the kernel actually built were only the generic ones:

drivers/devfreq/built-in.a ← governor_simpleondemand.o governor_remote.o governor_userspace.o

So the governor object files were skipped, but kgsl_pwrscale.o (which calls msm_adreno_tz_init / devfreq_gpubw_init) was still compiled → unresolved references at modpost. It's a kgsl-1.0.17-vs-this-kernel-tree mismatch, not a packaging regression.

It is not caused by the config-fragment sync

Checked both directions:

• The gating symbols (DEVFREQ_GOV_QCOM_ADRENO_TZ, QCOM_GPUBW, etc.) appear nowhere in the log — not in defconfig, not in any fragment, not in the merge output. So nothing in this build turned them off; they were simply never present.
• The three changed fragments (incus.config, watchdog.config, qcom-laptops.config) touch no devfreq / PM / GPU / kgsl symbol. The only occurrences of "GPU" in them are prose in comments. merge_config/olddefconfig therefore couldn't have dropped a devfreq governor.

A build of this same kernel tree without this commit would fail at exactly the same spot.

What to actually fix

The GPU devfreq governor config the kgsl DKMS module expects is missing from the kernel config. Options, roughly in order of correctness:

1. Add the governor config to the kernel — enable CONFIG_DEVFREQ_GOV_QCOM_ADRENO_TZ / CONFIG_DEVFREQ_GOV_QCOM_GPUBW_MON (as a fragment) if qcom-next at ae2606baf50f actually defines them. Given the generic-only devfreq list above, this tree likely doesn't carry those downstream governors — so this may not be available.
2. Bump/patch the kgsl DKMS module so its kgsl_pwrscale references are guarded by the same #ifdef as the governor compilation (i.e. the module should build cleanly when those governors are absent). This is the real bug — kgsl 1.0.17 is out of sync with this kernel.
3. If the GPU module isn't needed for this debug kernel, drop kgsl from DKMS_MODULES (the manifest lists kgsl camx iris-vpu audioreach) so bundle-dkms doesn't gate the build on it.

Worth confirming which qcom-next commit kgsl 1.0.17 was last known to build against — the pr165 tag suggests this tree is ahead of what the module targets.

On this:

• daily: debug kernel builds failing since 2026-10-23 · Issue #158 · qualcomm-linux/pkg-linux-qcom
• msm_kgsl fails to link with simple_ondemand default governor since 1.0.16 · Issue #24 · qualcomm-lin…

[Bjordis Collaku (bjordiscollaku)]

There is also a longer-term question of how to keep the two in sync, that belongs in another issue which I will create, though.

A weekly job that copies kernel-configs over and opens a PR when they differ would catch this kind of drift early. Longer term I'd rather have one copy. We can discuss further on the issue once it's up.

[Christopher Obbard (obbardc)]

There is also a longer-term question of how to keep the two in sync, that belongs in another issue which I will create, though.

A weekly job that copies kernel-configs over and opens a PR when they differ would catch this kind of drift early. Longer term I'd rather have one copy. We can discuss further on the issue once it's up.

Will be a separate PR :-)