Re: kernel rebuild and bitbake -c menuconfig

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 12-05-11 09:12 AM, Frans Meulenbroeks wrote:
> 2012/5/11 Bruce Ashfield<bruce.ashfield@windriver.com>:
>> On 12-05-11 08:51 AM, Frans Meulenbroeks wrote:
>>>
>>> 2012/5/11 Bruce Ashfield<bruce.ashfield@windriver.com>:
>>>>
>>>> On 12-05-11 03:07 AM, Frans Meulenbroeks wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm wondering how to do a kernel rebuild after doing changing the
>>>>> .config
>>>>> using
>>>>> bitbake -c menuconfig virtual/kernel
>>>>> I've tried forcing a recompile using:
>>>>> bitbake -ccompile -f virtual/kernel
>>>>> that indeed rebuilds the kernel
>>>>> However if I then do a bitbake virtual/kernel this does not result in
>>>>> an image in my deploy dir.
>>>>>
>>>>> system info
>>>>> host: ubuntu 12.04
>>>>> denzil 7.0 software (from tarball)
>>>>> target: ppc (actually for my own board but I did not do weird things
>>>>> in my bsp, like adding extra tasks.
>>>>>
>>>>> It seems the vmlinux.bin.gz is still generated but the uImage is not
>>>>> (which can also be seen from the log below where do_install is not
>>>>> ran.
>>>>> Additional proof:
>>>>> f5ad9f2b30047a8d3493a1a2880a-r1.40$ ls -l ./image/kernel/uImage
>>>>> ./linux-syrcxx-standard-build/vmlinux.bin.gz
>>>>> -rw-r--r-- 1 frans frans 1609509 2012-05-10 10:19 ./image/kernel/uImage
>>>>> -rwxr-xr-x 1 frans frans 1611499 2012-05-11 08:52
>>>>> ./linux-syrcxx-standard-build/vmlinux.bin.gz
>>>>> This si from after I ran the bitbake commands below.
>>>>>
>>>>> What is going wrong here?
>>>>
>>>>
>>>>
>>>> You are likely hitting this bug:
>>>>
>>>>   https://bugzilla.yoctoproject.org/show_bug.cgi?id=2256
>>>>
>>>> It's a known issue that is being worked on for 1.3, but the bugzilla has
>>>> workarounds that youl can use in the meantime.
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>> Bruce,
>>>
>>> Thanks for the reference.
>>> I am indeed seeing that bug.
>>>
>>> What I did was the solution of Darren that was listed in comment5, but
>>> that did not work for me.
>>> I was unaware of the cleansstate task.
>>>
>>> Actually thinking of it, if in the flow:
>>> $ bitbake virtual/kernel -c cleansstate
>>> $ bitbake virtual/kernel -c menuconfig
>>> $ bitbake virtual/kernel -c compile -f; bitbake virtual/kernel
>>> the first two steps can be exchanged (so first menuconfig then
>>> cleansstate, then menuconfig could force the cleansstate to run
>>>
>>> (or menuconfig could run cleanstate befure doing the actual menuconfig
>>> work)
>>
>>
>> Hopefully we'll end up with a flag that can just indicate that sstate
>> shouldn't be used for a particular package after a certain trigger has
>> been hit .. or something like that :)
>>
>> But indeed, we could automatically trigger some sstate cleaning as well
>> as an option.
>>
>> Glad to hear that you are around the issue now,
>>
>> Bruce
>
> Well the problem is not as well solved as I'd hoped for as cleansstate
> does imply a -clean and so blows away any other change
>
> I've added this to bug 2256:

Good (sort of) .. the bug is definitely the right place to log this.

>
> Unfortunately this does not only apply to menuconfig.
>
> The following scenario also does not work
> bitbake virtual/kernel
> modify a kernel source file
> bitbake -ccompile -f virtual/kernel
> bitbake virtual/kernel
> The latter does not run do_install
>
> This is on ppc
>
> I tried the cleansstate solution, as suggested by Darren in comment 7
> but unfortunately cleansstate implies clean so it removes the whole
> tree (including the modified file).
>
> Best regards, Frans
> (ps: for me it is nice to have do_install being run as I combine
> device tree and kernel image into a single file using mkimage in
> do_install_append.; will try next time to do a -c compile -f followed
> by a -c install f)

So the work around is slightly more complicated for now, with the extra
forced install.

Definitely something we'll fix up during the worklow streamlining being
done as part of 1.3.

Bruce