Hello, I'm seeing one more issue caused by this change.

Then you enable both:
CONFIG_MODULE_SIG
and
CONFIG_MODULE_COMPRESS/CONFIG_MODULE_COMPRESS_XZ/CONFIG_MODULE_COMPRESS_ALL

then the do_package fails in module_sign:

| DEBUG: Executing shell function post_strip_kernel_modules_signing
| NOTE: make ARCH=x86 CC=x86_64-oe-linux-gcc   -fuse-ld=bfd
-fcanon-prefix-map
-ffile-prefix-map=/OE/build/oe-core/tmp/work-shared/qemux86-64/kernel-source=/usr/src/debug/linux-yocto/7.2.4+git
 -ffile-prefix-map=/OE/build/oe-core/tmp/wor
k/qemux86_64-oe-linux/linux-yocto/7.2.4+git/linux-qemux86_64-standard-build=/usr/src/debug/linux-yocto/7.2.4+git
 
-ffile-prefix-map=/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/recipe-sysroot=
 -ffile-prefix-map=/O
E/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/recipe-sysroot-native=
  
-ffile-prefix-map=/OE/build/oe-core/tmp/work-shared/qemux86-64/kernel-source=/usr/src/kernel
 -ffile-prefix-map=/OE/build/oe-core/tmp/work-shared/
qemux86-64/kernel-build-artifacts=/usr/src/kernel
LD=x86_64-oe-linux-ld.bfd  OBJCOPY=x86_64-oe-linux-objcopy
STRIP=x86_64-oe-linux-strip HOSTCC=gcc
HOSTCFLAGS=-isystem/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git
/recipe-sysroot-native/usr/include -O2 -pipe
HOSTLDFLAGS=-L/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/recipe-sysroot-native/usr/lib

-L/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-y
octo/7.2.4+git/recipe-sysroot-native/lib
-Wl,--enable-new-dtags
-Wl,-rpath-link,/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/recipe-sysroot-native/usr/lib
             
-Wl,-rpath-link,/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/recipe-sysroot-native/lib

-Wl,-rpath,/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/recipe-sys
root-native/usr/lib
-Wl,-rpath,/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/recipe-sysroot-native/lib
                        -Wl,-O1 -Wl,--allow-shlib-undefined
-Wl,--dynamic-linker=/OE/bui
ld/oe-core/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
-pthread HOSTCPP=gcc  -E HOSTCXX=g++
HOSTCXXFLAGS=-isystem/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/recipe-sysroot-native/usr/include
-O2
-pipe HOSTPKG_CONFIG=pkg-config-native PAHOLE=false -C
/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/linux-qemux86_64-standard-build
MODLIB=/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/packag
e/usr/lib/modules/7.2.4-yocto-standard modules_sign
| make: Entering directory
'/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/linux-qemux86_64-standard-build'
|   SIGN    
/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/package/usr/lib/modules/7.2.4-yocto-standard/kernel/fs/nls/nls_cp737.ko
| At main.c:247:
| - SSL error:FFFFFFFF80000002:system library::No such file or
directory: ../sources/openssl-4.0.2/crypto/bio/bss_file.c:73
| - SSL error:10000080:BIO routines::no such file:
../sources/openssl-4.0.2/crypto/bio/bss_file.c:81
| sign-file: 
/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/package/usr/lib/modules/7.2.4-yocto-standard/kernel/fs/nls/nls_cp737.ko
| make[2]: *** 
[/OE/build/oe-core/tmp/work-shared/qemux86-64/kernel-source/scripts/Makefile.modinst:141:
/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/package/usr/lib/modules/7.2.4-yocto-standard/kernel/fs/nls/nls_c
p737.ko] Error 1
| make[1]: *** 
[/OE/build/oe-core/tmp/work-shared/qemux86-64/kernel-source/Makefile:2104:
modules_install] Error 2
| make: Leaving directory
'/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/linux-qemux86_64-standard-build'
| make: *** 
[/OE/build/oe-core/tmp/work-shared/qemux86-64/kernel-source/Makefile:248:
__sub-make] Error 2

oe-core $ ls 
/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/package/usr/lib/modules/7.2.4-yocto-standard/kernel/fs/nls/nls_cp737*
/OE/build/oe-core/tmp/work/qemux86_64-oe-linux/linux-yocto/7.2.4+git/package/usr/lib/modules/7.2.4-yocto-standard/kernel/fs/nls/nls_cp737.ko.xz

because the .ko files no longer exist, only .ko.xz are. Not sure if
there is a better place where to call module_sign or just disable this
post_strip one when CONFIG_MODULE_COMPRESS_* is set?

Easily reproduced with just oe-core:

diff --git a/meta/recipes-kernel/linux/files/module-sig.cfg
b/meta/recipes-kernel/linux/files/module-sig.cfg
new file mode 100644
index 0000000000..e2be1688cc
--- /dev/null
+++ b/meta/recipes-kernel/linux/files/module-sig.cfg
@@ -0,0 +1,4 @@
+CONFIG_MODULE_COMPRESS=y
+CONFIG_MODULE_COMPRESS_XZ=y
+CONFIG_MODULE_COMPRESS_ALL=y
+CONFIG_MODULE_SIG=y
diff --git a/meta/recipes-kernel/linux/linux-yocto_7.2.bb
b/meta/recipes-kernel/linux/linux-yocto_7.2.bb
index e3edaaada5..58278fc525 100644
--- a/meta/recipes-kernel/linux/linux-yocto_7.2.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_7.2.bb
@@ -40,6 +40,7 @@ PN:class-devupstream = "linux-yocto-upstream"
 KBRANCH:class-devupstream = "v7.2/base"

 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH};protocol=https
\
+           file://module-sig.cfg \
            
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-7.2;destsuffix=${KMETA};protocol=https"

 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"

Or with just MODULE_SIG for raspberrypi builds as the default
defconfig already has MODULE_COMPRESS in:
arch/arm64/configs/bcm2711_defconfig:CONFIG_MODULE_COMPRESS=y
arch/arm64/configs/bcm2711_defconfig:CONFIG_MODULE_COMPRESS_XZ=y
arch/arm64/configs/bcm2711_rt_defconfig:CONFIG_MODULE_COMPRESS=y
arch/arm64/configs/bcm2711_rt_defconfig:CONFIG_MODULE_COMPRESS_XZ=y
arch/arm64/configs/bcm2712_defconfig:CONFIG_MODULE_COMPRESS=y
arch/arm64/configs/bcm2712_defconfig:CONFIG_MODULE_COMPRESS_XZ=y

Regards,


On Mon, Sep 7, 2026 at 12:28 PM Anis Bougrine via
lists.openembedded.org
<[email protected]> wrote:
>
> 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 (#245476): 
https://lists.openembedded.org/g/openembedded-core/message/245476
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]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to