14344 2021-04-14 15:04:27 +0000 bitbake/OE "latches" sstate even with taskdep changes 2021-04-15 14:37:27 +0000 1 1 7 Build System, Metadata & Runtime OE-Core kernel unspecified x86 x86_64 RESOLVED NOTABUG Undecided normal --- 1 jandryuk bruce.ashfield randy.macleod tom.zanussi --- --- Don't know oldest_to_newest 89928 0 jandryuk 2021-04-14 15:04:27 +0000 Does OE/Bitbake "latch" its decision to use sstate and not re-evaluate if the dependent taskdeps change? We have builds using sstate, externalsrc and rm_work. We build signed kernel modules letting Linux auto generate a key. This key is stored in STAGING_KERNEL_BUILDDIR via do_shared_workdir and it is used to sign out-of-tree, externalsrc modules. Sometimes the externalsrc modules are rebuilt and don't have a matching key, so they cannot load. The scenario seems to be: virtual/kernel (linux-openxt) is selected from sstate argo-module needs to be rebuilt since exernalsrc and MACHINE changed argo-module -> depends on make-mod-scripts -> virtual/kernel:do_shared_workdir -> virtual/kernel:do_compile The kernel recompiles and generates a new signing key, which is used for argo-module. However, the newly re-compiled kernel is not packaged, so the old one from sstate is re-used. This leads to the signature mismatch. We added the following to linux-openxt to (try to) prevent such a scenario: def get_signing_key(d): path = os.path.join(d.getVar("B"),"certs","signing_key.x509") return path + ":" + str(os.path.exists(path)) do_shared_workdir[file-checksums] = "${@get_signing_key(d)}" However, the OE/bitbake decision to use sstate for virtual/kernel seems to be "latched" early on and not re-evaluated even though the task hashes for virtual/kernel changed. Is this expected? Thanks, Jason 89952 1 randy.macleod 2021-04-15 14:37:27 +0000 We have to resolve task hashes in advance of builds, ie. at parse time. So we don't support changing task hashes part way through the build.