Image generation change

I'm having a problem after the recent change
commit eacedb4f2afa98dbd2f5ea7a9f52e6ea952a72d2
Author: Richard Purdie <[email protected]>
Date: Wed Feb 29 16:24:26 2012 +0000

image_types: Correctness fixes

* Add a newline to improve the output formatting
* Use set() to turn the list into a set of unique items to prevnt the same image code running twice (for e.g. IMAGE_FSTYPES = "tar.gz tar.bz2")
* Support multiple compression extensions such as ".gz.u-boot"
* Fix basetype/type typo and fix multiple image generation

Signed-off-by Richard Purdie <[email protected]>

I build initrd-style images which can be loaded by U-Boot. This is a multi-step process - first create the root image as ext3.gz, then pack it into the U-Boot image. Before this change, I could use this setup:

IMAGE_FSTYPES = "ext3.gz initrd"
IMAGE_CMD_initrd = " uboot_initrd;"
IMAGE_ROOTFS_SIZE = "24576"

where the 'uboot_initrd' command expected the ext3.gz image to be complete and all it does is the U-Boot mkimage magic.

This no longer works as when uboot_initrd() runs, there is no ext3.gz image yet built. I'm not sure I understand the exact reason, but if I revert just these lines, the process works again.

meta/classes/image_types.bbclass +1 -1

index 5b48a09..8ea170a 100644
@@ -29,7 +29,7 @@ def get_imagecmds(d):
      if d.getVar('IMAGE_LINK_NAME', True):
          cmds += "      rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.*"
 
-    for type in set(types):
+    for type in types:
          ccmd = []
          subimages = []
          localdata = bb.data.createCopy(d)

If there is another way to solve my problem, i.e. generate the wrapped up initrd image, that will still work with the code as is, I'd be happy to use it, but I'm not sure how to write such a process.

Any ideas gladly accepted, thanks

Quoted 44 lines · Gary Thomas

I'm having a problem after the recent change
commit eacedb4f2afa98dbd2f5ea7a9f52e6ea952a72d2
Author: Richard Purdie<[email protected]>
Date: Wed Feb 29 16:24:26 2012 +0000

image_types: Correctness fixes

* Add a newline to improve the output formatting
* Use set() to turn the list into a set of unique items to prevnt the same image code running twice (for e.g. IMAGE_FSTYPES = "tar.gz tar.bz2")
* Support multiple compression extensions such as ".gz.u-boot"
* Fix basetype/type typo and fix multiple image generation

Signed-off-by Richard Purdie<[email protected]>

I build initrd-style images which can be loaded by U-Boot. This is a multi-step process - first create the root image as ext3.gz, then pack it into the U-Boot image. Before this change, I could use this setup:

IMAGE_FSTYPES = "ext3.gz initrd"
IMAGE_CMD_initrd = " uboot_initrd;"
IMAGE_ROOTFS_SIZE = "24576"

where the 'uboot_initrd' command expected the ext3.gz image to be complete and all it does is the U-Boot mkimage magic.

This no longer works as when uboot_initrd() runs, there is no ext3.gz image yet built. I'm not sure I understand the exact reason, but if I revert just these lines, the process works again.

meta/classes/image_types.bbclass +1 -1

index 5b48a09..8ea170a 100644
@@ -29,7 +29,7 @@ def get_imagecmds(d):
       if d.getVar('IMAGE_LINK_NAME', True):
           cmds += "      rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.*"
 
-    for type in set(types):
+    for type in types:
           ccmd = []
           subimages = []
           localdata = bb.data.createCopy(d)

Quoted 5 lines

If there is another way to solve my problem, i.e. generate the wrapped up initrd image, that will still work with the code as is, I'd be happy to use it, but I'm not sure how to write such a process.

Any ideas gladly accepted, thanks

Does the patch "image_types.bbclass: We need to preserve order in the types variable and avoid set()" fix this problem?