Conversation
- Enable CONFIG_MODULES for loadable module support - Enable CONFIG_DRM and CONFIG_DRM_BOCHS (which selects DRM_TTM) - Add CI steps to build NVIDIA open-gpu-kernel-modules - Download NVIDIA driver and extract GSP firmware for H100/modern GPUs - Package kernel modules + firmware as nvidia-modules-x86_64.tar.gz - Package userspace driver libraries as nvidia-driver-libs-x86_64.tar.gz (libcuda.so, libnvidia-ml.so, nvidia-smi, etc. for container injection)
Allow native overlay nesting (overlay-on-overlay) so BuildKit can use the kernel overlayfs snapshotter instead of falling back to fuse-overlayfs.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| tar czf kernel-headers-aarch64.tar.gz -C "${HEADERS_DIR}" . | ||
|
|
||
| echo "Kernel headers packaged for ${KVER} (aarch64):" | ||
| du -sh kernel-headers-aarch64.tar.gz |
There was a problem hiding this comment.
Riscv64 missing module build and headers packaging steps
Medium Severity
The riscv64 defconfig now enables CONFIG_MODULES=y, CONFIG_MODULE_UNLOAD=y, and CONFIG_MODVERSIONS=y — identical to the aarch64 and x86-64 defconfigs — but the release workflow has no "Build kernel modules (riscv64)" step, no "Package kernel headers (riscv64)" step, and no corresponding upload step. Both aarch64 and x86-64 received all three of these workflow additions. This inconsistency means the riscv64 release kernel advertises module support but ships without built modules or headers for out-of-tree module compilation.
Additional Locations (1)
|
|
||
| # Use the kernel's built-in script via make run-command to ensure proper env vars | ||
| mkdir -p "${HEADERS_DIR}" | ||
| ARCH=arm64 make run-command KBUILD_RUN_COMMAND="\${srctree}/scripts/package/install-extmod-build ${HEADERS_DIR}" |
There was a problem hiding this comment.
Aarch64 headers contain wrong-architecture host tools
High Severity
The aarch64 headers packaging step invokes make run-command with only ARCH=arm64 but omits CROSS_COMPILE=aarch64-linux-gnu-. Without CROSS_COMPILE, the kernel Makefile sets CC=gcc (same as HOSTCC=gcc), so the install-extmod-build script's CC != HOSTCC check evaluates false and the host tool rebuild branch is skipped. The packaged aarch64 headers will contain x86-64 host binaries (fixdep, modpost) from the build machine, which will fail with "exec format error" when someone tries to build kernel modules natively on an aarch64 system. The upstream builddeb script explicitly passes the cross-compiler as CC to trigger this rebuild.
3 participants
Note
Medium Risk
Changes affect the kernel build/release pipeline and materially expand kernel configuration (modules, networking, filesystems), which can introduce build regressions or runtime behavior changes in produced artifacts.
Overview
The release GitHub Action now runs on a self-hosted KVM runner with
contents: write, statically links host build tools viaHOSTLDFLAGS, builds kernel modules, packages kernel headers for x86_64 and aarch64, verifies key tools are statically linked, and uploads the header tarballs as release assets.All
ch_defconfigfiles (arm64/riscv/x86) are updated to rename the default hostname tohypeman, enableIKCONFIGin/proc, turn on loadable modules (with unload + modversions), and add support for netfilter/NAT + bridging, Bochs DRM, OverlayFS redirect/index, and EROFS (plus required misc-filesystems toggles where needed).Written by Cursor Bugbot for commit d64ceea. This will update automatically on new commits. Configure here.