Bug 11928 - When both cpio.gz and cpio.gz.u-boot are stated in IMAGE_FSTYPES the cpio.gz is finally deleted
Summary: When both cpio.gz and cpio.gz.u-boot are stated in IMAGE_FSTYPES the cpio.gz ...
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: 2.2
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 2.2.2
Assignee: Armin Kuster
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2017-08-14 14:48 UTC by Michal Vokáč
Modified: 2017-08-31 15:12 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Vokáč 2017-08-14 14:48:09 UTC 
From my understanding of the documentation it is expected that all image types stated in the IMAGE_FSTYPES variable are produced.

Lets imagine I went through these steps.

  1. I set up the recipe so that tar.bz2 and cpio.gz images are generated.

  IMAGE_FSTYPES = "tar.bz2 cpio.gz"
  inherit core-image

  The tar is just for development debugging and the cpio.gz is packed into
  a FIT image that goes into production.

  2. After some unspecified time a need arose to produce also
  the cpio.gz.u-boot image that can be loaded manually in U-Boot
  during development.

  I changed the recipe like this:

  IMAGE_FSTYPES = "tar.bz2 cpio.gz cpio.gz.u-boot"
  inherit core-image
  inherit image_types_uboot

Now the cpio.gz is deleted and only the tar.bz2 and cpio.gz.u-boot resides in deploy dir.
Comment 1 Tom Rini 2017-08-14 22:00:16 UTC 
This is further fallout from 46bc438374de (which is in morty) and is corrected by 0a7ce0b971a208956cb895ba5a869ec8c5d94703 from master.  This change would also be applicable to pyro.  The potential downside here is that there may be layers adding in custom IMAGE_CMD types that do a similar "clean" as the u-boot command was doing and would be broken by correcting the problem.
Comment 2 Armin Kuster 2017-08-17 15:38:23 UTC 
backported and pushed to stagging for next build.