[OE-core] [PATCH] bootimg-efi.py: Use IMGDEPLOYDIR instead of DEPLOY_DIR_IMAGE for initrd

Alejandro Hernandez alejandro.hernandez at linux.intel.com
Fri Jun 30 20:38:54 UTC 2017


Hey Patrick,


On 06/30/2017 01:43 PM, Patrick Ohly wrote:
> On Fri, 2017-06-30 at 10:53 -0700, Alejandro Hernandez wrote:
>> When using wic to create an image from a certain build, wic is expecting
>> to find initrd at the final destination of our images (DEPLOY_DIR_IMAGE),
>> which is wrong, since the initrd file has not been copied to the final
>> directory yet, so instead of trying to use an initrd file from
>> DEPLOY_DIR_IMAGE we get it from IMGDEPLOYDIR, which is the directory
>> where the resulting images are placed before their final destination,
>> and its where we can find the correct initrd file for our image.
> Can you give an example with some real image and initramfs recipe where
> this works? In other words, provide an example where the old behavior
> fails and the new one works?
Sure, so the problem comes when you add "wic" to IMAGE_FSTYPES (which is 
not default for core-image-minimal nor core-image-minimal-initramfs).
If you do this, do_image_wic will be executed automatically, and if it 
tries to use foo.cpio.gz file as initrd, it will fail to find it on
DEPLOY_DIR_IMAGE (unless a previous build was completed without 
executing do_image_wic) since this file is still on IMGDEPLOYDIR and hasnt
been copied to DEPLOY_DIR_IMAGE yet.

So a real example on real hardware:

if you build:
DISTRO="poky-tiny"
MACHINE="intel-corei7-64"
bitbake core-image-tiny-initramfs

You'll get an error stating that the foo.cpio.gz file cant be found.

I did a build for both core-image-minimal and 
core-image-minimal-initramfs and I dont see how theyre affected, the 
necessary files are
on IMGDEPLOYDIR in both cases as well.

>
> When using core-image-minimal and core-image-minimal-initramfs, then
> both have different IMGDEPLOYDIRs, therefore code in core-image-minimal
> can only find the .cpio.gz in the DEPLOY_DIR_IMAGE. So to me, the
> current approach seems correct.
>




More information about the Openembedded-core mailing list