[OE-core] Kernel: Builds use old version of defconfig

[Bruce Ashfield]

On Thu, Nov 24, 2016 at 5:32 AM, Mike Looijmans <mike.looijmans at topic.nl>
wrote:

> On 24-11-16 11:10, Mike Looijmans wrote:
>
>> I'm currently experiencing a problem with "defconfig" files and the
>> kernel.
>>
>> In short, when I make a change to the "defconfig" file, the kernel is
>> rebuilt
>> (which is correct), but the resulting kernel has been built using the old
>> defconfig from a previous build, instead of the new one.
>>
>> The kernel recipe just contains "file://defconfig" in its SRC_URI. The
>> defconfig file is in the project's overlay.
>>
>> For example, I have a kernel with "CONFIG_DEVMEM" disabled:
>>
>> # gunzip < /proc/config.gz | grep DEVMEM
>> # CONFIG_DEVMEM is not set
>>
>> Now, I change the defconfig to contain CONFIG_DEVMEM=y and build the
>> image.
>> The result:
>>
>> # gunzip < /proc/config.gz | grep DEVMEM
>> # CONFIG_DEVMEM is not set
>>
>> So the change did not make it into the actual kernel, even though the
>> kernel
>> was rebuild as a result of the change.
>>
>> I run "bitbake -c cleansstate virtual/kernel" and build the image again:
>>
>> # gunzip < /proc/config.gz | grep DEVMEM
>> CONFIG_DEVMEM=y
>>
>> After cleaning, the result is correct and the new defconfig is active.
>>
>> I'm trying to figure out how this can happen, any help is welcome...
>>
>
> What seems to be the problem is this code in kernel.bbclass:
>
>         # Copy defconfig to .config if .config does not exist. This allows
>         # recipes to manage the .config themselves in
> do_configure_prepend().
>         if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
>                 cp "${WORKDIR}/defconfig" "${B}/.config"
>         fi
>
> This keeps any existing ".config" file if it happens to still be in the $B
> path, which is the case if you're rebuilding a kernel.
>
> I see two possible ways to fix this.
>
> 1) During "cleanup" also remove the .config file in the build dir.
> However, the build dir is probably kept alive for a reason? I also can't
> figure out how that "cleanup" is being done.
>
>
> 2) Remove the second part of the "if" statement, so it becomes:
>
>         # Copy defconfig to .config if "defconfig" exists. This allows
>         # recipes to manage the .config themselves in
> do_configure_prepend().
>         if [ -f "${WORKDIR}/defconfig" ]; then
>                 cp "${WORKDIR}/defconfig" "${B}/.config"
>         fi
>
> I've tested that, and it solves my problem. However, it will probably
> break other people's config mangling?
>
>
Yep, in particular all the fragment processing which has the capability of
starting
with a defconfig and then apply fragments from any number of other places.
When
that task completes, a full .config is in ${B}.  If that statement comes
along and
clobbers the .config ...

I'm actually working in the 2.3 release cycle to make the fragment
processing
be available to all kernels, which will likely solve this problem .. but we
can't
wait for that.

So I'm hoping that there's a way to make the behaviour cover both use cases.

Maybe someone with more bitbake knowledge can point out a way that can
detect if the task is being run due to a change in the task signature.

Since if you've modified the defconfig, the task is being re-run for that
change
and at that point we could safely remove the .config (versus forcing it on
the
clean step).

Bruce




>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79
> E-mail: mike.looijmans at topicproducts.com
> Website: www.topicproducts.com
>
> Please consider the environment before printing this e-mail
>
>
>
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20161124/94815944/attachment-0002.html>