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.guth...@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
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
