Image generation change

Image generation change

[Gary Thomas]

I'm having a problem after the recent change
   commit eacedb4f2afa98dbd2f5ea7a9f52e6ea952a72d2
   Author: Richard Purdie <richard.purdie@linuxfoundation.org>
   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 <richard.purdie@linuxfoundation.org>

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.

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 5b48a09..8ea170a 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -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

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Image generation change

[Richard Purdie]

On Thu, 2012-03-01 at 18:19 -0700, Gary Thomas wrote:
> I'm having a problem after the recent change
>    commit eacedb4f2afa98dbd2f5ea7a9f52e6ea952a72d2
>    Author: Richard Purdie <richard.purdie@linuxfoundation.org>
>    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 <richard.purdie@linuxfoundation.org>
> 
> 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.
> 
> diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
> index 5b48a09..8ea170a 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -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

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

Cheers,

Richard

Re: Image generation change

[Gary Thomas]

On 2012-03-02 05:14, Richard Purdie wrote:
> On Thu, 2012-03-01 at 18:19 -0700, Gary Thomas wrote:
>> I'm having a problem after the recent change
>>     commit eacedb4f2afa98dbd2f5ea7a9f52e6ea952a72d2
>>     Author: Richard Purdie<richard.purdie@linuxfoundation.org>
>>     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<richard.purdie@linuxfoundation.org>
>>
>> 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.
>>
>> diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
>> index 5b48a09..8ea170a 100644
>> --- a/meta/classes/image_types.bbclass
>> +++ b/meta/classes/image_types.bbclass
>> @@ -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
>
> Does the patch "image_types.bbclass: We need to preserve order in the
> types variable and avoid set()" fix this problem?
>

Yes, this works great, thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------