From cf48c823a8a8e07ad0206bd912683335b70fca13 Mon Sep 17 00:00:00 2001
From: Harry Waschkeit <44188360+HarryWaschkeit@users.noreply.github.com>
Date: Wed, 22 Jul 2026 21:37:11 +0200
Subject: [PATCH] fix(kernel): narrow do_sign/do_deploy DISTRO_FEATURES vardep
 to secureboot

do_sign (linux-common-secureboot.inc) and do_deploy (linux-phytec-fitimage.inc)
each read the raw DISTRO_FEATURES string directly to check for 'secureboot'
membership. BitBake's automatic vardep scanner therefore ties both tasks'
taskhash to the entire feature list, not just the secureboot flag.

Because do_compile/do_configure/do_kernel_metadata/do_compile_kernelmodules
have no sstate object of their own, any unrelated DISTRO_FEATURES change
(e.g. wifi/bluetooth flags driven by device_caps.json, introduced in
e1ad988) forces the whole kernel compile lineage to re-run for real on
the next build, while do_package_write_ipk's own signature is untouched
and gets served from an older cached object. This produces an internally
inconsistent image where the deployed kernel Image and the packaged
kernel modules originate from different builds and refuse to load
(module version magic mismatch).

Observed directly in omnect-os-build/tauril2,gateway-devel build 107
(2026-07-10): do_sign/do_deploy executed fresh due to a DISTRO_FEATURES
change, while do_package_write_ipk hit the shared sstate cache with an
object from build 104, shipping kernel modules incompatible with the
freshly built kernel Image.

This adds a derived SECUREBOOT_ENABLED variable and excludes the raw
DISTRO_FEATURES var from do_sign/do_deploy's tracked vardeps, so their
taskhash only changes when secureboot membership itself actually
toggles.
---
 .../linux/linux-phytec-imx_%.bbappend         | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/dynamic-layers/phytec/recipes-kernel/linux/linux-phytec-imx_%.bbappend b/dynamic-layers/phytec/recipes-kernel/linux/linux-phytec-imx_%.bbappend
index e24369915..a4ec8dd8f 100644
--- a/dynamic-layers/phytec/recipes-kernel/linux/linux-phytec-imx_%.bbappend
+++ b/dynamic-layers/phytec/recipes-kernel/linux/linux-phytec-imx_%.bbappend
@@ -1,3 +1,24 @@
 FILESEXTRAPATHS:prepend := "${THISDIR}/linux:"
 
 SRC_URI += "file://0001-feat-linux-imx-added-ramoops-for-tauril2.patch"
+
+# Both linux-common-secureboot.inc's do_sign() ("secureboot" in
+# d.getVar('DISTRO_FEATURES')) and linux-phytec-fitimage.inc's
+# do_deploy:append() ("echo ${DISTRO_FEATURES} | grep -wq secureboot")
+# read the *raw* DISTRO_FEATURES string directly. BitBake's vardep
+# scanner therefore ties do_sign/do_deploy's taskhash to the ENTIRE
+# feature list, not just secureboot membership. Because do_compile,
+# do_configure, do_kernel_metadata etc. have no sstate object of their
+# own, any unrelated DISTRO_FEATURES churn (e.g. wifi/bluetooth flags
+# driven by device_caps.json, see commit e1ad988) forces the whole
+# kernel/module compile lineage to re-run for real, while
+# do_package_write_ipk's own (unrelated) signature stays cache-hit --
+# producing a kernel/module version mismatch (observed 2026-07-10,
+# build 107 of omnect-os-build/tauril2 gateway-devel). Narrow the
+# tracked dependency to just the boolean outcome these tasks actually
+# care about.
+SECUREBOOT_ENABLED := "${@bb.utils.contains('DISTRO_FEATURES', 'secureboot', '1', '0', d)}"
+do_sign[vardeps] += "SECUREBOOT_ENABLED"
+do_sign[vardepsexclude] += "DISTRO_FEATURES"
+do_deploy[vardeps] += "SECUREBOOT_ENABLED"
+do_deploy[vardepsexclude] += "DISTRO_FEATURES"