tlied2

@Gunwoo Gim as a workaround, I have found that forcing it to use gcc-14 allows dkms to successfully build the zfs modules against the kernel packages from the repo. I had trouble finding a working way to configure dkms to use a specific compiler, but replacing the global /usr/bin/gcc symlink got things working. # The gcc-14 packages likely got installed as a dependency, but double-check before replacing ls /usr/bin/gcc-14 && sudo ln -sf /usr/bin/gcc-14 /usr/bin/gcc This appears to confirm my theory that this is a build chain issue relating to how the CI system is building packages for the apt repo. It isn't just the kernel packages/configs that are built against gcc-14, as much of the system depends on the gcc-14-base package. I only had a quick peek, but it looks like there was some significant work on the CI package build system between 26.5 and 26.8, and the July commits in https://github.com/armbian/ci/commits/main/userpatches strike me as suspicious in this context, but if it were just that I would expect the issue to be more widespread than it seems to be.

I have been experiencing the same issue building zfs-dkms with 26.8 noble. I have done some testing and have some observations which may be helpful to someone with better knowledge of the kernel build/packaging/publishing system. I believe the error message to be misleading, as CONFIG_MODULES is set in .config as @Wernerpoints out, and is likely masking some other toolchain issue relating to the configure process. If I use armbian-config to install the 26.8.3 kernel 6.18.44 (or 26.8.1/6.18.43) package, the dkms build fails. It appears those packages are built with GCC 14 on Debian, where older versions have been built with GCC 13 on Ubuntu. CONFIG_CC_VERSION_TEXT="aarch64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0" If I use the armbian build framework (with docker) on the v26.08 branch (or v26.8.0-trunk.X tags) to build the kernel packages myself (with ARTIFACT_IGNORE_CACHE=yes to avoid using the pre-built package), and install those, the dkms build succeeds. The diff in this case looks similar to the 26.5.1 diff. Is it perhaps a matter of the build platform being used for the pre-built kernel packages?