Created attachment 4301 [details] Compilation logs when building hello-mod against 4.16.5 and 4.16.7 Sorry in advance, if I am reporting this bug under the wrong product/component. It seems that the hello-mod recipe from meta-skeleton does not build under Linux 4.16.7, but builds fine under Linux 4.16.5. Is anyone else able to replicate this issue?
Ok, this bug doesn't have to do with a specific kernel, it just resolves itself (temporarily) when moving between kernels. In two cases, I tried to build a new image starting with (i) 4.16.8 and (ii) 4.16.5. Both of these builds failed as per the output in the previous attachment. I then change the version of Linux by modifying the SRCREV / commit id to (i) 4.16.5 and (ii) 4.16.8, and in both cases the build succeeds and hello.ko is included in my image. I had a look at the output of bitbake -e using grep (against "hello" and "MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS") but couldn't find any significant differences. I also checked the compilation and configuration logs, the only interesting thing I saw was in the configuration logs where on the second run this is printed: DEBUG: Executing shell function do_configure NOTE: make KERNEL_SRC=/path/to/poky-rocko/build/tmp/work-shared/duovero/kernel-source clean rm -f *.o *~ core .depend .*.cmd *.ko *.mod.c rm -f Module.markers Module.symvers modules.order rm -rf .tmp_versions Modules.symvers DEBUG: Shell function do_configure finished DEBUG: Executing python function do_qa_configure DEBUG: Python function do_qa_configure finished while on the first run, only this is printed DEBUG: Executing shell function do_configure DEBUG: Shell function do_configure finished DEBUG: Executing python function do_qa_configure DEBUG: Python function do_qa_configure finished Although this may have just occurred since this was the second run of the configure task for hello-mod.
The 4.16 kernel is not supported in Rocko (Yocto 2.4).
Thank you for the feedback Stephano! I didn't realise this :)
Reopening since this issue is also present in sumo. The following steps recreate the report issue. --- 1. Starting from my home directory, I clone the sumo and open embedded layers git clone -b sumo git://git.yoctoproject.org/poky.git poky-sumo cd poky-sumo git clone -b sumo git://git.openembedded.org/meta-openembedded 2. I then clone the layer for the duovero board git clone https://github.com/jumpnow/meta-duovero.git 3. Apply a quick fix mv meta-duovero/conf/local.conf-sample meta-duovero/conf/local.conf.sample 4. Copy the hello-mod recipe inside the meta-duovero layer cp -r meta-skeleton/recipes-kernel/hello-mod meta-duovero/recipes-kernel/ 5. Add the line 'MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS = "kernel-module-hello"' to the machine configuration in meta-duovero/conf/machine/duovero.conf 6. Init the environment TEMPLATECONF=meta-duovero/conf source oe-init-build-env 7. Build a console image from the duovero layer (defaults at the time of writing to a 4.16.8 kernel) bitbake console-image
Created attachment 4306 [details] The output of bitbake -e when building with sumo
Created attachment 4307 [details] All logs and scripts from the failed attempt at building hello-mod
Created attachment 4308 [details] All logs and scripts from building linux-stable
Can I provide any additional information or do any further testing to help resolve this bug?
Hi, Sorry about the delay in looking at this, I think we're a little confused about where the problem lies. We test building hello-mod quite extensively with the core Yocto Project and this works on sumo and on master. It appears therefore to be something odd about the usage of newer kernels with the older release. Since you last made comments on this bug the duovero layer appears to have changed, it also appears to include a copy of the hello-mod as hello-mod2 which may confuse things. Are you still having the problem and are the errors the same? It could be there are some missing steps which need to be run when building newer kernels, such as "make prepare" on the kernel sources. The change from master was: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=0f85563eacf5138d98b826343cdfc3833d1c5c8e but sumo behaves quite a bit differently as there were code changes in this area (the make-mod-scripts moved to a separate recipe). It may be worth trying adding the prepare to the make-mod-scripts task? Also, technically this bugzilla isn;t really the right place for this bug as the bug appears to be introduced by the external layer and doesn't seem to be a bug reproducible in OE-Core.
I tried taking the linux-stable 4.18 recipe from this layer and building hello-mod with sumo and it works fine. I also note that rocko did have some backports related to newer kernels: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=rocko&id=9e83976054925a49196f4c5be7eb4b4b9cc1e041, http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=rocko&id=9e83976054925a49196f4c5be7eb4b4b9cc1e041 As far as I can tell, things are therefore working as intended and if there are issues, they're being added by other layers outside of OE-Core and are outside the scope of this bugzilla.
Hi there, I swapped some emails with the duovero layer maintainer and we found a solution to the problem. See this commit on Github: https://github.com/jumpnow/meta-duovero/commit/99fc9d3ba3820367e5c7f65a278fba8a8d5a4f79 To provide some context, this is our conversation leading to the solution / commit. --- Hi Scott, Just a quick note, I noticed something else strange (and possibly a related problem) with your layer. When I do a build from scratch, without any external kernel modules like hello-mod, hello-mod2 and enter menuconfig with "bitbake linux-stable -c menuconfig" I noticed that CONFIG_ARCH_OMAP4 was not selected... I then ran "bitbake linux-stable -c kernel_configme -f" (yes, force was required), and re-ran menuconfig to see that now "CONFIG_ARCH_OMAP4=y". I have 'INHERIT += "rm_work"' in local.conf commented out so this shouldn't be causing any problems. So just a thought, but if this is happening, perhaps there is a general problem with the defconfig and if CONFIG_MODULES was not selected at the time of building the kernel, that may explain why the external kernel modules were failing to build... If you build an image from scratch, are you able to replicate this observation / behavior? --- That was it. Some of the steps linux-yocto.inc adds don't run at the right time. Anyway, there was nothing important there so I created a simpler linux-stable.inc for the common kernel stuff and am using that for the linux-stable_4.17.bb recipe. Seems to be working with multiple boards on clean TMPDIR builds. meta-duovero has the commits.
Thanks for the info, that helps explain a lot! I did try and replicate this with sumo and couldn't so I think the underlying issues have also been fixed now. I appreciate having the resolution info here though so anyone else running into this knows how it was solved.