On Wed, Nov 27, 2024 at 8:24 AM Enrico Jörns <e...@pengutronix.de> wrote:
> Hi, > > Am Mittwoch, dem 27.11.2024 um 01:29 -0800 schrieb Christian Gudrian via > lists.yoctoproject.org: > > Hello! > > Kernel modules depend on a specific version of the kernel package that > includes the Git commit > > hash of the kernel source tree at compile time (KERNEL_VERSION). When > using a patched kernel > > source this Git commit hash changes each time the patches get applied, > making each kernel binary > > effectively unique. This KERNEL_VERSION, however, is not part of the > shared state hash signature, > > as for this purpose it gets replaced by the plain LINUX_VERSION. > > Building out-of-tree kernel modules depend on a locally compiled kernel. > Doing this in a clean > > working directory leads to a freshly patched kernel source which in turn > results in a new > > KERNEL_VERSION. The out-of-tree kernel module then RDEPENDS on a kernel > package with this new > > KERNEL_VERSION. As the shared state signature of the newly compiled > kernel matches the existing > > one (the LINUX_VERSION hasn't changed) the new kernel is not packaged > and doesn't end up in the > > package feed. > > Consequently installation of the out-of-tree kernel module fails as the > required kernel package is > > not available. > > I have tried to make the packages aware of the specific KERNEL_VERSION. > But as this variable gets > > re-assigned during parsing I get unstable basehash values. > > Another approach would be to apply the patches in the upstream > repository to circumvent the need > > for local patching. > > Is there an easier way? > > I have some context on this that I would like to add since we just faced a > similar issue in a > project. > > The above-mentioned issue is caused by a combinations of: > > * a kernel recipe using kernel-yocto.bbclass > * kernel source pointing to tar (rather than a git) > * CONFIG_LOCALVERSION_AUTO set in kernel config > > The kernel-yocto class creates a Git repository from the archive content, > resulting in an > unreproducible commit hash (due to using the current user's Git author > settings and the current > system time). Subsequently, CONFIG_LOCALVERSION_AUTO causes this commit > hash to be embedded in the > kernel version, leading to non-reproducible kernel version strings. > > I guess the correct way to handle this would be to create the initial git > commit with e.g. > PATCH_GIT_USER_NAME/PATCH_GIT_USER_EMAIL and set the date to something > like SOURCE_DATE_EPOCH. > That should already be in place (the username and email). See the call to "check_git_config" in the bbclass. If it really is just the creation of the repository that is the issue here, then I could absolutely bring over some of the reproducible git options that are used in the kern-tools (see below). It also depends on exactly how the kernel is being patched. If the kern-tools are being used, then reproducible commits are already the case. If the lib/oe/patch.bbclass is being used, I don't see options like --committer-date-is-author-date being used, but I suspect I'm just not looking in the right place, since if the weren't anyone using PATCHTOOL="git" might be running into reproducibility issues, but only if what they are building captures git hashes .... which is the hint). > > If that sounds right, I could make a patch against kernel-yocto.bbclass. > > A project-specific quick fix would be of course to just disable > CONFIG_LOCALVERSION_AUTO. > This is what I do in oe-core (I've never liked localversion_auto). Bruce > > Regards, Enrico > > > Christian > > > > > > > > -- > Pengutronix e.K. | Enrico Jörns | > Embedded Linux Consulting & Support | https://www.pengutronix.de/ | > Steuerwalder Str. 21 | Phone: +49-5121-206917-180 | > 31137 Hildesheim, Germany | Fax: +49-5121-206917-9 | > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#64367): https://lists.yoctoproject.org/g/yocto/message/64367 Mute This Topic: https://lists.yoctoproject.org/mt/109804058/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
