Hello Richard, Sorry to hear that, and sorry for making you debug this for hours.
I just saw your patch, “kernel-module-split: Remove get_ext_mod”. I’m OK with that workaround. On my side, I’ll think about a better solution to cover all out-of-tree module use cases. I’m rebuilding my PC for an upgrade, so it will take a while. Thank you. BR, Anis On Sat 5 Sep 2026 at 09:39, Richard Purdie < [email protected]> wrote: > On Thu, 2026-08-27 at 01:34 +0200, Anis Bougrine wrote: > > Fixes [YOCTO #12927] > > > > Currently, signed kernel modules are not stripped in order to preserve > > their valid signatures. See commit 4c47e5f. > > > > Therefore, this commit makes kernel modules stripped and correctly > > signed. Two options are possible: > > > > - Strip the kernel modules after installation and before signing. > > - Re-sign the kernel modules after stripping and before package > splitting. > > > > The first option was rejected because debug symbols would be dropped > early > > in the build workflow, which may impact the SPDX process. > > > > The second option is adopted because it does not impact the build flow. > > > > Reported-by: Ross Burton <[email protected]> > > Signed-off-by: Anis Bougrine <[email protected]> > > --- > > .../kernel-module-split.bbclass | 25 +++++++++++++++++++ > > 1 file changed, 25 insertions(+) > > > > diff --git a/meta/classes-recipe/kernel-module-split.bbclass > b/meta/classes-recipe/kernel-module-split.bbclass > > index ab2f0d1c37..2b40437cc2 100644 > > --- a/meta/classes-recipe/kernel-module-split.bbclass > > +++ b/meta/classes-recipe/kernel-module-split.bbclass > > @@ -35,6 +35,11 @@ modprobedir ??= > "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '${nonarch_b > > > > KERNEL_SPLIT_MODULES ?= "1" > > PACKAGESPLITFUNCS =+ "split_kernel_module_packages" > > +# Order matters: > > +# 1. Strip the modules > > +# 2. Re-sign the modules (if enabled) > > +# 3. Split the packages > > +PACKAGESPLITFUNCS =+ "post_strip_kernel_modules_signing" > > > > KERNEL_MODULES_META_PACKAGE ?= "${@ d.getVar("KERNEL_PACKAGE_NAME") or > "kernel" }-modules" > > > > @@ -42,6 +47,26 @@ KERNEL_MODULE_PACKAGE_PREFIX ?= "" > > KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}" > > KERNEL_MODULE_PROVIDE_VIRTUAL ?= "1" > > > > +# This function supports both in-tree and out-of-tree modules. > > +post_strip_kernel_modules_signing(){ > > + # Read .config values to determine if module auto-signing is enabled > > + is_modules="$(${STAGING_KERNEL_DIR}/scripts/config --file > ${KBUILD_OUTPUT}/.config --state MODULES)" > > + is_module_sig="$(${STAGING_KERNEL_DIR}/scripts/config --file > ${KBUILD_OUTPUT}/.config --state MODULE_SIG)" > > + is_module_sig_all="$(${STAGING_KERNEL_DIR}/scripts/config --file > ${KBUILD_OUTPUT}/.config --state MODULE_SIG_ALL)" > > + > > + if [ "$is_modules" = "y" ] && [ "$is_module_sig" = "y" ] && [ > "$is_module_sig_all" = "y" ]; then > > + # Sign modules under ${PKGD}, with M= if out-of-tree module. > > + # Out-of-tree module Makefiles invoke the kernel Makefile by > appending M= (the module directory) to MAKEFLAGS. > > + # However, they usually do not provide a modules_sign target. > Therefore, the kernel modules_sign target has to > > + # be invoked manually after retrieving M= variable from package > source code Makefile. > > + oe_runmake \ > > + -C ${KBUILD_OUTPUT} \ > > + > MODLIB=${PKGD}${nonarch_base_libdir}/modules/${KERNEL_VERSION} \ > > + ${@'M=%s' % oe.kernel_module.get_ext_mod(d) if not > "virtual/kernel" in d.getVar('PROVIDES') else ''} \ > > + modules_sign > > + fi > > +} > > This has merged and I'm really happy to see the signing code improved. > There is a weird bug this as introduced though where the eSDK is > breaking in kernel module compile tests. > > This is an example failure: > > https://autobuilder.yoctoproject.org/valkyrie/#/builders/30/builds/4551 > > In the bad environment, you can source the test eSDK environment: > > . > /srv/pokybuild/yocto-worker/qemux86/build/build/tmp/work/qemux86-poky-linux/core-image-sato/1.0/testsdkext/environment-setup-core2-32-poky-linux > > Rerun the compile step: > > > /srv/pokybuild/yocto-worker/qemux86/build/build/tmp/work/qemux86-poky-linux/core-image-sato/1.0/testsdkext/tmp/work/qemux86-poky-linux/kernel-module-hello-world/1.0+git/temp/run.do_compile > > where you see hello-world.ko get generated: > > make[2]: Entering directory > '/srv/pokybuild/yocto-worker/qemux86/build/build/tmp/work/qemux86-poky-linux/core-image-sato/1.0/testsdkext/workspace/sources/kernel-module-hello-world' > LD [M] hello-world.ko > make[2]: Leaving directory > '/srv/pokybuild/yocto-worker/qemux86/build/build/tmp/work/qemux86-poky-linux/core-image-sato/1.0/testsdkext/workspace/sources/kernel-module-hello-world' > > then watch: > > devtool build kernel-module-hello-world > > fail as above, noting that the hello-world.ko file disappears by the time > it runs. > > To cut a long story short (hours of debugging), this happens during > parsing of the kernel-module-hello-world recipe. If you add a > bb.warn("Executing make") to oe.kernel_module.get_ext_mod() in > meta/lib/oe/kernel_module.py, you will see it runs make during parsing > and that make command deletes the .ko file. > > This raises a few questions: > > a) why is make being run during parsing? > > The shell function is being expanded to work out dependencies > and that triggers the python function call. This should definitely not > be happening during parsing so that is a bug. > > b) why does calling --dry-run on the kernel makefile delete files? > > We need to fix this somehow to avoid the failures/bad behaviour. I at > least wanted to explain the issue now I'd found the underlying area of > the problem. I've not really had a chance to think about solutions yet. > > Cheers, > > Richard > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#245243): https://lists.openembedded.org/g/openembedded-core/message/245243 Mute This Topic: https://lists.openembedded.org/mt/120949282/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
