Since commit 78cde87bb6e7 ("kernel-module-split: Append KERNEL_VERSION string to kernel module name"), 47400e36484b in yocto, cross recipe kernel module dependency generation stopped working, i.e. when having multiple external kernel modules from multiple recipes, where they depend on each other. To generate these dependencies, the kernel build system's KBUILD_EXTRA_SYMBOLS feature is used. This variable is supposed to contain a list of all Module.symvers of kernel modules that are dependencies. With this, the .modinfo ELF section of each kernel module will contain entries for all its dependencies. kernel-module-split.bbclass parses this to inject package dependencies for the package manager. It also installs Module.symvers into ${D}${includedir}${BPN}, and adds this location to KBUILD_EXTRA_SYMBOLS when building the dependent module. See commits 88f1bc77c220 ("module.bbclass: use Module.symvers for dependants") and e4af1fa3aee7 ("kernel-module-split.bbclass: generate dependencies across recipes") in oe-core. Since the KERNEL_VERSION string is appended to the generated package, we now get three packages: 1) kernel-module-A 2) kernel-module-A-dev 3) kernel-module-A-${KERNEL_VERSION} kernel-module-A is empty, kernel-module-A-dev depends on kernel-module-A and kernel-module-A-${KERNEL_VERSION} contains the actual .ko When installing kernel-module-B into an image, where kernel-module-B depends on symbols from A, the package manager now installs kernel-module-A. This obviously is incorrect, as kernel-module-A is empty and doesn't satisfy the dependency. I am not sure where kernel-module-A is generated, but the fix should probably be to: - make sure kernel-module-A isn't created - make sure the -dev package is actually called kernel-module-A-${KERNEL_VERSION}-dev, and provides kernel-module-A-dev - make the -dev package depend on kernel-module-A-${KERNEL_VERSION}
I actually have no idea how to fix this, and have some other big features to submit to M1 .. so won't be getting to this anytime soon. My suggestion is to just revert that change in oe-core, and go back to the submitter of the patch. They broke it .. they fix it :D
I actually started working on something... stay tuned
Given current events on the mailing list ('kernel: Add support for multiple kernel packages'), I am postponing doing anything here for now, as this touches similar places. I have a slightly better understanding of the issues now, tough. And it's slightly different than described originally in comment #0. One of my recipes is kernel-module-mac80211.bb, which builds more than one kernel module, each for different hardware. Let's call one of those modules ralink.ko. One important thing I didn't mention before is that I have KERNEL_MODULES_META_PACKAGE = "". I need this, because the recipe name corresponds to a helper kernel module created during the build, and there is no main kernel module as such which could serve as the recipe name. Firstly, I need to add extra RDEPENDS to some of the automatically splitted packages. This stopped working, as my RDEPENDS_${PN} = "crda" has no effect anymore. RDEPENDS_${PN}${KERNEL_MODULE_PACKAGE_SUFFIX} = "crda" would work, if it didn't cause checksum hash mismatch errors. Secondly, because of KERNEL_MODULES_META_PACKAGE="" I get an empty package with the name of the recipe with no additional dependencies, kernel-module-mac80211. Previously, that package contained mac80211.ko, but now mac80211.ko is moved to the kernel-module-mac80211${KERNEL_MODULE_PACKAGE_SUFFIX} package. So during image creation the empty package is installed. Given the kernel-module-mac80211${KERNEL_MODULE_PACKAGE_SUFFIX} package does RPROVIDE kernel-module-mac80211, the issue is creation of the kernel-module-mac80211 package due to ALLOW_EMPTY_${PN} in module.bbclass. I think I have an idea for how to solve these.
Bruce did you want Andre to fix this?
Bulk move of 64 bugs to 4.3 M3 after a quick review. If a bug is actually fixed, please add a commit link and resolve it. -- Randy for YP bug team.
Moved to M4.
Bulk move to 5.0 M1. -- Randy
This doesn't appear to be urgent so I'm moving it to M3.
Bulk move of bugs from 5.0-M3 to 5.99. The bugs in this list are all unassigned and are ones that I consider to be nice to do some time but not essential track from milestone to milestone in 5.0 or 5.1. We agreed on this bug handling approach in the YP bug review on Feb 22, 2024. If you disagree, please move back to a 5.[012...]-M* milestone.
Via email Andre said: Hi Randy, On Wed, 2026-03-11 at 11:04 -0400, Randy MacLeod wrote: > > Can you confirm that: > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12290 > > > is still a valid bug? If so and if it's still not urugent, it'll go to 6.99. TBH, I'd be fine with closing the bug. I am not in a position to test whether or not this still is a problem or if it was fixed again (maybe as a side-effect of something else). It could always be reopened if somebody (or even I) requires this to work again in the future. What do you think? Cheers, Andre'
Re-tested on current master (oe-core, kernel 6.18.x). The bug does not reproduce. Reproducer: two external kernel-module recipes — kernel-module-testfoo (EXPORT_SYMBOL) and kernel-module-testbar (consumes the symbol, DEPENDS = "kernel-module-testfoo"). After building, pkgdata shows: RDEPENDS:kernel-module-testbar-<KV>: kernel-<KV> kernel-module-testfoo-<KV> RPROVIDES:kernel-module-testbar-<KV>: kernel-module-testbar RDEPENDS:kernel-module-testbar: kernel-module-testbar-<KV> The consumer's .ko-containing package RDEPENDS the real -${KERNEL_VERSION} package of the exporter — not the empty unsuffixed package, which was the original failure mode. In the code this comes from frob_metadata() generating the modinfo-derived RDEPENDS via the suffixed output_pattern in kernel-module-split.bbclass, plus KERNEL_MODULE_PROVIDE_VIRTUAL making the suffixed package RPROVIDE the unsuffixed name and the recipe-name meta package RDEPEND the real split packages. To guard against regressing this again, I've submitted an oe-selftest to the openembedded-core list: oeqa/selftest/kernelmodulesplit: test cross-recipe kernel module dependencies Patch: https://patchwork.yoctoproject.org/project/oe-core/patch/20260619130323.2640105-1-sivakumar.bs@gmail.com/ (run with oe-selftest -r kernelmodulesplit.KernelModuleSplit.test_cross_recipe_module_dependency).
Patch merged: https://git.openembedded.org/openembedded-core/commit/?id=6ca1f213e2718b95c52a1e643b80d17bb9317da5