[poky] kernel.release being regenerated

Richard Purdie richard.purdie at linuxfoundation.org
Wed Feb 11 01:10:57 PST 2015


On Wed, 2015-02-11 at 09:27 +0100, Holger Hans Peter Freyther wrote:
> On Tue, Feb 10, 2015 at 10:51:26PM +0000, Richard Purdie wrote:
> > Hi Holger,
> 
> Hi Richard,
> 
> > The fact the kernel.release is being recreated suggests something in the
> > configuration is changing (different environment or commandline
> > options?) or that there is a problem in your kernel to do with the
> > Makefiles and the dependencies of the kernel.release file.
> 
> This issue should be seen by everyone but the race is pretty small.
> do_shared_workdir must run shortly after compilemodules has started
> and removed the file but didn't create a new one. This is the kind
> of race I am more likely to hit than the average population. The
> "configuration is changing" part looks like a red herring to me.
> From looking at the Makefile I see a FORCE as dependency of the
> kernel.release rule. With my 3.10er kernel (and it doesn't look
> like we have patched the Makefile) the dependency chain is like
> this:
> 
>  init -> prepare -> prepare0 .. -> prepare3 -> kernel.release -> FORCE
> 
> This means that on any target being executed the kernel.release
> will be re-created. I think the only stable way would be to have
> do_compile copy the kernel.release to another place and have the
> copying task pick this file from another place.

This does sound like a flaw in how we're copying the file if it is
regenerated on each execution of make within the kernel build.

What puzzles me is that the use of kernel.release isn't new, the
previous do_install code used to do this and technically would have
raced with do_compilemodules too. So was it just bad luck you started
hitting this now?

(http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/kernel.bbclass?id=92725ad46f4d331bea6a2fa65964158d78a7add8)

As you say, if this really is getting regenerated as you describe, we'll
have to store a safe copy in the tree.

Cheers,

Richard



More information about the poky mailing list