Bug 12748

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.