On 12/20/2017 05:51 PM, Richard Purdie wrote:
On Tue, 2017-12-19 at 15:54 -0500, Tom Rini wrote:
On Tue, Dec 19, 2017 at 12:11:48PM -0800, Saul Wold wrote:

We have seen more failures, but have not been able to directly
reproduce
it maybe svaing the rootfs and it contains some content that is
tripping
up the e2fsprogs mkfs.ext4 populate_rootfs() function

Signed-off-by: Saul Wold <s...@linux.intel.com>
---
  meta/classes/image_types.bbclass | 7 ++++++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image_types.bbclass
b/meta/classes/image_types.bbclass
index 9188bed4197..6b4f39ed274 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -86,9 +86,14 @@ oe_mkext234fs () {
        bbdebug 1 Executing "dd if=/dev/zero
of=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype
seek=$ROOTFS_SIZE count=$COUNT bs=1024"
        dd if=/dev/zero
of=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype
seek=$ROOTFS_SIZE count=$COUNT bs=1024
        bbdebug 1 "Actual Rootfs size:  `du -s ${IMAGE_ROOTFS}`"
-       bbdebug 1 "Actual Partion size: `ls -s
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype`"
+       bbdebug 1 "Actual Partion size: `ls -l
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype`"
        bbdebug 1 Executing "mkfs.$fstype -F $extra_imagecmd
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype -d
${IMAGE_ROOTFS}"
        mkfs.$fstype -F $extra_imagecmd
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype -d
${IMAGE_ROOTFS}
+       if [ $? -ne 0 ]; then
+               tmp_saved_rootfs=`mktemp -d -p /tmp
saved_rootfs.XXXXX`
+               cp -r ${IMAGE_ROOTFS} $tmp_saved_rootfs
+       fi
Wouldn't it be better to just fail on error here, rather than dump
stuff to /tmp ?

We have a problem with a recurring issue where the image generation
code is failing in the eSDK selftests. The eSDK selftests run a
completely separate build which then gets cleaned up. I'm not entirely
sure the best way to handle this but that is why Saul is proposing
this.

It may be an idea to detect the failing selftest and then stop the
cleanup in that case. That is going to be fairly invasive on the

+1 on this, the cleanup makes the debug very hard when error happens.

// Robert

selftest code though

I may just pull this into master-next (but not master) so at least if
it fails there we have better debugging. We are struggling to get to
the bottom of the issue :(.

Cheers,

Richard


--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to