linux/poky.git/meta/classes/image.bbclass, branch yocto-2.2.2

image: Fix "metadata is not deterministic" when chaining 2+ CONVERSION_CMDs

2017-08-29T15:50:54+00:00

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 (From OE-Core rev: a786b59a42e6b49229e2e0633728fd7b268438a9) Signed-off-by: Tom Rini Signed-off-by: Richard Purdie (cherry picked from commit 98a2afeb3a53bec7a72a4a9846e1dba636cc6f3d) Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

image.bbclass: Correct chaining compression support

2017-08-29T15:50:54+00:00

When chaining of compression/conversion types was added, we had a new way to handle doing things like "ext4.bz2.sha256sum" or "ext2.gz.u-boot". However, because the U-Boot image class isn't included normally, it wasn't properly converted at the time. After the support was added the "clean" argument that the .u-boot code uses no longer functions. The fix for this inadvertently broke chaining compression/conversion. First, correct the u-boot conversion code. Fixes: 46bc438374de ("image.bbclass: do exact match for rootfs type") Cc: Zhenhua Luo Cc: Richard Purdie Cc: Patrick Ohly (From OE-Core rev: e1546856890a438b5ea3763af3cdc13db8e8f236) Signed-off-by: Tom Rini Signed-off-by: Ross Burton Signed-off-by: Richard Purdie (cherry picked from commit 0a7ce0b971a208956cb895ba5a869ec8c5d94703) excluded lz4 and lzo chnages Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

Remove RM_OLD_IMAGE, it's no longer useful

2016-10-15T09:01:42+00:00

Since the move to put image deployment under sstate control in d54339d4b1a7e884de636f6325ca60409ebd95ff old images are automatically removed before a new image is deployed (the default behaviour of the sstate logic). RM_OLD_IMAGE is therefore no longer required to provide this behaviour, remove the variable and its users. (From OE-Core rev: 93631befe8b962bf99524746b49f4ebca336175c) Signed-off-by: Joshua Lock Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

image.bbclass: Make do_rootfs depend on PACKAGE_EXCLUDE_COMPLEMENTARY

2016-10-06T06:51:00+00:00

(From OE-Core rev: 7294c550eb3c7e31f8b80c7055aa84945c75c7f1) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

image.bbclass: add IMAGE_DEVICE_TABLE to rootfs[vardeps]

2016-09-15T11:15:07+00:00

IMAGE_DEVICE_TABLE and IMAGE_DEVICE_TABLES are both referenced by _create_devfs, therefore ensure that rootfs is rebuilt if changes are made to either variable. (From OE-Core rev: 06092cee0dc8c7cd2408ddfa9e9dc43fd9dfea2e) Signed-off-by: Andre McCurdy Signed-off-by: Richard Purdie

image.bbclass: also mask debugfs versions of masked images

2016-09-14T21:22:12+00:00

When IMAGE_GEN_DEBUGFS is enabled, and IMAGE_FSTYPES_DEBUGFS is left at its default (as suggested by local.conf.sample.extended), recipe parsing fails: bitbake kern-tools-native # or anything else for that matter ERROR: /meta/recipes-core/images/build-appliance-image_15.0.0.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'debugfs_vmdk' - possibly invalid type name or missing support class ERROR: Failed to parse recipe: /meta/recipes-core/images/build-appliance-image_15.0.0.bb Summary: There was 1 WARNING message shown. Summary: There were 2 ERROR messages shown, returning a non-zero exit code. i.e. bitbake doesn't even finish parsing... Since IMAGE_FSTYPES_DEBUGFS is based on IMAGE_FSTYPES, and since the build-appliance-image is setting IMAGE_FSTYPES to vmdk, image.bbclass/image_types.bbclass will be trying to build a debugfs_vmdk, causing the error, as this is not implemented. One solution to solving this problem could be as simple as adding a line IMAGE_FSTYPES_DEBUGFS_remove = "vmdk" to the build-appliance-image recipe, but that is very specific to the error encountered and carries the risk of the error being reintroduced in another recipe. Another solution could be to add 'debugfs_vmdk' to IMAGE_TYPES_MASKED in image-vm.bbclass, but again, this approach doesn't seem generic enough. None of the live and vm type images have an implementation for building a debugfs version, it doesn't seem to make sense to build debugfs versions of any of them anyway, and given IMAGE_TYPES_MASKED appears to be intended for those image types exclusively, it seems the right approach is to unconditionally also mask all debugfs_ flavours from IMAGE_TYPES_MASKED to achieve a generic solution. Do that so. (From OE-Core rev: 9bd682c4f1c19d68c573c11822888ee799809272) Signed-off-by: André Draszik Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

image.bbclass: do not check size of the debugfs image

2016-09-14T21:22:12+00:00

The debugfs is supposed to be used in addition to the normal image for debugging purposes, it doesn't make sense to artificially limit its maximum size. (From OE-Core rev: 7cdf3b2444df8cd322d9eff1bdbdc5adddcaf22a) Signed-off-by: André Draszik Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

meta: cleanup d.getVar(var, 0)

2016-09-14T21:22:07+00:00

(From OE-Core rev: 33b0d940b09a5ce1462476614213a58d3d62e80d) Signed-off-by: Robert Yang Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

image.bbclass: Put image_complete under sstate control

2016-09-03T23:07:28+00:00

Adding image_complete task should make sstate machinery to generate manifest for deployed images and do final deployment to DEPLOY_DIR_IMAGE. Made sure IMGDEPLOYDIR doesn't contain images from past deployments to prevent them to be included into sstate manifests. Set stamp-extra-info flag for do_image_complete task. This flag is used in the name of sstate manifest. Setting it to predetermined value for image_complete should help to get correct manifest filenames when processing runQueueTask events. (From OE-Core rev: d54339d4b1a7e884de636f6325ca60409ebd95ff) Signed-off-by: Ed Bartosh Signed-off-by: Richard Purdie

image: Deploy images to IMGDEPLOYDIR

2016-09-03T23:07:28+00:00

Changed deployment directory from DEPLOY_DIR_IMAGE to IMGDEPLOYDIR to make sstate machinery to do final deployment and generate manifest. Renamed variable deploy_dir to deploy_dir_image in selftest code to avoid confusion with DEPLOYDIR variable. Updated the code of rootfs.py:Rootfs class to use IMGDEPLOYDIR variable as it's now used as a new deployment destination. (From OE-Core rev: 6d969bacc718e21a5246d4da9bf9639dcae29b02) Signed-off-by: Ed Bartosh Signed-off-by: Richard Purdie