custom-kernel headers: scripts are wrong architecture

["MOESSBAUER, Felix" <felix.moessbauer@siemens.com>]

Dear devs,

while debugging a broken non-cross kernel module build, I found that
there is a more generic issue about our linux-headers-${KERNEL_NAME}
package: It might contain the kernel scripts (ELF binaries) in the
wrong architecture. This only happens if the kernel itself is cross-
compiled.

Let's consider the following example, where we compile for a debian
bookworm arm64 target. We further look at the 'fixdeps' script from the
kernel tools (required during kmod builds).

Example 1 (stock kernel):

The script is located in package linux-kbuild-6.1 (dependency of linux-
headers-<...>).
- file /usr/lib/linux-kbuild-6.1/scripts/basic/fixdep: ELF 64-bit LSB
pie executable, ARM aarch64, ...
- linux-headers-arm64 : arm64
- linux-kbuild-6.1 : arm64

Example 2 (custom kernel):

- file /usr/src/linux-headers-6.1.54-cip6-rt3/scripts/basic/fixdep: ELF
64-bit LSB pie executable, x86-64
- linux-headers-iot2050-rt : arm64

In example 2, the kmod build is obviously broken, as the emulated build
will not be able to execute the x64 binary. Also, in an :arm64 package,
there must be no foreign architecture binaries.

This behavior can also be reproduced, by cross-compiling a target with
a custom kernel and disabling the cross-build for a module, using
ISAR_CROSS_COMPILE="0" in the module build recipe.

It would be great, if someone could have a look there. At a first
glance, this issue looks closely related to "linux-custom: Split up
binaries from kernel headers to kbuild packages". Maybe Stefan can
comment on this as well.

PS: This bug was uncovered today, as the cross-build of a kernel module
on debian bookworm arm64 is currently broken in upstream debian. I
already reported this bug in [1].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061075

Best regards,
Felix

-- 
Siemens AG, Technology
Linux Expert Center