[OE-core] Image generation change
Gary Thomas
gary at mlbassoc.com
Fri Mar 2 12:39:19 UTC 2012
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 at 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 at 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
------------------------------------------------------------
More information about the Openembedded-core
mailing list