extensions: skip DKMS modules on kernels built with clang - #10600
igorpecovnik wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (11)
🚧 Files skipped from review as they are similar to previous changes (11)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe build configuration now marks clang-built kernels as unable to build DKMS modules. Ten DKMS extensions use this state to skip header preparation, package installation, module builds, and autodetection when required. ChangesDKMS buildability gating
Estimated code review effort: 2 (Simple) | ~15 minutes Merge Risk: ⚪ Minimal · up to The change skips DKMS extensions for kernels that cannot build them with the available toolchain while preserving kernel headers; no actionable merge-blocking risk remains beyond normal checks and review. Sequence Diagram(s)sequenceDiagram
participant config_post_main
participant DKMSExtensionHooks
participant KernelPackageInstallation
config_post_main->>DKMSExtensionHooks: Publish DKMS buildability state
DKMSExtensionHooks->>KernelPackageInstallation: Skip unsupported DKMS operations
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
size/medium
Xiaomi-sheng desktop images fail to build. v4l2loopback's DKMS build dies
immediately:
DKMS make.log for v4l2loopback/0.15.3 for kernel 7.1.8-edge-sm8550-sheng
# command: make ... v4l2loopback LLVM=1
The kernel was built by: Debian clang version 19.1.7
/bin/sh: 1: clang: not found
make[4]: *** [v4l2loopback.o] Error 127
sm8550-sheng sets KERNEL_COMPILER="clang", and kernel-debs.sh deliberately
preserves CONFIG_CC_IS_CLANG in the headers package (via the sidecar tarball
added for #9425) so the headers describe the kernel as actually compiled. That
is correct, and it is also why DKMS then selects LLVM=1 -- but clang is not
installed in any Armbian rootfs, so no out-of-tree module can be built.
Nothing here is specific to v4l2loopback: any DKMS extension hits the same wall
on such a kernel. Add a gate, KERNEL_DKMS_BUILDABLE, computed once in
config_post_main and consulted by all ten DKMS extensions alongside the
KERNEL_HAS_WORKING_HEADERS check they already share.
Deliberately a separate variable rather than folding this into
KERNEL_HAS_WORKING_HEADERS. The headers package is genuinely fine here -- the
postinst clang leak was already fixed in 3c077ad -- and flipping that flag
would also stop the linux-headers deb being built and change the kernel
artifact package map, hence the artifact hash, invalidating caches and dropping
headers for users who may want to install clang themselves.
Skipping rather than shipping the toolchain: gcc is not a fallback, because
these kernels set CONFIG_LTO_CLANG/CONFIG_LTO_CLANG_THIN and gcc-built modules
cannot link against a ThinLTO kernel. Installing clang/lld/llvm in the image
would cost ~270MB (libllvm19 122MB, llvm-19 69MB, libclang-cpp19 66MB, lld-19
5MB) and would still have to keep matching the kernel's clang major across
future kernel upgrades. This mirrors the kernel >= 7.2 cutoff v4l2loopback-dkms
already carries.
Verified with `compile.sh configdump` on real boards:
xiaomi-sheng edge 7.1 KERNEL_COMPILER=clang
KERNEL_DKMS_BUILDABLE=no
KERNEL_HAS_WORKING_HEADERS=yes (unchanged)
orangepi5-max edge 7.2 KERNEL_COMPILER=aarch64-linux-gnu-
KERNEL_DKMS_BUILDABLE=yes
KERNEL_HAS_WORKING_HEADERS=yes (unchanged)
so gcc-built boards are untouched and the headers deb still ships on sheng.
Descriptions updated on the five extensions whose @description already
enumerates skip conditions. bash -n clean across all extensions.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
4570b31 to
7ef7e52
Compare
|
Hmm. Avoiding it could be, but it seems to me the clang stuff needs to be able to modify the linux-headers debian/control to depend on clang instead of build-essential -- way more intricate, but that would allow clang-built headers to work everywhere. Or would it? @iav for awareness |
|
You're right that the Depends line is the actual problem — kernel-debs.sh hardcodes gcc for every kernel, clang-built ones included. But sheng is the only kernel we build with clang, and I don't think fixing the dependency gets us "works everywhere". clang is distro-defined and we ship the same kernel across several distros; it's not just needing clang, it's needing a matching major (this one is Debian clang 19.1.7), plus lld and LLVM binutils because of ThinLTO. Where the distro's clang doesn't line up, DKMS breaks on the user's device rather than in CI. And it's ~270 MB in every image for something most users never use. Recommends: would soften that, but not the version problem. So I'd rather skip DKMS on clang kernels for now. The two aren't exclusive: even with proper clang deps you'd want the skip as a fallback where the toolchain doesn't match. |
|
The gcc dep is a single flat literal at kernel-debs.sh:557 (the linux-headers control). KERNEL_COMPILER is already known at packaging time and kernel-make.sh (:40, :129) branches on |
3 participants
The failure
armbian/ci run 33517020634, Xiaomi-sheng gnome + kde:
Cause
sm8550-sheng.confsetsKERNEL_COMPILER="clang", andkernel-debs.shdeliberately preservesCONFIG_CC_IS_CLANGin the headers package (the sidecar tarball added for #9425) so the headers describe the kernel as actually compiled. Both are correct — and together they mean DKMS selectsLLVM=1, while clang is installed in no Armbian rootfs.Note this is not the same bug as the one fixed in
3c077ad35. That scopedLLVM=1to the kernel make so it stopped leaking into the linux-headers postinst. DKMS reaches the identical wall by a different route: it reads the shipped headers rather than inheriting the environment.And nothing about it is specific to v4l2loopback — any of the ten DKMS extensions hits it on such a kernel.
Change
A gate,
KERNEL_DKMS_BUILDABLE, computed once inconfig_post_mainand consulted by all ten DKMS extensions next to theKERNEL_HAS_WORKING_HEADERScheck they already share.Why a separate variable. The headers package here is genuinely fine. Folding this into
KERNEL_HAS_WORKING_HEADERSwould also stop thelinux-headersdeb being built and change the kernel artifact package map — hence the artifact hash — invalidating caches and removing headers from users who might install clang themselves.Why skip rather than ship the toolchain. gcc is not a fallback: these kernels set
CONFIG_LTO_CLANG/CONFIG_LTO_CLANG_THIN, and gcc-built modules cannot link against a ThinLTO kernel. Installing the toolchain would cost ~270 MB (libllvm19122,llvm-1969,libclang-cpp1966,lld-195) and would still have to keep matching the kernel's clang major on every future kernel upgrade. Skipping mirrors the kernel ≥ 7.2 cutoffv4l2loopback-dkmsalready carries.The visible effect is that sheng images lose v4l2loopback (virtual camera). They currently build no image at all.
Verification
compile.sh configdumpagainst real boards:KERNEL_COMPILERKERNEL_DKMS_BUILDABLEKERNEL_HAS_WORKING_HEADERSclangyes(unchanged)aarch64-linux-gnu-yesyes(unchanged)So gcc-built boards are untouched and the headers deb still ships on sheng.
bash -nclean across all extensions.Related
The other failures in that run are Orange Pi 5 Max / bcmdhd on 7.2, fixed separately and released as bcmdhd-dkms 101.10.591.52.27-8, which
extensions/bcmdhd.shpicks up automatically.Summary by CodeRabbit