[yocto] fitImage and initramfs

[Hamish Guthrie]

Hi Rick,

I found the cause of the problem, but I possibly still do not understand why this happens. It turns out that in fact two processes try to decompress the cpio.xxx file concurrently when building the fitImage. There is something similar which happens with tar - see this commit: 8c5f3454971074d3f1de7bcde9481e881221e076.

This patch fixes the issue

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index fa598cf..395973f 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -160,6 +160,7 @@ EXTRA_OEMAKE = " HOSTCC="${BUILD_CC}" HOSTCPP="${BUILD_CPP}""
 KERNEL_ALT_IMAGETYPE ??= ""

 copy_initramfs() {
+       set +e
        echo "Copying initramfs into ./usr ..."
        # In case the directory is not created yet from the first pass compile:
        mkdir -p ${B}/usr

- Hamish

 
On Wed, Dec 21, 2016 at 10:11 AM, Hamish Guthrie <Hamish.Guthrie at kistler.com> wrote:
Hi Rick,

>> What happens if you use core-image-minimal-initramfs for INITRAMFS_IMAGE? 

I just tried that and Yocto complains with Nothing PROVIDES 'core-image-minimal-initramfs'

>> I think the main problem is that you are telling Yocto to include the full rootfs image as an initramfs instead of the reduced, special-purpose initramfs image.

I am not sure that Yocto should give a damn about what I am trying to put into my initramfs, if I am stupid enough to include a 100G image into my initramfs, it is my problem, not Yocto's! If I am stupid enough to do that, knowing that I only have 256M RAM, I should be the one bitten!

I have tried doing the same thing with a special reduced filesystem for our update software (which is about 4M, by the way), and I get the same error with (Unexpected end of input), so I do not believe for a moment it is the size of the initramfs. I suspect something in the kernel.bbclass, but for the life of me I cannot see why it would fail. It should just WORK!

Hamish