[yocto] How to recreate rootfs image

[Paul Eggleton]

On Friday 28 August 2015 13:32:23 Lenivyy Viktor wrote:
> > On Thursday 27 August 2015 08:25:38 Lenivyy Viktor wrote:
> > > > In your kernel recipe are you using SRC_URI to fetch from a git
> > > > repository (e.g. git:// URI) or from a local directory?
> > >
> > > This kernel is fetched from local directory.
> > >
> > > > I guess that if you're using a local path, there can be either some
> > > > uncommitted changes, or a stale git index.
> > >
> > > No, because kernel built from sources in local directory doesn’t have
> > > “-dirty” in version string.
> > > 
> > > > You can try just for the experiment to add your current kernel
> > > > sources to a test git repo and point the SRC_URI to it, so bitbake
> > > > can clone the repo by git revision (SRCREV = "${AUTOREV}" will skip
> > > > the need to update the recipe revision constantly during
> > > > development). This should work fine, without the "-dirty" version
> > > > suffix.
> > >
> > > I can try this, but it doesn't answer main question:
> > > how can I recreate rootfs image starting from the point after fetching
> > > Linux sources, so Yocto’s copy will remain intact?
> > 
> > 
> > Well one way would be:
> > 
> > 
> >  bitbake -C compile virtual/kernel <imagename>
> > 
> > 
> > (note the capital -C, not -c).
> 
> Hi, Paul. And thank you.
> Looks like the most relevant answer.
> IMO this "-C" flag is poorly documented. Thus if you don't know what it's
> doing, you can't figure out to use it.
> Only some info in maillists found
> by Google can give a clue what "--clear-stamp" is intended for. 

Right, that may well be the case.
 
> > In the near future "devtool modify" should support the kind of workflow
> > that it looks like you're attempting to get (where you want to modify
> > the kernel sources locally and then build them and/or incorporate them in
> > an image) - it already works well for non-kernel recipes.
> 
> I think this workflow is useful for many things, not only for workaround
> "-dirty", as in my case. It's not very convenient to wait for fetching
> sources every time you do some little modification.
> Why we need separate
> command i.e. "devtool modify" if we can go without it?

The assumption is that you wouldn't normally be fetching the source from a 
local path as you are, you would fetch it from some repository (though that 
repository may be internal to your organisation). At some point you run 
"devtool modify" which is effectively a way of saying "I want to start working 
on the source for this particular recipe in this location" - at which point 
either you're specifying an existing source checkout that you've prepared, or 
you specify -x and it prepares it for you. Having run that, the fetch/unpack 
tasks are disabled, and the specified external source tree will be used in the 
build. Additionally, that external source tree is yours to keep should you 
wish - it will never be deleted by the build system; the same *cannot* be said 
of the build system's temporary source checkout under tmp/work - your work in 
progress can be lost in an instant if you run -c clean or have rm_work 
enabled. There really are two different modes here - normal build, where you 
want the sources as anyone else building the system would fetch, and 
development, where you want your own sources that you are in control of.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre