Debian DKMS path: kgsl-dkms Build-Depends install hard-fails when msm_kgsl cannot be built for the builder kernel

[bjordiscollaku]

Summary

Adding kgsl-dkms to the kernel Build-Depends (#54) makes the Debian /
Debusine build fail at dpkg --configure kgsl-dkms, during build-dependency
installation, before the bundling step ever runs. The identical situation on the
Ubuntu / docker path succeeds today, but for an incidental reason (an older
packaging revision of kgsl-dkms, see Why the outcomes differ below), so the Ubuntu path is exposed to
the same failure as soon as that package is rebuilt from current packaging.

Root cause in one line: no builder-kernel headers -> no module build ->
module-not-installed -> kgsl-dkms's own postinst check hard-fails. The fix
proposed below (/etc/dkms/no-autoinstall in the build environment) is the
bypass that this check itself explicitly honors.

Why this surfaced now

The Debian path only became exercisable recently: the out-of-tree DKMS module
packages (kgsl-dkms) were published to the Debusine qli workspace only
recently. That made the Debian DKMS build path exercisable for the first time,
through #54 (which adds kgsl-dkms to the kernel Build-Depends on the
packaging branch) and #56 (which wires the Debusine build to resolve build-deps
from qli). Exercising it surfaced this blocker.

Same situation, different outcome

Neither builder has headers for its running kernel. The logs differ only in the
last step.

Debian / Debusine (fails), package 1.0.4-0qli2~bpo13+1:

Setting up kgsl-dkms (1.0.4-0qli2~bpo13+1) ...
Loading new kgsl/1.0.4 DKMS files...
WARNING: No kernel headers were found, skipping module build.
         To get the headers for the running kernel (6.12.86+deb13-cloud-arm64)
         please install the linux-headers-6.12.86+deb13-cloud-arm64 package.
ERROR: msm_kgsl was not installed by dkms autoinstall, has your kernel the required options?
dpkg: error processing package kgsl-dkms (--configure):
 installed kgsl-dkms package post-installation script subprocess returned error exit status 1

Ubuntu / docker (succeeds), package 1.0.4-1:

Setting up kgsl-dkms (1.0.4-1) ...
Loading new kgsl/1.0.4 DKMS files...
WARNING: No kernel headers were found, skipping module build.
         To get the headers for the running kernel (6.8.0-1030-aws)
         please install the linux-headers-6.8.0-1030-aws package.
depmod: ERROR: could not open directory /lib/modules/6.8.0-1030-aws: No such file or directory
depmod: FATAL: could not search modules: No such file or directory

The Ubuntu install proceeds despite those depmod errors (they come from a
depmod -a || true in that package revision's postinst) and the kernel build
later compiles msm_kgsl against the staged target headers as designed.

Root cause

Two lines in the failing output come from two different layers: the WARNING is
dkms; the ERROR and the non-zero exit are kgsl-dkms's own postinst.

1. Installing kgsl-dkms runs the dh_dkms postinst, which calls
   /usr/lib/dkms/common.postinst. Because kgsl's dkms.conf sets
   AUTOINSTALL="yes", dkms tries to build msm_kgsl for the builder's kernels.

2. The builder's running kernel has no headers, so dkms prints
   No kernel headers were found, skipping module build and returns 0. This is
   only a warning, and it behaves identically on Debian and Ubuntu.

3. kgsl-dkms's hand-written postinst then verifies the module was actually
   installed, and that verification is what exits non-zero:

   # from debian/kgsl-dkms.postinst (pkg-kgsl, qli/debian/latest)
   if ! [ -f /etc/dkms/no-autoinstall ] && ! dkms status | grep -qx 'kgsl/.*:installed' ; then
       >&2 echo "ERROR: msm_kgsl was not installed by dkms autoinstall, has your kernel the required options?"
       exit 1
   fi

In short: no headers -> no build -> module-not-installed -> kgsl's postinst
hard-fails. It is a header problem at the root, but the thing that actually
kills the install is kgsl's own "did the module get installed?" check, not a raw
dkms "headers required" error.

The autoinstall this gates on targets the builder's kernel and is redundant
here in any case: the module is built explicitly against the target kernel's
staged headers in the bundling step.

Why the outcomes differ

This is a packaging-revision difference, not a distro, dkms, or headers difference. Verified against pkg-kgsl history:

• The verification check was added on 2026-06-19 (commit 8bc8432 "postinst:
  make sure module was installed") on the Debian packaging lineage
  (qli/debian/latest), first released as 1.0.4-0qli1 (2026-06-25). The
  Debusine build installs 1.0.4-0qli2~bpo13+1, which carries the check.
• The Ubuntu Artifactory package 1.0.4-1 (tag resolute/1.0.4-1, from the
  qcom/ubuntu/resolute lineage) predates it: its postinst has no verification
  check, and its depmod -a || true is the source of the swallowed depmod
  errors in the passing log above.
• The dkms package itself behaves the same on both distros for this case
  (dkms 3.2.2: warning plus exit 0 on missing headers; Ubuntu's
  ignore-autoinstall-errors patch concerns build failures, not missing
  headers).

Consequence: the Ubuntu path passing today is incidental. If the Ubuntu package
is rebuilt from packaging that includes the check, the docker path fails the
same way. The fix therefore belongs in both build environments, not only the
Debian one.

Proposed fix

Create /etc/dkms/no-autoinstall in the build environment before the
kgsl-dkms build dependency is configured.

That single file resolves the chain at both layers, and it is the bypass the
verification check itself was written to honor (see the
! [ -f /etc/dkms/no-autoinstall ] guard in the postinst snippet above, added
by the same commit that introduced the check):

• dkms's common.postinst short-circuits at the top:

  if [ -f /etc/dkms/no-autoinstall ]; then
      echo "autoinstall for dkms modules has been disabled."
      exit 0
  fi

  so no build is attempted for the builder kernel.
• kgsl-dkms's postinst guard is then false, so its hard-fail check is skipped.

Properties:

• Distro-agnostic. Honored by common.postinst for dkms >= 3.0.13 and by
  dkms autoinstall for >= 3.1.x, so it works on trixie / forky / Ubuntu.
  (Caveat: dkms 3.0.10 on Debian bookworm does not honor it. The targets here
  are trixie and Ubuntu, so this is fine.)
• No change to pkg-kgsl and no dkms patch.
• A build-environment file only; it is not baked into the produced .deb.
• It does not affect the bundling: dpkg still installs the module source
  (/usr/src/kgsl-<ver>/), so the tool still resolves dkms.conf and builds
  msm_kgsl against the staged target headers as designed.
• Applying it on both paths also removes the Ubuntu path's current dependence on
  an old package revision.

This is the "arrange so the running-kernel headers are not required" direction:
the install-time autoinstall is not needed at all, because the module is built
explicitly against the staged headers.

Open implementation question

Where to place the file. On the Ubuntu / docker path the builder image is under
this project's control, so it is straightforward there. On the Debian path the
build-dep install happens inside the Debusine-managed build chroot, so a
Debusine-side mechanism is needed to inject /etc/dkms/no-autoinstall into that
chroot before build-deps are configured (the source package's own
debian/rules runs too late).

Alternatives (draft, for discussion)

Trade-offs stated as facts, not verdicts. The levers fall into two groups, and
the distinction matters: kgsl-dkms is also installed directly on devices via
the normal DKMS flow, so a change to its packaging changes that on-device
behaviour too (and couples the module package to the kernel build). The proposed
fix is a build-environment change precisely because it leaves the shipped module
package untouched.

Build-environment changes (affect only the builder, not the on-device package):

• The proposed /etc/dkms/no-autoinstall above.
• Provide the builder kernel's headers so the autoinstall builds and kgsl's
  check is satisfied. Works on both distros, but in a CI chroot it needs the exact
  builder kernel's /lib/modules/<ver> directory and headers present, and it
  builds a module that is then discarded.

Module-packaging changes (modify pkg-kgsl; these also change how the package
behaves when installed directly on a device, so they are noted here but not the
default direction):

• AUTOINSTALL="no" in dkms.conf does not have the intended effect anyway:
  common.postinst reads AUTOINSTALL by raw-sourcing the file and testing
  emptiness, not the value, so "no" still builds. Only an empty/absent
  AUTOINSTALL skips, which would disable auto-build on real target devices.
• BUILD_EXCLUSIVE_* gates make non-matching kernels skip cleanly (dkms
  returns 77), but they change which kernels the module builds for on devices.
• Adjusting kgsl's own postinst check (the dkms status guard) is possible,
  but changes the package's device-install semantics.

Does not apply: /etc/dkms/framework.conf has no autoinstall-disabling key;
policy-rc.d gates service starts, not the dkms build; dkms.service does not
run in a build chroot (no systemd).

dkms mechanism detail and version map

• The dh_dkms-generated postinst block is byte-identical on Debian and Ubuntu; it
  just calls /usr/lib/dkms/common.postinst, so the divergence is not in dh_dkms.
• The missing-headers warning (empty KERNELS) and its exit 0 come from Debian
  patch 0002-common.postinst-emit-a-warning-if-no-kernel-headers (dkms 3.2.2-1),
  fixing dkms upstream issue #545 (previously a silent exit 0).
• Ubuntu's ignore-autoinstall-errors.patch (LP #2028366) makes a build failure
  (exit $res) into continue when /etc/dkms/no-autoinstall-errors exists or
  RELEASE_UPGRADE_IN_PROGRESS=1. Debian does not carry this patch. It does not
  apply to the missing-headers case.

Distro/release	dkms	missing-headers	build-failure
Debian bookworm	3.0.10	silent exit 0 (no no-autoinstall marker)	exit $res (fails)
Debian trixie/sid	3.2.2	WARNING, exit 0	exit $res (fails)
Ubuntu questing/resolute	3.2.x-ubuntuN	WARNING, exit 0	continue iff no-autoinstall-errors / release-upgrade
Sources: dkms upstream dkms_common.postinst.in, dkms.in, dkms_framework.conf.in
(dell/dkms); upstream issue dkms-project/dkms#545; Debian packaging debian/scripts/postinst-dkms,
debian/patches/0002-*, debian/patches/series, debian/changelog (salsa debian/dkms);
Ubuntu ignore-autoinstall-errors.patch and changelog (Launchpad ubuntu/+source/dkms);
bugs Debian #1114731, Launchpad #2028366, Debian #1107232.

Links

• Design and tracking: Integrate out-of-tree DKMS modules into the kernel package at build time #44
• Build-time DKMS module integration: Integrate out-of-tree DKMS modules into the kernel at build time #54
• Debusine qli workspace for DKMS build-dependencies: ci(debusine): include qli workspace for DKMS build-dependencies #56
• Failing Debian run: https://github.com/qualcomm-linux/pkg-linux-qcom/actions/runs/28977694679
• Passing Ubuntu run: https://github.com/qualcomm-linux/pkg-linux-qcom/actions/runs/28193902324
• pkg-kgsl postinst check: qualcomm-linux/pkg-kgsl@8bc8432

[lool]

Bjordis Collaku (@bjordiscollaku) great (albeit long!) write-up

I just fixed the kgsl-dkms installation issue an hour ago

I'm not a fan of hardcoded assumptions about the build environment, so I don't recommend pushing a file there; I think we should arrange not to pull any kernel headers in the build environment, and then dkms should be skipped (I hope).

Another way to go about it is to split the dkms in two packages: a -source, and a -dkms. The -source only transports the source, the -dkms has the DKMS config and autobuilds it. But this might go against the idea of using DKMS as an interface for pkg-linux-qcom.

[bjordiscollaku]

Bjordis Collaku (@bjordiscollaku) great (albeit long!) write-up

I just fixed the kgsl-dkms installation issue an hour ago

I'm not a fan of hardcoded assumptions about the build environment, so I don't recommend pushing a file there; I think we should arrange not to pull any kernel headers in the build environment, and then dkms should be skipped (I hope).

Another way to go about it is to split the dkms in two packages: a -source, and a -dkms. The -source only transports the source, the -dkms has the DKMS config and autobuilds it. But this might go against the idea of using DKMS as an interface for pkg-linux-qcom.

Yeah, agreed on dropping the /etc/dkms/no-autoinstall path. Looked at the kgsl PR qualcomm-linux/pkg-kgsl#62, the extra dkms check seems gone now and it's back to stock dkms behaviour, so the hard-fail on the kgsl-dkms install should be out of the way. Is the rebuilt package already up in the trixie apt repo?

[bjordiscollaku]

Resolved by qualcomm-linux/pkg-kgsl#62, which dropped the extra kgsl-dkms postinst check and returned it to stock dkms behaviour. With the rebuilt kgsl-dkms now published in the trixie apt repo, the Build-Depends install no longer hard-fails.

The Debian/Debusine path now builds end to end: run 29125019996 completed and msm_kgsl.ko is bundled into the linux-image. Closing.