Re: How to build a kernel using menuconfig

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2011-09-28 at 05:33 -0600, Gary Thomas wrote:
> On 2011-09-27 21:45, Darren Hart wrote:
> >
> >
> > On 09/26/2011 06:45 AM, Gary Thomas wrote:
> >> I'm working with a recent Poky checkout:
> >>     meta-yocto        = "master:7a0cbe6b0e5185aebabedc515b427994bc2a15dc"
> >>
> >> I used to be able to do this:
> >>     % bitbake<some-image>
> >> This step builds everything, including the kernel
> >>     % bitbake virtual/kernel -c menuconfig
> >> Adjust some settings
> >>     % bitbake virtual/kernel -c compile -f
> >>     % bitbake virtual/kernel
> >> Rebuild my image with the new kernel included
> >>     % bitbake<some-image>
> >>
> >> In the past, this would let me adjust some kernel settings, e.g. add a new
> >> module, then rebuild it and later add this to an image.  Sadly, when I run
> >> through these steps with the current master, the new kernel gets compiled
> >> (because I used -f), but not packaged.
> >>
> >> The only thing I've done differently, save updating master, is my build
> >> today includes
> >>     INHERIT += "rm_work"
> >>
> >> Am I missing something?
> >>
> >> How can I build the kernel and make these in-tree adjustments like I used to?
> >> I do this to figure out what kernel settings to set/save for my final packaging.
> >
> >
> > Yeah, this is standard kernel devel workflow. I typically use the kernel
> > recipe name directly, but otherwise my process is the same. What happens
> > now when you run "bitbake virtual/kernel" after the compile -f ?
> >
> 
> As indicated above, nothing.  If I remove rm_work from my configuration
> and then rebuild the kernel, it works as expected.

It sounds like there is a bad interaction between rm_work and this set
of steps. I can kind of see why, rm_work promotes the stamp files to
setscene ones (so the same as if a sstate build was made). Nothing in
the above steps would actually remove the setscene stamps so bitbake
sees them and assumes everything is still valid.

If you did a bitbake -c package -f virtual/kernel then I suspect it
would actually sort itself out. Off the top of my head I can't see a way
to fix this in any straightforward way :/.

Cheers,

Richard