[OE-core] [PATCH] image: Fix "metadata is not deterministic" when chaining 2+ CONVERSION_CMDs

[Tom Rini]

On Fri, Sep 15, 2017 at 09:41:36AM +0200, Martin Hundebøll wrote:
> 
> 
> On 2017-07-25 21:58, Tom Rini wrote:
> >When we have more than one CONVERSION_CMD being used, for example
> >ext4.gz.sha256sum we will see errors about "metadata is not
> >deterministic".  This is because we do not have a stable order of
> >intermediate files that will be removed in the generated shell command.
> >We fix this by calling sorted() on the set of rm_tmp_images so that we
> >will have a stable hash again.
> >
> >Cc: Patrick Ohly <patrick.ohly at intel.com>
> >Signed-off-by: Tom Rini <trini at konsulko.com>
> >---
> >  meta/classes/image.bbclass | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> >index b095bca..dee17ae 100644
> >--- a/meta/classes/image.bbclass
> >+++ b/meta/classes/image.bbclass
> >@@ -474,7 +474,7 @@ python () {
> >          # Clean up after applying all conversion commands. Some of them might
> >          # use the same input, therefore we cannot delete sooner without applying
> >          # some complex dependency analysis.
> >-        for image in rm_tmp_images:
> >+        for image in sorted(rm_tmp_images):
> >              cmds.append("\trm " + image)
> >          after = 'do_image'
> >
> 
> This commit has resulted in more or less persistent basehash issues
> for my cpio.gz.u-boot image:
> 
> ERROR: When reparsing /home/mnhu/projects/pil/yocto/meta-pil/recipes-filesystems/rescue-rootfs.bb.do_image_cpio,
> the basehash value changed from ac9907bbb8ee2ee6d9ca90f7a7e265f5 to
> 8c7b717add6b1d1ba6ff761ebfdedf01. The metadata is not deterministic
> and this needs to be fixed.
> 
> The error occurs repeatedly when doing `bitbake -c clean
> rescue-rootfs && bitbake rescue-rootfs`. Reverting the commit makes
> the error go away.
> 
> Also, the issue only appears for cpio.gz.u-boot image types, but not
> for cpio.gz
> 
> I am far from an expert in bitbake signature handling, so please let
> me know what to do, to debug this further.

Can you let me know what layers and machine I need to reproduce this?
I'll take a look, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170915/b50a068a/attachment-0002.sig>